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

Re: [Public WebGL] Support precompiled shaders as extensions

Hi Florian,

May I have few questions please, 
Context sharing cannot share shaders.

As far as I know, it should share all possible resource handles: texture, buffer (VB), renderTarget, and shader as well, am I wrong ?

They (promises) would work poorly for languages that compile to JS via asm.js or web assembly ....
As far as I understand we can not pass WebGLContext objects like WebGLTextures, WebGLFramebuffers, WebGLBuffers to  web assembly
Even more, we can not even call to uniform1f from web-asm code.

We have to store all this objects in arrays and use indices in the these arrays in web-asm. 
Also for each gl call we have to call back form native web-asm function back to JS. 

Does it mean that WebGL is not friendly to web assembly at all ? 


On Wed, Nov 23, 2016 at 7:51 PM, Florian Bösch <pyalot@gmail.com> wrote:
On Wed, Nov 23, 2016 at 4:45 PM, 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.
The OpenGL context itself is bound to a process, and another process cannot operate it at the same time simultaneously (the command queue is synchronized). Context sharing cannot share shaders. The call to check compile status is blocking, it means that no other command in the command queue proceeds until that call has finished, and that call can only finish when compilation has either wholly succeeded or failed. Without support of the underlying backend for actual asynchronous compilation (checking the status before completion and without blocking), when a worker would check the compile status, it would block all other calls.

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.
Promises itself are bad (they can lead to GC cycles) and they destroy the stack (for debugging purposes). They would work poorly for languages that compile to JS via asm.js or web assembly and they're not GL idiosyncratic so an existing codebase cannot easily be ported over while maintaining native API compatibility.