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

Re: [Public WebGL] WebVulkan and multithreaded command queue assembly



The impression I get is that web workers are already the web's model for threads and that seems unlikely to change. Canvas rendering from workers already aims to lift draw call generation off the main thread. I would guess getting the browser to manage the thread safety of canvas proxy draw calls is much more practical than making the entire JS engine thread-safe. I would think the most likely direction to go in is canvas rendering from *multiple* workers - but how that works, or if it would even be useful, probably needs to wait until there is at least a draft Vulkan spec!

Ashley


On 4 March 2015 at 16:18, Florian Bösch <pyalot@gmail.com> wrote:
On Wed, Mar 4, 2015 at 5:09 PM, Brandon Jones <bajones@google.com> 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.