Re: Data transfers from/to client

Thanks for taking another look. I think we are on the same page and both of
your concerns are because the document wasn't clear enough.

1. The document isn't clear enough: we are not looking at have synchronous
polling work when used with a while-loop like this. We could even spec
isPending to not be able to change until Javascript execution yields to the
browser (like qury results i nWebGL). The for loop was just an
(unfortunate) image of what calls the application would do inside a RAF or
setTimeout loop. That said WebGL _might_ allow blocking in workers in the
future. We should probably piggy-back on its decision.

2. I'm not sure what race there is. The pointer would go back to null only
if the buffer or the memory are unmapped. The buffer cannot be used by the
GPU while it is mapped because it has to stay in the MapRead usage (NXT's
concept of "memory barrier") until unmapped. Hence the application controls
when the memory is invalidated and when getPointer() returns nullptr.

I've clarified both point in the document 1. with an addition to the
comment in the SYNCHRONOUS ifdef, 2. with a drawing of the state machines
for WebGPUBuffer and WebGPUMappedMemory.

Let me know if there are other parts that are unclear.

Corentin

On Mon, Feb 5, 2018 at 3:30 PM, Myles C. Maxfield <mmaxfield@apple.com>
wrote:

> After re-reading the NXT document describing buffer uploads and downloads,
> we have these thoughts:
>
> 1. Just as we don’t want to create a synchronous WebGPU API call which
> blocks the main thread, it looks like the JS code under the SYNCHRONOUS
> macro in the example allows web authors to synchronously block the main
> thread. Promises solve this problem by never being fulfilled during JS
> execution, so an app which busywaits on their callback being run would hang
> every browser equally in a well-defined manner (and the web author would
> realize they did it wrong and try again writing their code better).
>
> 2. To make matters worse, any app which doesn’t hang the main thread would
> then incur a race condition. They would periodically ask the
> WebGPUMappedMemory object if isPending(), and they may never happen to ask
> at the right time. Their code would “see" the buffer go directly from
> “pending” to “getPointer() returning null” because of the timing of their
> code. The only thing the app can do is simply try running the race again
> and hope they win this time, which would lead to loading screens that are
> either infinitely long or even longer than they would have been if we had
> just done the copies (that this proposal is trying to avoid!) in the first
> place. Promises solve this by guaranteeing that your transfer completes in
> a finite amount of time.
>
> —Myles
>
> On Jan 31, 2018, at 2:09 PM, Kai Ninomiya <kainino@google.com> wrote:
>
> That's also absolutely true. I would like to enable both. See the doc
> Corentin sent for a proposal hopefully allows both (by making the
> mapped-object thenable)
>
> On Wed, Jan 31, 2018 at 2:07 PM Kirill Dmitrenko <dmikis@yandex-team.ru>
> wrote:
>
>> Yep, there's that. I've raised that point at one of the previous
>> meetings. However, after thinking about it for some time, I found an upside
>> to promises regarded that situation. If an application doesn't render or do
>> background tasks continuously, but only when an update is really needed
>> (i.e, as a result of new data from net or user interaction), promises may
>> same CPU time is JS:
>>
>> let raf = 0;
>> let rafJobQueue = [];
>>
>> promise.then((data) => {
>>     rafJobQueue.push(data);
>>     if (!raf) {
>>         raf = requestAnimationFrame(render);
>>     }
>> });
>>
>> function render() {
>>     for (const data of rafJobQueue) { /* do stuff */ }
>>
>>     /* render */
>>
>>     raf = nextFrameNeeded ? requestAnumationFrame(render) : 0;
>> }
>>
>> Same argument goes for requestIdleCallbacks: promises may allow not to
>> constantly schedule callbacks for checking if there's something to do.
>>
>> 31.01.2018, 23:12, "Kai Ninomiya" <kainino@google.com>:
>> > More importantly than GC pressure, probably, is that shimming a C API
>> on top of a Promise also inherently adds latency:
>> >
>> > let resolved = false;
>> > prom.then(() => { resolved = true; });
>> >
>> > raf(() => {
>> >   if (resolved) { ... }
>> > }
>> >
>> > So I think we'll need something non-promise-based for WASM anyway.
>> >
>> > On Wed, Jan 31, 2018 at 11:59 AM Kirill Dmitrenko <
>> dmikis@yandex-team.ru> wrote:
>> >> When promise-based interface was proposed to the WebGL community,
>> there're some concerns about generating garbage (thread:
>> https://www.khronos.org/webgl/public-mailing-list/public_
>> webgl/1701/msg00001.php). However, maybe those concerns need some
>> qualitative analysis.
>> >>
>> >> 25.01.2018, 22:01, "Corentin Wallez" <cwallez@google.com>:
>> >>> On Wed, Jan 24, 2018 at 9:41 PM, Dzmitry Malyshau <
>> dmalyshau@mozilla.com> wrote:
>> >>>> === 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.
>> >>
>> >> --
>> >> Kirill Dmitrenko
>> >> Yandex Maps Team
>>
>>
>> --
>> Kirill Dmitrenko
>> Yandex Maps Team
>>
>
>