Created attachment 110885 [details]
screenshot from Ubuntu Linux with Intel GPU

Created attachment 110886 [details]
screenshot from windows 8

do we have any update on this bug?
Thanks

I took a brief look, this looks good when disabling optimizations, all of them from brw_fs backend and most of the frontend running ones (everything under opt_constant_folding, except loop handling stuff which is not optimization).

Great
do we have fix for it now?
When the patch will be released?
Thanks a lot

Is there any update on this issue?
Thanks

(In reply to qiang.miao from comment #6)
> Is there any update on this issue?
> Thanks

Sorry no fix or patch available for the bug. I just made a quick look to see if bug can be pinpointed to a single location. Unfortunately this is not the case, there are likely a couple of separate issues here.

Created attachment 113212 [details]
Patch to the test that fixes the undefined variables

This is caused by undefined variables in the webGL shaders.  The attached patch to the test fixes the problem.  In short: Not a mesa bug.

Can't agree with you
Why the same code can work correctly on Windows?

If these variables areundefined variables like you said
WebGL will report error and draw nothing

+  vec2 uv = vec2(0, 0);
   vec2 motion = decode2( texture2D(sampler_fluid, uv))*pixelSize*0.75;
 
-  vec2 uv = uv - motion; // add fluid motion
+  uv = uv - motion; // add fluid motion


-  vec2 gz; // blue blur2 gradient vector
+  vec2 gz = vec2(0, 0); // blue blur2 gradient vector

Those variables are defined without initial value
There is something wrong with shader compiler on how to handle default value

(In reply to qiang.miao from comment #9)
> Can't agree with you
> Why the same code can work correctly on Windows?
> 
> If these variables areundefined variables like you said
> WebGL will report error and draw nothing
> 
> +  vec2 uv = vec2(0, 0);
>    vec2 motion = decode2( texture2D(sampler_fluid, uv))*pixelSize*0.75;
>  
> -  vec2 uv = uv - motion; // add fluid motion
> +  uv = uv - motion; // add fluid motion
> 
> 
> -  vec2 gz; // blue blur2 gradient vector
> +  vec2 gz = vec2(0, 0); // blue blur2 gradient vector
> 
> Those variables are defined without initial value
> There is something wrong with shader compiler on how to handle default value

No.

The GLSL spec says "Reading a variable before writing (or initializing) it is legal, however the value is undefined."

(In reply to qiang.miao from comment #9)
> Can't agree with you
> Why the same code can work correctly on Windows?

It works "correctly" on windows because their shader compiler probably puts that vec2 in a different register that just so happens to be zero.  That's a matter of luck not default values.  As matt said,

(In reply to Matt Turner from comment #10)
> The GLSL spec says "Reading a variable before writing (or initializing) it
> is legal, however the value is undefined."

Therefore, it's perfectly legal for us to give them a junk value if they don't assign one.  Any shader that uses undefined values is a broken shader.  The fact that it looks OK on windows is a fluke.

Created attachment 113265 [details]
Patch v2 to the test that fixes undefined variables

The author of the test pointed out that the uv variable is actually defined as an input varying.  However, the "gz" variable is still undefined.  Fixing just "gz" fixes the test so that was probably the root problem.

*** Bug 79414 has been marked as a duplicate of this bug. ***