CallList slower than Begin/End...?
Author
Hello all,
I've got a large dataset of lines that I'm rendering. I was getting about 47fps (via a Fraps check) on a Athlon-64 3000 & NVidia 6600 GT with sending the vertices via glBegin/glEnd every frame.
Thinking that would most likely be the bottleneck, I compiled a display list and changed the render loop to simply glCallList. Much to my suprise, my frame rate _dropped_ to 37fps.
After thinking about this a bit, I'm guessing that it's possible that vertices which are sent via Begin/End might be culled by the driver before sending them onto the hardware. Whereas with a display list, the driver doesn't do any culling and sends them on to the hardware directly. If I pull the camera all the way back so all of the lines are in view, then my frame rate drops to about 38fps, so this seems likely.
Does anyone know if this is how NVidia's OpenGL driver works? I wouldn't expect the driver to do any culling for me at all -- but maybe NVidia does whatever they can to get extra performance... :)
yeah nvidia does do culling in the drivers. theyve gotten alot of flak for it too.
post some code of how you are generating the lists
post some code of how you are generating the lists
make sure you aren't creating a display list per frame, or even several times a second. this is not an effecient use of display lists, but i still see people do it.
Turn culling off, draw as a wireframe or with transparency or something like that.
Then compare performance.
This will give you a better idea of whether or not culling is responsible.
Then compare performance.
This will give you a better idea of whether or not culling is responsible.
Author
Quote:post some code of how you are generating the lists
Code... well, it's not much...
Since this is work-related code, I've had to trim out a few things, but the GL calls are done pretty much in this order.
// create line display list linDList = glGenLists(1); glNewList(linDList, GL_COMPILE); glDisable(GL_DEPTH_TEST); for (t = 0; t < linCount; t++) _drawLIN(&linList[t]); glEndList();--------------------------------------------------------------static void _drawLIN(LINData *lin){ // iterate through all entries for (entryIdx = 0; entryIdx < lin->entryCount; entryIdx++) { glColor4ubv((u8 *)&colorTable[entry->color]); // render a line strip glBegin(GL_LINE_STRIP); // send all points while (pointCnt--) { // send it glVertex2f((lin->xpos + point->x) * 15.0f, (lin->ypos + point->y) * 15.0f); } glEnd(); }}The render code simply calls: glCallList(linDList). I don't think you'll find anything out of place, though. :)
Just to give you an idea of how much data I'm dealing with, the total number of lines is 71726 (289728 vertices). I guess I'll just have to implement my own view frustum culling earlier than I expected. *sigh*
Quote:make sure you aren't creating a display list per frame, or even several times a second.
I'm not. The load routine and the render loop are completely separated.
Quote:Turn culling off, draw as a wireframe or with transparency or something like that.
These are lines, not polygons. Just how do I turn culling off, or draw a line as wireframe? :)
Quote:Original post by adam17God forbid NVIDIA should optimize their drivers.
yeah nvidia does do culling in the drivers. theyve gotten alot of flak for it too.
Quote:Original post by bpoint
...
I'm not. The load routine and the render loop are completely separated.Quote:Turn culling off, draw as a wireframe or with transparency or something like that.
These are lines, not polygons. Just how do I turn culling off, or draw a line as wireframe? :)
that still sounds worrisome, diplay lists take extra overhead to create, so if your data changes often they can actually create a performance hit. if areas of the display are static, then put them in a display list. if your data rapidly changes, you should not be using display lists.
if your lines never change, you can always draw to a texture for extra performance as well.
EDIT: and don't cull lines, but the call is glEnable(GL_CULL_FACE).
Just use vertex arrays and be done with it. Display lists are not the recommended batching method.
Author
Quote:Original post by anist
that still sounds worrisome, diplay lists take extra overhead to create, so if your data changes often they can actually create a performance hit. if areas of the display are static, then put them in a display list. if your data rapidly changes, you should not be using display lists.
The lines are static -- they never change.
Quote:if your lines never change, you can always draw to a texture for extra performance as well.
Unfortunately, that won't quite apply for what I'm doing. Regardless of the zoom level (camera position), I need a constant width for the lines. Plus, I'm nearing the limits of texture memory as it is already.
Quote:and don't cull lines, but the call is glEnable(GL_CULL_FACE).
Face culling is already enabled for other polygons/meshes in the scene. Disabling it didn't seem to affect speed either way though.
Quote:Just use vertex arrays and be done with it. Display lists are not the recommended batching method.
I was under the impression display lists would cut out a large portion of the Begin/End overhead (at least, that's the way it worked on the GameCube :) ), but if anything, it just helped cut back the function call overhead on the CPU.
I will try vertex arrays and VBOs later on. Thanks for the idea.
Quote:Original post by bpoint
The lines are static -- they never change.
Regardless of the zoom level (camera position), I need a constant width for the lines. Plus, I'm nearing the limits of texture memory as it is already.Quote:Just use vertex arrays and be done with it. Display lists are not the recommended batching method.
I will try vertex arrays and VBOs later on. Thanks for the idea.
yeah, display lists will work fine actually, but it's odd that your drawing is static though you have a constant width for your lines. technically, they would have a constant width on the texture, not if you zoomed out. so i am thinking you mean the lines increase in size as you zoom out. i think you can still change the line width outside of the display list though (not 100% on that).
a screenshot may help here, it's hard to tell what the issue is here with the posted code.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
