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

Re: [Public WebGL] async shader compiliation

Is there any way shader compilation could be done on a webworker using webassembly, then we wouldn't have to make changes to the browser?

On Tue, Feb 28, 2017 at 3:38 AM John Davis <jdavis@pcprogramming.com> wrote:
For what it's worth, at 10-15 seconds the user has been lost.  Studies have shown there are only 2-3 seconds to capture someone's attention, otherwise they move on.

On Tue, Feb 28, 2017 at 12:33 AM Kenneth Russell <kbr@google.com> wrote:
I've never built a project with the huge number (or size) of shaders being described here, but is it not possible to start rendering with simpler shaders and gradually increase the quality as the app runs? There are plenty of good looking physically based rendering demos and apps out there by PlayCanvas, Sketchfab, Marmoset, Floored, etc. that start up quickly -- far less than 10-15 seconds.

The main short-term workaround that could be done would be to add truly asychronous shader compilation to WebGL. Using simpler shaders at the start of rendering would still need to be done.

Still hoping for a stress test that compiles all the shaders from some real-world content back-to-back, that we could use to profile the shader translator.

On Mon, Feb 27, 2017 at 9:50 AM, Joshua Groves <josh@joshgroves.com> wrote:

It would be great to avoid freezing by implementing a method as
Corentin suggested. However the cold start performance should still be
investigated if there are further optimizations to be made outside of
the HLSL compilation step.

Max's approach still doesn't work for some uber-shaders depending on
their length, i.e. (warning: this will freeze your browser)

On Mon, Feb 27, 2017 at 9:21 AM, Maksims Mihejevs <max@playcanvas.com> wrote:
> 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.

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