nsIGfxInfo::FEATURE_HARDWARE_VIDEO_DECODING is used on all platforms so let's use it on Linux too and don't add new feature for Linux only.
Differential Revision: https://phabricator.services.mozilla.com/D149765
Reuse decoder device also to release on intel GPU on Windows, since it is also necessary for zero copy hardware decoded video.
Reuse decoder device handling is also updated as aligned to FEATURE_HW_DECODED_VIDEO_ZERO_COPY.
Differential Revision: https://phabricator.services.mozilla.com/D150448
nsIGfxInfo::FEATURE_HARDWARE_VIDEO_DECODING is used on all platforms so let's use it on Linux too and don't add new feature for Linux only.
Differential Revision: https://phabricator.services.mozilla.com/D149765
nsIGfxInfo::FEATURE_HARDWARE_VIDEO_DECODING is used on all platforms so let's use it on Linux too and don't add new feature for Linux only.
Differential Revision: https://phabricator.services.mozilla.com/D149765
This removes a bunch of custom code from GfxInfo to obtain screen
information, and instead collects that screen information in
ScreenManager.
This, apart of removing duplicated code, has the extra benefit of
reporting multi-monitor information on GTK (and potentially in the
future reporting scale and refresh rate properly as well, I've kept the
telemetry as it was on that regard).
Differential Revision: https://phabricator.services.mozilla.com/D145178
This removes a bunch of custom code from GfxInfo to obtain screen
information, and instead collects that screen information in
ScreenManager.
This, apart of removing duplicated code, has the extra benefit of
reporting multi-monitor information on GTK (and potentially in the
future reporting scale and refresh rate properly as well, I've kept the
telemetry as it was on that regard).
Differential Revision: https://phabricator.services.mozilla.com/D145178
This patch just adds the plumbing to allow for baked in blocklist rules
or the downloadable blocklist to prevent certain configurations from
getting WebGPU. It does not add any rules.
It also changes us from allowing WebGPU only in nightly, including
tests, to not release and not beta. This allows try to run the WebGPU
tests as expected, since even try builds forked from mozilla-central are
not considered nightly builds by CI (or so it seems).
Differential Revision: https://phabricator.services.mozilla.com/D141682
Bug 1742985 added the test helper_zoom_after_gpu_process_restart.html,
but it doesn't actually get run on any platform with the GPU process
enabled. (Due to bug 1495580 on windows, and because the GPU process
isn't yet enabled on android.)
The test kills the GPU process, then tries to wait for it to be
restarted before proceeding. However, the function
ensureGPUProcessReadyForTests doesn't always work as intended, as the
GPUProcessManager may not have yet noticed that the process has been
killed, and therefore may return immediately from EnsureGPUReady.
This patch removes the buggy ensureGPUProcessReadyForTests function,
and instead makes the test wait for the "compositor-reinitialized"
topic to be observed.
Differential Revision: https://phabricator.services.mozilla.com/D138125
Add KillGPUProcessForTests, which kills the GPU process without
generating a crash dump (unlike the existing CrashGPUProcessForTests).
Additionally add EnsureGPUProcessReadyForTests, which returns a
promise that resolves to true when the GPU process is enabled and
ready, and false if it is disabled. If called while the GPU process is
being (re)started, it will not resolve until it has finished launching
(or was disabled due to error).
Finally, make GPUProcessHost::IsConnected check whether the process
handle is valid. This ensures it returns false immediately following a
call to KillProcess but prior to the GPUChild being destroyed. This
means tests can call EnsureGPUProcessReadyForTests immediately after
KillGPUProcessForTests or CrashGPUProcessForTests, and it will
reliably wait for the new process to launch, as intended.
Depends on D135207
Differential Revision: https://phabricator.services.mozilla.com/D135328
Add a function to GPUProcessManager to force the GPU process to crash,
and expose it through gfxInfo. Expose this to geckoview tests via the
test-support webextension.
Add a junit test GpuCrashTest, which triggers a GPU process crash and
ensures the crash reporter was notified.
Additionally, ensure the TestCrashHandler service is stopped in
between tests, as otherwise only the first crash test to run will be
notified of the crash.
Differential Revision: https://phabricator.services.mozilla.com/D132812
Currently, reftest-content uses GfxInfo::GetInfo() to obtain information about
the Azure backend. GetInfo() uses Win32k APIs, and therefore will mostly
return garbage in content processes.
This adds a new way to obtain the same information directly from GfxInfo
without using Win32k APIs.
Differential Revision: https://phabricator.services.mozilla.com/D111890
Loading cached shaders with glProgramBinary fails consistently for all
but the most trivial of our shaders on Adreno 3xx, so caching and
attempting to load them is a waste of time. Chromium and other
projects also appear to have disabled their shader caches on Adreno
3xx due to bugs.
This patch moves the gfx.webrender.program-binary-disk pref
declaration from all.js to StaticPrefList.yaml. Rather than directly
using the value of the pref to decide whether to create the shader
cache, we now initialize a Feature in gfxConfigManager with a default
value from the pref and then configure it from the blocklist. On
Android we block the feature on Adreno 3xx devices. The pref remains
true by default on Android and Windows, and false by default on Linux
and Macos.
Differential Revision: https://phabricator.services.mozilla.com/D111427
Webrender's pre-optimized shaders result in completely broken
rendering on a Huawei MediaPad M2 (Mali-T628). As a precaution,
disable optimized shaders on all Mali-T6xx devices.
Differential Revision: https://phabricator.services.mozilla.com/D104752
Webrender's pre-optimized shaders result in completely broken
rendering on a Huawei MediaPad M2 (Mali-T628). As a precaution,
disable optimized shaders on all Mali-T6xx devices.
Differential Revision: https://phabricator.services.mozilla.com/D104752
Webrender's pre-optimized shaders result in completely broken
rendering on a Huawei MediaPad M2 (Mali-T628). As a precaution,
disable optimized shaders on all Mali-T6xx devices.
Differential Revision: https://phabricator.services.mozilla.com/D104752
GfxInfo::RefreshMonitors() could not be called in ScreenHelperWin::RefreshScreens(), since the RefreshScreens() is called within nsAppShell::Init(). Then GfxInfo::RefreshMonitors() is called during WM_DISPLAYCHANGE event handling.
Differential Revision: https://phabricator.services.mozilla.com/D103661
GfxInfo::RefreshMonitors() could not be called in ScreenHelperWin::RefreshScreens(), since the RefreshScreens() is called within nsAppShell::Init(). Then GfxInfo::RefreshMonitors() is called during WM_DISPLAYCHANGE event handling.
Differential Revision: https://phabricator.services.mozilla.com/D103661
As we make the transition to using EGL over GLX, we will need our
detection code to be sufficient without EGL to determine the device in
use. This patch makes us always use the EGL testing code over the GLX
testing code, regardless of the pref/envvar setting.
At the very least, we need to know the vendor ID of the device in use.
We can determine this if there is only one GPU on the PCI list, if we
get a driver name from Mesa, or if it is a proprietary driver (i.e.
NVIDIA) which includes its name in the vendor ID. If we know the vendor
ID, we can usually derive the device ID from the PCI list.
We now also track which path glxtest took. If we successfully did the
test via EGL, then we will allow the pref/envvar to use EGL instead of
GLX. If the test reverted to GLX, then it will use GLX regardless of the
pref/envvar. This is necessary because we need to know if the libraries
are available or not -- some systems may be missing one or the other.
Differential Revision: https://phabricator.services.mozilla.com/D102933
As we make the transition to using EGL over GLX, we will need our
detection code to be sufficient without EGL to determine the device in
use. This patch makes us always use the EGL testing code over the GLX
testing code, regardless of the pref/envvar setting.
At the very least, we need to know the vendor ID of the device in use.
We can determine this if there is only one GPU on the PCI list, if we
get a driver name from Mesa, or if it is a proprietary driver (i.e.
NVIDIA) which includes its name in the vendor ID. If we know the vendor
ID, we can usually derive the device ID from the PCI list.
We now also track which path glxtest took. If we successfully did the
test via EGL, then we will allow the pref/envvar to use EGL instead of
GLX. If the test reverted to GLX, then it will use GLX regardless of the
pref/envvar. This is necessary because we need to know if the libraries
are available or not -- some systems may be missing one or the other.
Differential Revision: https://phabricator.services.mozilla.com/D102933
Fetch the DRM device in the EGL version of glxtest, set it in gfxInfo and pass
it to gfxVars. Finally, use it in nsDMABufDevice::Configure().
While on it, also clean up EGL typedefs and defines a bit to match how it's
done for GLX.
Inspired by and copied from wlroots and Xwayland. Thanks to emersion!
Differential Revision: https://phabricator.services.mozilla.com/D98108
Fetch the DRM device in the EGL version of glxtest, set it in gfxInfo and pass
it to gfxVars. Finally, use it in nsDMABufDevice::Configure().
While on it, also clean up EGL typedefs and defines a bit to match how it's
done for GLX.
Inspired by and copied from wlroots and Xwayland. Thanks to emersion!
Differential Revision: https://phabricator.services.mozilla.com/D98108
Fetch the DRM device in the EGL version of glxtest, set it in gfxInfo and pass
it to gfxVars. Finally, use it in nsDMABufDevice::Configure().
While on it, also clean up EGL typedefs and defines a bit to match how it's
done for GLX.
Inspired by and copied from wlroots and Xwayland. Thanks to emersion!
Differential Revision: https://phabricator.services.mozilla.com/D98108
The main-thread requirements for DXVA appear to have been needed when we initialized a crash guard. We now only run DXVA in the GPU and RDD processes, which don't support crash guards. This removes the main thread dispatch and the crashguard code, and enforces that we're in the GPU/RDD process to init DXVA.
This also removes the DLL blocklist code. This was disabled via pref when in the GPU process, which should be the majority of the time. In rare cases we would have been running DXVA in the RDD process (on older win7 when the GPU process isn't available). In these cases we can just do the same as the GPU process, allowing crashes and recovering from them (and disabling DXVA).
Differential Revision: https://phabricator.services.mozilla.com/D98036
The main-thread requirements for DXVA appear to have been needed when we initialized a crash guard. We now only run DXVA in the GPU and RDD processes, which don't support crash guards. This removes the main thread dispatch and the crashguard code, and enforces that we're in the GPU/RDD process to init DXVA.
This also removes the DLL blocklist code. This was disabled via pref when in the GPU process, which should be the majority of the time. In rare cases we would have been running DXVA in the RDD process (on older win7 when the GPU process isn't available). In these cases we can just do the same as the GPU process, allowing crashes and recovering from them (and disabling DXVA).
Differential Revision: https://phabricator.services.mozilla.com/D98036
