I ran across an old thread recently regarding redundant state changes and how evil they are.What noone brought up though was how expensive they get when encapsulated in a display list.Would a lot of state changes in a disp. list be much more expensive than just one? There obviously wouldn’t be any overhead for parameter checking etc.
So if for each material/shader in your scene you execute a display list setting say 20 states(texture,blend, all of it) and render all geometry will but also try to sort shaders so that as many of the state changes (esp. expensive ones) as possible will be rendundant,would that work?It certainly seems easy and clean to code.
Remember that display lists are ment to be a kind of optimizer for what you want to feed to GL. The driver should be smart enough and do it’s job, even if you send it a lot of crap.
As for switching shaders beeing costly or not, that was asked by jwatte some time ago but I think the question was left open.
Dont forget about nested display lists if you have parts that need to be dynamic.
When I’m talking about shaders I actually mean just a structure containing GL state need to draw am object. So If we follow this naive (but nice) approach and just compile these shaders into display lists,were looking into setting say about 30+ states per shader(lighting state, rasterization state, texture object state, texenv state, pixel ops state and framebuffer control state).Even assuming that GL validation will be performed for each state category and not for each single state changed there will be a lot of validation performed per shader even though most shaders will probably just change states in about three categories(lighting for materials, texture object and probably pixel ops) most of the time.This should be even worse considering that all this state changing will be done per pass not shader(so more than once per shader).So the real question is: is all of the above true(regarding inner gl operation)?Is this naive approach of just converting shaders into display lists usable?It sure is simple and all but I doubt it or everyone would be doing it.
Maybe Matt could enlighten us on this?
How would you minimise redundant state changes using a display list approach?
How is this portable to other API’s?
Display lists are an ugly ‘solution’, in my opinion.
I would not suggest using Display Lists to change state. It seems, from experience with modern drivers, that DL’s are optimized for sending geometry, not for sending state changes. I would imagine that, if a state change has no analog in hardware, it must sync the entire graphics pipeline and CPU before it can change that state. Driver writers are intensely stubborn about not revealing any information that could help us make informed decisions in this matter.
Another problem comes from having to specify so much state. Because GL is a state machine, you must specify, in each DL, all of the state that matters for rendering that object. In short, you are always going to have state changes, even when they are redundant.
Yes, I’d have redundant state changes.Lots of 'em.But much that makes a state change slow(like checking wether we’re inside glBegin/glEnd and checking if the arguments are valid etc.) would be avoided.There would still be the need for checking if HW rendering is still possible and sending the commands to the HW but that would happen once per shader pass.I doubt this would be efficient myself but I thought it might be worth asking.
How is this portable to other API’s?
Not that I care that much about this but there is something like this in DX I believe although it can be used to compile state changes only.
Display lists are an ugly ‘solution’, in my opinion.
In this case it seems to me that disp. lists fit in quite nicely.If you think of it the shader in text form is the source code.This gets parsed and then compiled to opcodes inside a display list.All you have to do then is exec the shader(dl) and you’re all set up.