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
If creation of the `CompilationInfo` promise fails in
`mozilla::webgpu::Device::CreateShaderModule`, propagate the error
properly, rather than leaving a local `ErrorResult` unhandled.
Differential Revision: https://phabricator.services.mozilla.com/D197600
If creation of the `CompilationInfo` promise fails in
`mozilla::webgpu::Device::CreateShaderModule`, propagate the error
properly, rather than leaving a local `ErrorResult` unhandled.
Differential Revision: https://phabricator.services.mozilla.com/D197600
The new implementation is simpler: It just forwards messages to wgpu on the parent process using the usual mechanism. It also better aligns with the spec because it works whether or not the pipeline has an implicit layout (current implementation is only implemented for implicit layouts). And finally it fixes a bug in the current implementation causing undefined behavior due to zero IDs being cast into NonZero rust types at the ffi boundary.
Differential Revision: https://phabricator.services.mozilla.com/D189942
For presenting WebGPU without readback, wgpu does rendering to ExternalTexture. Then the ExternalTexture is pushed to RemoteTextureMap for present.
With DX12, ExternalTextureD3D11 is implemented for gecko side implementation. ExternalTextureWgpu holds necessary resource that is necessary by wgpu. ExternalTextureWgpu is created and destroyed by gecko side's ExternalTexture.
Presenting current texture starts at CanvasContext::SwapChainPresent(). CanvasContext::SwapChainPresent() posts current texture for present. And the current texture is set invalid, since the texture is going to be posted to WebRender. Next CanvasContext::GetCurrentTexture() call creates a new texture of swap chain.
WebGPUParent::RecvSwapChainPresent() receives present request. It pushes to RemoteTextureMap for presenting.
TextureRaw is recycled with ExternalTexture recycling.
Differential Revision: https://phabricator.services.mozilla.com/D190249
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
* Add validation for requested features and devices for
adapter.requestDevice().
* Promote webgl's AutoAssertCast to mfbt/Casting.h/LazyAssertedCast.
Differential Revision: https://phabricator.services.mozilla.com/D177110
* Add validation for requested features and devices for
adapter.requestDevice().
* Promote webgl's AutoAssertCast to mfbt/Casting.h/LazyAssertedCast.
Differential Revision: https://phabricator.services.mozilla.com/D177110
Time to finally add some (barebones) diagnostics! When a user calls [`GPUDevice.createShaderModule`], if there are any messages returned:
1. Create a collapsed console group. Use a generic title for the console group (for now).
1. Inside the console group, print containing a log entry per message with a JS log level according to the message severity.
Differential Revision: https://phabricator.services.mozilla.com/D175303
WebGPU uses CompositableInProcessManager to push TextureHost directly from WebGPUParent to WebRender. But CompositableInProcessManager plumbing has a problem and caused Bug 1805209.
gecko already has a similar mechanism, called RemoteTextureMap. It is used in oop WebGL. If WebGPU uses RemoteTextureMap instead of CompositableInProcessManager, both WebGPU and oop WebGL use same mechanism.
WebGPUParent pushes a new texture to RemoteTextureMap. The RemoteTextureMap notifies the pushed texture to WebRenderImageHost.
Before the change, only one TextureHost is used for one swap chain. With the change, multiple TextureHosts are used for one swap chain with recycling.
The changes are followings.
- Use RemoteTextureMap instead of CompositableInProcessManager.
- Use RemoteTextureOwnerId instead of CompositableHandle.
- Use WebRenderCanvasData instead of WebRenderInProcessImageData.
- Add remote texture pushed callback functionality to RemoteTextureMap. With it, RemoteTextureMap notifies a new pushed remote texture to WebRenderImageHost.
- Remove CompositableInProcessManager.
Differential Revision: https://phabricator.services.mozilla.com/D164890
Having the code in the same place makes it easier to follow. This made me realize that the validation of aMode in mapAsync has to move to the device side (fix coming in a followup).
Depends on D151631
Differential Revision: https://phabricator.services.mozilla.com/D151632
Per spec (and discussion with someone on the chromium side where spec is vague), the correct behavior should be:
- MapAsync validation happens on the device timeline, so we should reject the promise in mapAsync on the content side if we run into an internal error not described by the spec.
- Unmap immediately rejects all pending mapping promises on the content side (there can be multiple of them since we have to catch that error on the device timeline).
This patch tracks a single mapping promise at a time and immediately rejects on the content side any subseqent mapping
request made until unmap is called. This means our current implementation deviates slightly from the current state of
the spec in that:
- The promise is rejected earlier on the content timeline,
- If the first request fails, all subsequent requests will fail until either unmap or when the content side receives and processes the rejected
promise, whereas Dawn's implementation would allow the first valid request to succed.
There was some confusion around the the use of uint64_t and size_t which probably originated at point where this code was working differently. This patch uses uint64_t (=BufferAddress) more consistently removing the need for some of the casting and overflow checks.
One notable change in the overall logic is that SetMapped is now called when the buffer is actually in the mapped state (before this patch it was called as soon as the buffer had a pending map request).
Depends on D151618
Differential Revision: https://phabricator.services.mozilla.com/D151619
No funcitonal change here, I like to have the code maintaining and depending on the same invariants to be in the same place.
Depends on D151616
Differential Revision: https://phabricator.services.mozilla.com/D151617
This commit makes WebGPU buffers use unsafe shmems.
Instead of relying on moving the shmem back and forth between the two processes to ensure thread safety, we instead rely on the validation done on both sides. The upside is that it makes it much easier to implement said validation correctly.
In the interest of splitting the buffer mapping rework into small-ish commits, this one puts some structural pieces in place but doesn't necessarily do justice to the final implementation:
- The validation itself is coming in subsequent patches in this series.
- Mapping sub-ranges of the buffer was somewhat implemented in some parts of the parent code and not in others, and was fairly broken as a whole. This commit always maps the entire buffer and proper logic for sub-ranges is coming in another commit.
The main things this commit does put in place:
- Each mappable buffer is associated with a Shmem that is accessible to both sides.
- On the child side, if a buffer is not mappable, then Buffer::mShmem is in its default state (it doesn't point to any shared memory segment).
- On the parent side, if a buffer is not mappable it does not have an entry in mSharedMemoryMap.
- The shmem is always created by the child and destroyed by the parent.
Depends on D151615
Differential Revision: https://phabricator.services.mozilla.com/D151616
Most operations maniplating shmems in WebGPU are fallible, we'll have to handle passing them conditionally in most messages.
This commit starts with BufferMap, to avoid crashing when map is called on an invalid buffer.
Differential Revision: https://phabricator.services.mozilla.com/D149892
Having the code in the same place makes it easier to follow. This made me realize that the validation of aMode in mapAsync has to move to the device side (fix coming in a followup).
Depends on D151631
Differential Revision: https://phabricator.services.mozilla.com/D151632
Per spec (and discussion with someone on the chromium side where spec is vague), the correct behavior should be:
- MapAsync validation happens on the device timeline, so we should reject the promise in mapAsync on the content side if we run into an internal error not described by the spec.
- Unmap immediately rejects all pending mapping promises on the content side (there can be multiple of them since we have to catch that error on the device timeline).
This patch tracks a single mapping promise at a time and immediately rejects on the content side any subseqent mapping
request made until unmap is called. This means our current implementation deviates slightly from the current state of
the spec in that:
- The promise is rejected earlier on the content timeline,
- If the first request fails, all subsequent requests will fail until either unmap or when the content side receives and processes the rejected
promise, whereas Dawn's implementation would allow the first valid request to succed.
There was some confusion around the the use of uint64_t and size_t which probably originated at point where this code was working differently. This patch uses uint64_t (=BufferAddress) more consistently removing the need for some of the casting and overflow checks.
One notable change in the overall logic is that SetMapped is now called when the buffer is actually in the mapped state (before this patch it was called as soon as the buffer had a pending map request).
Depends on D151618
Differential Revision: https://phabricator.services.mozilla.com/D151619
No funcitonal change here, I like to have the code maintaining and depending on the same invariants to be in the same place.
Depends on D151616
Differential Revision: https://phabricator.services.mozilla.com/D151617
This commit makes WebGPU buffers use unsafe shmems.
Instead of relying on moving the shmem back and forth between the two processes to ensure thread safety, we instead rely on the validation done on both sides. The upside is that it makes it much easier to implement said validation correctly.
In the interest of splitting the buffer mapping rework into small-ish commits, this one puts some structural pieces in place but doesn't necessarily do justice to the final implementation:
- The validation itself is coming in subsequent patches in this series.
- Mapping sub-ranges of the buffer was somewhat implemented in some parts of the parent code and not in others, and was fairly broken as a whole. This commit always maps the entire buffer and proper logic for sub-ranges is coming in another commit.
The main things this commit does put in place:
- Each mappable buffer is associated with a Shmem that is accessible to both sides.
- On the child side, if a buffer is not mappable, then Buffer::mShmem is in its default state (it doesn't point to any shared memory segment).
- On the parent side, if a buffer is not mappable it does not have an entry in mSharedMemoryMap.
- The shmem is always created by the child and destroyed by the parent.
Depends on D151615
Differential Revision: https://phabricator.services.mozilla.com/D151616
Most operations maniplating shmems in WebGPU are fallible, we'll have to handle passing them conditionally in most messages.
This commit starts with BufferMap, to avoid crashing when map is called on an invalid buffer.
Differential Revision: https://phabricator.services.mozilla.com/D149892
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
This *mostly* gets us the latest WebIDL API of WebGPU. There is a few limits we are missing, and maybe some things I didn't notice.
But it gets us the new `GPUCanvasContext`, `GPUSupportedLimits`, and `GPUVertexStepMode`.
Differential Revision: https://phabricator.services.mozilla.com/D120764
This *mostly* gets us the latest WebIDL API of WebGPU. There is a few limits we are missing, and maybe some things I didn't notice.
But it gets us the new `GPUCanvasContext`, `GPUSupportedLimits`, and `GPUVertexStepMode`.
Differential Revision: https://phabricator.services.mozilla.com/D120764
