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

Re: [Public WebGL] Support precompiled shaders as extensions



Create First WebGL Context -> Create Second WebGL Context -> Push Second WebGL Context to a WebWorker -> Compile some Shader (and hope the browser cache the result) -> Destroy the Shader after it has been compiled -> Compile the shader in the first WebGL Context (and hope it uses the cached version of it)
Even if it could work, this is not a solution to the problem, but nasty workaround with massive overhead in terms of logic.
Only few people would be able to use something like that, and it still does not solves long compilation times problem.

But assuming we have WebGL in workers and also every WebGL Context runs in its own thread you could do this
I might be wrong, but I assume that GPU thread might be still shared between related tabs.

On 23 November 2016 at 17:58, <p4jako@gmail.com> wrote:
Am Mittwoch, 23. November 2016 um 17:51 schrieb Florian Bösch:
Thats why I thought it would be nice to compile in another context, using in the background the cache mechanic that is already in place like in angle and reuse this cached version of the shader/program in the context you actually want to use the shader/program.
This mechanic should already works today, you can create a second WebGL Context and compile there and in theory your compiled shader gets cached by the browsers WebGL implementation. So if you create the same shader in the first context it can use the cached version. Only problem here is that both Contexts are on the same js thread so the first one would still get blocked.

But assuming we have WebGL in workers and also every WebGL Context runs in its own thread you could do this:

Create First WebGL Context -> Create Second WebGL Context -> Push Second WebGL Context to a WebWorker -> Compile some Shader (and hope the browser cache the result) -> Destroy the Shader after it has been compiled -> Compile the shader in the first WebGL Context (and hope it uses the cached version of it)

Assuming this works, my proposal was to be able to explicitly do this.
 
I also think that the WebGL API should have as little overhead as possible, you can always build small utils libs if you like to use promises, or async await around it.