PRIME offloading: Unable to run chrome

Graphics / Linux Linux
1

I’m using Fedora 30 with the negativo17 repo. Installed the latest 435.21 + xorg patches and it seems to work on my ASUS UX501VW (Intel HD 530 + NVidia GTX 960M).
I tried to run chrome with the NVidia card as follows:

__NV_PRIME_RENDER_OFFLOAD_PROVIDER=NVIDIA-G0 __GLX_VENDOR_LIBRARY_NAME=nvidia google-chrome-stable

but I keep getting the following error:

[844:844:0912/134157.456469:ERROR:gl_surface_glx.cc(78)] XGetWindowAttributes failed for window 113246212.
[844:844:0912/134157.456530:ERROR:gl_surface_glx.cc(839)] Failed to get GLXConfig
[844:844:0912/134157.456557:ERROR:gpu_info_collector.cc(60)] gl::GLContext::CreateOffscreenGLSurface failed
[844:844:0912/134157.456562:ERROR:gpu_info_collector.cc(199)] Could not create surface for info collection.
[844:844:0912/134157.456585:ERROR:gpu_init.cc(66)] gpu::CollectGraphicsInfo failed.
[844:844:0912/134157.458929:ERROR:viz_main_impl.cc(167)] Exiting GPU process due to errors during initialization
[1:1:0912/134158.061078:ERROR:child_process_sandbox_support_impl_linux.cc(81)] FontService unique font name matching request did not receive a response.
[1:1:0912/134158.061898:ERROR:child_process_sandbox_support_impl_linux.cc(81)] FontService unique font name matching request did not receive a response.

Chrome will open, but there’s no hardware acceleration (about://gpu) and it’s falling back to a software renderer (OpenGL ES 3.0 SwiftShader 4.1.0.7).
Are there any flags or something I need in order to be able to run the browser with proper acceleration provided by the NVidia card? is it even supposed to be able to run?

Any help, would be much appreciated!

2

Chrome gets confused about the second gpu, I guess. It works when using

__NV_PRIME_RENDER_OFFLOAD_PROVIDER=NVIDIA-G0 __GLX_VENDOR_LIBRARY_NAME=nvidia_only
3

I have tried that before, and it reports hardware acceleration, but that’s because it actually falls back to using the intel gfx and not nvidia (GL_RENDERER: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2)). Are you sure you’re getting it to run with the nvidia gpu?

4

You’re actually right, nvidia_only is only valid in the Vulkan context.

5

I noticed this too, but haven’t had a chance to dig into it much. I suspect Chrome is getting confused by the GLX fbconfigs being presented in render offload mode. They’re slightly different from what you see in non-offload mode because of limitations in how the driver is able to map NVIDIA fbconfigs to X11 Visuals on the target screen.

I suspect Chrome is getting confused by the backwards way it creates a window and then tries to find an fbconfig. There’s a comment about it in the source code here, and I have a feeling that doing what the comment suggests would fix the problem:
https://chromium.googlesource.com/chromium/chromium/+/master/ui/gl/gl_surface_glx.cc#168

// TODO(kbr): this is not a reliable code path. On platforms which
    // support it, we should use glXChooseFBConfig in the browser
    // process to choose the FBConfig and from there the X Visual to
    // use when creating the window in the first place. Then we can
    // pass that FBConfig down rather than attempting to reconstitute
    // it.
6

Thank you Aaron, that indeed seems to be the case.
So I guess it’s something that needs to be fixed by the chromium team. Hopefully, this is the only application causing this problem and they’ll fix it soon. This is going to be a problem for any electron/nwjs app that wants/needs access to the NVidia GPU and provide better acceleration.

7

I can confirm that it is not working for Firefox too.

8

I looked into the Firefox source a bit and it turns out that the test it uses to decide whether to enable WebGL is failing because it looks for a single-buffered GLX visual, and we currently only report double-buffered ones. You can work around the problem by going into about:config and setting webgl.force-enabled to true.

The problematic check is in toolkit/xre/glxtest.cpp:

///// Get a visual /////
  int attribs[] = {GLX_RGBA, GLX_RED_SIZE,  1, GLX_GREEN_SIZE,
                   1,        GLX_BLUE_SIZE, 1, None};
  XVisualInfo* vInfo = glXChooseVisual(dpy, DefaultScreen(dpy), attribs);
  if (!vInfo) fatal_error("No visuals found");

Note that if you don’t specify GLX_DOUBLEBUFFER, then glXChooseVisual will only return single-buffered visuals.

The actual code to create a WebGL context in gfx/gl/GLContextProviderGLX.cpp uses glXChooseFBConfig in a way that allows it to choose a double-buffered fbconfig, so it works fine if you bypass the glxtest check:

int attribs[] = {LOCAL_GLX_DRAWABLE_TYPE,
                   LOCAL_GLX_PIXMAP_BIT,
                   LOCAL_GLX_X_RENDERABLE,
                   X11True,
                   LOCAL_GLX_RED_SIZE,
                   8,
                   LOCAL_GLX_GREEN_SIZE,
                   8,
                   LOCAL_GLX_BLUE_SIZE,
                   8,
                   LOCAL_GLX_ALPHA_SIZE,
                   minCaps.alpha ? 8 : 0,
                   LOCAL_GLX_DEPTH_SIZE,
                   minCaps.depth ? 16 : 0,
                   LOCAL_GLX_STENCIL_SIZE,
                   minCaps.stencil ? 8 : 0,
                   0};

  int numConfigs = 0;
  scopedConfigArr = glx->fChooseFBConfig(display, screen, attribs, &numConfigs);

(If you don’t specify GLX_DOUBLEBUFFER then it defaults to GLX_DONT_CARE).

9

@aplattner: Thanks - WebGL is indeed working this way. But it seems like WebRender is disbled

about:support contains the following information:
Compositing: Basic
WEBRENDER
opt-in by default: WebRender is an opt-in feature
available by user: Force enabled by pref
unavailable by runtime: WebRender initialization failed
Failure Log
(#0) Error Failed to connect WebRenderBridgeChild.
(#1) GP+[GFX1-]: Failed GL context creation for WebRender: 0
(#2) GP+[GFX1-]: [OPENGL] Failed to init compositor with reason: FEATURE_FAILURE_OPENGL_CREATE_CONTEXT

10

Does it make sense to report these as bugs to upstream (i.e. Firefox/Chrome bugtracker) so they can get resolved someday?

It appears to be a problem due to how they are detecting the correct WebGL environment.

11

Good news: Chrome unstable (80.0.3987.7) works for me with GPU offloading.
I’m currently using the following options:

__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia /usr/bin/google-chrome-unstable --ignore-gpu-blacklist --enable-gpu-rasterization --enable-native-gpu-memory-buffers --enable-zero-copy

12

Whatever command line option I choose chromium doesn’t want to switch to Nvidia. Even flags

--gpu-testing-vendor-id=0x10de --gpu-testing-device-id=0x1d10

seems to be ignored.
Anyone got it working and confirmed under about:gpu?

13

Hi

Now in 2021-09 debian 11 is now embeed by default X in a version where all necessary git commits needed to run PRIME RENDER OFFLOAD were done (v1.20.11).

So with an Nvidia GPU in addition to any other GPU (could be the one embed in your CPU on a laptop or the one embed in your BMC card on a server) it’s possible to offload applications natively on the Nvidia GPU.

Good news, it’s a nice techno ! it works fine with most apps but it still not possible to make it work with google-chrome (version 93.0.4577.63-1) or even firefox (version 78.13.0esr)

With google-chrome, it generate millions of lines like this one in logs :

[221045:221045:0908/184655.524040:ERROR:angle_platform_impl.cc(44)] renderergl_utils.cpp:188 (ClearErrors): Preexisting GL error 0x00000507 as of ../../third_party/angle/src/libANGLE/renderer/gl/TextureGL.cpp, setImageHelper:256.

before falling back to the primary GPU and opening the window with this log output :

[0908/184729.697430:WARNING:exception_snapshot_linux.cc(427)] Unhandled signal -1
[221133:221133:0908/184729.689366:ERROR:angle_platform_impl.cc(44)] renderergl_utils.cpp:188 (ClearErrors): Preexisting GL error 0x00000507 as of ../../third_party/angle/src/libANGLE/renderer/gl/TextureGL.cpp, setImageHelper:256. 
[220712:220712:0908/184729.705637:ERROR:command_buffer_proxy_impl.cc(328)] GPU state invalid after WaitForGetOffsetInRange.
[220790:7:0908/184729.705582:ERROR:command_buffer_proxy_impl.cc(328)] GPU state invalid after WaitForGetOffsetInRange.
2[220712:220712:0908/184729.816388:ERROR:gpu_process_host.cc(961)] GPU process exited unexpectedly: exit_code=512
[221212:221212:0908/184729.997669:ERROR:gpu_init.cc(441)] Passthrough is not supported, GL is swiftshader

I understand that in version <80 there was some modification to do in chromium code but according to Stefan.Krause it seems to have been done from version 80.0.3987.7

@aplattner
Can you please confirm that it’s now possible (in 2021-09) to offload google-chrome on nvidia GPU using prime render offload ?

It’s required to use advanced functions like “taking remote control” in web applications like Microsoft Teams opened in google-chrome (the web version, not a version using xdg-open to run Microsoft Teams binary)

Got the same question for firefox, I was not able to run it on nvidia GPU using debian 11

Thanks for your reply and help
Kind regards,
nbanba