The former frees resources but keeps the handle. It can be called multiple times. The latter destroys the handle. Any subsequent reference to the same buffer is a bug and will cause the GPU process to crash.
Depends on D152080
Differential Revision: https://phabricator.services.mozilla.com/D152081
Per spec (and discussion with someone on the chromium side where spec is vague), the correct behavior should be:
- MapAsync validation happens on the device timeline, so we should reject the promise in mapAsync on the content side if we run into an internal error not described by the spec.
- Unmap immediately rejects all pending mapping promises on the content side (there can be multiple of them since we have to catch that error on the device timeline).
This patch tracks a single mapping promise at a time and immediately rejects on the content side any subseqent mapping
request made until unmap is called. This means our current implementation deviates slightly from the current state of
the spec in that:
- The promise is rejected earlier on the content timeline,
- If the first request fails, all subsequent requests will fail until either unmap or when the content side receives and processes the rejected
promise, whereas Dawn's implementation would allow the first valid request to succed.
There was some confusion around the the use of uint64_t and size_t which probably originated at point where this code was working differently. This patch uses uint64_t (=BufferAddress) more consistently removing the need for some of the casting and overflow checks.
One notable change in the overall logic is that SetMapped is now called when the buffer is actually in the mapped state (before this patch it was called as soon as the buffer had a pending map request).
Depends on D151618
Differential Revision: https://phabricator.services.mozilla.com/D151619
This commit makes WebGPU buffers use unsafe shmems.
Instead of relying on moving the shmem back and forth between the two processes to ensure thread safety, we instead rely on the validation done on both sides. The upside is that it makes it much easier to implement said validation correctly.
In the interest of splitting the buffer mapping rework into small-ish commits, this one puts some structural pieces in place but doesn't necessarily do justice to the final implementation:
- The validation itself is coming in subsequent patches in this series.
- Mapping sub-ranges of the buffer was somewhat implemented in some parts of the parent code and not in others, and was fairly broken as a whole. This commit always maps the entire buffer and proper logic for sub-ranges is coming in another commit.
The main things this commit does put in place:
- Each mappable buffer is associated with a Shmem that is accessible to both sides.
- On the child side, if a buffer is not mappable, then Buffer::mShmem is in its default state (it doesn't point to any shared memory segment).
- On the parent side, if a buffer is not mappable it does not have an entry in mSharedMemoryMap.
- The shmem is always created by the child and destroyed by the parent.
Depends on D151615
Differential Revision: https://phabricator.services.mozilla.com/D151616
Also return an empty slice instead of crashing in case of errors.
This is a small piece split off of the buffer mapping rework. Most of the call sites are completely rewritten in followup patches, and error reporting will also come in followups.
Depends on D151374
Differential Revision: https://phabricator.services.mozilla.com/D151615
Most operations maniplating shmems in WebGPU are fallible, we'll have to handle passing them conditionally in most messages.
This commit starts with BufferMap, to avoid crashing when map is called on an invalid buffer.
Differential Revision: https://phabricator.services.mozilla.com/D149892
The former frees resources but keeps the handle. It can be called multiple times. The latter destroys the handle. Any subsequent reference to the same buffer is a bug and will cause the GPU process to crash.
Depends on D152080
Differential Revision: https://phabricator.services.mozilla.com/D152081
Per spec (and discussion with someone on the chromium side where spec is vague), the correct behavior should be:
- MapAsync validation happens on the device timeline, so we should reject the promise in mapAsync on the content side if we run into an internal error not described by the spec.
- Unmap immediately rejects all pending mapping promises on the content side (there can be multiple of them since we have to catch that error on the device timeline).
This patch tracks a single mapping promise at a time and immediately rejects on the content side any subseqent mapping
request made until unmap is called. This means our current implementation deviates slightly from the current state of
the spec in that:
- The promise is rejected earlier on the content timeline,
- If the first request fails, all subsequent requests will fail until either unmap or when the content side receives and processes the rejected
promise, whereas Dawn's implementation would allow the first valid request to succed.
There was some confusion around the the use of uint64_t and size_t which probably originated at point where this code was working differently. This patch uses uint64_t (=BufferAddress) more consistently removing the need for some of the casting and overflow checks.
One notable change in the overall logic is that SetMapped is now called when the buffer is actually in the mapped state (before this patch it was called as soon as the buffer had a pending map request).
Depends on D151618
Differential Revision: https://phabricator.services.mozilla.com/D151619
This commit makes WebGPU buffers use unsafe shmems.
Instead of relying on moving the shmem back and forth between the two processes to ensure thread safety, we instead rely on the validation done on both sides. The upside is that it makes it much easier to implement said validation correctly.
In the interest of splitting the buffer mapping rework into small-ish commits, this one puts some structural pieces in place but doesn't necessarily do justice to the final implementation:
- The validation itself is coming in subsequent patches in this series.
- Mapping sub-ranges of the buffer was somewhat implemented in some parts of the parent code and not in others, and was fairly broken as a whole. This commit always maps the entire buffer and proper logic for sub-ranges is coming in another commit.
The main things this commit does put in place:
- Each mappable buffer is associated with a Shmem that is accessible to both sides.
- On the child side, if a buffer is not mappable, then Buffer::mShmem is in its default state (it doesn't point to any shared memory segment).
- On the parent side, if a buffer is not mappable it does not have an entry in mSharedMemoryMap.
- The shmem is always created by the child and destroyed by the parent.
Depends on D151615
Differential Revision: https://phabricator.services.mozilla.com/D151616
Also return an empty slice instead of crashing in case of errors.
This is a small piece split off of the buffer mapping rework. Most of the call sites are completely rewritten in followup patches, and error reporting will also come in followups.
Depends on D151374
Differential Revision: https://phabricator.services.mozilla.com/D151615
Most operations maniplating shmems in WebGPU are fallible, we'll have to handle passing them conditionally in most messages.
This commit starts with BufferMap, to avoid crashing when map is called on an invalid buffer.
Differential Revision: https://phabricator.services.mozilla.com/D149892
Inspired by emilio's suggestion in the shader module API patch. This tries to be the most straightforward way to go from the strings coming from IPC to the ones consumed by wgpu.
Differential Revision: https://phabricator.services.mozilla.com/D151024
This patch is a lot of plumbing for not that much functionality. The goal is to align CreateShaderModule's error reporting with the spec.
Creating a shader module is now a dedicated async IPDL message returning the compilation info so that it can be exposed as a promise by the WebGPU API.
Differential Revision: https://phabricator.services.mozilla.com/D146817
Inspired by emilio's suggestion in the shader module API patch. This tries to be the most straightforward way to go from the strings coming from IPC to the ones consumed by wgpu.
Differential Revision: https://phabricator.services.mozilla.com/D151024
This patch is a lot of plumbing for not that much functionality. The goal is to align CreateShaderModule's error reporting with the spec.
Creating a shader module is now a dedicated async IPDL message returning the compilation info so that it can be exposed as a promise by the WebGPU API.
Differential Revision: https://phabricator.services.mozilla.com/D146817
This patch is a lot of plumbing for not that much functionality. The goal is to align CreateShaderModule's error reporting with the spec.
Creating a shader module is now a dedicated async IPDL message returning the compilation info so that it can be exposed as a promise by the WebGPU API.
Differential Revision: https://phabricator.services.mozilla.com/D146817
Depends on [`wgpu#2673`].
WebGPU requires `GPUBufferDescriptor` validation failure to:
1) generate an error on the Device timeline, and
2) mark the new buffer as invalid.
Satisfy 1) by moving most validation to the compositor process.
Requirement 2) is harder. `wgpu_core::Global::device_create_buffer`
already takes care of some validation for us, and marks the provided
buffer id invalid when there's a problem. However, there are certain
errors the spec requires us to detect which `device_create_buffer`
cannot even see, because they are caught by standard Rust validation
steps in the process of creating the `wgpu_types::BufferDescriptor`
that one would *pass to* that function. For example, if there are
bogus bits set in the `usage` property, we can't even construct a Rust
`BufferUsages` value from that to include in the `BufferDescriptor`
that we must pass to `device_create_buffer`.
This means that we need to do some validation ourselves, in the
process of constructing that `BufferDescriptor`, and use the
`Global::create_buffer_error` method added in [`wgpu#2673`] to mark
the new buffer as invalid.
[`wgpu#2673`]: https://github.com/gfx-rs/wgpu/pull/2673
Differential Revision: https://phabricator.services.mozilla.com/D146768
Document various things. Spell out that the error messages are UTF-8.
Let `server.rs`'s `ErrorBuffer` take a `&str` instead of a `String`.
Differential Revision: https://phabricator.services.mozilla.com/D146767
The WebGPU spec says that `beginRenderPass` should generate a
validation error if the valid usage rules for
`GPURenderPassDescriptor` are not satisfied. In particular, a
`GPURenderPassDescriptor` may not contain more than eight color
attachments.
The `wgpu-core` crate will panic if a
`wgpu_core::command::RenderPassDescriptor` contains too many color
attachments. This is safe, but panics are not acceptable in Firefox,
so it falls to our WebGPU implementation to perform the error checks
described by the spec.
Since WebGPU error handling records the first error to occur within
each error scope, the API is sensitive to the order in which errors
are generated. To ensure that the error is properly ordered with
respect to other messages sent to the device, we must send the error
to compositor process. The WebGPUParent will then handle it
interleaved appropriately with other Device timeline activity.
Differential Revision: https://phabricator.services.mozilla.com/D146391
This reworks the CanvasManagerChild::GetSnapshot method to work with
WebGPU. This will allow it to be called for a WebGPU context from any
thread, which is useful for screenshots.
Differential Revision: https://phabricator.services.mozilla.com/D144308
This reworks the CanvasManagerChild::GetSnapshot method to work with
WebGPU. This will allow it to be called for a WebGPU context from any
thread, which is useful for screenshots.
Differential Revision: https://phabricator.services.mozilla.com/D144308
This reworks the CanvasManagerChild::GetSnapshot method to work with
WebGPU. This will allow it to be called for a WebGPU context from any
thread, which is useful for screenshots.
Differential Revision: https://phabricator.services.mozilla.com/D144308
