We have a driver-specific regression related to the shader optimizer
and also a small performance regression in a couple of tests. Rather
than back out the (large) patch set, disable the new path for now
to provide time to investigate and fix those issues.
Differential Revision: https://phabricator.services.mozilla.com/D176796
Added initial support for NVIDIA's "RTX Video Super Resolution" for
video overlays on Windows, which uses hardware accelerated AI to
upscale instead of traditional upscaling methods.
Currently behind new pref "gfx.webrender.super-resolution.nvidia"
(disabled by default), allowing for prefs for other vendors later.
NVIDIA also have a setting in their own driver settings. Currently
Chromium always enable it on their end if a new enough driver and not on
battery power. This patch just checks if we are using an NVIDIA GPU and
tries to use it if the pref is enabled.
Intel also have had similar tech for a while, see Bug 1780824.
Differential Revision: https://phabricator.services.mozilla.com/D172942
Added initial support for NVIDIA's "RTX Video Super Resolution" for
video overlays on Windows, which uses hardware accelerated AI to
upscale instead of traditional upscaling methods.
Currently behind new pref "gfx.webrender.super-resolution.nvidia"
(disabled by default), allowing for prefs for other vendors later.
NVIDIA also have a setting in their own driver settings. Currently
Chromium always enable it on their end if a new enough driver and not on
battery power. This patch just checks if we are using an NVIDIA GPU and
tries to use it if the pref is enabled.
Intel also have had similar tech for a while, see Bug 1780824.
Differential Revision: https://phabricator.services.mozilla.com/D172942
Added initial support for NVIDIA's "RTX Video Super Resolution" for
video overlays on Windows, which uses hardware accelerated AI to
upscale instead of traditional upscaling methods.
Currently behind new pref "gfx.webrender.super-resolution.nvidia"
(disabled by default), allowing for prefs for other vendors later.
NVIDIA also have a setting in their own driver settings. Currently
Chromium always enable it on their end if a new enough driver and not on
battery power. This patch just checks if we are using an NVIDIA GPU and
tries to use it if the pref is enabled.
Intel also have had similar tech for a while, see Bug 1780824.
Differential Revision: https://phabricator.services.mozilla.com/D172942
Device reset could cause front TextureClient lost in PersistentBufferProviderShared::SetKnowsCompositor(). In this case, ShareableCanvasRenderer::UpdateCompositableClient() does not have TextureClient for compositor.
Differential Revision: https://phabricator.services.mozilla.com/D176748
WebRenderAPI::FlushPendingWrTransactionEventsWithoutWait() does not wait remote texture ready. It should be OK, since it is called only in WebRenderBridgeParent::ClearResources(). But there were cases that hit the assert. The assert failure was false alarm.
The change suppresses assert of remote texture ready check in RemoteTextureMap::GetExternalImageIdOfRemoteTexture() if wait of the remote texture ready was skipped by the FlushPendingWrTransactionEventsWithoutWait().
Differential Revision: https://phabricator.services.mozilla.com/D176498
- Remove nsWaylandDisplay thread specific objects as we don't need them.
- Use nsWaylandDisplay as non-referenced objects. There's only a global one.
- Create nsWaylandDisplay global object in nsAppRunner when Firefox starts. That ensures we create it in main thread.
- Remove mEventQueue, we don't need it.
- Remove mSyncCallback, it's unused.
Differential Revision: https://phabricator.services.mozilla.com/D176125
- Make dmabuf preferences static so we don't need GetDMABufDevice() to access them.
- Configure GetDMABufDevice() when it's created.
- Init dmabuf members directly in class.
- Removed unused methods.
Differential Revision: https://phabricator.services.mozilla.com/D176404
We have seen reports that various websites, including twitter, perform
poorly on older Adreno devices due, to backdrop filter. We previously
encountered similar on Mali-G710 devices in bug 1809738, and it
appeared to be due to having to copy the contents of large
framebuffers--required to render the backdrop filter--to and from the
GPU's tile memory. On Mali we were able to avoid this penalty by
ensuring we performed an unscissored clear immediately after binding
the framebuffer, allowing the driver to omit initalizing the contents
of tile memory prior to rendering.
It's plausible that older Adreno drivers are not clever enough to be
able to make this optimization. However, there exists an extension
QCOM_tiled_rendering, which allows us to explicitly tell the driver
which subregion of a render target we are rendering too, and whether
it must be pre-initilized or post-resolved.
This patch makes use of this extension when rendering to color and
picture cache targets. In both cases we supply the region that is
being rendered and must only resolve the color attachment back to main
memory. In most cases we can additionally avoid initializing tile
memory prior to rendering, with the exception being in
draw_color_target() when we do not perform an initial clear, in which
case we must initialize the color attachment.
This results in a significant performance improvement on twitter when
tested on a Nexus 5 (Adreno 330) device.
Differential Revision: https://phabricator.services.mozilla.com/D176154
We have seen reports that various websites, including twitter, perform
poorly on older Adreno devices due, to backdrop filter. We previously
encountered similar on Mali-G710 devices in bug 1809738, and it
appeared to be due to having to copy the contents of large
framebuffers--required to render the backdrop filter--to and from the
GPU's tile memory. On Mali we were able to avoid this penalty by
ensuring we performed an unscissored clear immediately after binding
the framebuffer, allowing the driver to omit initalizing the contents
of tile memory prior to rendering.
It's plausible that older Adreno drivers are not clever enough to be
able to make this optimization. However, there exists an extension
QCOM_tiled_rendering, which allows us to explicitly tell the driver
which subregion of a render target we are rendering too, and whether
it must be pre-initilized or post-resolved.
This patch makes use of this extension when rendering to color and
picture cache targets. In both cases we supply the region that is
being rendered and must only resolve the color attachment back to main
memory. In most cases we can additionally avoid initializing tile
memory prior to rendering, with the exception being in
draw_color_target() when we do not perform an initial clear, in which
case we must initialize the color attachment.
This results in a significant performance improvement on twitter when
tested on a Nexus 5 (Adreno 330) device.
Differential Revision: https://phabricator.services.mozilla.com/D176154
We have seen reports that various websites, including twitter, perform
poorly on older Adreno devices due, to backdrop filter. We previously
encountered similar on Mali-G710 devices in bug 1809738, and it
appeared to be due to having to copy the contents of large
framebuffers--required to render the backdrop filter--to and from the
GPU's tile memory. On Mali we were able to avoid this penalty by
ensuring we performed an unscissored clear immediately after binding
the framebuffer, allowing the driver to omit initalizing the contents
of tile memory prior to rendering.
It's plausible that older Adreno drivers are not clever enough to be
able to make this optimization. However, there exists an extension
QCOM_tiled_rendering, which allows us to explicitly tell the driver
which subregion of a render target we are rendering too, and whether
it must be pre-initilized or post-resolved.
This patch makes use of this extension when rendering to color and
picture cache targets. In both cases we supply the region that is
being rendered and must only resolve the color attachment back to main
memory. In most cases we can additionally avoid initializing tile
memory prior to rendering, with the exception being in
draw_color_target() when we do not perform an initial clear, in which
case we must initialize the color attachment.
This results in a significant performance improvement on twitter when
tested on a Nexus 5 (Adreno 330) device.
Depends on D176153
Differential Revision: https://phabricator.services.mozilla.com/D176154
One assert check is remove from RemoteTextureMap::PushTexture(). The assert was wrong. RemoteTextureHostWrapper is unregistered when its Compositable ref becomes 0. It could happen.
On android, async RemoteTexture could not be enabled until Bug 1826687 fix.
Differential Revision: https://phabricator.services.mozilla.com/D175978
- Remove nsWaylandDisplay thread specific objects as we don't need them.
- Use nsWaylandDisplay as non-referenced objects. There's only a global one.
- Create nsWaylandDisplay global object in nsAppRunner when Firefox starts. That ensures we create it in main thread.
- Remove mEventQueue, we don't need it.
- Remove mSyncCallback, it's unused.
Differential Revision: https://phabricator.services.mozilla.com/D176125
Non-scrollable elements are immediately activated on touch-start, so it
is not necessary to delay firing the synthesized mouse and click events.
Differential Revision: https://phabricator.services.mozilla.com/D169727
This is done by moving them to a new test group, test_group_hittest-3.html.
Bug 1829021 tracks investigating the cause of their frequent failure on
Windows 11 and re-enabling them.
Differential Revision: https://phabricator.services.mozilla.com/D175967
Glenn Watson
CanadaHonk
Sandor Molnar
Iulian Moraru
Robert Longson
sotaro
Daisuke Akatsuka
stransky
Lee Salzman
Natalia Csoregi
Andrew Osmond
Cristian Tuns
Erich Gubler
Emilio Cobos Álvarez
Dan Robertson
Jamie Nicol
Cristina Horotan
Corinne R Pohl
Nicolas Silva
pmcmanis
Shravan Narayan
Jonathan Kew
Botond Ballo
Nika Layzell