Created attachment 55181 [details] tail -n 1000000 of Xorg.log with --enable-debug=full The latest SNA causes vlc with XVideo (it does not seem to happen with mplayer, though) to flash an older frame in an irregular interval. The frame that flashes is always the same and eventually, it will stay until the windows is resized, for example.
Now that is a debug log to scare. Everytime I think I covered all the possible horrible rendering paths... Haven't seen why you see flashing yet, but there's plenty in there that could be improved. :( Your setup is xfce4, no compositing, vlc?
(In reply to comment #1) > Now that is a debug log to scare. Everytime I think I covered all the possible > horrible rendering paths... > > Haven't seen why you see flashing yet, but there's plenty in there that could > be improved. :( > > Your setup is xfce4, no compositing, vlc? Almost ;). xfce4, vlc, with compositing
So... I think this is the same SHM issue. In this case, afaict it attempts to read back from the GPU through a SHM segment, which leads to all sorts of calamity if I incorrectly migrate it to the GPU and so the pixels in CPU memory become stale. Can you test again after updating to get the other path and see if it does indeed fix this issue as well?
(In reply to comment #3) > So... I think this is the same SHM issue. In this case, afaict it attempts to > read back from the GPU through a SHM segment, which leads to all sorts of > calamity if I incorrectly migrate it to the GPU and so the pixels in CPU memory > become stale. Can you test again after updating to get the other path and see > if it does indeed fix this issue as well? Unfortunately not. Should I post another Xorg.log without all the noise from the other bug that is now fixed?
I not yet seen anything like this yet, I've some other oddities to chase under xfce4 though. (The vlc controls seem not to be picked up by Damage/Composite and general redraw misbehaviour. That's probably just my bogus xserver... I can hope ;-) If you can take the time to grab another debug log, I'll certainly read through it and see if I can spot any more clues. Thanks.
Found my regression, over to you ;-)
Created attachment 55202 [details] 1M lines from the end of Xorg.log
Created attachment 55203 [details] 1M lines from the middle of Xorg.log I also added the part from the middle of the log in case this helps in any way. I did not wait for the video drawing to be stuck, however, the old frame flashed several times (every ~10 seconds) during this session.
Haven't found the issue yet, but I've tackled many of the distasteful things I read in the logs. If you do get the chance to verify that I haven't broken everything again, I'd appreciate it. The information is probably in there, it is just searching for a needle in a haystack. Can you test vlc without compositing to see if the issue still occurs? Otherwise, the rendering sequence looks pretty tame: draw a bunch of rects, draw some video, read back from the gpu, composite over top, repeat ad nauseam. I haven't spotted a variation on that pattern that would suggest a possible cause.
Disabling compositing does indeed work. Apart from that, there are no new issues :).
It's not a fullscreen video by any chance?... I don't think so if I remember the coordinates correctly.
Yes, the logs are taken from when vlc was in windowed mode.
I don't know if it is of any help but I found a reliable way to trigger this. Moving a window over vlc playing the video stops the frame from changing. This also works if vlc is always-on-top and no window actually covers vlc. I think the window has to be at least about the size of the video part of vlc. What I can say for sure is taking a window multiple times bigger than vlc always triggers the issue.
That sounded easy enough to reproduce, so I dragged the terminal over the top of the vlc video. The frames, they keep on changing.
The video not being redrawn should be an easier condition to spot than a repeated frame amongst hundreds. Do you mind giving --enable-debug=full another shot?
Well, what can I say? After updating to latest master, I haven't encountered the issue, yet. I'm gonna see the next few days whether the bug is indeed fixed or I just was (un)lucky. Nevertheless, thank you very much for your help :).
Today's master broke again, so I did a bisect and it returned that c353a8cfde838b070f3e71d3946f3b40d1d5113a is the bad commit. Do you still need me to take the full blown log? If yes, I'd go for it
Which level of breakage? Occasional time flows backwards or stuck video? So it sounds like I've not handling damage correctly on gen3 video.
Yes, the usual: the occasional old frame flashing and that frame displaying almost continuously when moving a window over it.
Ok, something to test. Can you update, in particular: commit 3d1bba033bc29fdf498dc082f3542c520a5ed39a Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Jan 24 18:22:12 2012 +0000 sna/gen3: Apply damage to video pixmap Reported-by: Paul Neumann <paul104x@yahoo.de> References: https://bugs.freedesktop.org/show_bug.cgi?id=44504 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Yep, it is fixed now.
\o/ I'm happy that we've finally explained the bug. Not so happy that something is triggering a readback and damage tracking, I can hope that's just a random GetImage... Thanks for the bug report and lots of testing.
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.