Given that we would otherwise disable remote canvas when we disable the
GPU process, it is not meaningfully worse for users to just disable
remote canvas keeping the GPU process as the final step. It is still
preferable to losing the GPU process sandbox. This includes D2D canvas,
accelerated canvas and WebGPU, as well as WebGL on Android.
Original Revision: https://phabricator.services.mozilla.com/D267667
Differential Revision: https://phabricator.services.mozilla.com/D267862
Add mochitests to verify that WebGPU is enabled/disabled to the
appropriate degree for the current Firefox build.
- In nightly builds, WebGPU should always be available. Specifically,
`navigator.gpu.requestAdapter`'s promise should not be rejected.
- In early beta builds:
- On Windows, `requestAdapter`'s promise should not be rejected.
- On all other platforms, it should be rejected.
- In late beta and release builds, the `navigator.gpu` property should
not be present.
In `dom/webgpu/tests/mochitest`:
- In the main `mochitest.toml` suite: change the `run-if` condition to
match the check used in `gfxPlatform::InitWebGPUConfig`: WebGPU is
enabled in nightly builds on all platforms, and in early beta builds
on Windows, and is disabled under all other circumstances.
- Add a new Mochitest suite, `mochitest-disabled.toml`, to run when we
expect `requestAdapter`'s promise to be rejected.
- Add two new tests, `test_adapter_enabled.html` and
`test_adapter_disabled.html`, to the appropriate suites above, that
do nothing but ensure that `requestAdapter`'s promise is
resolved/rejected when it should be.
- In the `mochitest-no-pref.toml` suite, change the `run-if` condition
to match the condition that determines thet `dom.webgpu.enabled`
pref's default value.
- Add a comment to `gfxPlatform::InitWebGPUConfig` reminding people to
update the mochitest conditions, although the test failures will
remind them as well.
Differential Revision: https://phabricator.services.mozilla.com/D246381
By Bug 1957563, GpuProcessD3D11FencesHolderMap is changed to instantiate also in Parent process when GPU process does not exist. Then it seems better to change its name.
Differential Revision: https://phabricator.services.mozilla.com/D244684
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
gfxPlatform::Init() is never called in the GPU process, so common memory reporters
never get registered, such as GfxImageMemoryReporter, leading to large amounts of
heap-unclassified showing up in the GPU process when using Accelerated Canvas2D.
For now, add a gfxPlatform::InitMemoryReportersForGPUProcess() hook for any such
registration to occur in the GPU process. Long-term, we probably should clean up
gfxPlatform::Init() to share far more code with GPUParent::Init/RecvInit, but that
is a much larger project beyond the scope of this patch.
Differential Revision: https://phabricator.services.mozilla.com/D239287
Merge the FontListChanged message sent by the parent when the list is updated
with the more general ForceGlobalReflow. Avoid forcing an update from the
InitOtherFamilyNames task if there is also a LoadCmaps operation in progress;
just ensure it will include the NeedsReframe flag in its message instead.
This should not change observable behavior, but aims to reduce the risk of
font data updates resulting in redundant multiple reflows.
Differential Revision: https://phabricator.services.mozilla.com/D232151
This adds a DMABUF_WEBGL feature that can be independently blocklisted from DMABUF itself.
After that, this adds a blocklist entry for the Nvidia driver which gives incorrect rendering.
Differential Revision: https://phabricator.services.mozilla.com/D227598
This adds a DMABUF_WEBGL feature that can be independently blocklisted from DMABUF itself.
After that, this adds a blocklist entry for the Nvidia driver which gives incorrect rendering.
Differential Revision: https://phabricator.services.mozilla.com/D227598
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
This patch moves the logic to draw the tiled picture overlay out of the entirely too large take_context into a separate function, and add a separate option to draw only the borders of all pictures (non-tiled ones included) and tiles. This new overlay is enabled via the pref gfx.webrender.debug.picture-borders and is useful when trying to observe the breakdown of the page into pictures.
It does not quite do what I want it to: borders for non-tiled pictures seem to only appear on the frame they are drawn and aren't shown in subsequent frames unles the containing tile cache is invalidated. So there will probably be followup adjustments, but the functionality is already useful in its current state.
Differential Revision: https://phabricator.services.mozilla.com/D222959
Attempting to use malloc_size_of with allocations that aren't directly backend by the global allocator crashes, so this commits compute the render task's report by in a more manual way.
In addition, add the allocator's memory footprint to memory reports.
Differential Revision: https://phabricator.services.mozilla.com/D219270
willReadFrequently already implies this; however that can't
be enabled on Windows. We can use our own attribute to control
the value as it plumbs into the depths of Canvas2D and WebGL
Differential Revision: https://phabricator.services.mozilla.com/D212178
This disables the legacy Direct2D backend in Windows Nightly in favor
of using Accelerated Canvas2D instead. The goal of this experiment
is to collect performance and other bug feedback on AC2D versus Direct2D.
In general, AC2D has been fairly stable on other platforms, so it would be
nice to gradually move towards using AC2D on Windows as well so that we
are using one consistent acceleration solution.
This experiment is the first step towards that end.
Differential Revision: https://phabricator.services.mozilla.com/D217851
This disables the legacy Direct2D backend in Windows Nightly in favor
of using Accelerated Canvas2D instead. The goal of this experiment
is to collect performance and other bug feedback on AC2D versus Direct2D.
In general, AC2D has been fairly stable on other platforms, so it would be
nice to gradually move towards using AC2D on Windows as well so that we
are using one consistent acceleration solution.
This experiment is the first step towards that end.
Differential Revision: https://phabricator.services.mozilla.com/D217851
willReadFrequently already implies this; however that can't
be enabled on Windows. We can use our own attribute to control
the value as it plumbs into the depths of Canvas2D and WebGL
Differential Revision: https://phabricator.services.mozilla.com/D212178
