[Nouveau] [Bug 98030] Stuttering video playback in totem after update to 1.19-rc1
https://bugs.freedesktop.org/show_bug.cgi?id=98030 Michel Dänzerchanged: What|Removed |Added Component|Driver/nouveau |Server/General Assignee|nouveau@lists.freedesktop.o |xorg-t...@lists.x.org |rg | -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 98030] Stuttering video playback in totem after update to 1.19-rc1
https://bugs.freedesktop.org/show_bug.cgi?id=98030 --- Comment #8 from Chris Wilson--- (In reply to Michel Dänzer from comment #7) > (In reply to Chris Wilson from comment #6) > > -if (NewOutputPending) > > -FlushAllOutput(); > > + FlushAllOutput(); > > This doesn't fix the problem for me. Yeah, because the first thing FlushAllOutput() does is check NewOutputPending. Bleh. :| I'm still pretty certain it is the change in considering when to flush output that causes the event/replies to become stuck. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 98030] Stuttering video playback in totem after update to 1.19-rc1
https://bugs.freedesktop.org/show_bug.cgi?id=98030 --- Comment #7 from Michel Dänzer--- (In reply to Chris Wilson from comment #6) > -if (NewOutputPending) > -FlushAllOutput(); > + FlushAllOutput(); This doesn't fix the problem for me. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 98030] Stuttering video playback in totem after update to 1.19-rc1
https://bugs.freedesktop.org/show_bug.cgi?id=98030 --- Comment #6 from Chris Wilson--- The change in 8f1edf4bd3a1f050ce9eeb5eac45dd1a8f7a6d5e is that we no longer wakeup and flush writers when space in the write queue becomes available - instead before we poll() we flush the writers iff NewOutputPending since the last poll(), i.e. diff --git a/os/WaitFor.c b/os/WaitFor.c index 8164c30..5b0c342 100644 --- a/os/WaitFor.c +++ b/os/WaitFor.c @@ -207,8 +207,7 @@ WaitForSomething(Bool are_ready) (100 / MILLI_PER_SECOND); wt = } -if (NewOutputPending) -FlushAllOutput(); + FlushAllOutput(); /* keep this check close to select() call to minimize race */ if (dispatchException) i = -1; -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 98030] Stuttering video playback in totem after update to 1.19-rc1
https://bugs.freedesktop.org/show_bug.cgi?id=98030 --- Comment #5 from Michel Dänzer--- (In reply to Mario Kleiner from comment #3) > If otoh i run applications which use fullscreen kms page-flipped windows, > e.g., Gnome shell, or regular fullscreen GL apps, they work fine under DRI2. I can confirm that for mutter, but not for e.g. glxgears in fullscreen. Maybe compositors just get unblocked by something else, similar to how input unblocks all affected DRI2 clients. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 98030] Stuttering video playback in totem after update to 1.19-rc1
https://bugs.freedesktop.org/show_bug.cgi?id=98030 Michel Dänzerchanged: What|Removed |Added CC||a...@nwnk.net, ||kei...@keithp.com --- Comment #4 from Michel Dänzer --- I bisected this to commit 8f1edf4bd3a1f050ce9eeb5eac45dd1a8f7a6d5e Author: Keith Packard Date: Thu May 19 13:59:54 2016 -0700 dix: Use list for ready clients This converts the dispatch loop into using a list of ready clients instead of an array. This changes the WaitForSomething API so that it notifies DIX when a client becomes ready to read, instead of returning the set of ready clients. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 98030] Stuttering video playback in totem after update to 1.19-rc1
https://bugs.freedesktop.org/show_bug.cgi?id=98030 --- Comment #3 from Mario Kleiner--- Ok, i think this is related: On 1.19-rc1 (current git master) under DRI2, windowed OpenGL apps like glxgears get stuck unless i press keys on the keyboard or move the mouse to create input events. KDE Plasma 5, being OpenGL driven afaik, has the same problem. If otoh i run applications which use fullscreen kms page-flipped windows, e.g., Gnome shell, or regular fullscreen GL apps, they work fine under DRI2. If i use DRI3/Present everything works fine. This both with a server built to use the new input-threads and also built without input-threads. This happens at least on nouveau-ddx and ati/amdgpu-ddx. I just retested glxgears, my own app and totem under gdb, and without me providing mouse/keyboard input, they all get stuck in the DRI2GetBuffersWithFormat request to the X-Server, waiting for a reply. That gets called when Mesa needs new renderbuffers for a new frame after a swapbuffers request, e.g., when glxgears or totem calls glClear(). So far so bad. So something gets stuck in the servers dispatch loop, but "external" input events from the kernel (evdev, kms-pageflip completion events?) gets it unstuck? -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 98030] Stuttering video playback in totem after update to 1.19-rc1
https://bugs.freedesktop.org/show_bug.cgi?id=98030 --- Comment #2 from Ilia Mirkin--- Apparently the issue also exists with modesetting on top of nouveau - i.e. if you run e.g. LIBGL_DRI3_DISABLE=1 glxgears, you'll end up with the same lag. Trying to collect more data to see if this is nouveau-specific or if it's an issue across drivers. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau