Write specification for GPUBuffer mapping following #605 #708

Kangz · 2020-04-15T13:19:14Z

This also does a number of cleanups to match the style of other WebGPU
functions with the valid usage section.

spec/index.bs

kvark · 2020-04-15T17:39:40Z

spec/index.bs

+    ::
+        The range of this {{GPUBuffer}} that is mapped.
+
+    : <dfn>\[[mapped_ranges]]</dfn> of type `sequence<ArrayBuffer>` or `null`.


Do I understand correctly that these may intersect? It's not obvious. If so, would be worth to mention that in the spec, and what the behavior is going to be.
For example, can I move one of them to a different worker? What happens if I try to read/write the same range in multiple ArrayBuffer objects from different workers?

The spec for getMappedRange says:

Let m be a new ArrayBuffer of size size pointing at the content of this.[[mapping]] at offset offset - this.[[mapping_range]][0].

Agreed that it isn't super clear, I'll call out that the mapped ranges can overlap in a note.

so what about the act of writing to the same sub-range from different workers?

They are ArrayBuffer and not SharedArrayBuffer. Also there is a TODO to talk about worker restrictions and I added that getMappedRange can only be called on the worker on which mapAsync was called.

It's an extremely unfortunate restriction, but I don't see a better way to do things in JS. Open to suggestions though.

Right. So if the user tries to send an array buffer to another thread, it gets detached, and no harm is done.
I'm still a bit concerned about multiple array buffers seeing the same memory, will reach out to our folks to see if that's ok.

I'm confident this is ok, because you can already do that in JS with the following code:

let a = new ArrayBuffer(12); let b = new Uint32Array(a, 0, 2); let c = new Uint32Array(a, 4, 2); b // Uint32Array(2) [0, 0] c // Uint32Array(2) [0, 0] b[1] = 42; c[0] // 42

That's only one ArrayBuffer, though; this is multiple. I'd worry if engines might assume aliasing is impossible with ArrayBuffers (and data can't change underneath you).

SharedArrayBuffers would almost certainly be OK though, since data can change underneath them normally.

So if the user tries to send an array buffer to another thread, it gets detached

But it's attached on the other thread. This would allow you to have ArrayBuffers on multiple threads that reference the same data, making them behave as SABs.

I think we should pick one of these options:

Returns SAB and you can send the SAB to other threads. Problem: we need to be able to detach, but SABs can't normally be detached; engines may rely upon this invariant. Also unmap races.

Returns a special AB that's non-transferable (could still be serializable, we'd just copy the data). Disallow getMappedRange except from the mapping thread.

Like you noted, option 1) is not doable so it has to be option 2).

spec/index.bs

kvark · 2020-04-15T17:51:18Z

spec/index.bs

+      1, |this| must be a [=valid=] {{GPUDevice}}.
+      1. |descriptor|.{{GPUBufferDescriptor/usage}} must be a subset of |this|.[[allowed buffer usages]].
+      1. If |descriptor|.{{GPUBufferDescriptor/usage}} contains {{GPUBufferUsage/MAP_READ}} then
+        it must be a subset of {{GPUBufferUsage/MAP_READ}} | {{GPUBufferUsage/COPY_DST}}.


So, if I see a mapAsync call somewhere, in order to understand what this can do with a buffer, I need to find out how it's created and whether it was MAP_READ here or MAP_WRITE?
I think your earlier proposal with separate calls was clearer in this sense.

While I agree, that's not the takeaway from last call. If we need to debate this more, let's do it independently of this PR.

I don't think there was a strong yes from you or anybody on the need to have a single call. It was rather "maybe?", and now that we see cleaner how this would look (thanks for the PR!) at least on my side the "maybe?" leans more towards "no".

We discussed this offline with @kvark @kainino0x and @jdashg another possibility would be to add a MapFlags argument to mapAsync that would have to match the MAP_* usage for now. It allows future extensibility and makes it clear at the map call which it is.

spec/index.bs

kvark · 2020-04-20T18:49:48Z

spec/index.bs

+    ::
+        The range of this {{GPUBuffer}} that is mapped.
+
+    : <dfn>\[[mapped_ranges]]</dfn> of type `sequence<ArrayBuffer>` or `null`.


Right. So if the user tries to send an array buffer to another thread, it gets detached, and no harm is done.
I'm still a bit concerned about multiple array buffers seeing the same memory, will reach out to our folks to see if that's ok.

kvark · 2020-04-20T18:55:58Z

spec/index.bs

+      1. If |descriptor|.{{GPUBufferDescriptor/usage}} contains {{GPUBufferUsage/MAP_READ}} then
+        it must be a subset of {{GPUBufferUsage/MAP_READ}} | {{GPUBufferUsage/COPY_DST}}.
+      1. If |descriptor|.{{GPUBufferDescriptor/usage}} contains {{GPUBufferUsage/MAP_WRITE}} then
+        it must be a subset of {{GPUBufferUsage/MAP_WRITE}} | {{GPUBufferUsage/COPY_SRC}}.


Supposing my staging buffer is for uploads (MAP_WRITE + COPY_SRC). Since we are always providing the contents that they have, and they can always read them, it sounds like MAP_READ is automatically supported, even if it's useless? I wonder if we should rename MAP_WRITE to just MAP or something like MAP_READ_WRITE or MAP_RW, etc

I think this distinction should remain somehow because MAP_READ can be used as a COPY_DST but we don't want your staging buffer to be one, for example.

Exactly, right now if you can't wrap shmem in GPU resources, the only things that needs to happen for uploads via mapAsync is that on unmap the ranges of data used in getMappedRange (or the whole mapAsync) need to be pushed to the GPU process.

When calling mapAsync no data needs to be moved from the GPU process to the content process because the GPU cannot write to it, and the data kept resident in the content process is already up to date.

@JusSn I'm not saying we should change MAP_READ - it's useful and needs to stay. I'm saying that MAP_WRITE could be renamed to something that indicates that it can be read as well, since only COPY_SRC is allowed with it, and there is no problem for reading it on CPU.

spec/index.bs

JusSn · 2020-04-21T02:26:13Z

spec/index.bs

+      1. If |descriptor|.{{GPUBufferDescriptor/usage}} contains {{GPUBufferUsage/MAP_READ}} then
+        it must be a subset of {{GPUBufferUsage/MAP_READ}} | {{GPUBufferUsage/COPY_DST}}.
+      1. If |descriptor|.{{GPUBufferDescriptor/usage}} contains {{GPUBufferUsage/MAP_WRITE}} then
+        it must be a subset of {{GPUBufferUsage/MAP_WRITE}} | {{GPUBufferUsage/COPY_SRC}}.


I think this distinction should remain somehow because MAP_READ can be used as a COPY_DST but we don't want your staging buffer to be one, for example.

JusSn · 2020-04-21T02:44:49Z

spec/index.bs

+    1. Throw an {{OperationError}}.

-        Issue: Specify that the rejection happens on the device timeline.
+  1. Let |m| be a new {{ArrayBuffer}} of size |size| pointing at the content of |this|.{{[[mapping]]}} at offset |offset| - |this|.{{[[mapping_range]]}}[0].


Suggested change

1. Let |m| be a new {{ArrayBuffer}} of size |size| pointing at the content of |this|.{{[[mapping]]}} at offset |offset| - |this|.{{[[mapping_range]]}}[0].

1. Let |m| be a new {{ArrayBuffer}} of size |size| pointing at the content of |this|.{{[[mapping]]}} at offset |offset|.

Right? If both |offset| and |this|.{{[[mapping_range]]}}[0] are relative to the start of the |this|.{{[[mapping]]}}?

This is confusing, but I think the original text is correct because [[mapping]] was created in the following line:

Set the content of m to the content of this’s allocation starting at offset offset and for size bytes.

Set this.[[mapping]] to m.

[[mapping_range]] is relative to the whole allocation of this, same for offset and size of getMappedRange, but [[mapping]] is a subrange of the allocation. This is all very confusing and I'd be happy to reword things if you find clearer names / explanations.

spec/index.bs

kvark · 2020-04-27T15:05:39Z

I talked to our JS folks with regards to intersecting array buffers. The conclusion is: we are fine with the intersection, but the offsets should be all aligned to 8 bytes. Otherwise, users wouldn't be able to create the typed views of them.

kainino0x · 2020-04-28T00:55:13Z

spec/index.bs

+    ::
+        The range of this {{GPUBuffer}} that is mapped.
+
+    : <dfn>\[[mapped_ranges]]</dfn> of type `sequence<ArrayBuffer>` or `null`.


That's only one ArrayBuffer, though; this is multiple. I'd worry if engines might assume aliasing is impossible with ArrayBuffers (and data can't change underneath you).

SharedArrayBuffers would almost certainly be OK though, since data can change underneath them normally.

kainino0x · 2020-04-28T01:01:21Z

spec/index.bs

+    ::
+        The range of this {{GPUBuffer}} that is mapped.
+
+    : <dfn>\[[mapped_ranges]]</dfn> of type `sequence<ArrayBuffer>` or `null`.


So if the user tries to send an array buffer to another thread, it gets detached

But it's attached on the other thread. This would allow you to have ArrayBuffers on multiple threads that reference the same data, making them behave as SABs.

I think we should pick one of these options:

Returns SAB and you can send the SAB to other threads. Problem: we need to be able to detach, but SABs can't normally be detached; engines may rely upon this invariant. Also unmap races.

Returns a special AB that's non-transferable (could still be serializable, we'd just copy the data). Disallow getMappedRange except from the mapping thread.

spec/index.bs

kainino0x · 2020-05-04T21:18:25Z

[editors call] Since we decided not to land this right now anyway, we may as well update it to require disjoint ranges before landing.

Kangz · 2020-05-05T12:50:13Z

Addressed comments raised in the meeting. Let me know if I can go ahead with a squash + rebase.

kainino0x · 2020-05-05T16:10:08Z

Please do, and we'll probably go ahead with landing after writeBuffer.

This also does a number of cleanups to match the style of other WebGPU functions with the valid usage section.

Kangz · 2020-05-05T16:53:52Z

Rebased and squashed.

kainino0x · 2020-05-07T16:54:07Z

Per the meeting let's get this merged with the outstanding things to discuss:

split the calls or add a flag (has Issue)
List of issues to discuss with TC39, WASM, JS engine teams #747

675: New map_async logic r=cwfitzgerald a=kvark Matches upstream changes in gpuweb/gpuweb#708 and gpuweb/gpuweb#796 TODO: - wgpu-native PR - wgpu-rs gfx-rs/wgpu-rs#344 Co-authored-by: Dzmitry Malyshau <[email protected]>

…b#708) This also does a number of cleanups to match the style of other WebGPU functions with the valid usage section.

Kangz requested review from kvark, kainino0x and JusSn April 15, 2020 13:19

kvark requested changes Apr 15, 2020

View reviewed changes

kvark requested changes Apr 20, 2020

View reviewed changes

JusSn reviewed Apr 21, 2020

View reviewed changes

kvark approved these changes Apr 21, 2020

View reviewed changes

kainino0x approved these changes Apr 28, 2020

View reviewed changes

kainino0x reviewed Apr 28, 2020

View reviewed changes

spec/index.bs Show resolved Hide resolved

kvark approved these changes May 5, 2020

View reviewed changes

kainino0x approved these changes May 5, 2020

View reviewed changes

Write specification for GPUBuffer mapping following gpuweb#605

1f6c7e0

This also does a number of cleanups to match the style of other WebGPU functions with the valid usage section.

Kangz force-pushed the map_async branch from 02dc369 to 1f6c7e0 Compare May 5, 2020 16:51

Kangz mentioned this pull request May 7, 2020

Add Queue/writeBuffer method #749

Merged

kainino0x merged commit bd36513 into gpuweb:master May 7, 2020

Kangz deleted the map_async branch May 7, 2020 16:54

kainino0x mentioned this pull request May 21, 2020

mappedAtCreation missing gpuweb/types#19

Closed

kvark mentioned this pull request May 26, 2020

Update mapping API with mapAsync gfx-rs/wgpu#671

Closed

kvark mentioned this pull request Jun 2, 2020

New map_async logic gfx-rs/wgpu#675

Merged

JusSn pushed a commit to JusSn/gpuweb that referenced this pull request Jun 8, 2020

Write specification for GPUBuffer mapping following gpuweb#605 (gpuwe…

23533d1

…b#708) This also does a number of cleanups to match the style of other WebGPU functions with the valid usage section.

JusSn pushed a commit to JusSn/gpuweb that referenced this pull request Jun 8, 2020

Write specification for GPUBuffer mapping following gpuweb#605 (gpuwe…

9e36a03

…b#708) This also does a number of cleanups to match the style of other WebGPU functions with the valid usage section.

ben-clayton pushed a commit to ben-clayton/gpuweb that referenced this pull request Sep 6, 2022

Remove some alpha blending factor validation (gpuweb#708)

c0179a2

	1. Let \|m\| be a new {{ArrayBuffer}} of size \|size\| pointing at the content of \|this\|.{{[[mapping]]}} at offset \|offset\| - \|this\|.{{[[mapping_range]]}}[0].
	1. Let \|m\| be a new {{ArrayBuffer}} of size \|size\| pointing at the content of \|this\|.{{[[mapping]]}} at offset \|offset\|.

Write specification for GPUBuffer mapping following #605 #708

Write specification for GPUBuffer mapping following #605 #708

Uh oh!

Conversation

Kangz commented Apr 15, 2020 • edited by pr-preview bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

kvark commented Apr 27, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Kangz commented Apr 15, 2020 •

edited by pr-preview bot

Loading