Created attachment 112362 [details] demsg from crash. I am running Arch Linux, and I used to be able to use my discrete graphics card for games using the method described below, but a while ago that stopped working, I believe after an update of nouveau and/or the kernel. I have: 00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) 01:00.0 VGA compatible controller: NVIDIA Corporation GK107M [GeForce GT 750M] (rev a1) with nouveau drivers. Steps to reproduce: I run xrandr --setprovideroffloadsink nouveau Intel at the startup of my desktop (cinnamon). Then I run DRI_PRIME=1 glxinfo (or any other openGL application that I've tried (glxgears, Civ V)), and X crashes and bring me back to my display manager (lightdm). Is there any other info you need, and/or did I report this issue completely wrong?
Created attachment 112363 [details] x log from crash.
While the situation is less-than-ideal, I don't see how nouveau is implicated. Accel is disabled because you have the "pgraph is off and we can't figure out how to turn it on" issue (there's already a bug open about that, no known resolution). Perhaps you can get debug symbols to see where it's dying?
Could you point me towards the bug report you mentioned, I couldn't find it.
https://bugs.freedesktop.org/show_bug.cgi?id=70354 From the backtrace, the crash appears to be happening in core X though... but perhaps as a result of something nouveau or intel is doing wrong.
(In reply to Ilia Mirkin from comment #4) > https://bugs.freedesktop.org/show_bug.cgi?id=70354 > > From the backtrace, the crash appears to be happening in core X though... > but perhaps as a result of something nouveau or intel is doing wrong. That seems to be likely the case. Try to remove xf86-video-nouveau or blacklist nouveau_drv.so to let nouveau fallback to modesettings. Or you could alternatively try the DRI3 variant of prime offloading: http://nouveau.freedesktop.org/wiki/Optimus/ That wont fix the actual bug but may help to work around this.
Created attachment 112372 [details] backtrace from crash I quickly compiled X with debug symbols, and this is what I got for a backtrace.
(In reply to Tobias Klausmann from comment #5) > (In reply to Ilia Mirkin from comment #4) > > https://bugs.freedesktop.org/show_bug.cgi?id=70354 > > > > From the backtrace, the crash appears to be happening in core X though... > > but perhaps as a result of something nouveau or intel is doing wrong. > > That seems to be likely the case. Try to remove xf86-video-nouveau or > blacklist nouveau_drv.so to let nouveau fallback to modesettings. Or you > could alternatively try the DRI3 variant of prime offloading: > http://nouveau.freedesktop.org/wiki/Optimus/ > > That wont fix the actual bug but may help to work around this. I might try one of these solutions. A couple questions for DRI3: how do I check if X and mesa have DRI3 support? Also, what setup do I need to do? Do I just need to use DRI_PRIME=1, without using xrandr --setprovideroffloadsink (like I would for DRI2)?
(In reply to aidan from comment #7) (snip) > I might try one of these solutions. A couple questions for DRI3: how do I > check if X and mesa have DRI3 support? Also, what setup do I need to do? > Do I just need to use DRI_PRIME=1, without using xrandr > --setprovideroffloadsink (like I would for DRI2)? You'll need the setup described at the nouveau's prime page, linked above, other than that, you just have to do: DRI_PRIME=1 app and it will offload to nouveau
(In reply to Tobias Klausmann from comment #8) > (In reply to aidan from comment #7) > (snip) > > I might try one of these solutions. A couple questions for DRI3: how do I > > check if X and mesa have DRI3 support? Also, what setup do I need to do? > > Do I just need to use DRI_PRIME=1, without using xrandr > > --setprovideroffloadsink (like I would for DRI2)? > > You'll need the setup described at the nouveau's prime page, linked above, > other than that, you just have to do: > DRI_PRIME=1 app > and it will offload to nouveau Except it won't work because we can't get accel going on his card... this bug should just be about the crash.
Right, the bug is just that we attempted to dereference a DRI2ScreenPtr on a GPU screen for which DRI2 was never initialised (due to NoAccel). So we have 2 bugs: 1. The code should be more robust and only add an offload_slave if DRI2 was enabled on that Screen (or be prepared for lies). 2. Nouveau shouldn't be claiming to be an offload slave if it doesn't support offloading (due to NoAccel).
(In reply to Chris Wilson from comment #10) > 2. Nouveau shouldn't be claiming to be an offload slave if it doesn't > support offloading (due to NoAccel). Except, offloading may be eiter DRI2 or DRI3 so this doesn't make sense.
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c index 8b94b8f..e048224 100644 --- a/hw/xfree86/dri2/dri2.c +++ b/hw/xfree86/dri2/dri2.c @@ -158,6 +158,9 @@ GetScreenPrime(ScreenPtr master, int prime_id) DRI2ScreenPtr ds; ds = DRI2GetScreen(slave); + if (ds == NULL) + continue; + if (ds->prime_id == prime_id) return slave; }
commit 082931014811e587a9734cbf4d88fd948979b641 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sat Jan 17 10:09:54 2015 +0000 dri2: SourceOffloads may be for DRI3 only As a DDX may declare offload support without supporting DRI2 (because it is using an alternative acceleration mechanism like DRI3), when iterating the list of offload_source Screens to find a matching DRI2 provider we need to check before assuming it is DRI2 capable. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88514 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Keith Packard <keithp@keithp.com>
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.