Error (https://w3ctag.github.io/promises-guide/#reasons-should-be-errors)

Done

I can't find any references to a standard, but I believe then method of a thenable should return a new Promise.

On this point, if the caller only uses the pollable interface, could we confirm the creation of a Promise is avoided entirely?

@dmikis I don't know for then-ables, but it looks to be the case for Promises (I'm sure you know already ^^) https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/then

@grovesNL correct, the Promise wouldn't get created. The only overhead would be some unused members of WebGPUMappedMemory.

@dmikis While I don't think a Thenable strictly speaking has to return anything in particular, you're right that it would be useful if it did.

ArrayBuffer? (i.e., nullable)?

Done

Typo: particular

Done

Typo: upload

Done

Typo: garbage

Done

Typo: visible

Done

On this point, if the caller only uses the pollable interface, could we confirm the creation of a Promise is avoided entirely?

How does it know what commands are "previous" and what are "subsequent"?

Here previous and subsequent refer to the order of the calls in the Javascript program order.

I think that's not very well-defined if we'll allow submission of commands from multiple workers.

IIRC, Vulkan does such "in-place" uploads via command buffers. Doing them the same way would make it a bit clearer what commands a before the upload and what are after (IIUC, not with multiple queues, though).

Can we associate this with a particular point in the queue, perhaps by passing the queue as an argument, or making this a member function on the queue? It would make it clear what data would get clobbered and what wouldn't. Doing this would also solve the problem of what happens when this is called during the time when a buffer is mapped.

We've heard from Metal developers that submitting commands in an order different than they were recorded is an important use-case.

typo: "uplaod"

Done

"as there are advantages"

Done

nit - codify the terms: then-able, Promise

Done

sentence is not clear, needs to be rewritten

Done

nit: codify method names

Done

needs to be re-phrased

Done

We often get this argument voiced (the need for immediate upload), but I don't think the API needs special handling for this case, as long as the sync behavior is achievable in general.

In this proposal, mapping for writing is asynchronous too, so there is no way to have sync behavior without Buffer.setSubData. The alternative would be a ArrayBuffer? Buffer.mapWriteSync(u32 offset, u32 size); but I'm not sure this is better. WDYT?

Mapping (local) mappable memory should be able to be synchronous if the mappable allocations are actually IPC shmem. Does this design run into issues with how we enqueue copies? It seems iffy, but ideal if it can work reliably synchronously.

instead of inventing a new "Device level" term, we could just say that the operation acts as if it's done after all device/queue level commands.

It is also done after previous Buffer.setSubData() calls and before subsquent ones. We need a name for these operations as they might not all be on the device and the queue (contrary to Vulkan). Do have suggestion on how to call this?

or we can move setSubData to the device, calling it like device.setSubData(buffer, data), which IMHO would make more sense from the implementation point of view (wait + map + unmap)

similar concern here about the mismatch of usage versus state concepts. Are they merged in NXT?

No but they are often confused there's the creation usage and the usage "state" (there's other state like the mapped state). So we never use the word "state" for usage, only "usage".

A resource is in a usage means it has that usage "state" value
A resource has a usage means it was created with this usage requested by the application.

We obviously we didn't spend enough time figuring out the naming of things so this is a bit confusing. I think the intent is clear here, what do you think of deferring the re-wording to when we decide what our memory barriers look like (if any)?

I do see a bit of elegance in merging usages and access flags, but it's also confusing to differentiate is/has...

I agree with @kvark. The distinction confused me as well.

Can buffers only be in more than one "is in" usage at a time? If so, then that usage should be a separate type that is not a bitfield. That makes it clear to the person calling functions that take "is in" usage that only one of them is valid.

If the set of "has a" usages contains members that are not valid for "is in" usage or vice versa, then that's also a reason to have separate types.

The description of "has a" vs. "is in" usages would be great explanatory text for the spec.

typo: "grabage"

Done

Can a buffer be TRANSFER_DST as well as MAP_WRITE? If so, what happens if web developers call setSubDatawhile a buffer is mapped? What happens when a developer calls setSubData, then mapRead, then unmap? Will the ArrayBuffer returned in the WebGPUMappedMemory contain the contents of what the developer passed to setSubData?

To keep things simple for MVP, might be good to have buffers be either MAP_* or TRANSFER_* but not both.

A buffer cannot be TRANSFER_DST and MAP_WRITE because they are both writable usages. This is similar to the D3D12 state transition that doesn't allow two writable states at the same time.

While the buffer is mapped everything is disallowed but mapWrite, mapRead and unmap which means setSubData is disallowed (and you can't transition away from MAP_READ/WRITE either).

You really need to allow buffers that are TRANSFER_DST | MAP_READ because that's the only way to get data back from the GPU. But the restrictions on mapping and usage state make it so you can't have both at the same time.

To avoid GC discoverability, the implementation of WebGPUMappedMemory should keep its corresponding WebGPUBuffer alive.

That's ony way, and the application can make sure the WebGPUMappedMemory don't keep the WebGPUBuffer alive by calling WebGPUBuffer.unmap which will invalidate the WebGPUMappedMemory objects and lose the references to the buffer.

Do you think there's something we could do along the lines of allowing the buffer and the expensive BAR0 allocation to disappear but making the buffer replace the ArrayBuffer for the WebGPUMappedMemory objects with a CPU copy of their content when the buffer was GCed? I'm not sure if the pointer in an ArrayBuffer is mutable.

I'm pretty sure the pointer isn't mutable.

One of the goals of mapping subregions of the buffer is to avoid having to ask for the whole thing from the underlying API. Since you can ask for the original ArrayBuffer from an ArrayBufferView (via the buffer attribute), returning an ArrayBufferView from getPointer seems to undermine that goal.

Thanks I didn't know that. This might mean that we need to require mapped ranges to be disjoint but that's a pretty big restriction. @jdashg's idea of more explicit "client buffers" become more attractive.

Your document talks about MAP_READ, MAP_WRITE and TRANSFER_DST. What APIs apply to TRANSFER_SRC buffers? Is there a WebGPUBuffer.getSubData?

Any WebGPUCommandBuffer copy operation that reads from a buffer requires TRANSFER_SRC (provided we have explicit barriers). In this proposal there is no plan for WebGPUBuffer.getSubData. The reason why WebGPUBuffer.setSubData requires TRANSFER_DST is because internally the implementation will always put the data in a staging buffer and enqueue a buffer to buffer copy operation.

OK.

Using promises for buffers that change state is tricky because you can't change the state of a promise once it has been resolved. A promise can have multiple .then callbacks hooked up. If the developer keeps the promise returned from WebGPUMappedMemory.then in a local variable and .then's the local hours later, the browser must callback the new .then with the same ArrayBuffer it did originally.

What is the validity lifetime of the ArrayBuffers given to promise revolves in the multiple .then case?

Thanks, I now remember we mentioned something like that in a meeting. A potential solution was for .then to act like a Promise<void> and just signal that the buffer is now in the available state? What do you think of something like this?

It can also behave like Promise<WebGPUMappedMemory> (it just returns itself). Then getPointer can still return null (or neutered AB, or whatever).

Although if getPointer is going to return a neutered AB, there's no reason the Promise can't resolve to a neutered AB as well.

My questions was more about what "validity" means in the context of buffers and the event loop. For readback, if multiple pieces of code .then the promise, will the ArrayBuffer only be non-neutered when the first .then is invoked or when all of them are invoked? When will WebGPUMappedMemory go from the available state to the invalidated state?

It never happens automatically, only on unmap.

Thank you for the clarification, @kainino0x . That means if the developer calls .then on the WebGPUMappedMemory object multiple times and unmaps it on the first callback, all of the subsequent callbacks would get a neutered ArrayBuffer. I presume this is necessary because we want to unmap the buffer as soon as we can to keep the pipeline going. I guess this is a case of "Too bad, so sad" for the subsequent callbacks. :-)

Perhaps we could sidestep this problem by using callbacks directly. There is no timing problem because the earliest the callback could be run is at the next micro task boundary. It also solves the problem of code reusability (due to Promises not being able to be re-used once they are fulfilled).

I think there would be pushback from the TAG, but it's a possibility.
(I don't know that they would like our "thenable" thing any better.)

What is the rationale for having the Promise give you an ArrayBuffer in the writing (mapWrite or setSubData) case? When would I want my own data given back to me?

The mapWrite ArrayBuffer is where you write the data and it is made available to the buffer when unmap is called. I'll edit the doc.