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 17 of 19 FirstFirst ... 71516171819 LastLast
Results 161 to 170 of 184

Thread: Official feedback on OpenGL 4.0 thread

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

    Re: Official feedback on OpenGL 4.0 thread

    Quote Originally Posted by Alfonse Reinheart
    Is that how you render an object in different places? By changing a vertex attribute?
    Aaaahhhh... the things we've done before for speed, particularly pre-DrawInstanced.

    Quote Originally Posted by Groovounet
    (Re ARB_instanced_arrays) I don't think it actually changed. For each instance, the divised attributes start back at the beginning just like any attribute.
    I agree with your first sentence, but your second confused me. This is garden variety vertex stream frequency dividers back from 2006 (see this PDF starting at pg 31), forged from the D3D "Oh crap! Our batch calls are 'so' expensive!" realization.

    I believe the typical ARB_instanced_arrays use case works like this: vertex attributes can represent one of two things:
    1. those that "repeat" per instance (e.g. position, normal, texcoord0, etc.)
    2. those that are "constant" per instance (e.g. an offset vector in texcoord1, a rotation quaternion in texcoord2, etc.)
    On the latter set, you set glVertexAttribDivisor to 1.

    Think of the latter set as those values you'd store in a texture buffer and "look up" using gl_InstanceID with glDrawInstanced now. Let's call this "instance data".

    Seems to me, the nice thing about this approach is it streams the instance data to the GPU (a push) as needed along with the instance definition, rather than having every single vertex in every single instance of your object bang on 1-N texture fetches from some potentially random (from the GPU's perspective) piece of a texture buffer (a bunch of pulls, albeit cached). Also, this gets rid of the need for texture buffer subload and bind "state changes" between instancing batches using the same material. Not only that, with the instance data now in VBOs, you ideally can bypass the setup overhead using bindless (had to tie that back in somehow ) That said, I haven't actually done a performance face-off between ARB_draw_instanced and ARB_instanced_arrays yet.

  2. #162
    Super Moderator Frequent Contributor Groovounet's Avatar
    Join Date
    Jul 2004
    Posts
    934

    Re: Official feedback on OpenGL 4.0 thread

    I think instancing based on texture buffer and instancing based on attribute data (ARB_instanced_arrays) are complementary, the will perform best in different situation.

    The positive side of instancing based on attribute data, just like you said, that is removed texture fetch latencies. However, you can read a massive amount of data in texture buffer for no further cost where the number of attributes is quite limited. A single 4x4 matrix => 4 attributes already taken!

    Moreover, if you want to instantiate a group of geometry (no just one) they should have the same number of vertices or you need to add more per-instance data instead of reusing those... well, I am not just is could be a lot of data, so maybe not such a problem.

    I think ARB_instanced_arrays will perform better for scenarios with more instances with small per-instance data and ARB_draw_instanced + texture buffer will perform better for scenarios with fewer instances but large per-instance data. Finally, somewhere in the middle, ARB_draw_instanced + uniform buffer might be the best performer.

    A complet test would be nice but it's a complicated test to do which could be platform dependent...




  3. #163
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Official feedback on OpenGL 4.0 thread

    I agree with your first sentence, but your second confused me. This is garden variety vertex stream frequency dividers back from 2006 (see this PDF starting at pg 31), forged from the D3D "Oh crap! Our batch calls are 'so' expensive!" realization.
    ... I don't know why I thought it was different before. I seem to recall that this form of instancing was based on building a large index array, with multiple copies of the same indexes, one for each instance. And then you set some state such that certain attributes divide the index by a number to produce the index they use, while others take the mod of the index. Or something.

    I don't know where I got this idea from.

  4. #164
    Super Moderator Frequent Contributor Groovounet's Avatar
    Join Date
    Jul 2004
    Posts
    934

    Re: Official feedback on OpenGL 4.0 thread

    Quote Originally Posted by Alfonse Reinheart
    I agree with your first sentence, but your second confused me. This is garden variety vertex stream frequency dividers back from 2006 (see this PDF starting at pg 31), forged from the D3D "Oh crap! Our batch calls are 'so' expensive!" realization.
    ... I don't know why I thought it was different before. I seem to recall that this form of instancing was based on building a large index array, with multiple copies of the same indexes, one for each instance. And then you set some state such that certain attributes divide the index by a number to produce the index they use, while others take the mod of the index. Or something.

    I don't know where I got this idea from.
    Probably from the billions of topics dealing about this on OpenGL forums!

  5. #165
    Member Regular Contributor
    Join Date
    Nov 2003
    Location
    Germany
    Posts
    293

    Re: Official feedback on OpenGL 4.0 thread

    I think the glext.h and gl3.h header files are missing some tokens and entry points. I noticed that for OpenGL 3.3 the GL_ARB_instanced_arrays definitions are missing (the ARB extension entries are there using the ARB suffix).

    Under the GL_VERSION_4_0 function pointer definitions references to GL_ARB_draw_indirect, ARB_draw_buffers_blend, GL_ARB_sample_shading, GL_ARB_texture_cube_map_array and GL_ARB_texture_gather are missing.

    Also, the gl3.h header file contains immediate mode entry points for the ARB_vertex_type_2_10_10_10_rev extension. This file should only contain entry points for core profile OpenGL.

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

    Re: Official feedback on OpenGL 4.0 thread

    That's because these are also missing from the .spec files.

    I'm happy that the ARB is getting much more proactive about advancing OpenGL, but you guys really need to do something about the errors in the .spec files in the initial releases.

  7. #167
    Super Moderator Frequent Contributor Groovounet's Avatar
    Join Date
    Jul 2004
    Posts
    934

    Re: Official feedback on OpenGL 4.0 thread


  8. #168
    Member Regular Contributor
    Join Date
    Apr 2006
    Location
    Irvine CA
    Posts
    299

    Re: Official feedback on OpenGL 4.0 thread

    Quote Originally Posted by Alfonse Reinheart
    That's because these are also missing from the .spec files.

    I'm happy that the ARB is getting much more proactive about advancing OpenGL, but you guys really need to do something about the errors in the .spec files in the initial releases.
    It's a trade off isn't it...

  9. #169
    Super Moderator Frequent Contributor Groovounet's Avatar
    Join Date
    Jul 2004
    Posts
    934

    Re: Official feedback on OpenGL 4.0 thread

    Agreed with you Rob and I think it's a good trade off.

    Anyway, let's be realist, OpenGL 4 and even OpenGL 3 aren't widely adopted. OpenGL 4 remains "for us" so quite a few people that can handle these issues.

    To have OpenGL 3.X widely adopted, we would need first "reference pages".

    Obviously a perfect world would be great.

  10. #170
    Member Regular Contributor
    Join Date
    Oct 2006
    Posts
    352

    Re: Official feedback on OpenGL 4.0 thread

    Nice review/summary, Groovounet.

    If I may suggest, filing a bug report is the quickest way to get the specs fixed. The specs are large and complex beasts and bugs are bound to pass through. It only takes 5 minutes to report such bugs, but those 5 minutes could save someone a large amount of time down the road.
    [The Open Toolkit library: C# OpenGL 4.4, OpenGL ES 3.1, OpenAL 1.1 for Mono/.Net]

Posting Permissions

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