"Unified" Shader Definitions

· by Steve · Read in about 4 min · (820 Words)

Ok, I’ve ended up slip-sliding into doing more work this week than I was really supposed to. Hmm - I guess I love my work far too much than is healthy. 😉 My excuse (which makes my wife roll her eyes) is that I’ve been picking off stuff that’s not that demanding, and it’s stuff I’ve wanted to add anyway. Well, here’s what you get from today’s commit: unified program definitions.

What’s that? Well, first a bit of background. We’ve found that whilst Cg is great for targetting both DirectX and GL with one program, the compiler isn’t always that great at sequencing the assembler it produces, particularly pixel shaders that need to do a lot of texture fetches. This has resulted in people (including us on the OGRE team) using specific HLSL and GLSL programs for the more complex effects. Cg 1.5 tries to do something about this, but has some other issues too so at the moment I’m sticking to HLSL and GLSL for the hard stuff. Recently that’s included HDR and the shader-based texture shadow effects.

The only problem with this has been that until now, it has required you to create multiple material techniques. OGRE’s technique system used for many things, including material LOD, hardware fallback, and for scheme-switching (say, flipping to unbounded HDR shaders, or other things). This is all fine when the techniques are actually different in their outcome, but using them to just automatically flip between totally equivalent GLSL and HLSL pipelines was really too cumbersome - you had to duplicate a lot of definition and it got worse the more complex your material got.

So, now you can skip all that and define a ‘unified’ program which wraps many equivalent programs:

`Ok, I’ve ended up slip-sliding into doing more work this week than I was really supposed to. Hmm - I guess I love my work far too much than is healthy. 😉 My excuse (which makes my wife roll her eyes) is that I’ve been picking off stuff that’s not that demanding, and it’s stuff I’ve wanted to add anyway. Well, here’s what you get from today’s commit: unified program definitions.

What’s that? Well, first a bit of background. We’ve found that whilst Cg is great for targetting both DirectX and GL with one program, the compiler isn’t always that great at sequencing the assembler it produces, particularly pixel shaders that need to do a lot of texture fetches. This has resulted in people (including us on the OGRE team) using specific HLSL and GLSL programs for the more complex effects. Cg 1.5 tries to do something about this, but has some other issues too so at the moment I’m sticking to HLSL and GLSL for the hard stuff. Recently that’s included HDR and the shader-based texture shadow effects.

The only problem with this has been that until now, it has required you to create multiple material techniques. OGRE’s technique system used for many things, including material LOD, hardware fallback, and for scheme-switching (say, flipping to unbounded HDR shaders, or other things). This is all fine when the techniques are actually different in their outcome, but using them to just automatically flip between totally equivalent GLSL and HLSL pipelines was really too cumbersome - you had to duplicate a lot of definition and it got worse the more complex your material got.

So, now you can skip all that and define a ‘unified’ program which wraps many equivalent programs:

`

At runtime when your materials reference this unified material, OGRE will automatically pick the delegate that’s supported by the current rendersystem / hardware. It’s almost like a mini-technique system, but it’s only for one program and can only be used when the programs are totally interchangeable (ie they have all the same inputs & outputs). I’ve used this to simplify my HDR shaders and I intend to use it on my depth shadowmapping system when I write the GLSL path (which is why this feature occurred to me now). It nicely addresses a very real problem, leaving the full technique system for the more complicated things where the results are actually different. Hope it’s useful to you too.

Doing this also caused me to iron out a historical quirk in the way that GLSL and HLSL addressed arrays of uniform parameters. You can now access the arrays in GLSL the exact same way as you did in Cg / HLSL, so that should resolve some issues - this affected my gaussian bloom shaders when I switched to a unified definition which is why I had to fix it 😀

On another topic - Nine Black Alps have to be one of the most underappreciated bands out there. I hadn’t heard of them at all until Pandora brought them to my attention, despite the fact that they’re a fairly recent band. I had their album ‘Everything Is’ for Christmas and it’s superb.