Official feedback on OpenGL 4.0 thread

[Dark Photon]

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.

(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.

[Groovounet]

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...

[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.

[Groovounet]

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!

[Chris Lux]

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.

[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.

[Groovounet]

My OpenGL 4.0 review

[Rob Barris]

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...

[Groovounet]

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.

[Stephen A]

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.