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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
The rejection process consumes the ErrorResult, so an rvalue reference is the honest thing here.
Differential Revision: https://phabricator.services.mozilla.com/D62632
--HG--
extra : moz-landing-system : lando
Adds support for bind groups and compute pipelines
The end goal of this PR is to run the compute example.
Differential Revision: https://phabricator.services.mozilla.com/D60746
--HG--
extra : moz-landing-system : lando
Adds support for bind groups and compute pipelines
The end goal of this PR is to run the compute example.
Differential Revision: https://phabricator.services.mozilla.com/D60746
--HG--
extra : moz-landing-system : lando
This is the basic functionality needed to work with buffers.
What it doesn't have:
- ability to re-map the buffer for writing
- async writing map
- most of the validation
Differential Revision: https://phabricator.services.mozilla.com/D55656
--HG--
extra : moz-landing-system : lando
This is the basic functionality needed to work with buffers.
What it doesn't have:
- ability to re-map the buffer for writing
- async writing map
- most of the validation
Differential Revision: https://phabricator.services.mozilla.com/D55656
--HG--
extra : moz-landing-system : lando
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
--HG--
rename : dom/webgpu/InputState.cpp => dom/webgpu/DeviceLostInfo.cpp
rename : dom/webgpu/Fence.h => dom/webgpu/DeviceLostInfo.h
rename : dom/webgpu/BlendState.cpp => dom/webgpu/OutOfMemoryError.cpp
rename : dom/webgpu/LogEntry.h => dom/webgpu/OutOfMemoryError.h
rename : dom/webgpu/BindGroup.h => dom/webgpu/ProgrammablePassEncoder.cpp
rename : dom/webgpu/BlendState.cpp => dom/webgpu/RenderBundle.cpp
rename : dom/webgpu/BlendState.h => dom/webgpu/RenderBundle.h
rename : dom/webgpu/AttachmentState.cpp => dom/webgpu/ValidationError.cpp
rename : dom/webgpu/AttachmentState.h => dom/webgpu/ValidationError.h
extra : moz-landing-system : lando
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
--HG--
rename : dom/webgpu/InputState.cpp => dom/webgpu/DeviceLostInfo.cpp
rename : dom/webgpu/Fence.h => dom/webgpu/DeviceLostInfo.h
rename : dom/webgpu/BlendState.cpp => dom/webgpu/OutOfMemoryError.cpp
rename : dom/webgpu/LogEntry.h => dom/webgpu/OutOfMemoryError.h
rename : dom/webgpu/BindGroup.h => dom/webgpu/ProgrammablePassEncoder.cpp
rename : dom/webgpu/BlendState.cpp => dom/webgpu/RenderBundle.cpp
rename : dom/webgpu/BlendState.h => dom/webgpu/RenderBundle.h
rename : dom/webgpu/AttachmentState.cpp => dom/webgpu/ValidationError.cpp
rename : dom/webgpu/AttachmentState.h => dom/webgpu/ValidationError.h
extra : moz-landing-system : lando
Dzmitry Malyshau
Cosmin Sabou
Bogdan Tara
Boris Zbarsky
Noemi Erli
Razvan Maries
Brindusan Cristian
Tooru Fujisawa
Sylvestre Ledru
Jeff Gilbert