Bug 111272

Summary: [DRI_PRIME] Error on multi GPU with only one enabled
Product: Mesa Reporter: Parker Reed <parker.l.reed>
Component: GLXAssignee: mesa-dev
Status: RESOLVED NOTABUG QA Contact: mesa-dev
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: DRI PRIME 0
DRI PRIME 1
DRI PRIME 1 vblank mode 1
dmesg output
Xorg log

Description Parker Reed 2019-07-31 18:11:39 UTC
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
Comment 1 Parker Reed 2019-07-31 18:12:02 UTC
Created attachment 144922 [details]
DRI PRIME 1
Comment 2 Parker Reed 2019-07-31 18:12:25 UTC
Created attachment 144923 [details]
DRI PRIME 1 vblank mode 1
Comment 3 Alex Deucher 2019-07-31 18:15:10 UTC
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.
Comment 4 Parker Reed 2019-07-31 18:25:27 UTC
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.
Comment 5 Parker Reed 2019-07-31 18:27:01 UTC
Created attachment 144924 [details]
dmesg output
Comment 6 Parker Reed 2019-07-31 18:27:18 UTC
Created attachment 144925 [details]
Xorg log
Comment 7 Michel Dänzer 2019-08-02 09:08:06 UTC
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.
Comment 8 Parker Reed 2019-08-02 12:24:27 UTC
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?
Comment 9 Parker Reed 2019-08-02 12:25:40 UTC
I need to wakeup and read the comment. So it's because DRI2. Thanks for the reply.
Comment 10 Parker Reed 2019-08-02 12:40:40 UTC
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.
Comment 11 Michel Dänzer 2019-08-02 14:30:38 UTC
(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.
Comment 12 Michel Dänzer 2019-08-02 14:32:56 UTC
In other words, the only thing preventing the Intel GPU from being used in this case is the i965 driver missing the blitImage functionality.
Comment 13 Parker Reed 2019-08-02 14:40:57 UTC
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.
Comment 14 Michel Dänzer 2019-08-02 14:43:51 UTC
(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.
Comment 15 Parker Reed 2019-08-02 14:52:45 UTC
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.