[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] async shader compiliation
On Wed, Mar 1, 2017 at 11:04 AM, Mark Callow <firstname.lastname@example.org>
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 <email@example.com>
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 <firstname.lastname@example.org>
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 <email@example.com>
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.