Bug 92271

Summary: Unusably slow OpenGL performance on nouveau (GeForce 9600 GT) with rotated output under DRI 3
Product: xorg Reporter: Adam Williamson <adamw>
Component: Driver/nouveauAssignee: Nouveau Project <nouveau>
Status: RESOLVED MOVED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: skeggsb
Version: git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
i915 platform: i915 features:
Description Flags
journal (inc. X logs) from 1.17.2
journal (inc. X logs) from 1.18.0-0.3.20150907
glxinfo from 1.17.2
glxinfo from 1.18.0-0.3.20150907 none

Description Adam Williamson 2015-10-03 22:33:54 UTC
Running Fedora 23, I just rebooted my system after it had been up for a long time and found GNOME Shell was unusably slow - far slower than a debug kernel, far slower than software rendering.

Running glxgears from an Xfce session had the same problem reported a speed of less than 2fps.

After trying various downgrades I finally hit the jackpot:

Packages Altered:
    Downgrade  xorg-x11-drv-dummy-0.3.6-23.fc23.x86_64                  @@commandline
    Downgraded                    0.3.6-24.fc23.x86_64                  @updates-testing
    Downgrade  xorg-x11-drv-libinput-0.14.0-1.fc23.x86_64               @@commandline
    Downgraded                       0.14.0-2.fc23.x86_64               @updates-testing
    Downgrade  xorg-x11-drv-nouveau-1:1.0.11-4.fc23.x86_64              @@commandline
    Downgraded                      1:1.0.12-0.2.fc23.x86_64            @updates-testing
    Downgrade  xorg-x11-server-Xephyr-1.17.2-2.fc23.x86_64              @@commandline
    Downgraded                        1.18.0-0.4.20150907.fc23.x86_64   @updates-testing
    Downgrade  xorg-x11-server-Xorg-1.17.2-2.fc23.x86_64                @@commandline
    Downgraded                      1.18.0-0.4.20150907.fc23.x86_64     @updates-testing
    Downgrade  xorg-x11-server-Xwayland-1.17.2-2.fc23.x86_64            @@commandline
    Downgraded                          1.18.0-0.4.20150907.fc23.x86_64 @updates-testing
    Downgrade  xorg-x11-server-common-1.17.2-2.fc23.x86_64              @@commandline
    Downgraded                        1.18.0-0.4.20150907.fc23.x86_64   @updates-testing

i.e. I went from the 1.18.0 X server snapshot down to 1.17.2 (and downgraded driver packages, since 1.18 has an ABI bump), and my performance is back to normal, Shell is usable again.

Note I did try an earlier build of the 1.18.0 snapshot - 1.18.0-0.2.20150907 - and it didn't help, so I'm pretty sure the bug is between 1.17.2 and the 1.18 snapshot, unless it's between -1 and -2 which seems unlikely.

Hardware is an NVIDIA GeForce 9600 GT:

01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G94 [GeForce 9600 GT] [10de:0622] (rev a1)

there were no obvious related messages in the system log, even with drm.debug=14. Please let me know what else I can do to help track this down. I'll try and see if I can build a current git snapshot and see if that works.
Comment 1 Adam Williamson 2015-10-05 23:43:43 UTC
Current git snapshot - e31fe8115ee080b58b2e96a5106f38e64944ce5e - does not help, same problem. So it hasn't been fixed between Fedora's current snapshot and now.
Comment 2 Adam Williamson 2015-10-07 17:51:59 UTC
Created attachment 118736 [details]
journal (inc. X logs) from 1.17.2

As requested by airlied, here are some logs: journal output (including X logs) and glxinfo from both 1.17.2 and 1.18.0-0.3.20150907 .
Comment 3 Adam Williamson 2015-10-07 17:52:24 UTC
Created attachment 118737 [details]
journal (inc. X logs) from 1.18.0-0.3.20150907
Comment 4 Adam Williamson 2015-10-07 17:52:38 UTC
Created attachment 118738 [details]
glxinfo from 1.17.2
Comment 5 Adam Williamson 2015-10-07 17:53:17 UTC
Created attachment 118739 [details]
glxinfo from 1.18.0-0.3.20150907
Comment 6 Adam Williamson 2015-10-07 17:59:07 UTC
diffing the X bits of the log, nothing really obvious pops out, I do see one (EE) that *goes away* in 1.18:

-(EE) NOUVEAU(0): [COPY] failed to allocate class.

the other diffs all seem to be input stuff. In glxinfo there's only one difference:

-    GLX_ARB_get_proc_address, GLX_ARB_multisample, 
+    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_buffer_age,

so, an extra extension is supported in 1.18. That *could* somehow be related?
Comment 7 Adam Williamson 2015-10-07 18:58:24 UTC
another thing airlied asked: if I remove xorg-x11-drv-nouveau and let it fall back to the 'modesetting' driver, performance seems fine (both GNOME Shell and glxgears). From the logs it looks like it uses glamor.

This is unusable for me, though, as I can't rotate my displays.

Hmm...I suppose it might be significant that I use dual displays, both rotated 90 degrees? Let me see if the issue still occurs with nouveau if I skip the rotation...
Comment 8 Adam Williamson 2015-10-07 19:00:38 UTC
hmm, actually, rotation with modesetting works with xrandr, just not with the GNOME control center. (just a side note, not really relevant to the bug).
Comment 9 Adam Williamson 2015-10-07 19:13:32 UTC
Aha - so rotation is definitely involved. Dropping down to one head doesn't help, but un-rotating certainly does: the instant I set the screen back to 'normal' orientation the GNOME session sped up again, didn't need a reboot or even a logout.
Comment 10 Adam Williamson 2015-10-07 19:14:01 UTC
And re-applying rotation immediately slows it down again.
Comment 11 Adam Williamson 2015-10-07 19:58:46 UTC
Something very similar happens on a laptop I also have, a Vaio Z (2010 model). It has two graphics adapters, an Intel and an NVIDIA, which I can switch between with a hardware switch - the firmware is hacked so the switch completely disables one adapter or the other, so on each boot the system only appears to have one adapter or the other.

With the Intel adapter enabled, I can boot an F23 Final TC1 Workstation live and rotate the display just fine.

With the NVIDIA adapter enabled, if I boot the same image and rotate the display, X seems to stop responding entirely (but a VT works fine). I see the same 'systemd-logind: got pause for XX:XX' messages that are in the journal on my desktop. But if I boot the Beta image instead - which has the older X server - rotating the display works fine with the NVIDIA adapter.

The adapter in that system is a GT216M, 10de:0a2b.
Comment 12 Adam Williamson 2015-10-07 20:49:39 UTC
CCing Ilia and Ben, as this seems to be nouveau-specific.
Comment 13 Ilia Mirkin 2015-10-07 22:48:26 UTC
There are a lot of moving parts here... let's try moving fewer of them.

What if you downgrade your X stack (which, correct me if I'm wrong, "works"), but upgrade nouveau to the unreleased 1.0.12? Do you still get the slowdown? [You might not have pre-built packages, but you can build it yourself.]

The fact that the error about the copy class is gone is expected -- I made it not try to create it in the first place when it wasn't going to be there.
Comment 14 Adam Williamson 2015-10-07 23:40:12 UTC
Aha, you're quite right: the issue exists if I build the xorg-x11-drv-nouveau git snapshot we're using against X server 1.17.2, it's not the server at all.

Apologies for missing that - I was thinking "downgrade X server" and just threw packages at the transaction till it worked, soI actually didn't notice there was a significant difference between the nouveau driver versions too.

I will do some bisecting between 1.0.11 and the snapshot we're at and see if I can see where it broke. I don't see anything between July 29 (when we took the snapshot) and now that looks like it'd be relevant.
Comment 15 Adam Williamson 2015-10-08 01:06:49 UTC
So I bisected it down and it looks like the cause is http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=241e7289f25a342a457952b9b0e539c2f0b81d99 , "enable dri3 support without glamor".
Comment 16 Ilia Mirkin 2015-10-08 01:11:43 UTC
You can force DRI (in a sufficiently new nouveau snapshot) by doing

Option "DRI" "2"

No idea what causes the slowdown tbh. All this DRI stuff is a little beyond me.
Comment 17 Adam Williamson 2015-10-08 01:21:24 UTC
Note: according to the logs, the system is using DRI2, not DRI3. So it seems like somehow, the DRI3 patch breaks the DRI2 case?
Comment 18 Ilia Mirkin 2015-10-08 01:33:58 UTC
(In reply to Adam Williamson from comment #17)
> Note: according to the logs, the system is using DRI2, not DRI3. So it seems
> like somehow, the DRI3 patch breaks the DRI2 case?

Don't trust everything you read online :) Pretty sure nothing would be printed differently, at least not in your version.
Comment 19 Adam Williamson 2015-10-08 01:46:23 UTC
Well, the code still claims that it defaults to DRI 2:


and Fedora is doing nothing to patch that.
Comment 20 Ilia Mirkin 2015-10-08 01:51:00 UTC

Only starting August. You said your snapshot was in July.
Comment 21 Adam Williamson 2015-10-08 01:59:08 UTC
ah, that could explain it. I'm currently running a build of git master, we'll see how that behaves, perhaps it'll work by default and show the bug if I force DRI3...
Comment 22 Adam Williamson 2015-10-08 02:13:38 UTC
So...yeah, it more or less works with a current git snapshot, except there's one odd thing...I have a file in /etc/X11/xorg.conf.d with this content:

Section "Device"
        Identifier  "nouveau"
        Driver      "nouveau"
        Option	"Monitor-DVI-I-1"	"Right Monitor"
	Option	"Monitor-DVI-I-2"	"Left Monitor"

Section "Monitor"
	Identifier	"Left Monitor"
	Option	"Primary"	"True"
	Option	"Rotate"	"left"

Section "Monitor"
	Identifier	"Right Monitor"
	Option	"RightOf"	"Left Monitor"
        Option  "Rotate"        "left"

it's to rotate my screens on desktops that don't do their own RandR stuff (and it used to work for GDM too, doesn't any more). But for some reason, if I have that file active with latest git nouveau, X won't start; I have to rename it to .conf.bak to make X start. Still, if I do that, it does run fine and at full speed, so this one looks like a bug tied to the particular nouveau DDX git snapshot Fedora is using. Guess I should move it downstream?
Comment 23 Ilia Mirkin 2015-10-08 02:17:04 UTC
(In reply to Adam Williamson from comment #22)
> it's to rotate my screens on desktops that don't do their own RandR stuff
> (and it used to work for GDM too, doesn't any more). But for some reason, if
> I have that file active with latest git nouveau, X won't start; I have to
> rename it to .conf.bak to make X start. Still, if I do that, it does run
> fine and at full speed, so this one looks like a bug tied to the particular
> nouveau DDX git snapshot Fedora is using. Guess I should move it downstream?

Need some logs. That config seems generally fine.

Also, does it run at full speed if you force DRI3?
Comment 24 Adam Williamson 2015-10-08 02:23:04 UTC
Damnit, sorry - bad test. Actually the current git build of nouveau is flat out failing to load at all; it's working when the config file isn't there because it's falling back to modesetting. I'll poke a bit more...
Comment 25 Adam Williamson 2015-10-08 02:45:11 UTC
OK, so I finally got a good test. I built a snapshot exactly at the DRI 2-by-default commit - http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=6296145654b78518f3299bb5887f224f0d3810fd - and that one loads OK. And indeed it behaves as we suspected: it works at full speed by default, if I force DRI 3, it loads but runs very slowly.

So the slowness-when-rotated is a genuine bug that's specific to DRI 3 mode, I guess.
Comment 26 poma 2016-01-20 16:45:54 UTC
Same with the NVIDIA G98,
Xfce, GNOME and KDE
Comment 27 poma 2016-04-06 11:12:46 UTC
Still there, with
X.Org X Server 1.18.3
OpenGL version string: 3.0 Mesa 11.2.0
Comment 28 Martin Peres 2019-12-04 09:04:40 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/220.

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.