Support for Cg's glslX and hlslX profiles added

[CABAListic]

Yesterday I pushed a couple of changes to the Cg ProgramManager to the repository. In Cg shaders you can now enable the profiles glslv/glslf/glslg and hlslv/hlslf. With these profiles Cg generates output in GLSL or HLSL that is then forwarded to an appropriate high level shader.

While the hlslX profiles probably aren't that interesting in practice, the glslX profiles are. For non-Nvidia cards the supported Cg profiles in OpenGL were basically restricted to the arb1 profiles, so that's a huge drawback to using Cg if you wanted to use it with OpenGL and AMD cards. The glslX profiles fix this problem as they should work for any graphics card.

You can check out the changes in the newly created v1-9 branch. If you want to follow development for the next major Ogre version 1.9, that'll be the branch to follow.

P.S. The glslg profile doesn't work correctly, yet. Once we figured out what is going wrong, we'll fix that one. But glslv/glslf appear to work quite well so far.

[bstone]

Nice. Even not being an OpenGL fan I see this as a useful improvement.

[duststorm]

That is a great feature! Thanks a lot for that.
This will relieve me from the arb limitation on linux with intel graphics.

Did you have to break much of the API to get this into the shader architecture?
I'll check it out later.

[CABAListic]

No, there have been no API changes, except that I had to add an option to the GLSL shaders to assign matrices in row-major order, because that's what Cg's output assumes. But as long as you don't enable that option (for specific shaders), you won't notice any change.

The solution is, however, somewhat hacky. Cg intends its output to be used with its own API for GL or D3D to actually bind and use the shaders. But this doesn't fit our own pipeline, so instead the CgProgramManager always forwards Cg's output to an appropriate shader in the D3D/GL rendersystems. While this has worked fine for low-level output, I had to hack the solution to work for the high-level outputs. Cg produces some weird output at first that needs to be postprocessed before it can work in our pipeline. This does bear the danger of possibly breaking if Nvidia ever changes anything in that regard. We'll just have to keep watch of any such changes.

Indeed, it was tricky to find out all the pitfalls that were needed to get Cg's output to work. Evidence of this is the fact that I first tried to add these profiles as far back as 2009. I had gotten hlslX profiles working then, but not the glslX profiles. I abandoned it because it seemed hopeless, but this time I was persistent and figured it out

[duststorm]

Great job. I can imagine it must have been a lot of hacking to get it working.
It was probably also very hard to come by any useable information

[PhilipLB]

I updated from trunk today with this and can't compile anymore, he can't find "CG_TEXUNIT16" and upwards. Do I need to update some dependencies?

[CABAListic]

Cg maybe? I had some version of Cg 3.0 (which is not the most recent), so might be that older versions don't work anymore. Judging from the error I could probably fix that relatively easily if necessary.

[PhilipLB]

I'm using a pretty old version of the dependencies, OgreDependencies_MSVC_20101231.zip from http://www.ogre3d.org/tikiwiki/tiki-ind ... requisites

[CABAListic]

Yeah, that probably has a pre-3.0 version of Cg.
Is the error you mentioned the only one you get? If so, we could put an ifdef around that particular block of code based on the Cg version.

[PhilipLB]

Yep, those missing defines are the only errors.
Wheras I'd prefer to update my dependencies. Is there any place where I can find more recent ones?

[CABAListic]

https://bitbucket.org/cabalistic/ogredeps

[PhilipLB]

That worked, thx.

[sparkprime]

I owe you a beer!

I can get this by merging in changes from trunk into my ogre branch?

Can you document the postprocessing you had to do for the cg output?

[CABAListic]

The changes are accessible in the v1-9, v2-0 and default branches of the Ogre repository, so if you're using any of those branches, just check out the latest revision. For v1-8 you'll have to backport the changes.

For the post-processing basically I had to do two things: For one, Cg replaces all variable names from the original shader and prepends them with an underscore and (sometimes, depending on Cg version) adds numbers to the end. I needed to revert these changes because otherwise assigning values to those variables in the GLSL shader wouldn't work.

The other problem is that Cg chooses a weird way to translate matrix types to GLSL. For example, a variable declaration

Code: Select all

float4x4 someMatrix;

is translated by Cg to GLSL:

Code: Select all

vec4 someMatrix[4];

But Ogre expects the mat4 type instead, so binding matrices doesn't work unless this type declaration is replaced.

[mysterycoder]

The other problem is that Cg chooses a weird way to translate matrix types to GLSL. For example, a variable declaration

Code: Select all

    float4x4 someMatrix;

is translated by Cg to GLSL:

Code: Select all

    vec4 someMatrix[4];

But Ogre expects the mat4 type instead, so binding matrices doesn't work unless this type declaration is replaced.

I've had to do this manually myself when converting shaders from Cg to GLSL, I think its because GLSL indexes differently. Also, it allows the GLSL to skip a transpose call. See http://www.ogre3d.org/forums/viewtopic. ... 75#p435365 where I was passing a dual quaternion (8 components) in as a float2x4.

[CABAListic]

Yes, Cg produces output that expects matrices to be in row-major. So I did add an additional option to GLSL shaders to specify that matrices are passed in transposed (or more accurately skip the transpose on bind, since Ogre matrices are already transposed from GL's point of view). I named the parameter 'column_major_matrices' with default true, which I chose because HLSL already has that option and it seemed appropriate. On second thought, maybe the name is not entirely correct, but the effect should be similar.

In any case, that's not the issue with the type declaration. You still need to replace float4 someMatrix[4] with mat4 someMatrix, or else Ogre's binding won't work, no matter the order of the matrix.

[mysterycoder]

You still need to replace float4 someMatrix[4] with mat4 someMatrix, or else Ogre's binding won't work, no matter the order of the matrix.

Yep, I understand. I was just pointing out that we probably can't get Cg to output to GLSL with the equivalent matrix type because of the possibility of the shader indexing the matrix directly rather than just multiplying.

edit: On a side note, this looks great! I remember trying to set these options before to no avail, thanks so much for adding this.

[sparkprime]

I assume cg uses column major, so instead of rewriting the indexes in the compilation process (which could get tricky in some cases), it is compiling to the equivalent of column major in gl, which is to use these 4 float4s. That way, the bulk of the shader code remains the same.

What I don't understand is why distinguish between 16 floats, 4 float[4] and mat in Ogre when uploading the uniforms? They should all be equivalent, if you consider the transposedness of the matrix to be an orthogonal attribute. In some sense tihs seems like a style issue that is even reminscent of structural typing vs nominal typing.

edit: 1000th post

[CABAListic]

For matrix types Ogre uses specific bind calls for these matrix types. I don't know how they work, but they definitely don't work if the type is declared as an array of vec4 instead of a mat4. (Well, it's not that they fail per se, it's just that the shader produces garbage.) This is not exactly my area of expertise, so I just hacked it this way so that it would work

[sparkprime]

OK I merged Ogre into my fork, fixed up a few things. Only one thing is broken so far and that is colour_op_ex. It seems the material attributes are set property (so not a problem with scripts) but the pass is rendered white. I'm not really interested in debugging that as I am going to move away form OverlayElements soon, and this is the last place I'm still using the fixed function pipeline. I just changed to use a 1x1 texture as a workaround for now. Going to rebuild and test on windows and then look into using the glsl target...

[CABAListic]

Hm, I don't think the Cg work broke that as it doesn't touch anything outside of shaders. But if that problem is present also in our vanilla repository, I'd welcome a bug report nonetheless

[sparkprime]

It could be a bug introduced by changes in my fork, but I suspect a regression in Ogre itself. Unless any of the samples use colour_op_ex? Should be easy enough to replace one of the texture units in a sample material with a solid red colour and see if it works.

edit: I only tested in GL too.

These were my materials (the latter one works)

Code: Select all

abstract pass overlay_pass {
    scene_blend alpha_blend
    fog_override true
    texture_unit {
        colour_op_ex source1 src_manual src_current 1 1 1
        alpha_op_ex source1 src_manual src_current 1
    }
}


material system/ConsoleBorder {
        technique {
                pass : overlay_pass {
            texture_unit {
                    colour_op_ex source1 src_manual src_current 0 0 0
                    alpha_op_ex source1 src_manual src_current .8
            }
                }
        }
}

material system/Console {
        technique {
                pass : overlay_pass {
            texture_unit {
                    colour_op_ex source1 src_manual src_current 0 0 0.2
                    alpha_op_ex source1 src_manual src_current 0.7
            }
                }
        }
}

material system/CrossHair {
        technique {
                pass {
            alpha_rejection greater 0
            fog_override true
            texture_unit {
                    texture "system/Crosshair.bmp"
                    tex_address_mode clamp 
                    filtering point point none
            }
                }
        }
}

[sparkprime]

glslv and glslf seem to have a lot of debug output?

[CABAListic]

Yes, they log Cg's output before and after my cleanup. I will disable those outputs eventually, but it's handy to have as long as there may still be problems left (glslg isn't working quite right, yet).

[sparkprime]

OK I got a crash when reloading shaders, gonna look into that. The visuals are also pretty screwed up, but I've got thousands of lines of shaders and deferred shading going on so will have to dissect it a bit to see what's going on.

Code: Select all

#0  0xb7fdd424 in __kernel_vsyscall ()
#1  0xb71911ef in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0xb7194835 in __GI_abort () at abort.c:91
#3  0xb71cc2fa in __libc_message (do_abort=2, fmt=0xb72c43bc "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:201
#4  0xb71d6e42 in malloc_printerr (action=<optimized out>, str=<optimized out>, ptr=0xad32150) at malloc.c:5007
#5  0x080956bf in deallocateBytes (ptr=<optimized out>) at ../../dependencies/grit_ogre/OgreMain/include/OgreMemoryStdAlloc.h:79
#6  deallocate (ptr=<optimized out>, this=<optimized out>) at ../../dependencies/grit_ogre/OgreMain/include/OgreMemorySTLAllocator.h:140
#7  _M_deallocate (__p=<optimized out>, this=<optimized out>, __n=<optimized out>) at /usr/include/c++/4.6/bits/stl_vector.h:156
#8  ~_Vector_base (this=0xa0bd3a8, __in_chrg=<optimized out>) at /usr/include/c++/4.6/bits/stl_vector.h:142
#9  ~vector (this=0xa0bd3a8, __in_chrg=<optimized out>) at /usr/include/c++/4.6/bits/stl_vector.h:351
#10 Ogre::GpuProgramParameters::~GpuProgramParameters (this=0xa0bd3a8, __in_chrg=<optimized out>)
    at ../../dependencies/grit_ogre/OgreMain/include/OgreGpuProgramParams.h:1169
#11 0x080957dc in Ogre::SharedPtr<Ogre::GpuProgramParameters>::destroy (this=0xbfffd46c) at ../../dependencies/grit_ogre/OgreMain/include/OgreSharedPtr.h:232
#12 0x0845aaa7 in release (this=<optimized out>) at OgreMain/include/OgreSharedPtr.h:218
#13 ~SharedPtr (this=<optimized out>, __in_chrg=<optimized out>) at OgreMain/include/OgreSharedPtr.h:155
#14 Ogre::GpuProgramUsage::recreateParameters (this=0xaec2808) at OgreMain/src/OgreGpuProgramUsage.cpp:162
#15 0x082c73d8 in Ogre::Resource::_fireLoadingComplete (this=0xb06f568, wasBackgroundLoaded=false) at OgreMain/src/OgreResource.cpp:366
#16 0x082c81fa in Ogre::Resource::load (this=0xb06f568, background=false) at OgreMain/src/OgreResource.cpp:266
#17 0x082c7526 in Ogre::Resource::reload (this=0xb06f568) at OgreMain/src/OgreResource.cpp:329