Store last submitted TextureId in PresentationData for getting front buffer snapshot.
WebGPUParent::RecvQueueSubmit() stores the latest TextureId in the swap chain in PresentationData::LastSubmittedTextureId. To do so, it retrieves the OwnerId from ExternalTexture. Next, get PresentationData from OwnerId.
If readback is required, it is performed synchronously. Its implementation is borrowed from WebGPUParent::RecvSwapChainPresent().
Differential Revision: https://phabricator.services.mozilla.com/D233473
A common pattern in WebGPUParent.cpp is to early return if ForwardError returns true which happens when it enconters an error other than DeviceLost. Teo suggested that DeviceLost should also cause the early-return which makes sense as far as I can tell so this patch implements the suggestion. As a result, a DeviceLost error while atempting a device will prevent us from continuing to run code that assumes the device has been successfully inserted in the registry.
In addition, some unnecessary code in RcvAdapterRequestDevice was removed. LoseDevice isn't needed since we haven't created the device in the first place, and the assertion was redundant with the code in ForwardError.
Differential Revision: https://phabricator.services.mozilla.com/D234473
To destroy vk::Image and vk::DeviceMemory, VkImageHandle::destroy() uses function pointers that were stored during allocating vk::Image and vk::DeviceMemory. But it caused crashes when they were destroyed after destroying Global.
The change stops to store the function pointers.
Differential Revision: https://phabricator.services.mozilla.com/D234133
When WebGPUParent::RecvSwapChainPresent() does readback, there is still pending ReadbackPresentCallback() exists. Since the callback is going to be called by next wgpu_server_queue_submit() or next wgpu_server_poll_all_devices().
Global::device_poll() triggers the ReadbackPresentCallback() if the callback is pending state.
Differential Revision: https://phabricator.services.mozilla.com/D232915
This patch is the first step towards shipping dxcompiler.dll and
dxil.dll (also referred to as DXC) on Windows for WebGPU.
With this patch DXC is disabled by default at build time and can be enabled
on x86_64 by adding `ac_add_options --enable-dxcompiler` in the mozconfig
file.
Followup work will include in no particular order:
- Enabling DXC by default.
- Enabling DXC for Windows on x86 and arm architectures.
- Using our own DXC builds instead of pulling the dlls from the Windows
SDK.
Differential Revision: https://phabricator.services.mozilla.com/D216293
This patch is the first step towards shipping dxcompiler.dll and
dxil.dll (also referred to as DXC) on Windows for WebGPU.
With this patch DXC is disabled by default at build time and can be enabled
on x86_64 by adding `ac_add_options --enable-dxcompiler` in the mozconfig
file.
Followup work will include in no particular order:
- Enabling DXC by default.
- Enabling DXC for Windows on x86 and arm architectures.
- Using our own DXC builds instead of pulling the dlls from the Windows
SDK.
Differential Revision: https://phabricator.services.mozilla.com/D216293
Allocate dmabuf in VKImage, since direct dmabuf creation by gbm_bo_* is not reliable and comes with various issue.
Texture of swap chain uses vk::ImageCreateFlags::ALIAS(VK_IMAGE_CREATE_ALIAS_BIT).
wgpu_server_adapter_request_device() allocates vulkan device for enabling the following extensions that is necessary for dmabuf support.
- khr::external_memory_fd
- ext::external_memory_dma_buf
- ext::image_drm_format_modifier
- khr::external_semaphore_fd
Differential Revision: https://phabricator.services.mozilla.com/D223910
ExternalTexture usage does not handle a case that creating texture with ExternalTexture is failed. In this case, it seems better to fallback to readback.
Differential Revision: https://phabricator.services.mozilla.com/D225327
This changes both the parent and the child to clarify that some device
lost callbacks from wgpu should not resolve the lost promise. It also
adds an assert to detect when we are getting the lost callback after
we've already unregistered device, which is a possible cause of timeouts
in this test.
It restores the part of the test that checks that device drop is
unobservable, which it once again is.
Differential Revision: https://phabricator.services.mozilla.com/D225733
This covers all the ways that we might forget about the device, ensuring
that the lost promise is resolved somehow. This means two things for the
faulty test:
1) What has been a timeout will now hopefully manifest as a test error,
with a message that tells us how the lost promise is eventually
resolved. This will help us fix that pathway in code, hopefully getting
us to a point where the lost promise is always resolved the way we
expect.
2) The scope loss of the device object is now observable through the
lost promise, which is something that the test was checking for. That
part of the test is removed. It's not clear if this is an important
feature. It doesn't appear to be required by spec.
Differential Revision: https://phabricator.services.mozilla.com/D224858
Add ExternalTextureDMABuf for handling DMA buf for WebGPU. Actual DMA buf allocation is going to be done in Vulkan by another bug.
Differential Revision: https://phabricator.services.mozilla.com/D223062
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
ExternalTexture allocation failure could happen when allocating size is too large or system does not have enough gpu memory. Then it seems better to remove the assert. ExternalTextureD3D11.cpp already has enough error logs.
Differential Revision: https://phabricator.services.mozilla.com/D205978
This logic is in an IPDL actor, and doesn't spin up its own threads.
Therefore, all methods in `WebGPUParent` are called on the same thread,
all the time. There's no need for a synchronization mechanism here; it
only serves to confuse the mental model of newcomers to this code.
Differential Revision: https://phabricator.services.mozilla.com/D203709
If we were in Rust, and I could extract a reference using only safe
code, I'd totally trust this, and be happy to avoid an atomic addition
on the strong ref-count. However, I think in our case for C++, it's
better to simply avoid the safety hazard altogether, and accept the
trivial performance hit.
Differential Revision: https://phabricator.services.mozilla.com/D203708
Failing to `return` here yields a crash in the case where the device is
lost, which is the root cause of bug 1879692. Crashing seems like
a pretty severe consequence for something that users may invoke
themselves (i.e., via `device.destroy`), so let's bail out instead.
Differential Revision: https://phabricator.services.mozilla.com/D203710
Validation errors are supposed to be errors that a WebGPU user are
solely responsible for. In cases where we encounter an error for
implementation internals, we should use
[`GPUInternalError`](https://gpuweb.github.io/gpuweb/#gpuinternalerror)
instead. If we encounter a validation error in our usage of `wgpu-core`
to implement presentation readback, coerce them to an internal error
before forwarding them to the applicable `GPUDevice`.
Differential Revision: https://phabricator.services.mozilla.com/D203711
Add ErrorBuffer::GetError() handling to wgpu_server_buffer_get_mapped_range() in ReadbackPresentCallback()
and call ForwardError(), if possible.
Differential Revision: https://phabricator.services.mozilla.com/D201790
