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

Re: [Public WebGL] async shader compiliation

Freezing is possible to workaround already - run app, get sources of shaders (if they are ubershaders), and compile only number of them to fit some threshold time. Then skip compiling to next frame. Basically, spread compilation through frames - this avoids stalling. But still asks user to wait for long time. And this wont help with runtime compilations while app is already running - stalls will lead to dropped framerates.

On 27 Feb 2017 3:43 p.m., "Corentin Wallez" <cwallez@google.com> wrote:
It won't help with how long the cold start will take, but it should avoid the freezing Florian mentions (assuming that's what "seizes up" means).

On Mon, Feb 27, 2017 at 10:39 AM, Maksims Mihejevs <max@playcanvas.com> wrote:
Corentin, this will not make cold compilation faster at all. Which is a major problem right now. Caching - is not a solution to slow shader compilation, as caching only benefits consequetive visitors. But in casual nature of web, first visit - is most important.

On 27 Feb 2017 3:04 p.m., "Corentin Wallez" <cwallez@google.com> wrote:
I really think the following could work in Chrome on platforms that have program binaries available (i.e. not OSX). It works today and has been possible for at least a year.

One thing that might work in Chrome with the current state of things would be to go through a list of shaders in a Worker and for each of them:
    • Compile it
    • glFinish (and destroy the shader)
    • send to the main event loop that this shader was warmed up
Then in the main event loop, recompile the shader expecting it to be already warm and instant to compile. However on platforms where the browser cannot use program binaries, things would actually be slower.

On Mon, Feb 27, 2017 at 9:57 AM, Maksims Mihejevs <max@playcanvas.com> wrote:
We have huge commercial project on the way, where we had to avoid any shader recompilation at any cost, which dramatically limits of what can be done with rich content.

On 27 Feb 2017 2:43 p.m., "Florian Bösch" <pyalot@gmail.com> wrote:
Just today I had a call with the architecture client. They've decided to kick the WebGL content (their core offering) off their landing page because it seizes up the machine for 10-15 seconds on a cold-start.

A solution to this issue is desperately needed, not yesterday, not last week, not even last year, it's needed years ago.