Created attachment 144921 [details] DRI PRIME 0 I have a Razer Blade Stealth late 2016 with a Razer Core V1 and an RX 560. Arch Linux Linux stealth 5.2.1-arch1-1-fsync #1 SMP PREEMPT Mon Jul 22 17:40:06 PDT 2019 x86_64 GNU/Linux mesa-aco-git 19.2.0_devel.114720.5c6077221dd-1 (Also happens on normal mesa-git and mesa stable) With only the AMDGPU enabled for Xorg, DRI_PRIME=1 attempts to use Intel, falls back to AMD as expected, but has the weird behavior of completely bypassing vsync. DRI_PRIME=0 works as expected Expected behavior is to ignore the Intel card since it's not currently loaded in Xorg. I can obviously set DRI_PRIME=0 and be fine, but the DRI_PRIME=1 behavior seems to be a bug. Xorg conf Section "Device" Identifier "AMD" Driver "amdgpu" BusID "PCI:07:0:0" EndSection xrandr corroborates this in the listproviders output Providers: number : 1 Provider 0: id: 0x57 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 5 outputs: 3 associated providers: 0 name:AMD Radeon (TM) RX 460 Graphics @ pci:0000:07:00.0 DRI_PRIME=1 glxinfo reports the same info aside from an error at the top of the output libGL error: Different GPU, but blitImage not implemented for this driver libGL error: failed to load driver: i965 Full glxinfo attached for DRI_PRIME=0, DRI_PRIME=1, and DRI_PRIME=1 with vblank_mode=1 glxgears for FPS example $ DRI_PRIME=0 glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 333 frames in 5.0 seconds = 66.549 FPS 300 frames in 5.0 seconds = 59.999 FPS 300 frames in 5.0 seconds = 59.997 FPS 301 frames in 5.0 seconds = 60.001 FPS $ DRI_PRIME=1 glxgears libGL error: Different GPU, but blitImage not implemented for this driver libGL error: failed to load driver: i965 Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 42158 frames in 5.0 seconds = 8431.391 FPS 42406 frames in 5.0 seconds = 8481.144 FPS 42266 frames in 5.0 seconds = 8453.060 FPS 42444 frames in 5.0 seconds = 8488.649 FPS $ vblank_mode=1 DRI_PRIME=1 glxgears libGL error: Different GPU, but blitImage not implemented for this driver libGL error: failed to load driver: i965 ATTENTION: default value of option vblank_mode overridden by environment. 42081 frames in 5.0 seconds = 8415.999 FPS 42527 frames in 5.0 seconds = 8505.298 FPS 42591 frames in 5.0 seconds = 8518.191 FPS 42508 frames in 5.0 seconds = 8501.433 FPS
Created attachment 144922 [details] DRI PRIME 1
Created attachment 144923 [details] DRI PRIME 1 vblank mode 1
Please attach your xorg log and dmesg output. Generally the laptop panel is only physically connected to the integrated GPU so you have to use the integrated GPU to get a display.
I'm not using the laptop panel or connector. This is a Thunderbolt eGPU. HDMI is direct into the external RX 560. While testing I just realized this behavior has nothing to do with multi GPU. Ran the same glxgears test on desktop that only has RX 480 and iGPU disabled in BIOS. Same behavior. $ DRI_PRIME=1 glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 28663 frames in 5.0 seconds = 5732.486 FPS 26437 frames in 5.0 seconds = 5286.734 FPS 26203 frames in 5.0 seconds = 5239.404 FPS 26759 frames in 5.0 seconds = 5346.603 FPS Will attach the current Xorg log.
Created attachment 144924 [details] dmesg output
Created attachment 144925 [details] Xorg log
Due to DRI_PRIME=1, libGL tries to initialize the i965 driver with DRI3, which fails: libGL error: Different GPU, but blitImage not implemented for this driver libGL error: failed to load driver: i965 So it falls back to DRI2, which uses the AMD GPU, because the Intel one wasn't initialized in Xorg. DRI2 doesn't support sync-to-vblank via PRIME. Reassigning to Mesa for now, but DRI_PRIME=1 really isn't intended to be used with a single GPU.
Aye, I was more intrigued by the vsync bypass. It even uncapped games with a forced 60 (regardless of vsync being on or off) Just a consequence of that DRI fallback?
I need to wakeup and read the comment. So it's because DRI2. Thanks for the reply.
So would DRI_PRIME=1 acting like 0 if only one GPU is present, be a possibility? The fact it's trying to load the non-existent GPU in the first place seems to be the root issue.
(In reply to Parker Reed from comment #10) > So would DRI_PRIME=1 acting like 0 if only one GPU is present, be a > possibility? The fact it's trying to load the non-existent GPU It's not really "non-existent", or libGL wouldn't try to use it. > in the first place seems to be the root issue. I think the real issue is using DRI_PRIME=1 when it can't work as intended.
In other words, the only thing preventing the Intel GPU from being used in this case is the i965 driver missing the blitImage functionality.
But the Intel card isn't enabled in the conf. Why is it trying to init it if it's not there? i915 is loaded kernel side but it's just dead displaying a TTY. I agree the DRI_PRIME shouldn't be called in this case. It's just odd behavior if it is called accidentally.
(In reply to Parker Reed from comment #13) > But the Intel card isn't enabled in the conf. That doesn't matter with DRI3. With it, libGL can use an alternative GPU without any explicit support for it in Xorg.
Ahh thanks. Wasn't aware of that. This can be closed out in that case. I'll bug the software I was using about not setting the DRI_PRIME in certain cases.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.