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

Re: [Public WebGL] Support precompiled shaders as extensions

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 ?