Jump to content
  • Advertisement
Sign in to follow this  
Falken42

OpenGL CallList slower than Begin/End...?

This topic is 4814 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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... :)

Share this post


Link to post
Share on other sites
Advertisement
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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? :)

Share this post


Link to post
Share on other sites
Quote:
Original post by adam17
yeah nvidia does do culling in the drivers. theyve gotten alot of flak for it too.
God forbid NVIDIA should optimize their drivers.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Just use vertex arrays and be done with it. Display lists are not the recommended batching method.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!