In libGLESv2, investigate moving the call to D3DCompile to a separate thread

[GoogleCodeExporter]

This Mozilla bug,

  https://bugzilla.mozilla.org/show_bug.cgi?id=863316

Shows D3DCompile causing a 2-second hang during the startup of the BananaBread 
WebGL game. The profile there shows that D3DCompile alone is an order of 
magnitude (13x, specifically) slower than ShCompile, so it is specifically 
D3DCompile that is the problem. As it should only be needed for rendering and 
not for validation or otherwise for any logic (AFAICS), it should be possible 
to move the call to D3DCompile to a separate thread, preventing it from 
stalling the thread calling into libGLESv2.

Original issue reported on code.google.com by jacob.be...@gmail.com on 18 Apr 2013 at 4:35

[GoogleCodeExporter]

This would also mitigate the known issue that D3DCompile sometimes takes 
infinitely long, see Issue 198.

Original comment by jacob.be...@gmail.com on 18 Apr 2013 at 4:38

[GoogleCodeExporter]

We'd need to complete the D3DCompile to know the link status, which is 
necessary for knowing whether any uniform calls (or whatever) involving the 
program will complete without error. Maybe with SM4.0 and up we could just 
assume that the shader compilation succeeded, as it should be pretty unlikely 
to fail.

Original comment by jbauman@chromium.org on 18 Apr 2013 at 6:18

[GoogleCodeExporter]

I was thinking from the perspective of a browser implementing WebGL: by the 
time we call D3DCompile, the shaders have been validated anyway, so there 
shouldn't be any cause left for compilation failure in D3DCompile. That may not 
play out perfectly well in practice, but given what we're seeing (from 2-second 
pauses to indefinite hangs) that may still be a worthwhile compromise.

Original comment by jacob.be...@gmail.com on 18 Apr 2013 at 6:38

[GoogleCodeExporter]

There are plenty of reasons why D3DCompile will fail on a shader (too many 
instructions, for example), though I think we've managed to work around the 
more egregious cases.

Original comment by jbauman@chromium.org on 18 Apr 2013 at 6:46

[GoogleCodeExporter]

I tried doing something like this some time ago. ANGLE would call D3DCompile on 
a worker thread and the main thread would give it n seconds to return and fail 
otherwise. I think it worked but as I remember we decided we didn't want 
program linking to fail non-deterministically. Instead, Chrome relies on the 
watchdog thread in its GPU process to terminate and lose the context if a 
program takes too long to link.

Some things that Chrome does to address these issues...

I notice Firefox is using D3DCompiler_43.dll. Chrome is using 
D3DCompiler_46.dll on Vista and later now and that helped with a few issues.

There was a case where ANGLE was passing D3DCompile HLSL that tried to use 
tex2D in loops with discountinuities, which is not allowed, and D3DCompile 
would take a very long time trying to unroll the loops. It was fixed in ANGLE 
r1722. Do you know what the problematic shaders are? It would be interesting to 
check that the translated HLSL is possible to compile.

Lastly, Chrome uses OES_get_program_binary to cache linked programs, which 
helps somewhat.

Original comment by apatr...@chromium.org on 18 Apr 2013 at 8:11

[GoogleCodeExporter]

One solution using threading is to compile the pixel and vertex shaders (and 
possibly geometry shader) on separate threads. We can support this using the 
angle platform, where the platform can supply an implementation for a Task 
callback. I'd like to look at this in the next quarter or so.

Austin, this would mean the for WinRT, we use a separate platform 
implementation which implements threads using std::async.

Original comment by jmad...@chromium.org on 10 Jul 2015 at 8:28

[GoogleCodeExporter]

Works for me.

Note that std::async should work on all platforms if you compile ANGLE using 
VS2015 (or at least using the CRT that comes with VS2015). VS2015 is released 
on July 20th. Is there any chance that ANGLE will move to VS2015 soon? 

Original comment by aukin...@microsoft.com on 10 Jul 2015 at 8:37

[GoogleCodeExporter]

I'm not really sure, seeing as VS2015 is not even officially released. In any 
case, if we wanted to use threading on any other platform, we'd need a more 
portable solution.

Original comment by jmad...@chromium.org on 10 Jul 2015 at 8:59