Arch Linux

Goran

Member

Registered: 2012-01-24

Posts: 92

Chromium unable to vsync.

Hardware: https://www.omen.com/us/en/laptops/2020 … tions.html

In short, it's a Laptop with:
Nvidia GTX 1660 ti GPU
Ryzen 7 4800H CPU - (has it's own iGPU, which was used by default, but I made nvidia the default card)

Software:

linux: 5.7.9.arch1-1
nvidia: 450.57-3
chromium: 84.0.4147.89-1

While both chromium and firefox seem unable to vsync to 144hz (the highest capability of my display), firefox can at least sync to 60hz, while chromium seems unable to even hold a frame rate that goes above 52fps, accoring to vsynctester.com.

Looking at chrome://gpu, I originally found the following:

Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Out-of-process Rasterization: Disabled
OpenGL: Enabled
Hardware Protected Video Decode: Unavailable
Rasterization: Software only. Hardware acceleration disabled
Skia Renderer: Enabled
Video Decode: Unavailable
Vulkan: Disabled
WebGL: Hardware accelerated
WebGL2: Hardware accelerated

By going to chrome://flags, and directly enabling:

Override software rendering list
GPU Rasterization
Out of process rasterization
Zero-copy rasterizer

I was able to (seemingly) enable everything but Vulkan, making the list look like this:

Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Out-of-process Rasterization: Hardware accelerated
OpenGL: Enabled
Hardware Protected Video Decode: Hardware accelerated
Rasterization: Hardware accelerated on all pages
Skia Renderer: Enabled
Video Decode: Hardware accelerated
Vulkan: Disabled
WebGL: Hardware accelerated
WebGL2: Hardware accelerated

However, even then, chromium is still unable to vsync to screen refresh rate, and vsynctester.com shows the frame rate at ~52 fps.

Running chromium with "--disable-frame-rate-limit" results in an erratically varying frame rate between 400 and 500 fps, producing the same stuttering issues as when running at 52 fps.

Upon launch, chroimum does spit out some errors to the terminal:

[62221:62221:0726/091559.319394:ERROR:vaapi_wrapper.cc(937)] vaQuerySurfaceAttributes failed, VA error: invalid parameter
[62221:62221:0726/091559.319587:ERROR:vaapi_wrapper.cc(826)] FillProfileInfo_Locked failed for va_profile VAProfileMPEG2Simple and entrypoint 1
[62221:62221:0726/091559.319685:ERROR:vaapi_wrapper.cc(937)] vaQuerySurfaceAttributes failed, VA error: invalid parameter
[62221:62221:0726/091559.319711:ERROR:vaapi_wrapper.cc(826)] FillProfileInfo_Locked failed for va_profile VAProfileMPEG2Main and entrypoint 1
[62221:62221:0726/091559.319735:ERROR:vaapi_wrapper.cc(937)] vaQuerySurfaceAttributes failed, VA error: invalid parameter
[62221:62221:0726/091559.319783:ERROR:vaapi_wrapper.cc(826)] FillProfileInfo_Locked failed for va_profile VAProfileMPEG4Simple and entrypoint 1
[62221:62221:0726/091559.319807:ERROR:vaapi_wrapper.cc(937)] vaQuerySurfaceAttributes failed, VA error: invalid parameter
[62221:62221:0726/091559.319827:ERROR:vaapi_wrapper.cc(826)] FillProfileInfo_Locked failed for va_profile VAProfileMPEG4AdvancedSimple and entrypoint 1
[62221:62221:0726/091559.319873:ERROR:vaapi_wrapper.cc(937)] vaQuerySurfaceAttributes failed, VA error: invalid parameter
[62221:62221:0726/091559.319970:ERROR:vaapi_wrapper.cc(826)] FillProfileInfo_Locked failed for va_profile VAProfileH264Baseline and entrypoint 1
[62221:62221:0726/091559.319994:ERROR:vaapi_wrapper.cc(937)] vaQuerySurfaceAttributes failed, VA error: invalid parameter
[62221:62221:0726/091559.320017:ERROR:vaapi_wrapper.cc(826)] FillProfileInfo_Locked failed for va_profile VAProfileH264Main and entrypoint 1
[62221:62221:0726/091559.320039:ERROR:vaapi_wrapper.cc(937)] vaQuerySurfaceAttributes failed, VA error: invalid parameter
[62221:62221:0726/091559.320059:ERROR:vaapi_wrapper.cc(826)] FillProfileInfo_Locked failed for va_profile VAProfileH264High and entrypoint 1
[62221:62221:0726/091559.320081:ERROR:vaapi_wrapper.cc(937)] vaQuerySurfaceAttributes failed, VA error: invalid parameter
[62221:62221:0726/091559.320103:ERROR:vaapi_wrapper.cc(826)] FillProfileInfo_Locked failed for va_profile VAProfileVC1Simple and entrypoint 1
[62221:62221:0726/091559.320124:ERROR:vaapi_wrapper.cc(937)] vaQuerySurfaceAttributes failed, VA error: invalid parameter
[62221:62221:0726/091559.320148:ERROR:vaapi_wrapper.cc(826)] FillProfileInfo_Locked failed for va_profile VAProfileVC1Main and entrypoint 1
[62221:62221:0726/091559.320171:ERROR:vaapi_wrapper.cc(937)] vaQuerySurfaceAttributes failed, VA error: invalid parameter
[62221:62221:0726/091559.320192:ERROR:vaapi_wrapper.cc(826)] FillProfileInfo_Locked failed for va_profile VAProfileVC1Advanced and entrypoint 1
[62221:62221:0726/091559.424415:ERROR:shared_context_state.cc(258)] OOP raster support disabled: GrContext creation failed.

Preferrably, there would a way to get chromium to to sync to my screen refresh rate (144hz), but I will settle for having it render at a steady 60 fps.

Any information you could provide in this regard would be appreciated.

Thank you.

Goran

Member

Registered: 2012-01-24

Posts: 92

Re: Chromium unable to vsync.

I have updated:

linux:  5.7.11.arch1-1
nvidia: 450.57-5
chromium: 84.0.4147.105-1

The situation is still the same ...

I would like some way to determine if this is an actual bug in chromium, rather than just some silly misconfiguration with my Arch system, before I start submitting bug reports. Any help with that would also be appreciated.

liewkj

Member

Registered: 2019-07-08

Posts: 210

Re: Chromium unable to vsync.

NVIDIA propriety Linux driver does not support GLX_OML_sync_control which is used by Chromium to precisely predict VSYNC on rendered frames presentation on the Linux GLX code path.
https://www.khronos.org/registry/OpenGL … ontrol.txt
You can verify that with

$ glxinfo | grep OML

Missing that GLX extension, Chromium will assume a VSYNC of 60FPS and fallback to its internal approximation trying to achieve the same thing, but that is a rough estimation so 52FPS can be close enough. Chromium design goal seems to be refraining from using X11 binding APIs (such as xcb-xrandr) otherwise that would be another proper way of getting the correct VSYNC.

Goran

Member

Registered: 2012-01-24

Posts: 92

Re: Chromium unable to vsync.

Thanks for the clear explanation.

Are there any plans for either nvidia to support that extension, or for chromium to support alternative methods by which proper vsync can be achieved on linux?

Given that there are alternatives for chromium to use, the fact that it doesn't seems kinda silly. Honestly, I would categorize this as a bug, because the program is clearly unable to operate as intended.

And what about firefox? Unlike chromium, it seems to be able to propely sync to at least 60hz, but it can't seem to sync to 144hz. Based on that, I assume it has the same (or maybe similar) issues as chromium, but with a somewhat better internal approximation?

Ropid

Member

Registered: 2015-03-09

Posts: 1,069

Re: Chromium unable to vsync.

In Firefox you have to enable hardware acceleration with the setting "gfx.webrender.all" in "about:config". It will then vsync to 144Hz, at least on AMD.

Something to look out for is, the Xorg driver from the "xf86-video-amdgpu" package cannot do "PRIME sync" from what I heard. This means the Nvidia driver will not be able to get vsync information of the laptop's display. You need to remove that xf86-video-amdgpu package so that the system falls back to using the "modeset" Xorg driver. You will know what driver you are using by looking into the Xorg log file.

Here's a bug report about PRIME sync and xf86-video-amdgpu, but the person there has a setup that's the other way around and the second GPU is AMD:

https://gitlab.freedesktop.org/xorg/dri … /issues/11

Last edited by Ropid (2020-08-01 02:28:24)

Goran

Member

Registered: 2012-01-24

Posts: 92

Re: Chromium unable to vsync.

Enabling "gfx.webrender.all" is one of the first things I did, when I originally noticed these sync issues, but firefox was still unable to vsync to anything but 60hz, with or without the xf86-video-amdgpu package.

However, without that package, system applications that were previously able to vsync (such as glxheads and glxgears), are no longer able to do so.

Mischa85

Member

Registered: 2020-12-06

Posts: 17

Re: Chromium unable to vsync.

NVIDIA propriety Linux driver does not support GLX_OML_sync_control which is used by Chromium to precisely predict VSYNC on rendered frames presentation on the Linux GLX code path.
https://www.khronos.org/registry/OpenGL … ontrol.txt
You can verify that with

$ glxinfo | grep OML

Missing that GLX extension, Chromium will assume a VSYNC of 60FPS and fallback to its internal approximation trying to achieve the same thing, but that is a rough estimation so 52FPS can be close enough. Chromium design goal seems to be refraining from using X11 binding APIs (such as xcb-xrandr) otherwise that would be another proper way of getting the correct VSYNC.

While the NVIDIA drivers do indeed lack support for GLX_OML_sync_control, it does support GLX_SGI_video_sync. Although there have been problems with this in the past, now it is once again fully enabled in Chromium. This should be used instead of the fallback mechanism you are referring to:

  g_glx_sgi_video_sync_supported = HasGLXExtension("GLX_SGI_video_sync");

  if (g_glx_oml_sync_control_supported) {
    vsync_provider_ = std::make_unique<OMLSyncControlVSyncProvider>(
        static_cast<GLXWindow>(glx_window_));
    presentation_helper_ =
        std::make_unique<GLSurfacePresentationHelper>(vsync_provider_.get());
  } else if (g_glx_sgi_video_sync_supported) {
    vsync_provider_ =
        std::make_unique<SGIVideoSyncVSyncProvider>(parent_window_);
    presentation_helper_ =
        std::make_unique<GLSurfacePresentationHelper>(vsync_provider_.get());
  } else {
    // Assume a refresh rate of 59.9 Hz, which will cause us to skip
    // 1 frame every 10 seconds on a 60Hz monitor, but will prevent us
    // from blocking the GPU service due to back pressure. This would still
    // encounter backpressure on a <60Hz monitor, but hopefully that is
    // not common.
    const base::TimeTicks kDefaultTimebase;
    const base::TimeDelta kDefaultInterval =
        base::TimeDelta::FromSeconds(1) / 59.9;
    vsync_provider_ = std::make_unique<gfx::FixedVSyncProvider>(
        kDefaultTimebase, kDefaultInterval);
    presentation_helper_ = std::make_unique<GLSurfacePresentationHelper>(
        kDefaultTimebase, kDefaultInterval);
  }

I do, however, still have problems getting Chromium to properly sync on anything else than 60 Hz. I'm currently on GNOME/Mutter, using the ForceFullCompositionPipeline=On setting in X. Will do some more experimentation changing these variables to see if I can pinpoint this issue.