🔒 Locked

Display lists performance

Started by adario Nov 24, 2003 at 9:12 AM 12 replies 700+ views

Original Post

Nov 24, 2003 at 9:12 AM

Hello, I am porting my Mac OS X OpenGL code to Windows XP, and I''m using Visual C++ 6.0 to compile it. My x86 laptop has a P4/3.06GHz with 768MB RAM, runs XP Pro, and sports an nVidia GeForce FX Go5200 card with 64MB VRAM. Previously I used glDrawElements to display my meshes. I am now moving to display lists all meshes whose geometry does not change. In order to avoid too much overhead with display lists, only meshes that have at least n (currently 8) vertices are converted to display lists; the others still use glDrawElements. Using display lists results in a 3x performance boost on Mac OS X: from a 24 FPS average to a 72 FPS average, with CPU usage from 80% down to 20% on average. However, on my Windows box I actually notice a *decrease* in FPS (about 9 less with display lists versus glDrawElements), and only a very slight performance increase in CPU usage (from 81% to 77%). This is the code I''m using to create display lists: GLuint listID = glGenLists(1); glNewList(listID,GL_COMPILE_AND_EXECUTE); glBegin(GL_TRIANGLES); for (int iTriangle = 0; iTriangle < iTriangles; ++iTriangle) { int iIndex = iTriangle * 3; for (int i = 0; i < 3; ++i) { int iVertex = aiConnect[iIndex + i]; if ( afTextures0 ) glMultiTexCoord2f(GL_TEXTURE0_ARB, afTextures0[iVertex].X(),afTextures0[iVertex].Y()); if ( afTextures1 ) glMultiTexCoord2f(GL_TEXTURE1_ARB, afTextures1[iVertex].X(),afTextures1[iVertex].Y()); if ( afTextures2) glMultiTexCoord2f(GL_TEXTURE2_ARB, afTextures2[iVertex].X(),afTextures2[iVertex].Y()); if ( afTextures3) glMultiTexCoord2f(GL_TEXTURE3_ARB, afTextures3[iVertex].X(),afTextures3[iVertex].Y()); if ( afColors ) glColor3f(afColors[iVertex].r,afColors[iVertex].g, afColors[iVertex].b); if ( afNormals ) glNormal3f(afNormals[iVertex].X(),afNormals[iVertex].Y(), afNormals[iVertex].Z()); glVertex3f(afVertices[iVertex].X(),afVertices[iVertex].Y(), afVertices[iVertex].Z()); } } glEnd(); glEndList(); On Mac OS X this code does indeed give the expected results: much better FPS and seriously reduced CPU usage. Not so on XP Pro. Am I missing something obvious on Windows? Thank you.

dmounty

Nov 24, 2003 at 4:44 PM

On some systems display lists do not provide any speedup, due to their simplistic implementation. Display lists also have an overhead in setting up and calling. Perhaps the implementation of glDrawElements on your windows system is very efficient, and you are simply seeing the overhead of the Display list call. Another possibility is the fact that you compile and run the display list. A compile and run will obviously be slower than just compiling would be, and its also slower than just calling the display list. I assume you have some reason for doing it this way, but perhaps its no an ideal approach? I just had a look back at your code, and you are drawing plenty of triangles in one batch... so the display list overhead, compared to rendertime should be minimal (ie slowdowns not from there). All I can say is that its probably a specific artifact on your system of fast indexed vertex array rendering, and badly implemented display lists, and that in general it should be faster (though 3x seems a lot!). It could even be something related to your graphics card being very fast, and the bottleneck in performance shifting from the transfer and triangle rendering/transformation, to the display list use? Try setting your threshold for using display lists considerably higher... That might help matters if that is the case.

EDIT: There is also no reason you couldn't simply put your indexed vertex array implementation inside your display list implementation. This is possible, and could provide the performance boost you are looking for (maybe :S )

[edited by - dmounty on November 24, 2003 5:47:43 PM]

Raloth

Nov 24, 2003 at 8:47 PM

quote:
Original post by adario
I am porting my Mac OS X OpenGL code to Windows XP, and I''m using Visual C++ 6.0 to compile it. My x86 laptop has a P4/3.06GHz with 768MB RAM, runs XP Pro, and sports an nVidia GeForce FX Go5200 card with 64MB VRAM.

Your main problem is probably the video card...the 5200 isn''t exactly what you would call "fast". Anyway, have you tried changing "n" to something like 200 vertices? 8 is still too little. Your best bet would be to use the VBO extension if your laptop supports it.

adario

Author

adario

Nov 25, 2003 at 4:54 AM

quote:
Original post by dmounty
On some systems display lists do not provide any speedup, due to their simplistic implementation. Display lists also have an overhead in setting up and calling. Perhaps the implementation of glDrawElements on your windows system is very efficient, and you are simply seeing the overhead of the Display list call. Another possibility is the fact that you compile and run the display list.
A compile and run will obviously be slower than just compiling would be, and its also slower than just calling the display list. I assume you have some reason for doing it this way, but perhaps its no an ideal approach?

I don''t think that GL_COMPILE_AND_EXECUTE might be the culprit. The lists are created only once, so every subsequent frame is rendered with a simple glCallList. The reason to use GL_COMPILE_AND_EXECUTE is to avoid an additional glCallList when the lists are created.

I am starting to suspect a crappy display list implementation on nVidia''s part.

quote:
I just had a look back at your code, and you are drawing plenty of triangles in one batch... so the display list overhead, compared to rendertime should be minimal (ie slowdowns not from there). All I can say is that its probably a specific artifact on your system of fast indexed vertex array rendering, and badly implemented display lists, and that in general it should be faster (though 3x seems a lot!).

It might seem a lot, but that''s what I got on Mac OS X on an ATi Radeon 9000:

glDrawElements -> 24.53 FPS on average
glCallList -> 72.37 FPS on average

This is partly explained by the fact that my OS X machine has a fairly slow bus (133MHz), so using display lists means avoiding a trip over the bus, which might justify such an increase.

My XP Pro machine has a fairly fast bus (533MHz), so obviously I was not expecting the same kind of performance boost. But still, Windows is actually *slower* with display lists...

quote:
It could even be something related to your graphics card being very fast, and the bottleneck in performance shifting from the transfer and triangle rendering/transformation, to the display list use? Try setting your threshold for using display lists considerably higher... That might help matters if that is the case.

I will try to raise the threshold, but the large majority of my meshes has several hundred triangles, so it''s not like most glCallList invocations are performed on low polycount objects -- quite the contrary.

I am quit puzzled by these results.

quote:
EDIT: There is also no reason you couldn''t simply put your indexed vertex array implementation inside your display list implementation. This is possible, and could provide the performance boost you are looking for (maybe :S )

Unfortunately that path has some problems in current versions of Mac OS X, so it would imply another platform-dependent code section which I''d like to avoid...

Thank you for your reply.

Best regards,
Dario

adario

Author

adario

Nov 25, 2003 at 5:00 AM

quote:
Original post by Raloth
Your main problem is probably the video card...the 5200 isn''t exactly what you would call "fast". Anyway, have you tried changing "n" to something like 200 vertices? 8 is still too little. Your best bet would be to use the VBO extension if your laptop supports it.

Yes, I do realize my card is not exactly a screamer. That, however, does not justify *at all* the fact that display lists are *slower* on Windows than glDrawElements. The OpenGL specs state that, once overhead is taken into account, display lists are guaranteed to be "at least as fast, and in no case slower" than immediate mode rendering. You could argue glDrawElements is not immediate mode: I could argue the opposite, since it''s still has to copy data over the bus.

I have not tried to raise the threshold yet because over 90% of my meshes have a number of triangles on the order of a few hundred. I will definitely try to raise the threshold; however, I am afraid this would be too simple a solution.

I have not looked into the VBO extension yet (nor have I used it before) simply because I would like to keep my rendering as cross-platform as possible...

Thank you.

Best regards,
Dario

Lev Povalahev

Nov 25, 2003 at 5:41 AM

Never use COMPILE_AND_EXECUTE:

http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/001255.html
http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/000171.html
http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/002106.html

Use VBO to get the most out of your card. Using VBO is really just a few lines of code.

Regards
-Lev

adario

Author

adario

Nov 25, 2003 at 5:54 AM

quote:
Original post by Lev Povalahev
Never use COMPILE_AND_EXECUTE:

http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/001255.html
http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/000171.html
http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/002106.html

Thank you for the pointers, Lev.

quote:
Use VBO to get the most out of your card. Using VBO is really just a few lines of code.

I have nothing against VBO itself, but it''s not a portable, cross-platform solution -- display lists are, or at least should be... ;-)

Best regards,
Dario

Lev Povalahev

Nov 25, 2003 at 8:10 AM

Well, buffer objects are not supported on MAC as of yet, but after all they are part of a opengl 1.5 spec, so buffer objects should be supported in near future. But of course if your target timeframe doesn''t lie in the future thats pointless.

Regards
-Lev

adario

Author

adario

Nov 25, 2003 at 8:24 AM

quote:
Original post by Lev Povalahev
Well, buffer objects are not supported on MAC as of yet, but after all they are part of a opengl 1.5 spec, so buffer objects should be supported in near future. But of course if your target timeframe doesn''t lie in the future thats pointless.

Yes, I indeed have to release a prototype by the end of December, and I''m fairly certain there won''t be any support for VBO on Mac OS X by that date.

Thanks to your pointers, I have solved the issue: the problem was actually GL_COMPILE_AND_EXECUTE. Although in my code the performance boost given by display lists over glDrawElements on Windows XP is nowhere near the one seen on Mac OS X, it is still quite signficant (over 30% faster), so I will stick with GL_COMPILE -- and thanks again, Lev.

Best regards,
Dario

benjamin bunny

144

benjamin bunny

Nov 25, 2003 at 8:38 AM

quote:
Original post by adario
quote:
Use VBO to get the most out of your card. Using VBO is really just a few lines of code.

I have nothing against VBO itself, but it''s not a portable, cross-platform solution -- display lists are, or at least should be... ;-)

The code required to render with VBO doesn''t actually differ that much from vertex arrays. It''s pretty easy to write a vertex array wrapper class that uses VBO if available, or falls back to standard vertex arrays otherwise.

GamerSg

Nov 25, 2003 at 10:02 AM

Well, i have used display lists and i must say they are really great when used properly, easily giving a significant performance boost over Vertex Arrays when VBOs are not an option for whatever reason.

You talk about the bus speed. Is this the bus from the CPU to RAM? Or is it the AGP port from the MotherBOard to the gfx card? Im not aware of the MAC architecture but i would like to know.

adario

Author

adario

Nov 25, 2003 at 10:13 AM

quote:
Original post by GamerSg
Well, i have used display lists and i must say they are really great when used properly, easily giving a significant performance boost over Vertex Arrays when VBOs are not an option for whatever reason.

Plus they have been part of OpenGL for quite a long time, so all serious vendors are *supposed* to support them fairly well. Having said this, in the future I will definitely investigate whether VBOs would be faster for my application.

[quote[You talk about the bus speed. Is this the bus from the CPU to RAM? Or is it the AGP port from the MotherBOard to the gfx card? Im not aware of the MAC architecture but i would like to know.

The ATi Radeon 9000 Pro sits in a standard AGP 4x slot, but the actual CPU-to-RAM bus speed is 133MHz on my G4. More recent kinds of G4 have a 167MHz bus speed. The G5 machines have 800MHz, 900MHz or 1GHz bus speed.

Best regards,
Dario

GamerSg

Nov 25, 2003 at 10:18 AM

VBO should definitly be faster because they are very likely to end up in Video Memory. Also, VBOs are designed to render large polygon count models without having to send the data throught the bus every frame.

As for display lists, it is up to the driver to decide on where it ends up.

adario

Author

adario

Nov 25, 2003 at 10:27 AM

quote:
Original post by GamerSg
VBO should definitly be faster because they are very likely to end up in Video Memory. Also, VBOs are designed to render large polygon count models without having to send the data throught the bus every frame.

As for display lists, it is up to the driver to decide on where it ends up.

Your points are valid. However, on many OpenGL implementations display lists are indeed kept in VRAM, which eliminates the bus trip. That is definitely the case on Mac OS X. I am not sure about Windows XP, but I suspect it''s true there as well.

Anyway, like I said I''ve got nothing against VBO itself, and I will indeed look into VBOs as soon as they''re available (and equally supported) on both platforms. For the moment, however, display lists are easy to use and give me a sufficient performance boost on both Mac OS X and Windows -- that is, when using GL_COMPILE instead of GL_COMPILE_AND_EXECUTE.

Thanks again.

Best regards,
Dario

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.