Vertex Buffer Object / Vertex Array Range / Vertex Array Object

Started by
3 comments, last by Danny02 13 years, 9 months ago
Hi, this is my first time programming in opengl. I have always used direct3D and dx11. I would like to know under what general situation should I use Vertex Buffer Objects, Vertex Array Range or Vertex Array Object.

From what my understanding, I assume Vertex Buffer Object is similar to DX11 ID3D11Buffer. What about Vertex Array Range and Vertex Array Object?? And how are these compared to display list??

Am I right to say that contents that are created in display list are fixed and non changeable??

And lastly I read that pbuffers are legend and should not be used (in place of frame buffer objects)?? why is that so??

thank you
Advertisement
Quote:Original post by littlekid
I would like to know under what general situation should I use Vertex Buffer Objects, Vertex Array Range or Vertex Array Object.

Wenever you want to draw something you should use Vertex Buffer Objects (VBOs). Vertex Arrays (VA) are predecessors of VBOs and keep data always on the client side (read: in system memory), so every drawing requires to transfer the whole buffers to GPU's memory. Vertex Array Objects encapsulate client states (like enabled attributes) and is not recommended for the performance reasons, especially if you have a lot of VAOs. For a small number performances are very good.

Quote:Original post by littlekidFrom what my understanding, I assume Vertex Buffer Object is similar to DX11 ID3D11Buffer. What about Vertex Array Range and Vertex Array Object?? And how are these compared to display list??

VBO is the same as D3D buffer. Furthermore, with new extensions you can directly use D3D buffers and surfaces from the OpenGL!
Differences between VBOs and DLs are huge. I cannot elaborate this topic in few sentences. DLs are faster but static and deprecated. VBOs are little bit slower (but with Bindless extension almost gain the same speed) but not deprecated and, hence, enabled in GL 3.1-4.1 core profile.

Quote:Original post by littlekidAm I right to say that contents that are created in display list are fixed and non changeable??

Yes, you are right. In fact, you can rebuild DL, but it costs more than VBO filling.


Quote:Original post by littlekidAnd lastly I read that pbuffers are legend and should not be used (in place of frame buffer objects)?? why is that so??

The performance reason.
isn't it so that display lists are emulated with VBOs on newer hardware(3years old)
and because of that they arn't faster
Quote:Original post by Aks9
Vertex Arrays (VA) are predecessors of VBOs and keep data always on the client side (read: in system memory)
That is not quite true, Vertex Array Range includes both instructions to allocate GPU memory and transfer data to it, and fence instructions so you know when the card has pulled the data so it's safe to overwrite/free. The reason why one should not use them is that they are an old, complicated, error-prone, vendor-specific extension, and VBO encapsulates all of it nicely with no hassle at all.

Quote:Original post by Aks9
Vertex Array Objects encapsulate client states (like enabled attributes) and is not recommended for the performance reasons
I'm a bit surprised about that one as well. VAO lets you switch a dozen states with one driver call instead of a dozen calls, and they may allow the driver to collapse rebuilding/optimization/redundant state changes in some cases.
Remember that some "harmless" state changes may require the driver to change quite a few bits on the pipeline (up to re-linking shaders, in the worst case).
If you perform several such changes by hand, the driver cannot know this in advance, it has to "optimize" after each call. If you use a VAO, the driver knows that several changes are going to happen and could skip all pipeline optimizations up to the last one.
In case you bind several VBOs, the driver may make a more intelligent decision on what to purge too, if GPU memory is low. If you manually bind VBO1 which is momentarily paged out, the driver might purge VBO2 and VBO3 from GPU memory to make room for it. When you manually bind VBO2 and VBO3 afterwards, they will have to be transferred again. Had the driver known that you were going to do that, it might instead have purged VBO7 and VBO21 or some texture, or whatever.
So, broken drivers exempted, VAOs should make your code faster if anything, not slower.

Quote:
Quote:DLs are faster but static and deprecated. VBOs are little bit slower
isn't it so that display lists are emulated with VBOs on newer hardware(3years old) and because of that they arn't faster
Yep, display lists and all other fixed function have been emulated with buffer objects for several years. If VBOs appear slower, it's probably due to wrong usage flags or some illegit or suboptimal usage pattern (like forcing the driver into a data dependency stall).
Quote:Original post by samoth
That is not quite true, Vertex Array Range includes both instructions to allocate GPU memory and transfer data to it, and fence instructions so you know when the card has pulled the data so it's safe to overwrite/free. The reason why one should not use them is that they are an old, complicated, error-prone, vendor-specific extension, and VBO encapsulates all of it nicely with no hassle at all.

Vertex Array Range comes in two flavors: NV's and Apple's. Maybe GL_NV_vertex_array_range was fastest way "for transferring geometry from the application to the GPU", but it was a decade ago, and works only with NV drivers. I was speaking about ordinary vertex arrays. Sorry for misunderstood.

Quote:Original post by samoth
I'm a bit surprised about that one as well. VAO lets you switch a dozen states with one driver call instead of a dozen calls, and they may allow the driver to collapse rebuilding/optimization/redundant state changes in some cases.
...
So, broken drivers exempted, VAOs should make your code faster if anything, not slower.

It should be so, but it seems that it doesn't function that way. Take a look on number of complains about VAOs performance. Or maybe we have bad experience with NV drivers. Maybe on ATI it works differently. :(
These are just few of the links that discuss VAOs and bad implementation/performance characteristics:
http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=274914&page=1
http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=274549#Post274549

Quote:Original post by samothYep, display lists and all other fixed function have been emulated with buffer objects for several years. If VBOs appear slower, it's probably due to wrong usage flags or some illegit or suboptimal usage pattern (like forcing the driver into a data dependency stall).

Do you have an example that can prove these statements? Display lists are considerably faster than VBOs on NVIDIA hardware/drivers. According to my measurements at least 60 to 100% faster (nearly 2x). There are many forum posts that share my opinion that DLs are still the fastest way of drawing. (I have to be honest and say that I have ceased to use DLs some time ago, but that doesn't mean they are not the fastest. Just not supported in the core profile, and harder/slower to update)

it always depends on the hardware u use

This topic is closed to new replies.

Advertisement