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

Re: [Public WebGL] async shader compiliation

On Thu, Mar 2, 2017 at 2: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.

You miss the point.  I am not talking about efficiency of shader
compilation, but efficiency of context switching.

But Ken's right, there is a way to make it work on bad drivers if
resource sharing is still working on them.

> 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.

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