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

Re: [Public WebGL] Support precompiled shaders as extensions



It's particularly things like Unity3D and UE4 which wish to compile to JS through emscripten. WebAssembly will be quite a bit more flexible than asm.js, and may not be such an impediment to interact with the UAs APIs. I think one of the big advantages of WebAssembly (if it is indeed better at UA integration), is that you are guaranteed to get native code through a predictable pipeline, and that you won't have to deal with a GC (as long as the UA APIs are well behaved, which they haven't always been, and generally aren't for anything todo with the DOM).

On Thu, Nov 24, 2016 at 4:04 PM, Maksims Mihejevs <max@playcanvas.com> wrote:
It is WebAssembly not friendly to everything browser and JS related.
I still see it as a hack and attempt to do things that are not supposed to be done in the web.
Normal developers shall not and will not use WA for any real case applications, only those who don't write JS code in first place, and really need to port their stuff to web, will use that path.

On 24 November 2016 at 14:17, Kirill Prazdnikov <kirill.prazdnikov@jetbrains.com> wrote:
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 ? 

Thanks



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.