Data transfers from/to client

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/files/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

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

=== 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?

Thank you,
Dzmitry