Shader Metatunnel is not working in ShaderToy

[GoogleCodeExporter]

>>> What steps will reproduce the problem?
1. Go to http://www.iquilezles.org/apps/shadertoy/
2. Select in the Presets the shader "Metatunnel" and Load

>>> What is the expected output? What do you see instead?
We should have a blue tunnel with some blob.
We have instead a white screen

>>> What version of the product are you using? On what operating system?
Chrome 9. Tested also with latest SVN AngleProject version.

>>> Please provide any additional information below.
Other shaders in ShaderToy are not working, but they are using an extension 
that is not supported in WebGL.
But Metatunnel for example doesn't use this extension.
I have looked at the generated HLSL and It seems to be fine and well translated 
from the GL version.

BTW, is there any way to debug Angle on Chrome with PIX, as the single-process 
option doesn't work anymore?

Original issue reported on code.google.com by alx.xo...@gmail.com on 12 Feb 2011 at 8:53

[GoogleCodeExporter]

Does appear to be ANGLE related. The GPU process seems to lock up (haven't 
obtained a stack trace yet) with memory usage slowly increasing. The shader 
doesn't seem to be using vertex texture fetch. Shader works with 
--use-gl=desktop.

Original comment by kbr@chromium.org on 14 Feb 2011 at 6:32

• Changed state: Accepted

[GoogleCodeExporter]

+apatrick who has gotten PIX debugging to work with ANGLE.

Original comment by kbr@chromium.org on 14 Feb 2011 at 6:33

[GoogleCodeExporter]

To address the PIX issue, I confirmed that --single-process is broken in both 
the stable and canary channels on Windows. However, it worked for top of tree 
and I was able to debug ANGLE/WebGL using PIX. That was Chromium r74859. 
Hopefully the fix will be in the canary channel soon.

Original comment by apatr...@chromium.org on 15 Feb 2011 at 12:37

[GoogleCodeExporter]

See http://code.google.com/p/chromium/issues/detail?id=71719 for a similar 
issue.

Original comment by kbr@chromium.org on 15 Feb 2011 at 11:55

[GoogleCodeExporter]

After a short diagnostic, there is nothing we can do about HLSL compilation 
time. This is due to the way the HLSL compiler is evaluating a shader in order 
to choose if it has to unroll a loop or not. Current HLSL compiler is bad at 
this, and It seems to be well known from DirectX team (at least, some recent 
post on gamedev can attest this: 
http://www.gamedev.net/topic/593463-d3dcompile-way-too-slow/)

Even with this long shader compilation time, It still doesn't explain to me why 
display results are incorrect. At a first sight, the HLSL translation from the 
GLGL seems to be correct... so the error might come from another part of 
Angle... This could be confirmed by debugging with PIX.

Original comment by alx.xo...@gmail.com on 16 Feb 2011 at 4:46

[GoogleCodeExporter]

r74859 is now in the canary channel but --single-process is still not working. 
If I build is from source it works though. I'm still looking into it.

In the meantime, the continuous builds are here and --single-process is working 
in r75112:

http://build.chromium.org/f/chromium/continuous/win/2011-02-16/75122/

These are even less stable than canary.

I found a bug in the shader translator while debugging your shader in PIX. It 
is checked into ANGLE at r562 but it's not yet in Chrome:

http://codereview.appspot.com/4179054

I found that by switching to D3DX9 version 43 (previously we were using 42) and 
disabling shader optimization, the compile times were reduced significantly.

The question now is whether this will disable shader optimization altogether or 
whether the new Vista / Windows 7 driver model will optimize further down the 
pipe.

I think the correctness issue might have something to do with the number of 
iterations of the nested loop. The body of the inner loop can run 375 times. By 
reducing the iteration counts, I got it to at least render something other than 
white.

Original comment by apatr...@chromium.org on 16 Feb 2011 at 8:59

[GoogleCodeExporter]

The problem by disabling the shader optim is that the number of instructions 
slots used is going from 520 to 868 instructions for this particular pixel 
shader... that might have a significant impact on the performance... but could 
be an acceptable tradeof for WebGL, less perf for a shorter startup...

Yes, I can render something by removing the inner loop. What I don't understand 
is why this is rendering fine under glsl for the same code. It's like 
computation is giving different results... weird

Original comment by alx.xo...@gmail.com on 16 Feb 2011 at 9:25

[GoogleCodeExporter]

The issue with shaders taking a long time to compile should be fixed in Chrome 
Canary 12.0.713.0, which has ANGLE r591 and D3DX9 version 43. The solution was 
to use the D3D10 shader compiler with a low optimization level. The performance 
did not seem to be adversely affected for the shadertoy examples, unlike 
disabling optimization altogether.

The Microsoft documentation for the optimization level describes it like this:

"Directs the compiler to use the lowest optimization level. If you set this 
constant, the compiler might produce slower code but produces the code more 
quickly. Set this constant when you develop the shader iteratively."

http://msdn.microsoft.com/en-us/library/gg615083(VS.85).aspx

Since WebGL has no offline shader compilation ability, this seems appropriate.

Unfortunately, MetaTunnel still isn't rendering right.

Original comment by apatr...@chromium.org on 24 Mar 2011 at 10:42

[GoogleCodeExporter]

Original comment by geofflang@chromium.org on 10 Dec 2013 at 3:51

[GoogleCodeExporter]

This specific sample no longer exists, but most if not all shadertoy.com 
samples run correctly now.

Original comment by c...@chromium.org on 31 Jan 2014 at 7:21

• Changed state: Fixed