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

Re: [Public WebGL] Support precompiled shaders as extensions

There is not a single use of promise pattern in WebGL, and please lets not introduce it. With ES6/7 promises is obsolete abstraction. And suffers a lot from big GC footprint due to need to allocate a lot of anonymous functions, whole scoping stuff and internals related to object allocations with passing it around through promises chain.

Runtime performance and low GC footprint for real-time applications is extremely important in the web.

Querying - is what WebGL/GL is following. It is not JS friendly, indeed, but it is bare minimum to make this working.
Then there can be async way to do this, but please, no promises - they are not runtime friendly at all.

Here are some references to async points from above conversation:

Florian Bösch
#1: Nonblocking compile signaling (@khronos-wg)

Corentin Wallez
We should instead look at tackling the shader compilation problem in other ways. How about having a glFenceSync for GL_CPU_COMMANDS_BIT so that you can know when your shader has been compiled? Can we make shader compilation parallel? etc.

And more others within the topic.
Implementation of how it is async - either by query status call or callback, is trivial implementation details, underlying functionality - is what is missing here.


On 23 November 2016 at 15:45, Ryan Patterson <ryan.goat@gmail.com> wrote:

I read the entire thread and did not see any discussion similar to Peter's suggestion to detach shader compilation from the glContext so that it can be performed in a worker.  It sounds like a new idea to me.

If we ever do get async shader compilation in webGl I hope it is presented in a _javascript_ friendly way.  ie. resolve/reject a promise when the compilation succeeds/fails instead of having to repeatedly query the status.

Ryan Patterson

On Sat, Nov 19, 2016 at 4:35 PM, Maksims Mihejevs <max@playcanvas.com> wrote:
Hi Peter.

Please read the conversation above. As this all been suggested and talked already.


On 19 November 2016 at 20:29, <p4jako@gmail.com> wrote:
long time lurker here, so here are my thoughts regarding this problem:

So what about an extension that lets you compile shader text sources to binary shaders. That would be independent from the GLContext and non blocking.
When the compilation is done you get a binary blob that contains the compiled binary shader. Then you can use the blob and upload the binary shader to your GLContext.

To verify that the binary blob has not been modified, the browser could do an hash check before it does upload the binary shader to the GLContext.  So only binary shader that has been compiled with this browser installation would be valid.

Another idea, after compiling to binary you get an object back that represents the binary shader blob (so you can't access the binary source of the shader) You can use that object to upload the binary shader to your GLContext. Unfortunately caching would not be possible with this solution.

So as long as your graphics platform supports binary shaders this extension would be implementable. You can async compile shaders and with the first solution even cache them locally.

With WebGL in web workers you could even implement:
Compile async inside web workers and only allow program binaries that has been has been linked locally and have not been modified.



Am Samstag, 19. November 2016 um 11:24 schrieb Maksims Mihejevs:

Hey, Kirill Prazdnikov.
Do you have any example that uses a bit more complex shaders with multiple lights and/or cubemaps?

Simple shaders - is easy to compile. Shaders with loops, many functions, will take way way longer.
Have you done measurements and tests on medium mobile platforms, which are still majority of WebGL consumer on mobile?

However if one thinks that this might be a problem, 
why not to cache binary shaders in the browsers internal implementations:
String -> Blob ?
This does not solves cold-start, where cache is not available problems. Nor solves freezes with first compilation in runtime. Only improves consequent compilations.
Cache is not solving main problem - slow initial compilation. Problem - is fact of compilation being slow, and that has to be either solved, or means to prevent blocking provided.

Florian Bösch
Do you think that D3D would be capable of implementing ARB_parallel_shader_compile?
That would be great to have.

However, since the browser runs the driver in its own process (at least in some cases), the browser can emulate the non blocking behavior (in a very suboptimal way). Upon the webgl context asking for COMPLETION_STATUS_ARB, it could query the underlying GL backend for the compile or link status, which will block the GPU process, but the call from JS could proceed to return false right away. I'm not sure it'd be a good idea to emulate it that way.
Does that means that GPU will be blocked, and any other query that will block, for example uploading texture, will end up blocked?
Basically, there is number of WebGL calls, such as getProgramParameter(program, gl.ACTIVE_ATTRIBUTES) and other methods that are not shader related. If with blocked GPU those methods will eventually block - trying to query Texture related things for example. Then use of such "partly-async" shader compilation will be under big question.

On 19 November 2016 at 09:53, Kirill Prazdnikov <kirill.prazdnikov@jetbrains.com> wrote:
I'm the 3d engineer of cospaces project (https://studio.cospaces.io/#Gallery)
We do everything in gl: 2d UI and 3d and VR.
We have about 50 shaders, and we dont having issues with shader compilation timings.

However if one thinks that this might be a problem, 
why not to cache binary shaders in the browsers internal implementations:
String -> Blob ?