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

Re: [Public WebGL] Support precompiled shaders as extensions



On Thu, Nov 24, 2016 at 3:17 PM, Kirill Prazdnikov <kirill.prazdnikov@jetbrains.com> wrote:
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 ?
Sorry, I was confusing them with framebuffer objects which (at least in some implementations) you can't share. However it is usually the case that operations done on resources in one context need to be completely finished before any of their state can be shared with another context (i.e. you have to invoke a blocking call such as getting the compile status, or calling glFinish), I'm sure similar restrictions apply to D3D.
 
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 ? 
All WebGL functions accept array buffers, integers and strings. No closures or other JS objects are required (but some such as lists can be supplied). Most resource creating functions of WebGL return a webgl specific object wrapping the integer the native API returns, which makes WebGL less than ideal for web assembly. However FFI like code for WebGL bindings exists and is used by Unity3D and UE4 through emscripten. Web Assembly is a bit more flexible and well defined than asm.js, so managing the returned webgl objects might be a bit easier there.