Remove FenceInfo. Instead use GpuProcessFencesHolderId and GpuProcessD3D11FencesHolderMap.
GpuProcessD3D11FencesHolderMap is changed to instantiate also in Parent process when GPU process does not exist. Then it seems better to change its name. The name change is going to be handled in Bug 1958752.
Differential Revision: https://phabricator.services.mozilla.com/D244539
When ExternalExture is still being used by wgpu, ExternalTexture::GetSnapshot() does not work. In this case, do readback by wgpu.
Differential Revision: https://phabricator.services.mozilla.com/D236665
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
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
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
