about:support's feature table still shows blocklisting, just not whether
the pref is set.
If different from default, dom.webgpu.enabled still shows up in about:support under
"Important Modified Prefs" like normal.
Also renames "gfx.webgpu.force-enabled" to "gfx.webgpu.ignore-blocklist"
to reflect its functionality.
Differential Revision: https://phabricator.services.mozilla.com/D169007
Calling mozilla::dom::TypedArray_base::Data on a detached ArrayBuffer
returns null, so GPUQueue.writeBuffer or GPUQueue.writeTexture need to
be prepared for this case.
Consolidate validation code from mozilla::webgpu::Queue::WriteBuffer
and WriteTexture into a new function, GetBufferSourceDataAndSize, and
use that in both cases.
Differential Revision: https://phabricator.services.mozilla.com/D169117
Calling mozilla::dom::TypedArray_base::Data on a detached ArrayBuffer
returns null, so GPUQueue.writeBuffer or GPUQueue.writeTexture need to
be prepared for this case.
Consolidate validation code from mozilla::webgpu::Queue::WriteBuffer
and WriteTexture into a new function, GetBufferSourceDataAndSize, and
use that in both cases.
Differential Revision: https://phabricator.services.mozilla.com/D169117
In WebGPU, entry point names and labels from types like
`GPUComputePipelineDescriptor` eventually get turned into Rust `&str` values.
The prior code used `LossyCopyUTF16ToASCII` to produce `nsCString`s from the
`nsString`s received from the WebIDL bindings, and then passed the resulting
bytes to Rust `std::ffi::CStr::to_str`. Unfortunately, that "ASCII" actually
means Latin-1, so if the entry point named happened to be representable in
Latin-1 that happened not to be valid UTF-8, `wgpu_bindings::cow_label` would
return `None`, leading to a panic when unwrapped by
`wgpu_bindings::client::ProgrammableStageDescriptor::to_wgpu`.
The fix: just call `CopyUTF16ToUTF8` instead. This should always produce bytes
that `CStr::to_str` can consume. The WebIDL for WebGPU uses `USVString` for
entry point names and labels, so these values should never contain unpaired
surrogate code points, meaning that conversion should always succeed.
Differential Revision: https://phabricator.services.mozilla.com/D168188
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
As of the prior patch, these are no longer needed. I removed
these with a script, then ran clang-format on the files, then
manually reverted a few unrelated changed from the formatter.
Differential Revision: https://phabricator.services.mozilla.com/D164829
Bug 181137 made ContentIteratorBase no longer refcounted, but
it did not remove this bit of CC boilerplate. With the inline
root, using this macro in a non-refcounted class is an error.
ObjectModel.h and ClientWebGLContext.cpp used macros to define
root and unroot, but that is no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D164828
Just allocate the smallest possible shmem if needed, the same workaround exist when creating mappable buffers.
Also validate that the size is a multiple of 4 bytes to match the spec.
Differential Revision: https://phabricator.services.mozilla.com/D158965
I think that this issue was introduced by another series of patch (when we started passing nsACStrings as parameter in the bindings), but were hidden by unified builds.
Differential Revision: https://phabricator.services.mozilla.com/D154247
The former frees resources but keeps the handle. It can be called multiple times. The latter destroys the handle. Any subsequent reference to the same buffer is a bug and will cause the GPU process to crash.
Depends on D152080
Differential Revision: https://phabricator.services.mozilla.com/D152081
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
Another cosmetic change. I've dabbled with IPDL actors too much to not think about WebGPUParent when reading "mParent". Also the parent-child relationship between Device and Buffer is not very obvious to me (nor is it part of the specification).
So I find that wrapping mParent in a GetDevice method to make the code easier to understand. It also makes it explicit that the parent pointer cannot be null.
Depends on D151630
Differential Revision: https://phabricator.services.mozilla.com/D151631
Make sure to always clean up any potential content-side state and only avoid sending Destroy each time.
Depends on D151621
Differential Revision: https://phabricator.services.mozilla.com/D151629
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
Sebastian Hengst
Kelsey Gilbert
Jim Blandy
Cristina Horotan
Nicolas Silva
Csoregi Natalia
sotaro
Nika Layzell
Cosmin Sabou
Andrew McCreight
Cristian Tuns
Iulian Moraru
Olli Pettay
Andrew Osmond