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

Re: [Public WebGL] Support precompiled shaders as extensions

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.