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

Re: [Public WebGL] async shader compiliation


The speed mess we're in is because both Khronos and Microsoft did it wrong. Khronos a good idea (a machine independent standard format) but took a wrong turn because supplying source text to be compiled by drivers is predestined to run into compilation speed problems. Microsoft had a good idea (machine independent bytecode) but took a wrong turn at the implementation (making it an unspecified proprietary format rather than an open standard to build toolchains atop). Both took a wrong turn by not focusing enough on modularity of GPU programs.

In an ideal world these mistakes would not have happened decades ago, and the entire driver/API ecosystem would not be built upon these mistakes. We do not live in that world. And now these mistakes are nigh impossible to correct. Which is sad, and unnecessary, but it is what it is.

None of that precludes solving UX issues we do have with asynchronicity. 

On Thu, Mar 2, 2017 at 11:13 AM, Florian Bösch <pyalot@gmail.com> wrote:
On Wed, Mar 1, 2017 at 11:04 AM, Mark Callow <khronos@callow.im> wrote:
Throughout the time I’ve been working with OpenGL ES 2+, ubershaders have generally been regarded as something to avoid.
The problem is in no way specific to ubershaders.

On Wed, Mar 1, 2017 at 11:58 AM, Maksims Mihejevs <max@playcanvas.com> wrote:
We do need async shader compilation, but more we need is faster shader compilation in first place.
Faster would be nice, but for technical reasons cannot be achieved quickly or comprehensively. Async can be achieved to some degree and work comprehensibly within expectations, without too much difficulty. That's why we need Async more, because it's a solvable problem.

On Thu, Mar 2, 2017 at 5:04 AM, Zhenyao Mo <zmo@chromium.org> wrote:
Thinking more on the implementation side, currently Chrome uses
virtual contexts on many GPUs in Android and also on Linux NVidia due
to driver bugs (for example, flush order isn't guaranteed) and
performance (MakeCurrent is very slow). This kills the possibility of
implementing an efficient async shader compile.

Of course if we can justify the need, then we can push driver vendors
to fix the issues, but that's proven to be an uneasy task.

I am not saying I don't support async shader compile, just want to
point out some unpleasant reality.
The efficiency of shader compilation, and the asynchronicity of it are two seperate mostly unrelated things. One is solvable to some degree (asynchronicity) comprehensibly, and the other is difficult/impossible to solve (speed). Let's focus on the one we can solve, not on objections or "realities" to the problem we can't, as a justification to not solve the problem we can solve.

On Thu, Mar 2, 2017 at 8:30 AM, Kenneth Russell <kbr@google.com> wrote:
Good points Mo. I do wonder though whether even on these platforms we could still spawn a background thread in Chrome's GPU process dedicated to shader compilation and program linking. Resource sharing still works even on these badly behaved platforms, and the background thread would have its own dedicated OpenGL context, sharing the compile and link results with the main thread.
Many platforms only do any actual work at the linking stage. Separate contexts aren't going to get you out of the clinch to implement fence/wait on a CPU bound process that should not block the tab compositor and JS-thread.