display list : 480 fps
glbegin : 18 fps
lol ? sure your geforce isn’t cheating ?
is the whole mesh visible all the time ?
i heard that nvidias display lists perform a visibility check by constructing a cube around the whole drawn vertices and then check if you can see the cube
I don’t know how my geforce should cheat here…
the fps are calculated by measuring the time used to draw.
The meshes are visible all the time. (they’re rotating…)
the performance-loss with glBegin could have other possibilities because the vertices etc. are stored in STL-Containers. so I think it’s more the CPU than GPU who decreases the performance.
I think the performance difference is because drawing with glBegin doesn’t use T&L on geforce cards but display lists do.
Thanks to this thread I’m changing my next project to default to display lists, I had forgotten how good they are. All I’m worried about is the memory hit, how much memory does a display list take compared to the corresponding vertex arrays? And where do they get stored, main or video memory? I know this is implememtation dependent, but I’d like to hear some of the common solutions.
-Ilkka
“I think the performance difference is because drawing with glBegin doesn’t use T&L on geforce cards but display lists do.”
Are you SURE?? That would mean that the whole great achievement of a T&L engine is completely useless if not using display lists!? I can’t believe that… and after all, a display lists also contains glBegin and glEnd, only that it is in the graphics card memory and probably compiled.
But this thread also strengthens my belief in display lists… experiences:
my “small” terrain engine has about 50.000 faces (triangle strpis) and is running absolutely flawless in terms of memory. the “large” terrain (whole germany, flightsim) has about 1000000 to 2000000 faces that are all in display lists at the same time, and there, sometimes swapping seems to occur as it slows down sometimes a little bit (“ruckeln”, what is the english word?).
Jan
VBOs with STATIC_DRAW usage should perform just as well as display lists.
I don’t think T&L gets switched off in immediate mode. Immediate mode is slow for large batches, but I’d attribute that to comparatively slow transfer bandwidth and function call overhead, not to T&L …
Originally posted by JanHH
<…> it slows down sometimes a little bit (“ruckeln”, what is the english word?).
It depends …
If it runs smooth overall but some single frames take a bit longer, you’re looking for “hitches” or the popular “stuttering”.
Another nice one is “[it runs] choppy”, but that often refers to overall low performance.
I have not helped in this forum in a long time… But it is never too late…
Are you drawing your mesh as lines or as filled polygons?
Draw them as filled polygons…
Miguel C
Sorry, I need to be more explicit… Both faces must be filled.
Regards,
mc
Originally posted by mancha:
[b]I have not helped in this forum in a long time… But it is never too late…
Are you drawing your mesh as lines or as filled polygons?
Draw them as filled polygons…
Miguel C[/b]
“stuttering” is the right word. it runs very fluent but sometimes slows down for a few frames, I guess that is when the graphics card memory gets swapped. But I was really impressed to see what larga data can be put into display lists.
Jan
I’ve read from this forum (Matt I think it was) a long time ago, that T&L isn’t used in immediate mode, but I’m not sure if that’s valid information anymore. The results speak for themselves, though. I’m sure you can take advantage of T&L when using vertex arrays, but I don’t know if it’s used with the basic setup, perhaps you need to use cva, var ot vbo to get it.
So how is it, NVidia guys?
-Ilkka
Guys, I doubt that the issue is due to T&L and video card combination… I have both, a raedon and an NVidia and I get consistent results with both when using the same method of data feeding. e.g. when both are running with vertex array and both are with immidiate mode.
The thing I saw is that when I was using vertex arrays to gain performance, I in fact had significantly lost it as compared to inmidiate mode; my head almost pop open from the steam built up.
At the very least, vertex array is going to be as fast as immidiate mode; regardless of T&L…
The problem is that vertex is optimized for filled polygons. When I set my polygons to be filled, must be both faces, vertex arrays lived up to its reputation of being faster.
In case you dont know what I mean by filled polygons, simply place the two lines of code where you initialize the opengl settings.
glPolygonMode( GL_FRONT, GL_FILL );
glPolygonMode( GL_BACK, GL_FILL );
Give it a shot.
Originally posted by JustHanging:
[b]I’ve read from this forum (Matt I think it was) a long time ago, that T&L isn’t used in immediate mode, but I’m not sure if that’s valid information anymore. The results speak for themselves, though. I’m sure you can take advantage of T&L when using vertex arrays, but I don’t know if it’s used with the basic setup, perhaps you need to use cva, var ot vbo to get it.
So how is it, NVidia guys?
-Ilkka[/b]
Originally posted by JustHanging:
[b]I’ve read from this forum (Matt I think it was) a long time ago, that T&L isn’t used in immediate mode, but I’m not sure if that’s valid information anymore. The results speak for themselves, though. I’m sure you can take advantage of T&L when using vertex arrays, but I don’t know if it’s used with the basic setup, perhaps you need to use cva, var ot vbo to get it.
So how is it, NVidia guys?
-Ilkka[/b]
That was probably the “T&L vertex cache”, which won’t work with immediate mode or DrawArrays, simply because you’re not reutilising any vertices.
Of course HW T&L is still used regardless of how you specify your geometry.
[This message has been edited by Madoc (edited 12-22-2003).]
Damn, I was wrong. I just went through the archives, and yes, all modes seem to exploit T&L just fine. Sorry.
Mancha: Isn’t GL_FRONT_AND_BACK, GL FILL the default mode? Therefore you shouldn’t have to do anything about it unless you’ve messed it up, right?
-Ilkka
JustHanging, that would be right… But when our fellow requesting help says “a mesh” it sounds like he is not using filled polygons. I am assuming too much I guess.
But if he is getting those results with filled enabled, I would like to look at the code because I am sure it is a wrong setting he has.
mc
Originally posted by JustHanging:
[b]Damn, I was wrong. I just went through the archives, and yes, all modes seem to exploit T&L just fine. Sorry.
Mancha: Isn’t GL_FRONT_AND_BACK, GL FILL the default mode? Therefore you shouldn’t have to do anything about it unless you’ve messed it up, right?
-Ilkka[/b]
…
I’m using textured polygons.
if no texture is avaiable, GL_COLOR_MATERIAL is also enabled 
in my initgl():
glPolygonMode(GL_FRONT_AND_BACK, GL_FILL);
glEnable(GL_TEXTURE_2D);
glEnable(GL_COLOR_MATERIAL);
but to get back to my initial question: what the hell am I doing wrong?
greetings, Bastian
If you want you can send me your code and I will inspect it…
miguel@wayne.edu
mc
Originally posted by mcbastian:
[b]…
I’m using textured polygons.
if no texture is avaiable, GL_COLOR_MATERIAL is also enabled
in my initgl():
glPolygonMode(GL_FRONT_AND_BACK, GL_FILL);
glEnable(GL_TEXTURE_2D);
glEnable(GL_COLOR_MATERIAL);
but to get back to my initial question: what the hell am I doing wrong?
greetings, Bastian[/b]
the fps are calculated by measuring the time used to draw.
That will not give meaningful results. You have to measure time right after calling SwapBuffers(), then measure time right after the next SwapBuffers(), and subtract your first time; that’s your frame-draw-time. One over frame-draw-time equals FPS.
If you only measure the time it takes to issue the commands, no doubt the lists will be very fast, as they’re all in memory already, and “drawing” the list consists of putting a command in some queue, pointing it at the memory – that doesn’t actually DRAW the list to screen; it just queues the command.
Swapbuffers doesn’t always block unless you have another swap in the buffer so this isn’t 100% reliable, and you’ll actually be measuring the earlier frame when it is, although you get a strange hybrid of code & dispatch from the latter frame and draw from the earlier frame, although being pipelined only the slowest will be timed, in a naive view of the scenario.
[This message has been edited by dorbie (edited 12-24-2003).]
Hi!
STUPID ME!!! STUPID ME!!! STUPID ME!!!
Thank you for your help. but I finally found my stupid mistake. I didn’t measure the time used for drawing a frame, instead I measured the time it took to call only the gl*()-functions, without taking a look at the time including SwapBuffers()…
now I got the following results:
Immediate-Mode: 18.9FPS
Display-List: 75.6FPS
DrawArrays() 73.9FPS
DrawArrays() 70.2FPS
uses gl*Pointer
uses glInterleavedArrays()
Now everything is clear for me. You shouldn’t code after midnight. And if you do, you should double-check your result
Thanks for help 
Bastian