Hi Bruce,
On Tue, Jun 29, 2010 at 5:41 PM, Bruce Wheaton <[email protected]> wrote:
> One is that GLSL is quite poor for initialization. The main problem with this
> is if you were to enable a shader with, say, 8 uniforms, there wasn't, until
> very recently, a way to initialize them, and the stateset enable calls
> generally are single parameter. So in with the definitions of a new possible
> shader mode, and the attributes/uniforms it needs, we will probably need a
> way to initialize any uniforms that the shader needs, but the user may not
> specifically set. Default values, in essence, but also just non-random values.
Default values in the OSG are provided by default constructed
osg::StateAttribute, and this is how I'd expect the uniforms to
continue to be set, we want to customize the defaults for a particular
scene graph we simple assign the appropriate StateAttribute of Uniform
to the topmost StateSet in the scene graph, or attached the viewer's
Camera.
> Second is that, although your point about trying linking on the fly and then
> seeing what happens is a good one, I'm worried about the fact that different
> GPUs, drivers, OS's etc have very different costs for this, (all of which
> would be too much in some circumstances).
>
> I was thinking that we could maybe build in the ability to use a conditional
> in each shader as a matter of course. That way the program object can be left
> as is, and sorted correctly, and the conditional uniform set instead of
> re-linking. The comparable mechanism to me is the 'dynamic' setting of nodes,
> or the 'useDisplayLists' setting.
>
> So for example, instead of just:
>
> vec4 applyBlur (vec4 inPixel
> {
> return inPixel;
> }
>
> or
>
> vec4 applyBlur (vec4 inPixel)
> {
> vec4 outPixel;
> // do costly blur
> return outPixel;
> }
>
> the non-placeholder version might have:
>
> vec4 applyBlur (vec4 inPixel)
> {
> if (!blurEnabled)
> return inPixel;
>
> vec4 outPixel;
> // do costly blur
> return outPixel;
> }
>
> I hope you see the advantages - far more shader sharing and less compilation
> in a complex situation.
My current expectation is that we'll leave the choice of osg::Shader
and osg::Uniform usage to a each specific StateAttribute subclass or
ShaderSet configuration, and the have the main injection code be the
only part that is tightly formalized. So depending upon what the
StateAttribugte/ShaderSet does it'll make the choice between using
more uniforms and sharing more osg::Shader, or less uniforms and more
osg::Shader.
In terms of performance variation between compilers I would expect how
they handle uniforms will be one the greatest differences - some might
choose to treat some uniforms as constants and recomple/relink
programs and optimize away conditional branches when you change the
uniforms, others might treat uniforms as regularly changing attributes
and leave conditional branches in the code.
I suspect that depending on the complexity of the shaders in play
we'll get a different balance between whether it's better to have more
Program+Shaders and less Uniforms vs less Program+Shaders and more
Uniforms. Perhaps we should even consider having multiple
implementations to explore just where the balance lies on different
hardware/drivers. It could be that we might even want to have
multiple implementations supported directly and be able to choose
between them at runtime to optimize for each OS/driver/hardware
configuration.
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
