* Add validation for requested features and devices for
adapter.requestDevice().
* Promote webgl's AutoAssertCast to mfbt/Casting.h/LazyAssertedCast.
Differential Revision: https://phabricator.services.mozilla.com/D177110
* Add validation for requested features and devices for
adapter.requestDevice().
* Promote webgl's AutoAssertCast to mfbt/Casting.h/LazyAssertedCast.
Differential Revision: https://phabricator.services.mozilla.com/D177110
@jimb expressed concern that a collapsed group of compilation messages for WebGPU shaders in the JS console isn't easy enough to discern from scanning a console log manually. We can't associate a log level with the group itself (which would let us paint the group with color for contrast), unfortunately. So, we decided to have a "sentinel" message right before groups that uses the highest "severity" of message in the entire set of compilation messages.
Differential Revision: https://phabricator.services.mozilla.com/D175404
Time to finally add some (barebones) diagnostics! When a user calls [`GPUDevice.createShaderModule`], if there are any messages returned:
1. Create a collapsed console group. Use a generic title for the console group (for now).
1. Inside the console group, print containing a log entry per message with a JS log level according to the message severity.
Differential Revision: https://phabricator.services.mozilla.com/D175303
@jimb expressed concern that a collapsed group of compilation messages for WebGPU shaders in the JS console isn't easy enough to discern from scanning a console log manually. We can't associate a log level with the group itself (which would let us paint the group with color for contrast), unfortunately. So, we decided to have a "sentinel" message right before groups that uses the highest "severity" of message in the entire set of compilation messages.
Differential Revision: https://phabricator.services.mozilla.com/D175404
Time to finally add some (barebones) diagnostics! When a user calls [`GPUDevice.createShaderModule`], if there are any messages returned:
1. Create a collapsed console group. Use a generic title for the console group (for now).
1. Inside the console group, print containing a log entry per message with a JS log level according to the message severity.
Differential Revision: https://phabricator.services.mozilla.com/D175303
In WebGPU, entry point names and labels from types like
`GPUComputePipelineDescriptor` eventually get turned into Rust `&str` values.
The prior code used `LossyCopyUTF16ToASCII` to produce `nsCString`s from the
`nsString`s received from the WebIDL bindings, and then passed the resulting
bytes to Rust `std::ffi::CStr::to_str`. Unfortunately, that "ASCII" actually
means Latin-1, so if the entry point named happened to be representable in
Latin-1 that happened not to be valid UTF-8, `wgpu_bindings::cow_label` would
return `None`, leading to a panic when unwrapped by
`wgpu_bindings::client::ProgrammableStageDescriptor::to_wgpu`.
The fix: just call `CopyUTF16ToUTF8` instead. This should always produce bytes
that `CStr::to_str` can consume. The WebIDL for WebGPU uses `USVString` for
entry point names and labels, so these values should never contain unpaired
surrogate code points, meaning that conversion should always succeed.
Differential Revision: https://phabricator.services.mozilla.com/D168188
WebGPU uses CompositableInProcessManager to push TextureHost directly from WebGPUParent to WebRender. But CompositableInProcessManager plumbing has a problem and caused Bug 1805209.
gecko already has a similar mechanism, called RemoteTextureMap. It is used in oop WebGL. If WebGPU uses RemoteTextureMap instead of CompositableInProcessManager, both WebGPU and oop WebGL use same mechanism.
WebGPUParent pushes a new texture to RemoteTextureMap. The RemoteTextureMap notifies the pushed texture to WebRenderImageHost.
Before the change, only one TextureHost is used for one swap chain. With the change, multiple TextureHosts are used for one swap chain with recycling.
The changes are followings.
- Use RemoteTextureMap instead of CompositableInProcessManager.
- Use RemoteTextureOwnerId instead of CompositableHandle.
- Use WebRenderCanvasData instead of WebRenderInProcessImageData.
- Add remote texture pushed callback functionality to RemoteTextureMap. With it, RemoteTextureMap notifies a new pushed remote texture to WebRenderImageHost.
- Remove CompositableInProcessManager.
Differential Revision: https://phabricator.services.mozilla.com/D164890
As of the prior patch, these are no longer needed. I removed
these with a script, then ran clang-format on the files, then
manually reverted a few unrelated changed from the formatter.
Differential Revision: https://phabricator.services.mozilla.com/D164829
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
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
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
