Bug 92271

Current git snapshot - e31fe8115ee080b58b2e96a5106f38e64944ce5e - does not help, same problem. So it hasn't been fixed between Fedora's current snapshot and now.

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 .

Created attachment 118737 [details]
journal (inc. X logs) from 1.18.0-0.3.20150907

Created attachment 118738 [details]
glxinfo from 1.17.2

Created attachment 118739 [details]
glxinfo from 1.18.0-0.3.20150907

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?

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...

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).

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.

And re-applying rotation immediately slows it down again.

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.

CCing Ilia and Ben, as this seems to be nouveau-specific.

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.

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.

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".

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.

Note: according to the logs, the system is using DRI2, not DRI3. So it seems like somehow, the DRI3 patch breaks the DRI2 case?

(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.

Well, the code still claims that it defaults to DRI 2:

http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/tree/src/nv_driver.c#n1080

and Fedora is doing nothing to patch that.

http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=6296145654b78518f3299bb5887f224f0d3810fd

Only starting August. You said your snapshot was in July.

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...

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"
EndSection

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

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

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?

(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?

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...

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.

Same with the NVIDIA G98,
Xfce, GNOME and KDE
https://bugs.freedesktop.org/show_bug.cgi?id=92307#c32

Still there, with
X.Org X Server 1.18.3
OpenGL version string: 3.0 Mesa 11.2.0

-- 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.