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

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



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.

-Floh

On Wed, Mar 4, 2015 at 5:18 PM, 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.

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------