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
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
gecko uses IDXGIResource::GetSharedHandle(). But it is recommend not to use anymore to retrieve the handle to a shared resource.
IDXGIResource1::CreateSharedHandle() with D3D11_RESOURCE_MISC_SHARED_NTHANDLE flag should be used instead of the GetSharedHandle().
The CreateSharedHandle() could be called only once for a shared resource. Later calls fail.
HANDLEs of ID3D11Texture2D are replaced by gfx::FileHandleWrappers.
Differential Revision: https://phabricator.services.mozilla.com/D192173
In wgpu, command encoders and command buffers actually share the same identity and resource, so dropping one drops the other. This commit makes it so that our gecko wrappers take that into account. The lifetime is now tied to the encoder which may be held alive by a command buffer if there is one.
Differential Revision: https://phabricator.services.mozilla.com/D193313
In wgpu, command encoders and command buffers actually share the same identity and resource, so dropping one drops the other. This commit makes it so that our gecko wrappers take that into account. The lifetime is now tied to the encoder which may be held alive by a command buffer if there is one.
Differential Revision: https://phabricator.services.mozilla.com/D193313
In wgpu, command encoders and command buffers actually share the same identity and resource, so dropping one drops the other. This commit makes it so that our gecko wrappers take that into account. The lifetime is now tied to the encoder which may be held alive by a command buffer if there is one.
Differential Revision: https://phabricator.services.mozilla.com/D193313
wgpu dx12 requests to Texture that if its usage has STORAGE_BINDING, D3D12 resource needs to have D3D12_RESOURCE_FLAG_ALLOW_UNORDERED_ACCESS.
The equivalent of D3D12_RESOURCE_FLAG_ALLOW_UNORDERED_ACCESS in D3D11 is D3D11_BIND_UNORDERED_ACCESS. Therefore, D3D11 textures in ExternalTextureD3D11 also require D3D11_BIND_UNORDERED_ACCESS if STORAGE_BINDING is used.
Differential Revision: https://phabricator.services.mozilla.com/D192976
