On Mon, Jul 29, 2019 at 7:29 AM Solerman Kaplon <soler...@gmail.com> wrote: > > Às 14:46 de 27/07/2019, Ilia Mirkin escreveu: > > On Sat, Jul 27, 2019 at 7:37 AM Ralph Corderoy <ra...@inputplus.co.uk> > > wrote: > >> The video plays, CPU load is less (my aim), but there's ‘tearing’ of the > >> picture as if small rectangles that are updates are appearing in the > >> wrong location, off by a little. If I step through the frames with > >> mpv's ‘.’ and ‘,’ then I've found a pattern: one frame's picture is > >> good, followed by N bad ones where N is 3 or 7, i.e. every 4th or 8th > >> frame is okay. Don't know if that's a clue or helps someone here > >> recognise a known problem. > <snip> > >> Unfortunately I've never tracked down the cause for this. > >> https://nouveau.freedesktop.org/wiki/VideoAcceleration/ - see note #4. > >> > >> I have, over time, collected some sample videos where this happens in > >> the first few frames. The plan was to do mmt traces of the blob > >> driver, and figure out what it was doing differently. > > <snip> > > I don't really know anything about hw coding, but looking from the outside, it > seems some kind of ring buffer with exact 3 frames maybe intended to work > kinda > like using tripple buffering? I know for once that nvidia works better using > tripple buffering from what I've read from the kwin threads.
The actual decoded images are wrong here -- triple buffering normally refers to how many (image) buffers you hold in the display queue. The deeper the queue, the more you're isolated from render timing. However in this case, the images themselves are bad out of the decoding logic. -ilia _______________________________________________ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
