ExternalTextures imported from HTMLVideoElements get "expired" in the
"automatic expiry task source", which is implemented by scheduling a
stable state task. ExternalTextures imported from VideoFrames get
expired when the VideoFrame is closed.
Keep track of each external texture used by any used bind group when
encoding compute and render passes. When submitting, if any passes
contain expired external textures then raise a validation error.
Currently we always create a new ExternalTexture when
importExternalTexture() is called. When support for reusing previously
imported textures is added, we must ensure they are correctly
"unexpired".
Differential Revision: https://phabricator.services.mozilla.com/D260295
Most changes are automated. Relevant bit is dom/.clang-format. I had to
manually disable clang-format in a few places where importing external
files and so on that aren't self-contained, and fix a couple includes /
forward declarations.
Differential Revision: https://phabricator.services.mozilla.com/D256800
Driven by [gpuweb#4838](https://github.com/gpuweb/gpuweb/pull/4838).
The vast majority of this script was implemented with a Nushell script,
using the `nu` binary and the wonderful `fastmod` tool
```
# Copy-pasted from the OP in [`gpuweb`#4838](https://github.com/gpuweb/gpuweb/pull/4838).
let renames_table = '
Type Old New Used in
dict GPUImageDataLayout GPUTexelCopyBufferLayout "writeTexture,
parent type of ↙"
dict GPUImageCopyBuffer "GPUTexelCopyBufferInfo
extends ↑" T2B, B2T
dict GPUImageCopyTexture GPUTexelCopyTextureInfo T2B, B2T, T2T, writeTexture
dict GPUImageCopyTextureTagged "GPUCopyExternalImageDestInfo
extends ↑" copyExternalImageToTexture
dict GPUImageCopyExternalImage GPUCopyExternalImageSourceInfo copyExternalImageToTexture
union GPUImageCopyExternalImageSource GPUCopyExternalImageSource member of ↖
'
let renames_table = $renames_table
| from tsv
| select 'Old ' 'New '
| rename old new
| update new { $in | lines | get 0 } # only the first line has the renamed symbol identifier
| update new { str trim }
| update old { str trim }
| sort-by old | reverse # Replace most specific symbol names first (some have the same "word segments" but with fewer segments)
# Rename image APIs.
let rename_paths = [
...("dom/webgpu/*.{cpp,h}" | str expand)
"dom/webidl/WebGPU.webidl"
] | each { glob $in } | flatten
for entry in $renames_table {
print $'replacing ($entry.old | to nuon) with ($entry.new | to nuon)'
fastmod --accept-all $'\b($entry.old)' $entry.new ...$rename_paths
}
```
Differential Revision: https://phabricator.services.mozilla.com/D230193
Driven by [gpuweb#4838](https://github.com/gpuweb/gpuweb/pull/4838).
The vast majority of this script was implemented with a Nushell script,
using the `nu` binary and the wonderful `fastmod` tool
```
# Copy-pasted from the OP in [`gpuweb`#4838](https://github.com/gpuweb/gpuweb/pull/4838).
let renames_table = '
Type Old New Used in
dict GPUImageDataLayout GPUTexelCopyBufferLayout "writeTexture,
parent type of ↙"
dict GPUImageCopyBuffer "GPUTexelCopyBufferInfo
extends ↑" T2B, B2T
dict GPUImageCopyTexture GPUTexelCopyTextureInfo T2B, B2T, T2T, writeTexture
dict GPUImageCopyTextureTagged "GPUCopyExternalImageDestInfo
extends ↑" copyExternalImageToTexture
dict GPUImageCopyExternalImage GPUCopyExternalImageSourceInfo copyExternalImageToTexture
union GPUImageCopyExternalImageSource GPUCopyExternalImageSource member of ↖
'
let renames_table = $renames_table
| from tsv
| select 'Old ' 'New '
| rename old new
| update new { $in | lines | get 0 } # only the first line has the renamed symbol identifier
| update new { str trim }
| update old { str trim }
| sort-by old | reverse # Replace most specific symbol names first (some have the same "word segments" but with fewer segments)
# Rename image APIs.
let rename_paths = [
...("dom/webgpu/*.{cpp,h}" | str expand)
"dom/webidl/WebGPU.webidl"
] | each { glob $in } | flatten
for entry in $renames_table {
print $'replacing ($entry.old | to nuon) with ($entry.new | to nuon)'
fastmod --accept-all $'\b($entry.old)' $entry.new ...$rename_paths
}
```
Differential Revision: https://phabricator.services.mozilla.com/D230193
This makes sure we never create an invalid (zero) ID after incorrect usage of a command encoder.
It also simplifies the code. The JS object should not do any validaion (per spec) and simply forward the commands to the parent process where all of the validation is done.
Differential Revision: https://phabricator.services.mozilla.com/D192839
This makes sure we never create an invalid (zero) ID after incorrect usage of a command encoder.
It also simplifies the code. The JS object should not do any validaion (per spec) and simply forward the commands to the parent process where all of the validation is done.
Differential Revision: https://phabricator.services.mozilla.com/D192839
This makes sure we never create an invalid (zero) ID after incorrect usage of a command encoder.
It also simplifies the code. The JS object should not do any validaion (per spec) and simply forward the commands to the parent process where all of the validation is done.
Differential Revision: https://phabricator.services.mozilla.com/D192839
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 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
Sylvestre Ledru