Hi Mathias, 2010/6/28 Mathias Fröhlich <[email protected]>: > So, ok, we will get state sorting for the fixed function pipline state > attributes because of these being traditionally sorted in the state graph. > Ok, and the additional non fixed function shader snipets will be sorted > because of being such state attributes too. > Right?
Yes, even if we tweak the API a bit in StateSet any new elements will sorted virtue of being in StateSet. Whatever we do StateSet's will remain the container for all things state in the scene graph, and the what basis of coarsed grained state sorting and lazy state updating that the OSG provides by default. > So in effect you will know the final shader combination for a render leaf at > cull time. > Right? Yes, once you've traversed down the graph to the osg::Drawable leaves you know all the state inheritance and can compute the final program and uniform combination that will be required. > Wouldn't it be better to match the final shaders programs at cull time instead > of draw time? The only reason there might be an advantage is that if you draw traversal was more CPU limited than the draw. In general I would expect the cost of selecting the appropriate programs during draw will be very low relative to the cost of dispatching the data itself. The only part that might be expensive is the composition of the shader mains and then compiling these main shaders, but again the cost of composing the main shaders is likely to be much lower than the OpenGL side of compiling them, and you have to do the compiling in the draw traversal any so the saving again is likely to be be pretty small if detectable. Doing more work in the cull will mean we'll have to pass more data to draw which itself may result in a performance overhead as the extra data structures will need to be dynamically allocated/destroyed. Right I want to get things working, the API and the backend are going to be new and complex enough that I want to take the route of least resistance and not worry to much about small possible optimization. Moving more work into cull might be an optimization that would be worth doing, but then it could just as easily be worse for performance. A more clear cut optimization would be to have a NodeVisitor that we can run on the scene graph after it's loaded and then work out the likely shaders that will be combined and from this what shader mains we'll need to compose during rendering, from this we could populate the cache and precompile both the user/fixed function emulation shaders and the newly created shader mains. The draw traversal would then just select from this cache. > ... which would only possible if the state attributes compose call might not > work on the State object itself, but on some to be defined object that is > used by the cull visitor to combine/collect/map/hash the shaders. Once we > emit a render leaf to the render graph, the final shader program is attached > to the render leaf and just used during call. > Sure, if a new combination appears this one needs to be compiled/linked first. We'll once we have a working shader composition API and implementation checked in you can start experimenting with different back-end implementations to your hearts content, if you find something useful then you'll be able to provide nice benchmarks to illustrate it's value :-) Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
