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
Arrange for passing an invalid `BindGroupLayout` to `CreatePipelineLayout` or
`CreateBindGroup` to produce an invalid `PipelineLayout`/`BindGroup`, instead of
trying to pass the `BindGroupLayout`'s bogus `RawId` (which is zero) over to the
GPU process, causing a panic in deserialization (thank you, Rust!).
Arrange for a `PipelineLayout` constructed with a zero `RawId` to mark itself
invalid, as most other WebGPU content objects do. This permits
`WebGPUChild::DeviceCreatePipelineLayout` to return zero if the descriptor is
invalid.
Differential Revision: https://phabricator.services.mozilla.com/D145036
This patch hooks up the improved CanvasManagerChild::GetSnapshot method
to the WebGPU canvas context object in order to do readbacks for various
DOM facing methods such as ConvertToBlob and for Firefox Screenshots.
Differential Revision: https://phabricator.services.mozilla.com/D144309
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 patch hooks up the improved CanvasManagerChild::GetSnapshot method
to the WebGPU canvas context object in order to do readbacks for various
DOM facing methods such as ConvertToBlob and for Firefox Screenshots.
Differential Revision: https://phabricator.services.mozilla.com/D144309
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 patch hooks up the improved CanvasManagerChild::GetSnapshot method
to the WebGPU canvas context object in order to do readbacks for various
DOM facing methods such as ConvertToBlob and for Firefox Screenshots.
Differential Revision: https://phabricator.services.mozilla.com/D144309
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
Continue to set the returned stream to `nullptr` (which callers do not
check for, but is safe), but return `NS_ERROR_NOT_IMPLEMENTED` instead
of `NS_OK` --- callers do check the `nsresult`.
Returning an `NS_FAILED` result from our `GetInputStream`
implementation causes `HTMLCanvasElement.prototype.toDataURL` to
return the fallback value `"data:,"`.
Differential Revision: https://phabricator.services.mozilla.com/D144242
Remove the unused source directory `dom/webgpu/ffi`.
The `wgpu_ffi_generated.h` header actually #included by
`gfx/wgpu_bindings/wgpu.h` is generated by `gfx/wgpu_bindings/moz.build` at
build time and placed in the obj directory. The copy in the source directory is
ignored, and it's confusing to keep it around.
Differential Revision: https://phabricator.services.mozilla.com/D143931
New versions of several crates are introduced to third_party/rust, by
changing the versions requested in `gfx/wgpu_bindings/Cargo.toml` and
running `mach vendor rust`:
- `wgpu-core`, `wgpu-hal`, and `wgpu-types`, as used by `wgpu_bindings`
- `naga`, `ash`, and `metal`, as used by the above
These are all exact copies of the upstream sources, at the git
revisions listed in `.cargo/config.in`.
This brings in fixes for some upstream `wgpu` bugs that were fuzzblockers:
- Compute pipelines never freed at runtime, leaking memory #2564https://github.com/gfx-rs/wgpu/issues/2564
- Device::drop doesn't actually free the device when using backend::direct::Context #2563https://github.com/gfx-rs/wgpu/issues/2563
The Firefox sources also needed some adjustments to catch up with
upstream changes:
- The C type `mozilla::webgpu::ffi::WGPUTextureFormat` is now a struct
containing a tag enum and a union, not just an enum. This is needed
for [gfx-rs/wgpu#2477](https://github.com/gfx-rs/wgpu/pull/2477).
(Note that Firefox's `WebGPU.webidl` is behind the current spec,
so even though the newest ASTC texture formats are supported in `wgpu`,
they're not available in Firefox yet.)
- `wgpu` got a new feature, `id32`, which cbindgen needed to be told
about so that it would generate preprocessor-protected code like
this:
#if defined(WGPU_FEATURE_ID32)
typedef uint32_t WGPUNonZeroId;
#endif
#if !defined(WGPU_FEATURE_ID32)
typedef uint64_t WGPUNonZeroId;
#endif
instead of just spitting out two conflicting definitions of
`WGPUNonZeroId`.
- The `wgpu_core::hub::IdentityHandlerFactory` trait's `spawn` method
no longer takes a `min_index` argument. (Our implementations of that
trait never used that argument anyway, so this was easy to
accommodate.)
Differential Revision: https://phabricator.services.mozilla.com/D142779
New versions of several crates are introduced to third_party/rust, by
changing the versions requested in `gfx/wgpu_bindings/Cargo.toml` and
running `mach vendor rust`:
- `wgpu-core`, `wgpu-hal`, and `wgpu-types`, as used by `wgpu_bindings`
- `naga`, `ash`, and `metal`, as used by the above
These are all exact copies of the upstream sources, at the git
revisions listed in `.cargo/config.in`.
This brings in fixes for some upstream `wgpu` bugs that were fuzzblockers:
- Compute pipelines never freed at runtime, leaking memory #2564https://github.com/gfx-rs/wgpu/issues/2564
- Device::drop doesn't actually free the device when using backend::direct::Context #2563https://github.com/gfx-rs/wgpu/issues/2563
The Firefox sources also needed some adjustments to catch up with
upstream changes:
- The C type `mozilla::webgpu::ffi::WGPUTextureFormat` is now a struct
containing a tag enum and a union, not just an enum. This is needed
for [gfx-rs/wgpu#2477](https://github.com/gfx-rs/wgpu/pull/2477).
(Note that Firefox's `WebGPU.webidl` is behind the current spec,
so even though the newest ASTC texture formats are supported in `wgpu`,
they're not available in Firefox yet.)
- `wgpu` got a new feature, `id32`, which cbindgen needed to be told
about so that it would generate preprocessor-protected code like
this:
#if defined(WGPU_FEATURE_ID32)
typedef uint32_t WGPUNonZeroId;
#endif
#if !defined(WGPU_FEATURE_ID32)
typedef uint64_t WGPUNonZeroId;
#endif
instead of just spitting out two conflicting definitions of
`WGPUNonZeroId`.
- The `wgpu_core::hub::IdentityHandlerFactory` trait's `spawn` method
no longer takes a `min_index` argument. (Our implementations of that
trait never used that argument anyway, so this was easy to
accommodate.)
Differential Revision: https://phabricator.services.mozilla.com/D142779
The WebGPU tests are actually failing silently on Ubuntu 18.04 and
Windows 7. This is because we catch the exception thrown in the async
function wrapping the test and then discard it at the end. Now if we
catch any errors, we fail the test, which requires us to mark these
tests as failing on some platforms.
Differential Revision: https://phabricator.services.mozilla.com/D141793
This patch just adds the plumbing to allow for baked in blocklist rules
or the downloadable blocklist to prevent certain configurations from
getting WebGPU. It does not add any rules.
It also changes us from allowing WebGPU only in nightly, including
tests, to not release and not beta. This allows try to run the WebGPU
tests as expected, since even try builds forked from mozilla-central are
not considered nightly builds by CI (or so it seems).
Differential Revision: https://phabricator.services.mozilla.com/D141682
The changes in this patch stack will change how IPDL generated files are built,
such that these issues are now surfaced, especially during non-unified builds.
Differential Revision: https://phabricator.services.mozilla.com/D137165
This patch removes more main thread dependencies from the content side
of WebGPU. Instead of issuing a resource update for an external image,
we now use an async image pipeline in conjunction with
CompositableInProcessManager from part 1. This allows us to update the
HTMLCanvasElement bound to the WebGPU device without having to go
through the main thread, or even the content process after the swap
chain update / readback has been requested.
Differential Revision: https://phabricator.services.mozilla.com/D138887
This patch removes more main thread dependencies from the content side
of WebGPU. Instead of issuing a resource update for an external image,
we now use an async image pipeline in conjunction with
CompositableInProcessManager from part 1. This allows us to update the
HTMLCanvasElement bound to the WebGPU device without having to go
through the main thread, or even the content process after the swap
chain update / readback has been requested.
Differential Revision: https://phabricator.services.mozilla.com/D138887
This patch ensures that we only update the external image resource for
WebGPU when there has been an actual change for the resource. In order
to guarantee this, we wait for the present to complete, and only then
issue the update. WebRenderBridgeChild::SendResourceUpdates will also
trigger a frame generation if any resources were changed, which means we
don't need to trigger a paint on the frame itself anymore.
Note that we still have a race condition when we write into the
MemoryTextureHost while in PresentCallback, and the renderer thread may
be accessing the pixel data to upload to the GPU.
Differential Revision: https://phabricator.services.mozilla.com/D138349
This is necessary for when WebGPU objects are accessed from a worker
thread instead of the main thread. It should be otherwise a
non-functional change.
Differential Revision: https://phabricator.services.mozilla.com/D138206