Replacing p with (p + vec2(0.0) leads to malformed image

[Alastair_D_1]

I attach a .zip containing shader.frag (among other files), and two .png images; good.png and bad.png.

shader.frag is taken from http://glslsandbox.com/ and is meant to produce an image looking like good.png.

If the expression "p" at line 48 is replaced with "(p + vec2(0.0))", the shader produces an image looking like bad.png.

I believe this is due to a compiler bug, since this expression change should likely have no effect (I would expect it to be optimized away).

My platform:

- Windows 10
- Intel(R) HD Graphics 520
- Driver version 20.19.15.4326

The attached archive contains the necessary files to reproduce this problem, with instructions on how to do so in README.txt.

I'd be really interested to know if you can reproduce it, and whether you consider the issue to be a compiler bug.  Please let me know if you need any more details.

[Michael_C_Intel2]

Hi,

Got it filed, and I will update you when we know something.

Thanks,

-Michael

[Richard_S_Intel1]

Hi,

I have taken a quick look at this one, and the only difference in the LLVM IR generated by the GLSL front end (built from latest source code) is an extra temporary created for the floating point addition of p.y and 0.0; this temporary is then used, instead of p.y, in the subsequent three floating point multiplications for the term cUp * (p + vec2(0.0)).y.

Once the IR has been optimised by the LLVM phases there is no difference between the two versions of the shader.

Possibly you are seeing a bug which has since been fixed.

- Richard

[Alastair_D_1]

Hi Richard

Thanks for looking into this - and I'm glad to hear + 0 is being eliminated as one would expect.

Is there any way for me to see the LLVM IR or final assembly for the current beta driver version (20.19.15.4326), or is there way to get hold of a more recent build?  Alternatively, would you have time to see whether the code generated for 20.19.15.4326 is different?  It would be useful to know whether the issue I am seeing is indeed due to a now-fixed bug or not; if not, then I must be doing something wrong.

Thanks!

Ally

[Stefan3D]

Hi all,

on my rig with BDW HD5500 / driver v4364 (via Windows update) the graphics flips between the good screen posted above and a blurred one.

Happens with either p.y or (p + vec2(0.0)).y

P.S.

NVIDIA's compiler complains
0(61) : warning C7050: "dist" might be used before being initialized

[Alastair_D_1]

Thanks Stefan.  To clarify: when you say "Happens with either p.y or (p + vec2(0.0)).y", do you mean that you get test2.png (the correct-looking image) with p.y and test1.png (the blurry-looking image) with (p + vec2(0.0))"?  Or do you mean you see the blurry image with both (in which case, what do you mean when you say it flips between these)?

Thanks for mentioning the Nvidia warning - I'll look into that in case it's the shader that is bad.

Cheers

Ally

[Stefan3D]

I see the blurry screen with both versions of code for 5 seconds, then the good one for 5 seconds and then the blurry one again etc.

[Alastair_D_1]

Ah, got it, thanks.

Are you able to share with me the host code you used to animate the shader?  It would be great to see whether with your host code I get a messed up animation or not.  If email is easier than forum, I'm at afd@imperial.ac.uk.

Thanks

Ally

[Stefan3D]

Alastair D. wrote:
Are you able to share with me the host code you used to animate the shader?  It would be great to see whether with your host code I get a messed up animation or not. 

Load this XML file in the latest version of GeeXLab

[Stefan3D]

Hi Ally,

did you upload www.glslsandbox.com/e#30824.4 ?

Looks good now unless you move mouse to the borders

Fixed by changing 0.5 to 0.3 at

// camera and ray
vec3 cPos = vec3(mouse.x - 0.3, mouse.y - 0.3, time);

[Alastair_D_1]

Hi Stefan

No, wasn't me.  I'm doing a research project on compiler testing, and have been investigating methods for testing GLSL compilers.  Have been using GLSL sandbox as a source of examples for the project, and used the original shader similar to the one you just mentioned as an example.  If you'd be interested in learning more then I'd happily send you a preview of a short paper we just wrote on the topic (not ready for broader public consumption yet) - let me know.  A challenge we face is reproducing what we believe to be bugs on other platforms.  GeeXLab has been helpful for this since you pointed it out - thanks.

Cheers

Ally

[Adel_S_]

I see the blurry screen with both versions of code for 5 seconds, then the good one for 5 seconds and then the blurry one again etc.

[Michael_C_Intel2]

Hi Alastair,

We found the issue and fixed it, the next drive release should contain the fix. 

-Michael 

[Alastair_D_1]

Hi Michael

Thanks for confirming this, and good to hear that it is now fixed.

Ally