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
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