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 2 of 2 FirstFirst 12
Results 11 to 16 of 16

Thread: VAO: Performance questions

  1. #11
    Junior Member Regular Contributor
    Join Date
    Nov 2012
    Location
    Bremen, Germany
    Posts
    149
    "such" as in referring to the pieces of state that are related to the definition of data. I would not be sure that a buffer-binding would fall into that category for itself - only in conjunction with a pointer.

  2. #12
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    I would not be sure that a buffer-binding would fall into that category for itself
    Even ignoring the fact that OpenGL doesn't consider any particular state to be different or special from any other particular state, the text did specifically except GL_ARRAY_BUFFER_BINDING from VAOs, and it specifically did not except GL_ELEMENT_ARRAY_BUFFER_BINDING from them. So if the ARB's intent was that they didn't want the element array buffer to be part of the VAO, they would have said so.

    Give it up already. It's part of the VAO's state, and it's right there in black and white. And if you want more proof, GL 3.0 lays it out even more clearly, as the state tables 6.6-6.9 are named, "Vertex Array Object State", and GL_ARRAY_BUFFER_BINDING is explicitly moved to 6.10, named "Vertex Array Data (not in Vertex Array Objects)".

    Any ambiguity is what you've read into it, not what's in the text. Looking at the revision history of ARB_VAO, you may have simply been remember an earlier, more ambiguous version of the text, as it seems to have changed a bit since the original release.

  3. #13
    Junior Member Regular Contributor
    Join Date
    Nov 2012
    Location
    Bremen, Germany
    Posts
    149
    All state related to the definition of data used by the vertex processor is encapsulated in a vertex array object.
    You know what data used by the vertex processor is?

  4. #14
    Intern Contributor
    Join Date
    Oct 2011
    Posts
    57
    Quote Originally Posted by Alfonse Reinheart View Post
    The wiki, by and large, describes only the behavior of the core profile. If you're using the compatibility profile, you won't get that behavior. Or if you're using NVIDIA drivers from a year or two back.

    As to the main thrust of the OP, the performance characteristics of VAOs are generally unknown. There have been, to my knowledge, no recent, detailed performance analyses of the use of VAOs against non-VAO rendering across multiple hardware vendors. Valve did some tests, saying that VAOs weren't helping them, but it's not clear what their specific rendering circumstances were. And of course, the (relatively) new ARB_vertex_attrib_binding extension could have effects on top of VAOs or without them.

    At the end of the day, if performance really matters to you, you're going to have to profile it yourself.
    So if there's truly no good insight about VAO performance in general I suppose it's safe to assume that there's even less information on the effects of changing a VAO's state, performance wise.

    My intention was to probe my options to see if I was unaware of some known performance issue with this approach (changing VAO state in a critical section of the rendering loop), but I guess I'll have to do my own testing to see how it behaves with my own real world problem. I'm expecting however that the implementation I'll be doing to compare to the current one (i.e., single VAO with single IBO and IBO start / count values stored on nodes and rendered with glMultiDraw*) is going to be better performing regardless of the effects of IBO switching, but I guess that will give me an idea of its impact, if ever I require to do this again.

    Thanks for the feedback everyone.

  5. #15
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    Quote Originally Posted by hlewin View Post
    You know what data used by the vertex processor is?
    Why do you keep pointing to these irrelevant passages? I pointed to the one that matters: the one that lists every piece of state that the VAO contains. That's the one that matters because that's the one that actually lists every piece of state the VAO contains. It doesn't use wiggle language like "vertex processor" or other general terms. It explicitly lists that state which is encompassed by the object. The VAO contains the state used in 6.6, 6.7, and 6.8, minus the exceptions. Period.

    Indeed, this is how every standard OpenGL object is defined in the spec. There's a "general description" of it, followed by a description of the glBind* command. And it is in the description of the glBind* command where you get the actual normative definition of the state vector: a link to the table(s) that specify exactly what state is in the object. This is consistently how objects are defined.

    For example, sampler objects have this line:

    Additionally, a sampler object may be created to encapsulate only the second category - the sampling state – of a texture object.
    "the sampling state" is not a well-defined concept. Which is fine, because it is followed up on by this line:

    When a sampler object is first used in one of these functions, the resulting sampler object is initialized with a new state vector, comprising all the state and with the same initial values listed in table 23.18.
    This is the one that actually defines what state is used, because it actually lists the specific OpenGL state the object stores.

    Also, there's no definition in the OpenGL 2.1 specification of "vertex processor". So that statement's normative value is pretty much nil. Indeed, that silly sentence has managed to survive through GL 4.4, and there's still no definition of "vertex processor". Indeed, it's the only place in either the core or compatibility spec that uses that term.

  6. #16
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    Quote Originally Posted by Alfonse
    the performance characteristics of VAOs are generally unknown.
    And that's a darn shame. We really should come up with a performance test suite. If only it weren't for all that work ...

    Quote Originally Posted by Ed Daenar
    this is being implemented as a single VAO with the attached VBOs that contain the mesh information and an IBO with the whole index that would allow to draw the whole mesh
    Since this is often misunderstood: the VBO isn't attached to the VAO, i.e. ARRAY_BUFFER_BINDING isn't VAO state! The only direct association of VAOs and buffer objects is through the ELEMENT_ARRAY_BUFFER_BINDING. The vertex arrays (i.e. the stuff you setup with glVertexAttribPointer), however, are associated with the array buffer binding that is currently set when glVertexAttribPointer is called. That's how you get the connection between VAOs and VBOs. The corresponding state variable is VERTEX_ATTRIB_ARRAY_BUFFER_BINDING. Although probably not that common, you can have multiple vertex arrays associated with different VBOs in a single VAO and switch between them by enabling and disabling the arrays.

    Quote Originally Posted by Ed Daenar
    I'm expecting [..]
    With no substantial empirical data existing in regards to GL performance, you can't really expect anything. Your safe bet is: implement multiple algorithms that produce the same output and measure the performance. Then decide.
    Last edited by thokra; 07-29-2013 at 02:45 AM.

Posting Permissions

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