[Public WebGL] WebVulkan and multithreaded command queue assembly

Floh [email protected]
Wed Mar 4 11:11:35 PST 2015

I would be happy enough if there's an efficient solution for streaming
geometry data and textures without causing hickups in the game loop.
For instance:

- download asset file in worker
- parse/convert to WebGL friendly format in same worker

- either create WebGL resources directly in worker thread by calling
WebGL functions (similar to multiple GL contexts with shared resource
lists on desktop GL, except that this doesn't work at all in reality
(driver quality, etc)

- or (preferably): have a very efficient way to transfer the raw bytes
back to the main thread (meaning: without copying), and efficiently
setup the WebGL resource there. In emscripten this currently isn't
possible because of the one big typed array for the heap (that's where
the SharedArrayBuffer would come in), I guess otherwise this would
work with ownership transfer of a smaller typed array, however, this
would also mean that it must be guaranteed that WebGL doesn't do any
expensive data conversion in the render loop thread.


On Wed, Mar 4, 2015 at 5:18 PM, Florian Bösch <[email protected]> wrote:
> On Wed, Mar 4, 2015 at 5:09 PM, Brandon Jones <[email protected]> wrote:
>> mapBuffer in WebGL2
> That's quite a bummer.
>> That's not to say that we shouldn't look to this new wave of APIs for
>> inspiration. I think there's several concepts present across all of the new
>> APIs that would play well on the Web, and may even work nicely with web
>> workers in some form. I just don't don't believe we'll get a ~1:1 mapping
>> like we saw with WebGL and OpenGL ES.
> Well since Vulkan is the eventual future, I don't think it's sustainable to
> have a bifurcation of Web Hardware Accelerated something APIs with different
> semantics than native APIs. You'll lose out on:
> - existing experience
> - cross compilation
> - tooling
> - documentation
> - books
> That could easily break the back of any attempt to do so.

You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl

More information about the public_webgl mailing list