Display Lists in Opengl, the anti-optimization at high poly counts?
Author
I''ve written a small LWO importer for OpenGL that basically
loads the object into a rotating scene. Then to test out how much of an increase display lists are on the TNT2 chipset I ran a series of tests with ''brute force'' rendering and then display list rendering. Much to my dismay the display list actually got a worse framerate than the non display list version at high poly counts (~9000) and showed no gain when the poly count was low (~150).
What gives, I thought that display lists couldnt hurt the performance. Makes me wonder if commercial products use display lists extensively and if so how much performance im loosing
In my project I tried using a display list for my 5000-or-so-triangle object since it uses 3 passes. I didn''t get any noticeable performance gain or hit, actually. Are you sure you''re not accidentally building the list for each rendering pass or something? I can''t imagine why the performance would *drop* so significantly.
Can anyone out there say when display lists will actually do something significant?
Can anyone out there say when display lists will actually do something significant?
Author
Im using a single pass render... no textures no G.Lighting, just flat poly''s to test if the geometry imported ok.
I benchmarked using a really primitive method that involved counting the number of succesful calls to display() and outputing that number every second (reseting it to zero at that point). with this the fps was around 260 for the display listed high poly count and 300 for the non-type, that In my mind is a noticable hit. If you are HW accelling with a TNT2U i guess Im doing something terribly wrong otherwise It might just be the chipset implementation
-menasius
I benchmarked using a really primitive method that involved counting the number of succesful calls to display() and outputing that number every second (reseting it to zero at that point). with this the fps was around 260 for the display listed high poly count and 300 for the non-type, that In my mind is a noticable hit. If you are HW accelling with a TNT2U i guess Im doing something terribly wrong otherwise It might just be the chipset implementation
-menasius
you don''t have any transform matrices in the display list code, do you? if so, this''ll slow it down. display lists are only for rigid bodies, not if you''re going to do some subobject animation, like filling in a variable for a vertex.
a2k
a2k
Author
Nope no transformations ... I do however have a for loop because the geometry has an undefined number of polys (until runtime ) so it loops through all the vertices
-menasius
-menasius
No transforms here, either. The only major question I have, then, is whether or not it''s correct to have glBegin/glEnd within glNewList/glEndList or not. I *do*, and I can''t recall why I''d done that other than that it got things working. I''m using a regular TNT. To say the least, this problem is strange. I wonder if any Direct3D people are having similar issues.
When you are using display lists it is best if you only use one per object. When you say "loop through all the vertices", are you creating a seperate display list for each polygon? If you are you will find that the overhead per display list will drop your performance notably. If you aren''t then it is probably a driver issue, because display lists should be faster in most cases.
PreManDrake
PreManDrake
Author
no no no Im not that idiotic... The loop looks like this
start the list...
loop through vertices of triangles..
end list
so its one list with a bunch of vertices in it and a glBegin and glEnd (although I''ve tried it without)
-menasius
"Quitters never win...
winners never quit...
but those who never win and never quit, are idiots"
start the list...
loop through vertices of triangles..
end list
so its one list with a bunch of vertices in it and a glBegin and glEnd (although I''ve tried it without)
-menasius
"Quitters never win...
winners never quit...
but those who never win and never quit, are idiots"
Try using GL_COMPILE or GL_COMPILE_AND_EXECUTE to decrease render times for display list. These calls optimize the list before display and stores it in video memory(I believe). Also make sure you only call display() when absolutely necessary.
--Cauldron the Ancient
--Cauldron the Ancient
If I am not wrong, display list puts geometry and/or transformations into the video card that supports T&L.
I experienced steady speed increment by the dispaly list with a T&L supported board.
If the video board does not support T&L, display list may not have any advantage. When the memory allocation for the geometry/transformation is bad (jumping around?), you may suffer from speed delay.
HRS
I experienced steady speed increment by the dispaly list with a T&L supported board.
If the video board does not support T&L, display list may not have any advantage. When the memory allocation for the geometry/transformation is bad (jumping around?), you may suffer from speed delay.
HRS
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
