PDA

View Full Version : EXT_direct_state_access & ARB_vertex_array_object



Leith Bade
02-02-2011, 08:08 PM
I have today discovered the awesomeness of EXT_direct_state_access, and decided to rewrite my program using C++ objects to wrap the GL objects (so my code is nice, clean, and simple).

But I have hit a problem with the ARB_vertex_array_object. DSA has a bunch of functions for VAOs... but those functions are missing from the Khronos glext.h!

First two things:
1 - Why are they missing? Did the glext.h guy not notice that NVIDIA added some stuff in the DSA 1.1 update?
2 - How do I fix this? Bug report? Roll my own glext.h? Just stuff the functions in my header?

And last (not related to VAOs, just DSA):
Is there a DSA function/extension for glDrawElements? It seems silly to still have to bind to GL_ELEMENTS_ARRAY_BUFFER now that I dont use GL_ARRAY_BUFFER...

I just want to do glDrawElements(buffer, ...)

Alfonse Reinheart
02-02-2011, 08:41 PM
decided to rewrite my program using C++ objects to wrap the GL objects (so my code is nice, clean, and simple).

Woah. Slow down there. Wrapping GL objects in C++ objects is not a minor thing, and you shouldn't do it without being very careful of what you're doing.


Why are they missing? Did the glext.h guy not notice that NVIDIA added some stuff in the DSA 1.1 update?

Probably. The .spec files that define everything have the extra functions in them, but somehow glext.h didn't get updated.


How do I fix this? Bug report? Roll my own glext.h? Just stuff the functions in my header?

Well, a bug report is not going to cause it to be fixed today. And making your own glExt.h is entirely possible. Or you could use an extension loading library.


Is there a DSA function/extension for glDrawElements? It seems silly to still have to bind to GL_ELEMENTS_ARRAY_BUFFER now that I dont use GL_ARRAY_BUFFER...

No. This may sound silly, considering just how many functions DSA has, but that would mean adding a new function for every variant of glDrawElements.

Also, the point of DSA is to remove "bind to modify" actions. You can fill the element buffer just fine without binding it. You could use the same logic to say that you should be able to specify the program you want to use in glDrawElements. And the textures. And UBOs. And FBO that you are drawing to.

Bind to render isn't going anywhere. It's just removing "bind to modify".

Leith Bade
02-02-2011, 09:09 PM
Wrapping GL objects in C++ objects is not a minor thing, and you shouldn't do it without being very careful of what you're doing.

What do you mean? What should I be careful of?


Or you could use an extension loading library.

Thanks, I just added GLEW and it works fine now. Was sorta a hoping to avoid GLEW. I am on Linux so I can (normally) just link directly to all the functions exported by NVIDIA's libGL. I tried adding the functions as extern to my own headers but for some reason NVIDIA don't export the newer functions (but it works with GLEW), so I guess NVIDIA driver team also rely on glext.h being up to date.


Well, a bug report is not going to cause it to be fixed today.

EDIT:
I realise this (taking note of how many 'stale' bugs there are in the public bugzilla) but I'll add one more to their pile anyway. I just found this (http://www.khronos.org/bugzilla/show_bug.cgi?id=357) bug *smashes head*, guess Ill have to wait for the wheels to turn slowly at Khronos.


Bind to render isn't going anywhere. It's just removing "bind to modify".

I see the logic in that.
I had a peek at Direct3D 10's API and they seem to bind the index buffer with ID3D10Device::IASetIndexBuffer. But it is also interesting to see that they separate vertex buffers (ID3D10Device::IASetVertexBuffers) from the 'input layout' (ID3D10Device::IASetInputLayout).
Is there a good reason OpenGL mashes both VBOs and 'input layout' into the VAOs?

Finally, I was looking at NV_vertex_buffer_unified_memory. Is this extension any good/useful? I note that for some odd reason VertexAttribFormatNV uses bind to modify and not DSA even though DSA was released before this extension *smashes head*.

Alfonse Reinheart
02-02-2011, 10:29 PM
What do you mean? What should I be careful of?

Constructors getting called before OpenGL is created, destructors getting called after OpenGL is destroyed. That sort of thing.

Also, a lot of times, you're going to want to add higher-level features than what the OpenGL objects provide. Indeed, unless you do provide such features (or provide a rendering abstraction), there isn't much functional difference between raw use of OpenGL and object-wrapped classes. Things like supporting several buffer object streaming paradigms encapsulated in a single class, or having a uniform buffer abstraction and so forth.


Is there a good reason OpenGL mashes both VBOs and 'input layout' into the VAOs?

Like most things in OpenGL, it probably falls under the "It seemed like a good idea at the time," rubric Though the etymology of VAO goes through Apple, so it may just be it's what Apple thought was a good idea at the time.


Finally, I was looking at NV_vertex_buffer_unified_memory. Is this extension any good/useful?

To the extent that you're willing to limit yourself to NVIDIA hardware, yes. Though it's primary reason for existence is performance.


I note that for some odd reason VertexAttribFormatNV uses bind to modify and not DSA even though DSA was released before this extension *smashes head*.

To be fair, I don't think NVIDIA cares much for using VAOs to change between what objects get rendered. Their core OpenGL implementations still allow you to write rendering code that doesn't use VAOs at all, in violation of the specification.

Leith Bade
02-03-2011, 03:08 AM
To the extent that you're willing to limit yourself to NVIDIA hardware, yes. Though it's primary reason for existence is performance.

To be fair, I don't think NVIDIA cares much for using VAOs to change between what objects get rendered. Their core OpenGL implementations still allow you to write rendering code that doesn't use VAOs at all, in violation of the specification.

The program I am working on will run on NVIDIA only servers so any NVIDIA extension or hack that improves performance is fine.

I will do some testing with that NVIDIA extension to see how well it works. The program uploads fresh vertexes for each frame so it might not work as fast as they say it can though.

While we are on NVIDIA:
Is it possible to get two OpenGL contexts and render jobs running simultaneously on the same device? The Fermi chips can do this with CUDA kernels (using separate streams), so the hardware is capable of it. (Even if it only works on Tesla or Quadro cards - or maybe that Tesla/Quadro C2070Q)

Groovounet
02-03-2011, 03:50 AM
If you are interested in DSA, I think you need to have a look at the issues of DSAs:

http://www.g-truc.net/post-0363.html#menu

You will realized that you can't use DSA for 100% of the cases which is really annoying because conceptual DSA are just great!

"Bindless graphics", http://developer.nvidia.com/object/bindless_graphics.html, is definitely a great option if you are running on nVidia only.