Re: Data transfers from/to client

Hey Dzmitry,

On Wed, Jan 24, 2018 at 9:41 PM, Dzmitry Malyshau <dmalyshau@mozilla.com>
wrote:

> Hi Ken,
>
> === Data Races ===
>
> Could you clarify why protecting against data races between CPU and GPU is
> a strong requirement for the API? I'm sure that such a guarantee will be
> welcomed by developers, but I'm concerned that it's forcing the design into
> a more abstracted away side, where instead we could have something clear
> and consistent.
>
> I look at another example of a web API - shared array buffers - and they
> allow data races between CPU threads. The idea is that using them correctly
> at that level is hard, but various higher level abstractions are possible,
> and they are nice: https://hacks.mozilla.org/file
> s/2017/06/02_15-768x514.png
>
> I would very much prefer WebGPU to follow similar principles: stay low
> level, simple and consistent (but not necessarily easy!), but allow nicer
> higher level abstractions. At the end of the day, we are designing the API
> for
> > Web developers who are competent in GPU technologies
>
> Protecting against data races has many important properties:

   - It makes the API more portable. When you look inside the mapped buffer
   you get the same data on every browser / OS / HW / driver / backing API
   combination. This is important because even GPU experts using Vulkan /
   D3D12 do get synchronization wrong. In native we can have games require
   "<TITLE>-ready" drivers and be sloppy, but this is not an option for
   browsers. On the Web, a synchronization error would translate to an
   application not working. We (Google) care a lot about this because the
   chance of an application not working on our platforms is greater, with
   Chromium's GPU command buffer and the big variety of Android devices.
   - This kind of portability entails predictability for developers since
   they only have to test on one machine to know their code will work
   everywhere.
   - Allowing data-races would be punching a hole in the security boundary
   provided by WebGPU. If the inner working of WebGPU are opaque to the
   application, we can patch security issues without modifying its behavior.
   SharedArrayBuffers are currently disabled in all browsers, they made the
   security boundary thinner between the Web and the processor so Specter /
   Meltdown are exposed. It might be ok to pay the security cost of SAB
   because of how important they are for the performance of WASM but I don't
   believe direct mapping is as important as SABs.

=== Shape of the API for data transfers ===
>
> One of the benefits of having poll-like interface (with fences or
> something similar) is that it maps cleanly to C and thus maps perfectly to
> WASM.
> If we choose to have promises instead, how would they be accessible from
> WASM? I don't see anything immediately related in the Host Bindings
> Proposal.
>

I assume you meant the WASM Host Bindings Proposal. I'm not sure about
direct bindings to promises but implementing a poll-like interface on top
of a promise interface would be easy to do with a shim. That said I agree
that it isn't clear how to make it work with minimal overhead in WASM.
Something important for Chrome is that the range of data that will be
accessed be explicit, because otherwise we would have to send all of the
buffer's content through the GPU command buffer. It's easy to see how a
promise interface could have explicit bounds, but it is less clear how to
do it with a poll API.

>
> === Persistent Mapping ===
>
> I wasn't ready to engage into this conversation during the call without
> refreshing my memory on the previous talks, and 3 minutes before the end of
> time. Hopefully, we can continue it here. Could you write down the reasons
> why Chrome architecture is incompatible with persistent mapping?
>
> Actually we were the ones asking for you to come up with a proposal that
1) doesn't put Chrome's GPU command buffer at a disadvantage 2) could be
shimmed by something more complex in the event a security issue. Also
ideally 3) is predictable and portable like the data race free version of
buffer mapping we suggested. I don't think there's a way to do this.


> Thank you,
> Dzmitry
>