[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] ESSL -> HLSL -> cso, do we really need to do this?

On Mon, Feb 4, 2013 at 10:59 AM, Kornmann, Ralf <rkornmann@ea.com> wrote:
> Hi Kenneth,
> have you checked the result if it is still unrolled (in the case it was unrolled at all)?

Hi Ralf,

Yes, I used the [loop] directive and confirmed that if the HLSL
compiler attempted to unroll the loop, that compilation would fail.

> Do you mind sharing the compiler flags you have used. I am just curious how much skip optimization, skip validation and optimization level 0 can improve the compile time. Maybe it would be an option to do a this first in the compile call and offload an full optimized compile to another thread. I have the feeling that many OpenGL  implementations today do something similar.

Here's a gist containing the shader and fxc compiler options (thanks
Florian for granting permission to publish it):


Using /O0 is not viable at the moment. We have found that /O1 is
necessary to make the majority of shaders compile with the
transformations that ANGLE performs.

> If anything fail changing the shader compile and link functions to be async may be the last way out of this dilemma.

Yes, I think that it will probably be necessary to run the D3D HLSL
compiler on another thread in the WebGL implementation, and make the
compile fail after a couple of seconds. Hopefully though we can either
figure out what's going wrong with this test case or submit a bug
report to Microsoft.


> Unfortunately the D3D compiler was always build to be part of a production pipeline.
> Ralf
> -----Original Message-----
> From: Kenneth Russell [mailto:kbr@google.com]
> Sent: Montag, 4. Februar 2013 19:32
> To: Florian Bösch
> Cc: Brandon Jones; Kornmann, Ralf; public webgl
> Subject: Re: [Public WebGL] ESSL -> HLSL -> cso, do we really need to do this?
> The test shader Florian mentioned is the spherical harmonics fragment shader from his deferred irradiance volumes demo, translated to HLSL via ANGLE. It causes Microsoft's D3D Shader Compiler 9.29.952.3111 to take a really long time with /O1, even with the PS 5.0 profile. (On the same machine, ps_5_0 takes ~10 seconds; ps_3_0 takes ~18 seconds.
> Both of these are long enough to trigger timeouts in Chrome's WebGL implementation resulting in lost context.) Florian, would it be OK with you if I post the shader here?
> There have been multiple reports of slow shader compilation on Windows with ANGLE. Many of these occurred because ANGLE transformed the shader in a way that required the D3D shader compiler to unroll loops.
> ANGLE now detects many of these situations and does transformations such as avoiding gradient instructions in loops. I don't know why Florian's SH shader takes so long to compile; it doesn't seem to contain any of the pathological constructs.
> Florian's shader has been added to the top of tree WebGL conformance suite as https://www.khronos.org/registry/webgl/sdk/tests/conformance/glsl/misc/large-loop-compile.html
> . Its eventual inclusion will have to be debated among members of the working group, but it seems to me that even if compilation of the shader has to fail, that failure should occur in a reasonable period of time, and the WebGL context shouldn't be lost.
> -Ken
> On Sat, Feb 2, 2013 at 8:38 AM, Florian Bösch <pyalot@gmail.com> wrote:
>> On Sat, Feb 2, 2013 at 5:33 PM, Brandon Jones <bajones@google.com> wrote:
>>> Do we have any stats on that?
>> Kenneth would have a good test shader from me to see if DX10+ does better.

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl