I rewrite my code to replace “Display List” with VBO,but I found the new version is slower than old one.Why the new vbo technology is slow than display list?Which is faster,in most display card at present?And in future card?
VBOs are faster than Display lists unless you have really really old hardware, if used the right way that is.
Display lists are today just there for backwards compatibility, i think i read somewhere that the next version of openGL(3.0?) will remove display list support (though openGL 2.1 will still support it).
The driver can optimize the data stored within the display list by converting them to format that is better fit for the hw (or even supported by the hw) such as various alignments, types or cache optimalizations. With the VBOs you have the responsibility to prepare the data to the right format.
Display lists can also have some additional driver optimizations - it can divide complex geometry into smaller parts, make bounding boxes and perform frustum culling - such optimization is possible if you don’t use vertex shader (or your shader is position invariant).
I’ve observed this back on GeForce 4Ti - rendering 500k polygon object filling most of the screen was 2-3 times slower than rendering this object filling entire screen but having most polygons out of viewport.
As for current and future hardware I would suggest to use VBO. Combined with scene graph / BSP or other approaches will work fast. Also, make sure you don’t change textures and other stuff more times than you need to. Furthermore always try to put as much as you can in single draw call (many objects in one VBO).
Easier said than done with heavily instanced, dynamic engineering data - for which I’ve found display lists are the best approach for the current generation of professional cards (quadro/realizm). The hardware’s in the best position to decide how it wants its data, and so long as you don’t need the data for anything in your application, just compile it all into a display list.
Like k_szczech said, the hardware most definitely does do frustum culling with display lists (it calculates bounds during GL_COMPILE), and considering a display list draw call is literally one single API call passing one single integer into the command stream, you could feasibly disable your own scene culling altogether and not notice a change in frame rate (but your cpu usage would go down).
As you can probably tell, I’m a big fan of display lists, but only as a geometry submission abstraction, of course.
Now,the reason let me use Display list is the data store is optimized and GPU can access it efficiently,is it?My program’s task is rendering some geometries,and apply texture to it,in this scene,which one should I use?
I heard display list will be removed in future card,is it true?If it is,what time?
Display lists won’t be removed, they’ll be layered, possibly layered on to a new geometry buffer abstraction. This still gives the driver/hardware a point at which they can optimise the geometry into whatever format will render fastest.
For me, the geometry buffer abstraction is one of the major advantages GL has over D3D.
What do you mean with “geometry buffers”?
Did you have a look at the new D3D10 API (only available for Win Vista)? This seems to be very much like the new proposed OpenGL 3.0 L&M API would be (w.r.t. the state objects, texture objects, …) …
Originally posted by knackered:
Display lists won’t be removed, they’ll be layered, possibly layered on to a new geometry buffer abstraction. This still gives the driver/hardware a point at which they can optimise the geometry into whatever format will render fastest.
For me, the geometry buffer abstraction is one of the major advantages GL has over D3D.
What is “geometry buffer abstraction”?Is it a new extension?Where can I find doc about it?