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).
- Windows 10
- Intel(R) HD Graphics 520
- Driver version 184.108.40.20626
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.
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.
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 (220.127.116.1126), or is there way to get hold of a more recent build? Alternatively, would you have time to see whether the code generated for 18.104.22.16826 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 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.
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 firstname.lastname@example.org.
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);
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.