Hi Robert, On Monday 28 June 2010, Robert Osfield wrote: > 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. Ok.
> > 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. Ok. > > 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. Yes. > 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. True, compiling is expensive. But that is exactly what should be better done just once when a new shader combination appears. The final program should just be stored and reused once it is compiled *and* linked. I am sure that compiling a shader is expensive. But I am also sure that linking is *not* about for free. I expect that drivers will again do some optimizations once linking happens. For example there are GPU's out there which do not have jump instructions. In this case, linking must at least do inlining again. Also there are plenty of optimization opportunities that start to be available when the whole program is known. So, I expect that at link time the shader optimizer is started again and again improoves the shader code. So, what I think is that we need minimize shader compilation as well as shader *linking* as much as possible. If the implementation you have in mind really does this, then fine. If you intent to relink on about every StateAttribute::compose(osg::State&) call, I expect to run into problems. > 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. Sure, malloc is to be avoided for real time. Anyway, I am thinking more about something that computes a probably scalar key or pointer to an already existing object that is able to identify the final shader program combination in the cull stage and sets that key into the render leaf. On apply this key is taken to apply the opengl shader object containing the already finished shader program. May be this key could be the to be cached final shader program. So, no per draw dynamic memory management with this kind of approach. > 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. Ok. The only thing that might then turn out problematic is that then there is the StateAttribute::compose(State&) call which directly operates on the State object. Once this is in place, backward compatibility will never make that go away. In effect this will make a switch to a StateAttribute::compose(CullTimeShaderComposer&) call impossible... That is the reason I am thinking about that current proposal for such a long time. May be the State should provide such a 'ShaderCompositon' object as a member and you let the state attribute work on this member of the State? Then this could be moved easier if this turns out to be critical? So, again the critical thing from my point of view: If you can make sure that we never relink during draw once no new shader combination appears, I believe we are fine. Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
