Re: Data transfers from/to client

Hi Dzmitry,

Corentin's writeup is more complete than anything I could have put together
so let me just comment on one part.


On Thu, Jan 25, 2018 at 11:00 AM, Corentin Wallez <cwallez@google.com>
wrote:

> 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.
>

In Chrome's security architecture, the persistently mapped buffer visible
from the JavaScript side will not be, and can not be, the same mapped
memory given back by the GPU. Instead, it will be in shared memory between
the renderer (JavaScript) process and the GPU process.

Writes to that shared memory region will not be visible to the GPU without
calling e.g. FlushMappedBufferRange. (This will cause a memcpy into the
"real" mapped buffer and a call to the "real" FlushMappedBufferRange.) On
the other hand, in browsers that allow direct GPU access from the
JavaScript process, it's likely that even without calling
FlushMappedBufferRange, writes by the application to the persistently
mapped buffer will in fact be seen by the GPU – depending on the GPU
architecture and other factors.

In the latter browser architecture, there will be no way to guarantee that
writes to the persistently mapped buffer *without* calling
FlushMappedBufferRange *will not* be seen by the GPU. We think this will
lead to significant portability issues between browsers.

-Ken



> Thank you,
>> Dzmitry
>>
>
>