Best way to debug WebGL shader issue on Windows

[Tibor den Ouden]

I reported two WebGL fragment shader issues in chrome on windows : 

http://code.google.com/p/chromium/issues/detail?id=158223

http://code.google.com/p/chromium/issues/detail?id=158414

I want to give it a try to investigate this myself.

I know it is probably in the angle lib (http://code.google.com/p/angleproject/).

I am currently installing the Chromium project build and will dig in.

Any ideas, tips, pointers which  would help ?

Regards, 

Tibor den Ouden

[Kenneth Russell]

Thanks for the pointers to the bugs; I think it would have taken some
time for us to find them if you hadn't pointed them out. Thanks also
for the small test cases.

I've updated the bugs indicating that they look very similar to
another bug being investigated, but your small test cases will
probably allow regression tests to be created much more easily. The
indication is a bug in Microsoft's HLSL-to-D3D9 bytecode compiler, and
changing the optimization level of that compiler when invoked by ANGLE
seems to work around the bug.

Thanks again,

-Ken

> --
> Chromium Discussion mailing list: chromium...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-discuss

[Tibor den Ouden]

k, glad to be of help.

Would it make sense to create a HLSL test example and file this at Microsoft ?

Are they still developing the HLSL-to-D3D9 compiler or is all development halted ?

Do they have a statement about this ?

Thanks,

Tibor

[Kenneth Russell]

On Tue, Oct 30, 2012 at 2:11 PM, Tibor den Ouden
<tibord...@gmail.com> wrote:
> k, glad to be of help.
>
> Would it make sense to create a HLSL test example and file this at Microsoft
> ?
> Are they still developing the HLSL-to-D3D9 compiler or is all development
> halted ?

I think it would be very useful if you would create a standalone D3D
test demonstrating the bug. However, if the bug reproduces with a D3D9
based test, then you should also create one targeting D3D11 feature
level 9 (not sure which sub-level) and see if it reproduces there. If
it does, it's worth filing with Microsoft. If not, then don't bother.
ANGLE will migrate to D3D11 in the not too distant future.

> Do they have a statement about this ?

I highly doubt it.

-Ken

> Thanks,
>
> Tibor
>
>
> On Tuesday, October 30, 2012 11:43:38 AM UTC+1, Tibor den Ouden wrote:
>>
>> I reported two WebGL fragment shader issues in chrome on windows :
>> http://code.google.com/p/chromium/issues/detail?id=158223
>> http://code.google.com/p/chromium/issues/detail?id=158414
>> I want to give it a try to investigate this myself.
>> I know it is probably in the angle lib
>> (http://code.google.com/p/angleproject/).
>> I am currently installing the Chromium project build and will dig in.
>>
>> Any ideas, tips, pointers which would help ?
>>
>> Regards,
>>
>> Tibor den Ouden
>

[Tibor den Ouden]

In relation to issue :

http://code.google.com/p/chromium/issues/detail?id=158414

I am trying to get a valid HLSL shader.

I used essl_to_hlsl with as commandline :

-b=h -s=w -o D:\Dev\angle_base\Shaders\ForLoopOptimization.frag

-b=h : output HLSL code

-s=w : use WebGL spec

Contents of input file :

void main(void) {                                        

    mediump vec4 red = vec4(1.0, 0.0, 0.0, 1.0);         

    mediump vec4 green = vec4(0.0, 1.0, 0.0, 1.0);       

    mediump int store = -1;                              

    for (mediump int i_ix = 0; i_ix < 10; ++i_ix) {      

        if (i_ix == 4) {                                 

            store = i_ix;                                

            break;                                       

        }                                                

    }                                                    

    if (store == -1)                                     

        gl_FragColor = red;                              

    else                                                  

        gl_FragColor = green;                            

}                                                        

 

Output :

 

#### BEGIN COMPILER 0 INFO LOG ####

#### END COMPILER 0 INFO LOG ####

#### BEGIN COMPILER 0 OBJ CODE ####

// Varyings

static float4 gl_Color[1] = {float4(0, 0, 0, 0)};

void gl_main()

{

{

float4 _red = float4(1.0, 0.0, 0.0, 1.0);

float4 _green = float4(0.0, 1.0, 0.0, 1.0);

int _store = -1;

{

for(int _i_ix = 0; (_i_ix < 10); (++_i_ix))

{

{

if((_i_ix == 4))

{

{

(_store = _i_ix);

break;

;

}

;

}

;

}

;}

}

;

if((_store == -1))

{

(gl_Color[0] = _red);

}

else

{

(gl_Color[0] = _green);

}

;

}

}

#### END COMPILER 0 OBJ CODE ####

But this is not a valid hlsl pixel shader, for instance I see no color semantics (like COLOR0) in the code.  

I used this code (slightly modified to compile for pixel and vertex shader model 3.0) to test :

http://www.two-kings.de/tutorials/dxgraphics/dxgraphics18.html

What am I missing ?

Is there some skeleton code which I need to add ?

(I posted this already a few weeks ago but it seems to got lost)

Tibor

On Tuesday, October 30, 2012 11:43:38 AM UTC+1, Tibor den Ouden wrote:

[Kenneth Russell]

ANGLE does more postprocessing of the compiled shader to pack varying
variables and generate semantics for the input and output variables.
See for example ProgramBinary::linkVaryings,
src/libGLESv2/ProgramBinary.cpp.

While it would be possible for you to add logging code there to print
out the final versions of all the HLSL shaders submitted to the D3D
compiler, given how simple your shader is, I think it would be easier
for you to start with some simple D3D shader example and fit your
shader into it by hand, adding inputs, outputs and their semantics as
necessary.

-Ken