W3C home > Mailing lists > Public > public-gpu@w3.org > November 2017

Re: Notes from meeting with WASM WG at TPAC

From: JF Bastien <w3c@jfbastien.com>
Date: Fri, 10 Nov 2017 08:45:19 -0700
Message-ID: <CACeCrou1KiQYdG-q1K8sXB94_9OOhksHpdq-HEQh+-7ybyGZRQ@mail.gmail.com>
To: Dzmitry Malyshau <dmalyshau@mozilla.com>
Cc: Corentin Wallez <cwallez@google.com>, public-gpu <public-gpu@w3.org>, Bradley Nelson <bradnelson@google.com>
On Fri, Nov 10, 2017 at 8:14 AM, Dzmitry Malyshau <dmalyshau@mozilla.com>

> Thanks Corentin for an extensive report!
> In general, how was the reception of NXT demo? What where you able to show
> in the end?
> A few questions about the report:
> > In emscriptem headers for WebGPU some function calls will have special
> attributes that make them call into the Web engine directly without going
> through JS.
> Assuming this is faster and desirable in general, what are the
> conditions/requirements for a function to be called directly without JS?

The notes from the WebAssembly meeting where this was discussed should help:


The proposal is here:


> Callbacks into WASM are a bit of a slow path.
> Let's not use callbacks then?
> > Some objects could be stuck on one thread by having the host binding
> table not shared. between workers.
> A bit of an off-topic, but it would be really interesting to see if this
> semantics could be routed from Rust directly thanks to Send/Sync traits.
> > Command buffer building will not be possible on multiple threads in
> parallel
> Why? I believe this is critical to get right.

I think the problem comes from WebAssembly only supporting a single memory
per instance at the moment. With the threading proposal that memory can be
shared, like a SharedArrayBuffer, but it's not a free-standing memory than
you can then hand-off to the GPU without copy.
Received on Friday, 10 November 2017 15:45:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:52:22 UTC