PDA

View Full Version : state sorting and multipass rendering



zen
02-28-2003, 04:17 AM
Let's say we have shaders consisting of one or more passes where each pass is a collections of state changes(like texture binding,materials,etc.). Now the questions is: to sort the scene geometry in order to minimize state changes would it be better to:
a) consider shaders as atomic units, that is:
setup shader 1,draw all passes;setup shader 3,draw all passes, etc. or
b) consider passes as atomic units but not shaders, that is:
setup shader 3 pass 1,draw pass; setup shader 2 pass 1,draw pass;setup shader 3 pass 2,draw pass, etc.
In short should I draw all passes of a mesh at once?If I don't I won't be able to make much use of compiled vertex arrays but that doesn't seem so important especially since pretty soon it seems vertex objects(VAR,VAO,etc.) will be the way to go.Is it possible that the scene won't be rendered correctly though? That's the biggest problem.I don't think so but then again I don't have much experience with multipass rendering.

ckline
03-01-2003, 07:22 AM
You may find these threads helpful:
http://www.geocrawler.com/mail/thread.ph...uring&list=4856 (http://www.geocrawler.com/mail/thread.php3?subject=%5BAlgorithms%5D+Effective+usa ge+of+multitexturing&list=4856)

and to a lesser extent:
http://www.geocrawler.com/mail/thread.php3?subject=%5BAlgorithms%5D+Statebuffe ring+etc&list=4856 (http://www.geocrawler.com/mail/thread.php3?subject=%5BAlgorithms%5D+Statebufferin g+etc&list=4856)



[This message has been edited by ckline (edited 03-01-2003).]

zen
03-01-2003, 10:37 AM
Thanks for the links! The second one turned out to be especially usefull.But they still don't answer my initial question(unless the answer is somewhere in the first link and I overlooked it).That is, when multipassing over a piece of geometry, should I bind the piece and do all passes or can I just do some of them,bind another and then come back to it and finish it off.The questions are:
1)are vertex array(client) state changes(for vanilla,VAR and VAO arrays) expensive so that I should bind once and render all passes?
2)Is there any danger of artifacts etc. due to the mixing of passes of diff. geometry?

rgpc
03-01-2003, 04:09 PM
No doubt there will be 101 people who disagree with this, and 101 reasons why it may be wrong but...

I current do two passes on my geometry for shadow mapping (volumes). From my reading (so I blame cas & mark http://www.opengl.org/discussion_boards/ubb/wink.gif ) you should be able to render your entire scene (using your state sorting) and then go back to the geometry.

I am not actually using state sorting but the principle should be the same. I render a scene, which has multiple states (ie. Textures/Transforms/Reflection etc.), then I
render my shadow volumes, then I redo the scene.

And it appears to work fine (In fact I can't think of any way you could do it without having to switch states & then go back to do your second/third etc. passes.

zen
03-01-2003, 04:44 PM
That takes care of 2).Regarding 1), I doubt VARs and VAOs benefit from doing multiple sequential passes (after taking a look at the specs) so I guess sorting per shader pass and not per whole shader seems to be the way to go.

rgpc
03-02-2003, 04:19 PM
Originally posted by zen:
That takes care of 2).Regarding 1), I doubt VARs and VAOs benefit from doing multiple sequential passes (after taking a look at the specs) so I guess sorting per shader pass and not per whole shader seems to be the way to go.

I guess you have to weigh up whether you get a better performance hit from state sorting or from caching etc. (ie. doing your multiple passes sequentially per mesh). Given the size of caches and the size of the average mesh I think you'd benefit more from the state sorting.

There's probably some documentation/articles on this somewhere (the nVidia/ATI guys may know).

I think you should gain what you can out of the caching/VAR/VAO by sorting your verts/indicies appropriately and then use state sorting on top of that.

[This message has been edited by rgpc (edited 03-02-2003).]