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 172 of 173 FirstFirst ... 72122162170171172173 LastLast
Results 1,711 to 1,720 of 1724

Thread: OpenGL 3 Updates

  1. #1711
    Senior Member OpenGL Guru
    Join Date
    Dec 2000
    Location
    Reutlingen, Germany
    Posts
    2,042

    Re: OpenGL 3 Updates

    I really don't bother much about such minor details


    What i do bother about VERY MUCH: OpenGL has become a major pain in the ass regarding vertex attributes and i wonder, whether there is anything in the pipeline to remedy this (though i fear, if at all, it will become worse).

    Back in "the days", if i wanted to render something, i set a glVertexPointer, glNormalPointer and glTexCoordPointers. In the shaders i simply used the built in variables (gl_Normal, gl_MultiTexCoord*) and it was mostly fine.

    Well, glTexCoordPointer is deprecated, and anyway i have int-attributes and other stuff, such that i prefer to use generic vertex attributes.

    The problem with these is, i need to query the CURRENT shader, which bind-point a certain attribute is attached to. That actually means, that every time that i change a shader, i would need to reevaluate where to bind my vertex-arrays to. Some shader might not use one of the available attributes, such that some bind points change.

    That means there is for every shader/vertex-buffer combination a certain attribute mapping. Sure, i CAN handle this, i can even make this "fast", using VAOs (though they seem to be buggy yet, and not speed up anything) which i store for every such combination.

    But only because it's possible, doesn't mean it's not awkward...

    What i would really like to do, is simply to tell the API "here is my shader" and "here is a VBO that consists of the attribute arrays 'position', 'texcoord', 'tangent' and 'whatever'" and have the driver sort out any mappings internally. Just instead of "glGetAttibLocation ('bla') glBindAttibute (location, ..)" (at EACH shader switch) i'd rather say ONCE "glBindAttributeByName ('bla', ..)" and have the driver take care for the rest, until i deactivate the array again.


    But i fear i have to implement such an abstraction myself someday.

    Jan.
    GLIM - Immediate Mode Emulation for GL3

  2. #1712
    Advanced Member Frequent Contributor
    Join Date
    Apr 2003
    Posts
    661

    Re: OpenGL 3 Updates

    Why don't you use your own fixed scheme of (semantic) attribute stream to attribute location? You can enforce this using glBindAttribLocationARB().

  3. #1713
    Senior Member OpenGL Guru
    Join Date
    Dec 2000
    Location
    Reutlingen, Germany
    Posts
    2,042

    Re: OpenGL 3 Updates

    Hm, didn't know about that function. Well, it is a start. But if i see this right, i need to have the mapping for all attributes that i will ever use fixed before i link any shader, that uses it. So this one looks like the complete opposite of what i am doing right now. It just replaced one inconvenience with another. I will have to think about this a bit more. But thanks for the info.

    Jan.
    GLIM - Immediate Mode Emulation for GL3

  4. #1714
    Member Regular Contributor
    Join Date
    Oct 2006
    Posts
    352

    Re: OpenGL 3 Updates

    I have created an abstraction that works exactly like Jan's proposal. Since this is C# code, it is possible to use reflection and discover the mapping automatically at runtime, i.e. if the shader has a 'Position' attribute and the VBO has a 'Position' field, they will be bound automatically.

    I would very much like to see something like "glBindAttributeByName" in a future OpenGL version. Both current methods (query locations on every shader change or use fixed locations only) are problematic, awkward to use and suboptimal.
    [The Open Toolkit library: C# OpenGL 4.4, OpenGL ES 3.1, OpenAL 1.1 for Mono/.Net]

  5. #1715
    Junior Member Regular Contributor
    Join Date
    Mar 2007
    Location
    Latvia
    Posts
    225

    Re: OpenGL 3 Updates

    Stephen A: you don't need to query locations on every shader change. Do it only when linking occurs. Vertex attributes change locations only on shader linking.

  6. #1716
    Senior Member OpenGL Pro
    Join Date
    Sep 2004
    Location
    Prombaatu
    Posts
    1,386

    Re: OpenGL 3 Updates

    Any chance of getting an unofficial preview of what's in store for 3.2?

  7. #1717
    Member Regular Contributor
    Join Date
    Oct 2006
    Posts
    352

    Re: OpenGL 3 Updates

    Quote Originally Posted by martinsm
    Stephen A: you don't need to query locations on every shader change. Do it only when linking occurs. Vertex attributes change locations only on shader linking.
    Never claimed otherwise

    I build a map of attributes when each shader is linked, then create (a cached) map of attributes for each VBO. On rendering, I use these maps to bind the correct locations.

    If you think about it, this is a roundabout way of binding attributes: The driver knows the attribute names (you can query them) and also knows the attribute indices (you can also query them). Shadowing this information in the aforementioned maps is not optimal; it would be simple to expose a glBindAttributeByName and avoid this overhead, both in code and in memory.

    Also note that this trick is all but impossible to pull off in metadata-poor C or even C++. You are more or less forced to use fixed attribute locations, which are a performance minefield.
    [The Open Toolkit library: C# OpenGL 4.4, OpenGL ES 3.1, OpenAL 1.1 for Mono/.Net]

  8. #1718
    Advanced Member Frequent Contributor
    Join Date
    Apr 2003
    Posts
    661

    Re: OpenGL 3 Updates

    ...and having the driver to do a string-lookup every time you do a glAttribPointer("my_attribute", ...) call is not a performance minefield? And in which way are fixed attribute locations a performance minefield? The only "problem" they provide is that you may have more _possible_ streams than available attribute slots. But this simply boils down to the finding that you don't want to bind them all at once anyway. You can allow some kind of "aliasing", between attributes that are unlikely to be used together, in your own fixed scheme.

    Btw, we're getting slightly off-topc ;-)

  9. #1719
    Member Regular Contributor
    Join Date
    Oct 2006
    Posts
    352

    Re: OpenGL 3 Updates

    The driver already maintains a hashtable of attribute names <-> locations, so I don't see how this is a performance minefield.

    When you force your own, fixed attribute locations, you may be putting the driver out of the fast path. Check out this (under the custom vertex attributes section) and this.

    The following quote from the second link is especially damning:
    It is possible to assign the same location to multiple attributes. This process is known as aliasing, and is only allowed if just one of the aliased attributes is active in the executable program. HOWEVER the implementation is not required to check for aliasing and is free to employ optimizations that only work in the abscence of aliasing.
    That's the definition of a minefield.

    [The Open Toolkit library: C# OpenGL 4.4, OpenGL ES 3.1, OpenAL 1.1 for Mono/.Net]

  10. #1720
    Senior Member OpenGL Pro
    Join Date
    Sep 2004
    Location
    Prombaatu
    Posts
    1,386

    Re: OpenGL 3 Updates

    Fortunately for me I only use 1 or maybe 2 vertex formats tops for everything (but then I don't have to deal with anything but my little world).

Posting Permissions

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