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 change adds support for CanvasContext presenting WebGPU via CPU readback.
The presentation is handled mostly on GPU process side by managing a list of staging buffers
and copying the contents into a WR external image (backed by an external buffer).
Differential Revision: https://phabricator.services.mozilla.com/D68032
This change adds support for CanvasContext presenting WebGPU via CPU readback.
The presentation is handled mostly on GPU process side by managing a list of staging buffers
and copying the contents into a WR external image (backed by an external buffer).
Differential Revision: https://phabricator.services.mozilla.com/D68032
This change adds support for CanvasContext presenting WebGPU via CPU readback.
The presentation is handled mostly on GPU process side by managing a list of staging buffers
and copying the contents into a WR external image (backed by an external buffer).
Differential Revision: https://phabricator.services.mozilla.com/D68032
Previously, we kept the object IDs managed on content side only.
The GPU side would work with given indices.
When an object is destroyed, we'd free the ID on the content side and signal the GPU to delete the object.
Problem is that on the GPU process the object may still be kept alive for as long as any dependants are alive.
What this change is doing - hooking up the callbacks to the *actual* freeing of IDs on the GPU side.
These callbacks end up in messages from WebGPUParent to WebGPUChild, and only then the IDs are freed
on the content side and able to be reused.
Differential Revision: https://phabricator.services.mozilla.com/D67211
This mostly updates the bindings to the current state.
No actual logic backing them yet.
*Note*: the IDL does *not* need to be checked for matching the upstream spec precisely at this stage. The upstream is evolving, we just need to update in order to start integrating the implementation. What needs to be checked is - how C++ represents the IDL, esp with regards to derived classes, events, and hierarchies.
The trickiest points, arguably, are:
- WebGPU -> GPU prefix change
- the goop for interfaces that are not final
Differential Revision: https://phabricator.services.mozilla.com/D46166
This mostly updates the bindings to the current state.
No actual logic backing them yet.
*Note*: the IDL does *not* need to be checked for matching the upstream spec precisely at this stage. The upstream is evolving, we just need to update in order to start integrating the implementation. What needs to be checked is - how C++ represents the IDL, esp with regards to derived classes, events, and hierarchies.
The trickiest points, arguably, are:
- WebGPU -> GPU prefix change
- the goop for interfaces that are not final
Differential Revision: https://phabricator.services.mozilla.com/D46166
Nicolas Silva