[osg-users] ProgramBinary and shader composition - does it work?

[OpenSceneGraph Users]

Hello Robert,

I was looking in the glProgramBinary support in osg::Program. I don't *think* it is integrated with your "pragmatic" define-based shader composition system. Specifically there doesn't seem to be a way to associate a ProgramBinary with a particular defineString at the PerContextProgram level.

Am I right? And if so will you consider a submission to make this work?

Glenn Waldron / osgEarth

[OpenSceneGraph Users]

Hi Glenn,

On Wed, 19 Feb 2020 at 17:56, OpenSceneGraph Users <osg-...@lists.openscenegraph.org> wrote:

I was looking in the glProgramBinary support in osg::Program. I don't *think* it is integrated with your "pragmatic" define-based shader composition system. Specifically there doesn't seem to be a way to associate a ProgramBinary with a particular defineString at the PerContextProgram level.

Am I right? And if so will you consider a submission to make this work?

When writing the #pragma(tic) shader composition functionality I was just focused on conventional GLSL compiled shaders, I didn't consider glProgramBinary, so no idea of how it might interact, I don't expect it would would work though as the main task of shader composition is compositing the shaders to compile and compiling these at runtime.

Is there a reason why you are trying to the the glProgramBinary path?

Robert.

 

[OpenSceneGraph Users]

Robert,

I have an application with several complex shaders. According to the profiler some of them take a while to link (glLinkProgram), long enough to cause a frame drop. This app cannot tolerate any frame drops so I was looking into glProgramBinary as a possible mitigation. I'm open to other ideas of course.

Glenn Waldron / osgEarth

_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[OpenSceneGraph Users]

Hi Glenn,

The way I'd tackle the issue of compilation of shaders taking a long time is to avoid doing it frame time, doing as much work in scene graph setup/compilation.

For you usage case I assume you have a complex shader with many different constant inputs either controlling code paths or values, and the scene graph is configuring these as the values change provided by the scene graph via the #PCS defines.  If you can work out what range of different defines you will need then build a subgraph with each of these combinations and the sharing osg::Program that depends upon these then compile this subgraph, once it's all compiled you can discard it save for the osg::Program that you then reuse in your main application.

This approach should in theory populate the osg::Program with all the GLSL program combinations that you will need and the OSG can internally just use these when rendering your main scene graph.

Robert.