VBO vs display list?

mulova · February 19, 2009, 12:02pm

I read OpenGL FAQ and it says that VBO with Display List degrades performance in general.

(assuming that VBO is synonym to 'Vertex Array')

http://www.opengl.org/resources/faq/technical/displaylist.htm#0100

And Momoko_Fan says display list is old and VBO is better.

http://www.jmonkeyengine.com/jmeforum/index.php?topic=9172.0

Momoko_Fan said:

Display lists are pretty much deprecated as of now..

But for my computer, VBO with Display List is faster than VBO alone, Display List alone.
(I'm using Win XP SP3 / Radeon HD 3850.)

What is happening for mine?

basixs · February 19, 2009, 4:20pm

I think the key words are "…in general"

vear · February 19, 2009, 6:07pm

This question is a good candidate for a FAQ. Every couple of months this comes up.

vertex arrays != VBO

Display lists with vertex arrays is generally faster than VBO. In some new driver implementations, display lists are implemented using VBO's, and make not much difference. But display lists are more limited than VBO-s.

You cant use display lists together with VBO-s. OpenGL throws and error if you try to do that.

Aren't you mixing vertex arrays and VBO-s? That case IS causing a slowdown.

Momoko_Fan · February 19, 2009, 7:17pm

Display lists might be faster but they are still pretty much deprecated…

mulova · February 20, 2009, 12:07am

vear said:

vertex arrays != VBO

Display lists with vertex arrays is generally faster than VBO. In some new driver implementations, display lists are implemented using VBO's, and make not much difference. But display lists are more limited than VBO-s.

You cant use display lists together with VBO-s. OpenGL throws and error if you try to do that.
Aren't you mixing vertex arrays and VBO-s? That case IS causing a slowdown.

Thanks a lot.
I need to study more abut VBO/ vertex array and so on... :)

I called setVBOInfo() to use VBO and lockMesh() to use display list
Then the geometry is using VBO and displaylist. Is it right?
But it works faster and no error occurs.
About performance, I have to try it on other computer,
But According to my test, many hardwares don't report any exceptions for that.

tom · February 21, 2009, 12:45am

Momoko_Fan said:

Display lists might be faster but they are still pretty much deprecated..

Depricated in JME or Opengl 3.0? Pretty much everything is depricated in OGL 3.0 so you might aswell use display lists. They sure are easier to use and can be faster. The driver has at least a better opportunity to optimize display lists.

Momoko_Fan · February 21, 2009, 1:23am

tom said:

Depricated in JME or Opengl 3.0? Pretty much everything is depricated in OGL 3.0 so you might aswell use display lists. They sure are easier to use and can be faster. The driver has at least a better opportunity to optimize display lists.

Deprecated for most modern video cards (nVidia + ATI). Everything that is related to the fixed-function pipeline is deprecated in OpenGL3, and that includes display lists.
I heard this discussion about display lists and VBO few times, if you're feeling like arguing you may want to visit GDNet:
http://www.gamedev.net/community/forums/topic.asp?topic_id=378417

vear · February 21, 2009, 3:34am

Display lists do not compile commands to set textures, so texturing must be set before calling a display list. This is the basic reason why whole branches of the scenegraph cannot be compiled into a single display list, and why DL-s so lose on usefulness. Display lists do not support shaders AT ALL. If you apply a shader, then render a DL, the shader will be ignored altogether.

Lets evaluate the most important scenarios in regards to DL-s:

Character models

No vertex animation possible, not in software, not with a shader. Useless.
Static models, lots of instances of static models

Possible if no shader is used, possibly single texture or texture blending set up trough fixed functionality. There is a quite good instancing technique possible with OpenGL, not in current jME, but for the next jME release that may be advisable to implement. But, the technique requires a shader. So in current jME DL-s are good for static models, but for the future there is a better technique which improves performance more than DL-s do, and makes DL-s obsolete for this use.
Terrain

The primary use of DL-s so far. No LOD technique possible with DL, or only possible if you switch whole blocks. Basicaly you only got one LOD, which you can show from a greater distance, since DL rendering is more forgiving. You can even create the terrain block DL with locked world position if the block is unique. So yes this is usefull. But no shader can be used for texture splatting, and i'm not sure if shadow maps are possible.

In current jME, use DL-s if you want/can. I suggest dropping DL-s for the next release and implementing the other techniques instead. Things like depth-only pass, instancing, improvements to VBO-s.

mulova · February 21, 2009, 2:11pm

Thank you for the detailed example.

Long way to go for the VBO things in jme. :’(

tom · February 21, 2009, 3:57pm

vear said:
Display lists do not support shaders AT ALL. If you apply a shader, then render a DL, the shader will be ignored altogether.

And you got this information from where? Looking at the doc it seems like you can use shaders with DL. Have a look at question 31 in the ARB_shader_objects doc: http://www.opengl.org/registry/specs/ARB/shader_objects.txt. It says you can use UseProgramObjectARB inside a DL. So you can use all the examples you mentioned with DL, as long as all the vertex data is static.

Btw, I think it is the same with textures. You can bind a texture inside a DL. But you can't use activeTexture, so multitexturing may not be possible. But that is not a big problem. Just put it outside the DL and use DL for the geometry.

Display lists has several rendering advantages over static VBOs. First of all it can store the data in the optimal way according to the driver. Second VBO's have a very high setup cost. It can become a bottleneck if you render a lot of small objects.

vear · February 21, 2009, 5:37pm

tom said:

And you got this information from where? Looking at the doc it seems like you can use shaders with DL. Have a look at question 31 in the ARB_shader_objects doc: http://www.opengl.org/registry/specs/ARB/shader_objects.txt. It says you can use UseProgramObjectARB inside a DL. So you can use all the examples you mentioned with DL, as long as all the vertex data is static.

By testing, i got geometry rendered in white, whenever i applied a shader to a DL. It was some years ago, but you are right, it seems that it is possible to apply a shader inside the DL now. If you use the shader inside the DL, then you are locking the geometry to use that one shader. So you would need to set up a different DL for every geometry and every shader you use it with. You would need to recompile the DL if you wanted to change a uniform. When i think about it, perhaps not, but then the engine had to be able to handle out-of-DL uniforms separately from inside-DL uniforms.

tom said:

Btw, I think it is the same with textures. You can bind a texture inside a DL. But you can't use activeTexture, so multitexturing may not be possible. But that is not a big problem. Just put it outside the DL and use DL for the geometry.

Display lists has several rendering advantages over static VBOs. First of all it can store the data in the optimal way according to the driver. Second VBO's have a very high setup cost. It can become a bottleneck if you render a lot of small objects.

No multitexturing is "not a problem"? As i said, that is the reason why whole scenegraph branches cant be compiled to a single DL. The current jME is doing just what you said, applying the textures before rendering the DL.

There is an OGL technique for fast rendering of lots of small objects, its well documented. If we have that in the engine, no need for DL-s for that.

Please go and read the opengl.org forums for about half a year. You will see all the compatibility problems that even new cards have, all the engine design issues that special handling of those incompatibility issues arise. Its best to optimize the engine around and use either DL or VBO, not both at the same time.

For example, see this post from yesterday: http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=253318#Post253318

tom · February 21, 2009, 7:28pm

vear said:

By testing, i got geometry rendered in white, whenever i applied a shader to a DL. It was some years ago, but you are right, it seems that it is possible to apply a shader inside the DL now. If you use the shader inside the DL, then you are locking the geometry to use that one shader. So you would need to set up a different DL for every geometry and every shader you use it with. You would need to recompile the DL if you wanted to change a uniform. When i think about it, perhaps not, but then the engine had to be able to handle out-of-DL uniforms separately from inside-DL uniforms.

You have to use display lists in a way that makes sense. Just because it is possible to compile in shaders inside the lists, don't mean you have to. Store static geometry in DL and manage the state the usual way. If it makes sense to add state to the list you have to option to do that.

vear said:

No multitexturing is "not a problem"? As i said, that is the reason why whole scenegraph branches cant be compiled to a single DL. The current jME is doing just what you said, applying the textures before rendering the DL.

Just because you can not compile branches don't mean display lists are useless. Display lists can greatly reduce the number of gl calls and it can optimize static geometry. So the benifit can be great even if you have to set up the multitexturing outside the lists.

vear said:

There is an OGL technique for fast rendering of lots of small objects, its well documented. If we have that in the engine, no need for DL-s for that.

Instancing? Or something else?

vear said:

Please go and read the opengl.org forums for about half a year. You will see all the compatibility problems that even new cards have, all the engine design issues that special handling of those incompatibility issues arise. Its best to optimize the engine around and use either DL or VBO, not both at the same time.

For example, see this post from yesterday: http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=253318#Post253318

Spent about an hour on the opengl forum and I could anyone mentioning any bugs or compatibility problems. The example you mentioned was simply caused by wrong use.

vear · February 21, 2009, 11:17pm

tom said:

You have to use display lists in a way that makes sense. Just because it is possible to compile in shaders inside the lists, don't mean you have to. Store static geometry in DL and manage the state the usual way. If it makes sense to add state to the list you have to option to do that.

Setting the shader outside of DL does not work. From the OGL forum post, it seems that setting it inside does.

Just because you can not compile branches don't mean display lists are useless. Display lists can greatly reduce the number of gl calls and it can optimize static geometry. So the benifit can be great even if you have to set up the multitexturing outside the lists.

I didn't say they are useless for every application, i said that DL-s can be supplemented. If DL were able to compile branches, then they could not be supplemented, but they cant compile branches. Removing them makes the engine more clean, because special render paths for handling DL-s are not needed. And, since those paths are not not needed, the engine can be better extended with other, more up-to-date functionality. If DL-s are kept, then every new functionality must be tested, as how does that go with DL-s.

Instancing? Or something else?

I know of instancing by passing the transforms in vertex attributes, and so avoiding the slow glMatrix calls.

Spent about an hour on the opengl forum and I could anyone mentioning any bugs or compatibility problems. The example you mentioned was simply caused by wrong use.

Its not DL-s that have incompatibility issues, its the issues in general, that affect the engine, make it more complicated, and adding DL-s just makes it more complicated. There are posts saying that mixing VBO and DL rendering leads to slowdown, so that does qualify as a bug or at least as a quirck which needs to be taken into account.

DL-s have been around for quite a long of time, but they are obsolete. We should make the next version of the engine (the jME 3.0 branch) for today and tomorrow not for 6-7 year old graphics cards. I don't mind if VA+FF+DL support is added after the engine has been optimized for VBO+shader support.

Quote from Leadwerks:
"We don't even use vertex arrays or display lists, as that technology has been obsolete for at least five years."

Sorry, i just wont reply to this issue any more. If i cant convince you, then simply google on the issue, and read some more. Commercial engines are working with deferred lighting, and we are here discussing what? The ages old display lists.

tom · February 22, 2009, 5:00pm

vear said:

Setting the shader outside of DL does not work. From the OGL forum post, it seems that setting it inside does.

You should try it again. Maybe you encountered a driver bug or made a mistake. Setting the shader outside of DL definitely works. It says so in the spec. I also tested it now with lwjgl. I can post the code if you want.

vear said:

I didn't say they are useless for every application, i said that DL-s can be supplemented. If DL were able to compile branches, then they could not be supplemented, but they cant compile branches. Removing them makes the engine more clean, because special render paths for handling DL-s are not needed. And, since those paths are not not needed, the engine can be better extended with other, more up-to-date functionality. If DL-s are kept, then every new functionality must be tested, as how does that go with DL-s.

Fair enough, keeping the engine clean and maintainable is a valid goal.

vear said:

Its not DL-s that have incompatibility issues, its the issues in general, that affect the engine, make it more complicated, and adding DL-s just makes it more complicated. There are posts saying that mixing VBO and DL rendering leads to slowdown, so that does qualify as a bug or at least as a quirck which needs to be taken into account.

DL-s have been around for quite a long of time, but they are obsolete. We should make the next version of the engine (the jME 3.0 branch) for today and tomorrow not for 6-7 year old graphics cards. I don't mind if VA+FF+DL support is added after the engine has been optimized for VBO+shader support.

Quote from Leadwerks:
"We don't even use vertex arrays or display lists, as that technology has been obsolete for at least five years."

Sorry, i just wont reply to this issue any more. If i cant convince you, then simply google on the issue, and read some more. Commercial engines are working with deferred lighting, and we are here discussing what? The ages old display lists.

I disagree that display lists are obsolete. It was depricated in OpenGL 3.0 that came out 6 months ago. But so was almost everything else. The depricated parts will be supported for a long, long time. VBOs came out a long time ago but did not make display lists obsolete. First of all because display lists can hold other things than geometry. Even with static geometry display lists makes sense because it has lower setup cost and that it in theory can be better optimized. And you can use display lists with deferred lighting and other new algorithms.

If you're going to make an engine that can be used by casual games today, you have to support older graphics cards. Would be interesting to know what minimum requirements you're setting for JME 3.0. Is it going to be a pure Opengl 3.0 engine?

gouessej · February 22, 2009, 6:55pm

vear said:

Aren't you mixing vertex arrays and VBO-s? That case IS causing a slowdown.

It even causes some crashes in JOGL when using TextRenderer so please avoid doing it. Rather use static VBOs instead of display lists when the VBO extension is available.

Momoko_Fan · February 22, 2009, 11:25pm

I think the issue here is that supporting both DL and VBO would be a bit much. It would require more testing etc, and so from that standpoint it is much better to support modern features rather than old features.