Hi John, FYI, Roland's scheme does use a cache. I am however concerned about the performance of the build of shaders and lookup into the cache. Whatever scheme we end up with will need to perform as close as we can get it to the current fixed function pipeline scheme. This is a challenge as even without any shader composition in play - for instance running osgUtil::ShaderGen results in slightly lower performance on big databases than just running with the fixed function pipeline, doing extra runtime shader composition will only add to this cost.
As part of the shader composition work I believe we'll need to look at lowering the CPU overhead of managing uniforms and shaders, and when we add the shader composition on top the shader composition and selection from cache osg::Program will need to be as efficient as we can make it. It's no easy task. W.r.t discussing the topic on osg-users, I don't want to open out the debate until I've got a better handle of the issues myself. Community users reviewing the VirtualProgram/osgshadercompositor, osgUtil::ShaderGen and Roland's submission on shader composition would all be good to do before we all dive into a discussion. Robert. On Wed, Jun 23, 2010 at 8:10 AM, PCJohn <[email protected]> wrote: > Hi Robert, > >> I would appreciate others having a look at Roland's implementation as >> well. > > I took a look at Rolands code some time ago as I built my own simple shader > composition for myself as well. The problems, I found myself with shader > composition is that I often need to customize the shaders. Many people may > want to keep functionality similar to OpenGL pipeline, thus they would > prefer to use Gouraud shading. Me, I want to use Phong shading. One person > may prefer Blinn-Phong (half-vector) specular reflection, while I prefer > Phong reflection (reflection vector). Some people would want to include > Shadow maps that needs their small piece of code in fragment shader. Others > as me, look for shadow volumes in the future while they considers using > geometry shaders. > > In my opinion, the most difficult part of the design would be to allow a > programmer to make all these things and to add even more of them in the > future, based on the craziest (but meaningful) ideas of the programmers. > > One more experience from me: Shader compilation is time expensive work by my > experience. Say, it is a real difference to compile twenty shaders or > compile one and reuse it twenty times from cache. It would be nice to have a > cache and if the shader of particular parameters were already generated, it > would be reused. (Not sure, if Rolands submission includes cache feature.) > > Looking forward to have a shader composition in OSG! > John > > BTW: Sending copy to OSG-discussion as well, for others input. > > > Robert Osfield wrote: > > In terms of the final approach I merge, I would like to retain the > flexibility of the OSG current StateAttribute + GL mode approach, this > is already a form of state composition that has all the > inheritance/compositional behavior that I'd like to see, but we > currently rely upon the GL drivers to do the mapping fixed function > pipeline to shaders for us. Roland's approach does provide something > similar to this, am I'm still learning about the implementation > details so can't yet comment in full of how close it gets. > > I would appreciate others having a look at Roland's implementation as well. > > Robert. > > On Tue, Jun 22, 2010 at 12:56 PM, Wojciech Lewandowski > <[email protected]> wrote: > > > Hi, Robert > > I hope you will also look at Virtual Program in shader composition example. > I am not trying to sell the implementation but I really would like to see > shader composition simple and easy to use and I think that VirtualProgram > approach could be seen as such fairly simple interface. > > I was hoping that current osg::Program could be extended to allow incomplete > shaders like VirtualProgram allows. In that case VirtualProgram could be > removed. OSG could solve shader completness in similar way as uniforms are > handled: neccessary uniforms are selected and applied when program is > applied. > > I think shaders could be selected and compiled in the same moment ie when > program is applied and using similar logic and handling as uniforms. We > would need to have the functional name for the shader to select shaders used > by program. That name would work bit like uniform name. It was "semantics" > parameter in VirtualProgram but some other shader names could be used as > well for this purpose. > > And the other subject I think may affect your work are Open GL 4.0 > subroutines. Lets make the shader composition in OSG future compatible with > this concept. > > That are only my 2 cents. I don't want to start any fierce discussion. I > will accept a solution you would select as most appropriate. > > Cheers, > Wojtek > > -------------------------------------------------- > From: "Robert Osfield" <[email protected]> > Sent: Monday, June 21, 2010 7:02 PM > To: <[email protected]> > Subject: Re: [osg-submissions] Shader composition > > > > Hi Roland, Johannes et. al, > > I've mostly cleared my desk for other tasks so am now ready to dive > back into the topic of shader composition. My plan this week is to > dig out my own design notes, and do a review of Roland's submissions > and experiment with the runtime usage/results of the submission to get > better idea of the problem domain and the submission itself. > > Any updates on the submission or any thoughts on shader composition > would be most welcome. Once I'm more back up to speed on Roland's > submission and my collected more of my own thoughts together I'll > strik a discussion on osg-users about shader composition, but feel > free to chip in on this thread if you have comments about Roland's > submission. > > Cheers, > Robert. > _______________________________________________ > osg-submissions mailing list > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > > > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
