Sorry, no. I don't have an example of the problem easily to hand - I've changed jobs twice since the last time this happened to me - and it presumably hasn't happened since then because I've been using ftransform. The general form of a worst-case 'invariance problem' shader would likely be something that does the vertex position calculation in several steps (maybe something like Skeletal Mesh animation where there are four weighted bone transforms, then a separate modelview transform - and finally a separate perspective transform...and something that might cause the compiler to do some 'clever' optimization...such as using the intermediate result of the bone transforms to transform the Normal/Binormal/Tangent. Something like: glPosition = A * B * C ; #ifdef BEAUTY_PASS D = B * C ; #endif ...with the conditional code turned on, the compiler might rearrange the beauty pass to: D = B * C ; glPosition = A * D ; ...and calculate the depth pass as: temp = A * B ; glPosition = temp * C ; ...reversing the order of A*B*C from A*(B*C) to (A*B)*C ....which could obviously produce answers that are different in the least significant bit of glPosition between the two passes. But getting that to happen without a lot of internal knowledge of how the shader compiler optimizes is essentially a matter of blind luck. It's really tough to come up with examples (unless, of course your game is going gold next week and suddenly everything breaks because someone changed a shader constant someplace). But sadly, having an example that breaks under OpenGL (if you don't use ftransform or invariant) - and then showing that this same exact example DOESN'T break under D3D doesn't in any way demonstrate that some other example wouldn't break. The way these compilers optimize varies from platform to platform even for the same hardware vendor...so unless you have a cast-iron guarantee of invariance - no amount of "Look! This example doesn't break!" would be convincing proof of a non-problem. I've gotta say though - Microsoft's "solution" (as quoted below) is just lame! They are essentially saying "Well, you can solve the problem by turning off shader optimization"...but that means that you have to have the entire shader pessimally compiled just to stop a one or two line problem! Whoever thought THAT was an adequate response totally didn't understand the scope of the problem! When this problem strikes - it affects every single shader the project uses - since they all need to manage multi-pass correctly. -- Steve > On 07/13/2010. >> >> The closest thing we've been able to find is a SIGGRAPH article on >> D3D10 from Microsoft. >> () >> They briefly allude to this problem in section 5.4: >> >> "We." >> >> My assumption is that D3D9 must have had similar requirements. >> >> The version of Cg that was open-sourced is quite archaic at this >> point. The ANGLE compiler is open-sourced >> () and is based off the 3DLabs >> GLSL compiler. It compiles GLSL ES to HLSL9 which is then compiled >> to D3D9 byte-code using D3DXCompileShader. A future extension to >> ANGLE could be to generate D3D9 byte-code directly. However, even >> D3D9 bytecode is still an IL and there is no guarantee that the >> hardware executes those instructions exactly (and I know there are >> implementations which do compile/optimize this further). >> >> The issue raised about ftransform in CG and GLSL and position >> invariance was primarily an issue when using fixed function and >> shaders together, and it was indeed a very common problem. This is >> also why the "position_invariant" option was added to the >> ARB_vertex_program assembly extension. Examples of this occurring in >> shader-only applications are much more difficult to come by. >> >> Ideally, an example program which does exhibit invariance issues in >> webgl (or GLSL or GLSL ES) would be available to demonstrate that >> this is actually a real problem for webgl. If that existed, we could >> verify whether or not ANGLE on D3D9 has such problems, or if it just >> works. >> >> Steve Baker: do you have any such examples, or would you be able to >> put one together which demonstrates this problem? >> >> We are continuing to investigate the guarantees provided by D3D in >> this area and a concrete test case showing such issues would be >> invaluable for this. >> >> Thanks, >> Daniel ----------------------------------------------------------- You are currently subscribed to public_webgl@khronos.org. To unsubscribe, send an email to majordomo@khronos.org with the following command in the body of your email: