Re: Data transfers from/to client

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 <mailto: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 <mailto: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 <mailto: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 <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 <mailto:cwallez@google.com>>:
> >>> On Wed, Jan 24, 2018 at 9:41 PM, Dzmitry Malyshau <dmalyshau@mozilla.com <mailto: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