Open GoogleCodeExporter opened 9 years ago
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
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
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
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
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
Original issue reported on code.google.com by
jacob.be...@gmail.com
on 18 Apr 2013 at 4:35