[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Re: WebGL spec modifications for D3D

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

Something like:

      glPosition = A * B * C ;
      D = B * C ;

...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 12:29 PM, Daniel Koch wrote:
>> Hi folks,
>> The problem is that there is nothing like the "invariant" keyword in
>> D3D9 HLSL (or even D3D10 HLSL for that matter) that I am aware of.
>> In practise, there must be some form of invariance guaranteed by d3d9
>> (especially for position), since I know of many games which use
>> multi-pass rendering algorithms which work just fine.  The difficulty
>> lies in figuring out exactly what is guaranteed by D3D9, since we've
>> been unable to find any sort of public documentation or discussion of
>> these issues.  However, even if there is position invariance, this
>> does not provide a mechanism to toggle invariance on and off on a
>> per-variable basis as is required in GLSL.
>> The closest thing we've been able to find is a SIGGRAPH article on
>> D3D10 from Microsoft.
>> (http://download.microsoft.com/download/f/2/d/f2d5ee2c-b7ba-4cd0-9686-b6508b5479a1/Direct3D10_web.pdf)
>> They briefly allude to this problem in section 5.4:
>>     "We considered several solutions for how to specify invariance
>>     requirements in the source code itself, for example, requiring
>>     that subroutines be compiled in an invariant fashion even if they
>>     are inlined. However, our search ultimately led us to the more
>>     traditional route of providing selectable, well-defined
>>     optimization levels that must also be respected by the driver
>>     compiler."
>> 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
>> (https://code.google.com/p/angleproject/) 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: