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

Re: [Public WebGL] async shader compiliation

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