I use compton compositing manager wich uses DRM_IOCTL_WAIT_VBLANK for vsync. Recently I updated from kernel 3.9 to 3.13 and responsivness (or "input lag" or however it's called) got much worse, mostly noticable when moving windows or scrolling. With kernel 3.13 the windows are 3-5 frames behind mouse when moving, on 3.9 kernel they were only 0-1 frames behind. I also tried kwin, wich had less noticable slowdown (from 1-2 frames behind to 3-5 frames behind). I tried different kernel versions from nouveau git and found out, that the slowdown was caused by this commit: http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=0fa9061ae8c10a9178d696cf48d94c3bf2848f9f I guess the commit is important and can't be undone, but the bad responsiveness really annoys me, so I would be glad if there is a solution. GPU is GTX 560 Ti xserver 1.14.5 xorg-video-nouveau 1.0.10 libdrm 2.4.52 (Debian sid)
On the surface, this should have been a no-op change. You say you tried different kernel versions... is that to say you did a git bisect? e.g. can you confirm that 0fa9061ae8c10a9178d696cf48d94c3bf2848f9f has the issue but 0fa9061ae8c10a9178d696cf48d94c3bf2848f9f^ doesn't? One small difference that I noticed is that if stat == ~0 in the old code it'll return IRQ_NONE, whereas it will try to handle it in after the patch. I can't imagine that matters here though. Something to look at is what it is that the drm framework provided with the irq's that's not done by nouveau now.
I can confirm that 0fa9061ae8c10a9178d696cf48d94c3bf2848f9f has the problem and b9a3140ce8fcd616b02533fbdef375a87a910daf (previous commit) does'nt.
Actually the current code handles the intr == ~0 bit. The only other thing of mild consequence is that drm_device->irq_enabled is no longer set. Can you try adding dev->irq_enabled = true; to nouveau_drm.c:nouveau_drm_load somewhere after things look like they succeed? Or perhaps right before the nouveau_display_create, where it was before the patch. [And in an ideal world, one would also set it to false at some point, e.g. nouveau_drm_unload, but I doubt that's important for this experiment.]
(In reply to comment #3) > Actually the current code handles the intr == ~0 bit. The only other thing > of mild consequence is that drm_device->irq_enabled is no longer set. > > Can you try adding > > dev->irq_enabled = true; > > to nouveau_drm.c:nouveau_drm_load somewhere after things look like they > succeed? Or perhaps right before the nouveau_display_create, where it was > before the patch. [And in an ideal world, one would also set it to false at > some point, e.g. nouveau_drm_unload, but I doubt that's important for this > experiment.] This fix solved the problem for 0fa9061ae8c10a9178d696cf48d94c3bf2848f9f! That's great! I will try if it works for 3.13 too.
Yes, the fix works for 3.13 too. Thank you so much!
Great catch Ilia, from the DocBook [1] Manual IRQ Registration ... They must set the <structname>drm_device</structname> <structfield>irq_enabled</structfield> field to 1 upon registration of the IRQs, and clear it to 0 after unregistering the IRQs. [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/DocBook/drm.tmpl#n374
The fix is now upstream and will be included in the next 3.14-rc as well as be backported to the affected stable kernels. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7d3428cd4b2ad51af86fdbdf8284ca38fa95e601
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.