Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 42

Thread: VBO to VAO

  1. #21
    Member Regular Contributor
    Join Date
    May 2001
    Posts
    348

    Re: re: VBO to VAO

    Quote Originally Posted by Dark Photon
    Interesting. Are you sure about that? In the extension spec, I don't find mention of an ELEMENT_ARRAY bind point being stored in the VAO. Did I miss it?
    (Fixed the link) The extension spec says that a VAO contains all state in tables 6.6, 6.7, and 6.8 of the OpenGL 2.1 spec, minus GL_CLIENT_ACTIVE_TEXTURE. This does include GL_ELEMENT_ARRAY_BUFFER_BINDING.

    Curiously, it also includes GL_ARRAY_BUFFER_BINDING, which the 3.1 spec explicitly excludes from VAOs (see table 6.5). So there is a slight difference between the extension and 3.1 core.


    Quote Originally Posted by skynet
    All these speculations, doubts, the reported neglible (if at all) performance advantage, the limited application possibilities and weird usage make me wonder, why VAO has been promoted to core so quickly and un-asked for.

    Why hasn't it been availble as extension before to prove its usefulness? FBO has shown that this is a way which works. Now we have something in the core that nobody wanted this way, but will stay for a long time.
    The speculations and doubts could be reduced a lot if people tried to actually read the spec. VAOs are really not complicated at all, and I don't know what you think is weird about simply taking a bunch of context state and putting it into a separate state object. It's been done before with texture objects.

    What makes you think nobody wanted it this way?

  2. #22
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: re: VBO to VAO

    All these speculations, doubts, the reported neglible (if at all) performance advantage, the limited application possibilities and weird usage make me wonder, why VAO has been promoted to core so quickly and un-asked for.
    Nothing you have stated here is true, save perhaps for the performance advantage. Performance is naturally the pervue of the hardware makers. They will optimize VAO when they feel like devoting resources towards doing so.

    GL 3.0 is only 9 months old.

    Any of the "speculation" and "doubts" you are hearing is due to unfamiliarity with the extension. Its function is explicitly laid down in the specification. VBOs had a similar journey; it took a long time before people understood how binding a buffer object for rendering worked.

    Why hasn't it been availble as extension before to prove its usefulness?
    VAO was adapted from an Apple extensions. Coincidentally called APPLE_Vertex_Array_Object.

  3. #23
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    3,209

    Re: re: VBO to VAO

    Quote Originally Posted by Xmas
    (Fixed the link) The extension spec says that a VAO contains all state in tables 6.6, 6.7, and 6.8 of the OpenGL 2.1 spec, minus GL_CLIENT_ACTIVE_TEXTURE. This does include GL_ELEMENT_ARRAY_BUFFER_BINDING.
    Thanks for the correction. Sorry I missed that.

    So (to correct myself) it seems that a minimalist example for how VAOs would be used if you only needed to swap a texture and change vertex array and index array bindings between batches would be:

    Code :
      glBindTexture
      glBindVertexArray
      glDrawRangeElements
      ...
      glBindTexture
      glBindVertexArray
      glDrawRangeElements
      ...

    (after the VAOs have been built of course).

    ...which might explain why I didn't see a perf boost when I tried this before. Similar to how you often don't see a perf boost with VBOs unless everything's a VBO. I'll have to go back and retest that later...

  4. #24
    Member Regular Contributor
    Join Date
    May 2001
    Posts
    348

    Re: re: VBO to VAO

    You probably shouldn't expect a huge performance boost, as you mostly save a few state-changing calls. Unlike using VBOs, where you actually avoid a copy of all vertex data used in a draw call.

    But VAOs (and state objects in general) make working with OpenGL more convenient and less error-prone IMO.

  5. #25
    Advanced Member Frequent Contributor
    Join Date
    Apr 2003
    Posts
    664

    Re: re: VBO to VAO

    Nothing you have stated here is true, save perhaps for the performance advantage.
    I'll try to explain.
    1. The extension spec language for VAO is not very clear. The _main_ purpose is 'hidden' in the one small sentence: "BindVertexArray may also be used to bind an existing vertex array object." There would be less discussion going on here, if the spec was more explicit and elaborate at this point.

    2. I see the limitation in application mainly in the fact that it only supports static attribute/index data. There is no way to change a VAO after it has been created (err, first bound). I don't know if constantly creating/destroying VAOs is recommended performance wise (in the sense of streaming geometry from disk and dynamically placing them in larger VBOs). I would have liked to see a separation of vertex attribute format/layout and position inside a VBO.

    3. The 'weird usage' refers to the fact that a single function does both, storing and restoring state _depending on how often it gets called_ I would have liked to see two separate functions here. The current method resembles GL_COMPILE_AND_EXECUTE for display lists, which has been discouraged to use for a very long time now. Separation of store/restore would also enable to change a VAO several times.

    4. It might be true that VAO had a predecessor as APPLE extension. I don't have access to Macs, so Mac-only extensions are practically non-existent to me. Neither I heard any "success stories" about APPLE_vao in these forums.

    I don't criticize the fact that there are efforts to make GL faster and better. I just wonder, how quick and unreflected some extensions went straight into core, while others like EXT_texture_filter_anisotropic seem to starve to death.

  6. #26
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: re: VBO to VAO

    There would be less discussion going on here, if the spec was more explicit and elaborate at this point.
    Specifications are meant for those persons implementing the specification. They are not meant for users of the specification.

    While specifications are the only form of real documentation that OpenGL users get, this is not the intended situation.

    There is no way to change a VAO after it has been created (err, first bound).
    There is no such thing as an immutable OpenGL object. You may modify a VAO as much as you wish.

    The 'weird usage' refers to the fact that a single function does both, storing and restoring state _depending on how often it gets called_
    Your statement suggests that you do not know how VAOs work. Or that you do not understand how OpenGL objects in general work.

    Every OpenGL object is defined in terms of a set of context state data. Binding an object is the equivalent of copying the state stored in the object to the context. This is true for every OpenGL object and every binding action.

    The behavior of buffer objects and VAO are not dependent on how often either one gets called.

    It might be true that VAO had a predecessor as APPLE extension.
    It is true; your awareness of its existence being irrelevant to that truth. The VAO specification was even designed to use the same enumerators, so that there would be compatibility at some level between the two.

    Neither I heard any "success stories" about APPLE_vao in these forums.
    APPLE_Vertex_Array_Object is 7 years old. That you have neither heard of it nor heard of any "success stories" is again irrelevant.

    I just wonder, how quick and unreflected some extensions went straight into core, while others like EXT_texture_filter_anisotropic seem to starve to death.
    I have never understood this issue with what happens to be core vs. what is an extension. EXT_texture_filter_anisotropic is more widely implemented than GL 3.0. For practical purposes, you can assume it exists. For comparison, you have to ask for GL 3.0.

    A feature being an extension does not mean it is not widely supported, used, or tested. Similarly, a feature being core does not mean that implementations of it are mature or as fast as they could be. VAO being the best example of this.

  7. #27
    Advanced Member Frequent Contributor
    Join Date
    Apr 2003
    Posts
    664

    Re: re: VBO to VAO

    While specifications are the only form of real documentation that OpenGL users get, this is not the intended situation.
    Intended or not, most of the time it is the only source of information.
    Your statement suggests that you do not know how VAOs work.
    Indeed. I just realized minutes ago :-) Thanks!
    A feature being an extension does not mean it is not widely supported, used, or tested. Similarly, a feature being core does not mean that implementations of it are mature or as fast as they could be. VAO being the best example of this.
    In the strict sense, extensions are optional. You can leave them out and still have a compliant implementation. Why do you think that core features do not need maturity? IMHO maturity and usefulness should be the number one reasons why a feature is _promoted to core_ at all.

  8. #28
    Member Regular Contributor
    Join Date
    May 2001
    Posts
    348

    Re: re: VBO to VAO

    Do you think VAOs are not mature or not useful, and if so, why?

  9. #29
    Advanced Member Frequent Contributor
    Join Date
    Apr 2003
    Posts
    664

    Re: re: VBO to VAO

    The comment on maturity was not especially directed at VAO.
    A good example of "how its supposed to be" is EXT_fbo. When it came out, the community was asked if it should go to core. The community said no, leave us some time to evaluate. With time, a set of new extensions came out, enhancing FBOs and lifting many restrictions. FBOs matured and culminated into ARB_fbo, which is now in core.
    The whole process probably should have taken 2 years less, of course ;-)

  10. #30
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: re: VBO to VAO

    The community said no, leave us some time to evaluate.
    The community said "no," because EXT_FBO was not finished. There was missing functionality in the extension as written. It did not go into the core because it was not ready to be core.

    The version that was eventually adopted into the core was much more complete.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •