Display Lists
July 08, 2005 12:09 AM
I just finished the nehe lession on display lists, and im wondering, how much memory do these Display Lists take? They seem great for applications with many instances of a few models, but what about if there are a many different models, each with only a few instances?
5,051
July 08, 2005 02:01 PM
Somebody told me display lists take a quite big amount of memory on commodity hardware while professional video cards seems to behave just the opposite.
This however, was happening two years (or more) ago so it's probably false now.
What he told me was that it seems to be a price to pay "per command". Display lists with few commands takes X bytes while having more commands takes more, altough there's not a direct relationship as one may expect.
If a display list contains big chunks of data, then expect it to grow as much as the data contained (remember texture-object-display-lists).
I think this is however hardware specific so I think you should not care about this, they are always pretty efficient.
This however, was happening two years (or more) ago so it's probably false now.
What he told me was that it seems to be a price to pay "per command". Display lists with few commands takes X bytes while having more commands takes more, altough there's not a direct relationship as one may expect.
If a display list contains big chunks of data, then expect it to grow as much as the data contained (remember texture-object-display-lists).
I think this is however hardware specific so I think you should not care about this, they are always pretty efficient.
Previously "Krohm"
July 08, 2005 07:18 PM
mmm ok, thanks.
I also have another question. I dont know the inner workings of display lists, so this is probably a stupid question.. heh, but.. ok. Im sure that creating display lists causes extra overhead (speedwise, not memorywise). How does this overhead compare with the base overhead of creating and displaying individual polygons? For instance, Im sure that if theres some object that i only want to display once, creating a display list would be slower than directly displaying it. But what if i want to display it twice? Three times? I guess what im asking is, where is the cutoff where display lists begin to be worthwhile? Thanks.
I also have another question. I dont know the inner workings of display lists, so this is probably a stupid question.. heh, but.. ok. Im sure that creating display lists causes extra overhead (speedwise, not memorywise). How does this overhead compare with the base overhead of creating and displaying individual polygons? For instance, Im sure that if theres some object that i only want to display once, creating a display list would be slower than directly displaying it. But what if i want to display it twice? Three times? I guess what im asking is, where is the cutoff where display lists begin to be worthwhile? Thanks.
184
July 09, 2005 05:30 AM
How exactly displaylists work and how much memory they consume, is up to the driver. But it should grow linear with the amount of commands and data. The creation overhead is less than drawing the model once, since nothing is drawn. If you draw a model more than a couple of times it should be worth it and since you usualy draw somthing like 60 frames per second they would payoff preaty fast.
If you want to know exactly how many times you have to draw them, benchmark it with and with out display lists. Do something like draw the model 1000 time and store the time since the first frame both with and with out display lists. Look when display lists get faster. Repeat the experiment a few times to make sure it is no coinsident.
But generaly, as i said, the inner workings of display lists are up to the driver and it has to be considered a black box. Don't expect to get exactly the same memory/speed behaiviour from differen drivers.
If you want to know exactly how many times you have to draw them, benchmark it with and with out display lists. Do something like draw the model 1000 time and store the time since the first frame both with and with out display lists. Look when display lists get faster. Repeat the experiment a few times to make sure it is no coinsident.
But generaly, as i said, the inner workings of display lists are up to the driver and it has to be considered a black box. Don't expect to get exactly the same memory/speed behaiviour from differen drivers.
5,051
July 09, 2005 08:30 AM
Quote: Original post by nefthy
Don't expect to get exactly the same memory/speed behaiviour from differen drivers.
Quote: Original post by nefthy
The creation overhead is less than drawing the model once, since nothing is drawn. If you draw a model more than a couple of times it should be worth it and since you usualy draw somthing like 60 frames per second they would payoff preaty fast.
Well, I want to bonk on that. On my system display list creation cause noticeable hiccups on rendering. In some cases I have been able to read the "generating display list" string.
Personally I don't raccomand you to do this on the fly just as you wouldn't use TexImage on a per-frame basis.
The fact that COMPILE does not draw does not imply the whole thing is a nop nor it is faster than drawing. In fact, I would rather expect some checks to occur and data to be transferred.
I also never heard of applications which created display lists on the fly.
For this kind of applications, maybe a DYNAMIC vertex buffer is what you really need.
Previously "Krohm"
161
July 09, 2005 08:50 AM
Display list will always be faster provided that you...
Initialize the Displays once ie in InitGL();
And then use it using CallDisplayList();
IF however you need dynamic display Creating Display lists each frame just because your going 2 render it 10 times might not be worth it
Initialize the Displays once ie in InitGL();
And then use it using CallDisplayList();
IF however you need dynamic display Creating Display lists each frame just because your going 2 render it 10 times might not be worth it
----------------------------http://djoubert.co.uk
184
July 09, 2005 12:55 PM
Quote: Original post by Krohm
Well, I want to bonk on that. On my system display list creation cause noticeable hiccups on rendering. In some cases I have been able to read the "generating display list" string.
Personally I don't raccomand you to do this on the fly just as you wouldn't use TexImage on a per-frame basis.
The fact that COMPILE does not draw does not imply the whole thing is a nop nor it is faster than drawing. In fact, I would rather expect some checks to occur and data to be transferred.
I also never heard of applications which created display lists on the fly.
For this kind of applications, maybe a DYNAMIC vertex buffer is what you really need.
You are right. I didn't ment to imply that creating them on the fly is a good idea :) Nor that creation is for free. Just that it isn't terribly expensive. the checks that need to be made shouldn't be much different from the ones that are made if you draw in imidiate mode so the time to create a list should be less than drawing the same thing to screen.
Anyway:
Static geometry: display lists created ahead of time
Dynamic geometry: VBO's
5,051
July 10, 2005 07:14 AM
Then I have to give you my apologies, I fear I misunderstood your post. Good to know we reached an agreement anyway.
Previously "Krohm"
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement