Adapt `wgpu_server_queue_submit` to the new submission index
type.
Use corrected spelling `WGPUTextureFormat_Rg11b10UFloat`.
Assign queue ids explicitly, rather than deriving them from device ids:
- `wgpu_bindings::client::IdentityHub`: add an `IdentityManager` for queues.
Initialize it in `IdentityHub::default`.
- `dom::webgpu::DeviceRequest`: hold separate `mDeviceId` and `mQueueId`
members.
- `wgpu_client_make_device_id`: rename to `wgpu_client_make_device_queue_id`,
and have it allocate both a device id and a queue id.
- `PWebGPU` protocol's `AdapterRequestDevice` request: explicitly pass
an id for the new queue.
- `WebGPUChild::AdapterRequestDevice`: pass through the queue id from
`wgpu_client_make_device_queue_id` through to `SendAdapterRequestDevice`,
and also return it as `DeviceRequest::mQueueId`.
- `WebGPUParent::RecvAdapterRequestDevice`: accept a queue id, and pass
it along to `ffi::wgpu_server_adapter_request_device`.
- `wgpu_server_adapter_request_device`: take a new argument specifying the
new queue's id, and pass that along to `global.adapter_request_device`.
- `dom::webgpu::Adapter::RequestDevice`: given the `DeviceRequest` returned by
`WebGPUChild::AdapterRequestDevice`, pass the ids for both the new device and
the new queue to `dom::webgpu::Device::Device`.
- Let `dom::webgpu::Device::Device` take a new argument explicitly specifying
the device's queue's id.
Differential Revision: https://phabricator.services.mozilla.com/D219356
They are the same and the latter is more self explanatory.
The patch also addresses a couple of Cleanup methods where I forgot to check the bridge pointer.
Differential Revision: https://phabricator.services.mozilla.com/D206785
This patch makes several changes:
1) It modifies WebGPUParent::RecvAdapterRequestDevice to additionally
send a device lost callback to wgpu. The user data for this callback is
stored within WebGPUParent as a hash of unique_ptr memory, which allows
for the possibility that wgpu will not call the callback (though it
should). When the callback is received, this memory is cleared. When the
WebGPUParent is destroyed, it asserts that there is no remaining held
memory for pending callbacks. These callbacks also check a WeakPtr to
the parent as additional safety.
2) It corrects some behavior in Device::ResolveLost where checking the
existence of the underlying JS object is moved earlier, since later
operations on the promise require the JS object to exist.
Differential Revision: https://phabricator.services.mozilla.com/D194310
This patch makes several changes:
1) It modifies WebGPUParent::RecvAdapterRequestDevice to additionally
send a device lost callback to wgpu. The user data for this callback is
stored within WebGPUParent as a hash of unique_ptr memory, which allows
for the possibility that wgpu will not call the callback (though it
should). When the callback is received, this memory is cleared. When the
WebGPUParent is destroyed, it asserts that there is no remaining held
memory for pending callbacks. These callbacks also check a WeakPtr to
the parent as additional safety.
2) It corrects some behavior in Device::ResolveLost where checking the
existence of the underlying JS object is moved earlier, since later
operations on the promise require the JS object to exist.
Differential Revision: https://phabricator.services.mozilla.com/D194310
This patch makes several changes:
1) It modifies WebGPUParent::RecvAdapterRequestDevice to additionally
send a device lost callback to wgpu. The user data for this callback is
stored within WebGPUParent as a hash of unique_ptr memory, which allows
for the possibility that wgpu will not call the callback (though it
should). When the callback is received, this memory is cleared. When the
WebGPUParent is destroyed, it asserts that there is no remaining held
memory for pending callbacks. These callbacks also check a WeakPtr to
the parent as additional safety.
2) It corrects some behavior in Device::ResolveLost where checking the
existence of the underlying JS object is moved earlier, since later
operations on the promise require the JS object to exist.
Differential Revision: https://phabricator.services.mozilla.com/D194310
This is preparation for Bug 1843891.
ID3D11Fence and ID3D12Fence handling is necessary to interoperate between D3D11 and D3D12. Necessary fence value can be obtained from wgpu_server_queue_submit().
Differential Revision: https://phabricator.services.mozilla.com/D193619
These JS proxies are always safe to create. The ids are validated on the other side so if the GPU process comes back up and we try to use the object (on a new device), it will generate an error as expected.
Depends on D197799
Differential Revision: https://phabricator.services.mozilla.com/D197800
These JS proxies are always safe to create. The ids are validated on the other side so if the GPU process comes back up and we try to use the object (on a new device), it will generate an error as expected.
Differential Revision: https://phabricator.services.mozilla.com/D197799
The `mozilla::webgpu::Device::CreateShaderModule` and
`mozilla::webgpu::WebGPUChild::DeviceCreateShaderModule` definitions
do not need `MOZ_CAN_RUN_SCRIPT_FOR_DEFINITION` attributes, because
their declarations in the class bodies already have
`MOZ_CAN_RUN_SCRIPT` attributes.
Differential Revision: https://phabricator.services.mozilla.com/D197605
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
This ensures that both internal and external triggers of "lose the
device" resolve the lost promise using the same code path.
Differential Revision: https://phabricator.services.mozilla.com/D190129
This creates a WebGPUParent::LoseDevice entry point, which informs the
WebGPUChild that the device has been lost. The child side is largely a
stub, as a later part will rationalize the handling of the device.lost
promise in the child.
This also expands ErrorBufferType with a DeviceLost value. The
LoseDevice function is triggered for any error where webgpu_bindings
HasErrorBufferType error_type returns ErrorBufferType::DeviceLost.
Differential Revision: https://phabricator.services.mozilla.com/D188388
The change is preparation for Bug 1843891.
Current gecko uses a internal texture for SwapChain's texture. This bug changes as to use external dx11 texture for WebGPU dx12 backend on Windows.
WebGPUParent allocates dx11 texture for SwapChain's texture of dx12 backend WebGPU. wgpu uses the dx11 texture as ID3D12Resource. The readback for presenting to WebRender still exists.
The change handles only RBGA format.
Differential Revision: https://phabricator.services.mozilla.com/D187870
The change is preparation for Bug 1843891.
Current gecko uses a internal texture for SwapChain's texture. This bug changes as to use external dx11 texture for WebGPU dx12 backend on Windows.
WebGPUParent allocates dx11 texture for SwapChain's texture of dx12 backend WebGPU. wgpu uses the dx11 texture as ID3D12Resource. The readback for presenting to WebRender still exists.
The change handles only RBGA format.
Differential Revision: https://phabricator.services.mozilla.com/D187870
In `RenderBundleEncoder::Finish`, never construct RenderBundles with
an id of zero, as this will cause a panic in the GPU process when we
deserialize command buffers that refer to such bundles.
Instead, assign the invalid RenderBundle an id, and report to the GPU
process that this id is associated with an error.
Differential Revision: https://phabricator.services.mozilla.com/D177077
