[Mesa-dev] [Bug 85203] [DRI2][RadeonSI] Pageflip completion event has impossible msc.

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=85203

--- Comment #5 from Mario Kleiner <mario.kleiner at tuebingen.mpg.de> ---
(In reply to Michel Dänzer from comment #4)
> Mario, any ideas?
> 
> These are possible scenarios I can think of where this could still happen:
> 
> 1. The pflip interrupt triggers before the corresponding vblank interrupt
> 2. The page flip is queued just before the vertical blank period, such that
> it's
>    too late for the corresponding vblank interrupt to trigger, but early
> enough
>    for the flip to complete in the same vertical blank period.
> 3. Race condition when enabling the vblank interrupt, causing the vertical
> blank
>    counter to be off by 1.
> 
> AFAIK 1. shouldn't happen, not sure if 2. can happen.

3. Can't cause this: The ddx calls waitvblank ioctl() while preparing a swap,
to queue a vblank event -> vblank irqs on. They stay on for at least 5 seconds
after queueing and dispatching the vblank event to the server, and it won't
take the server/ddx over 5 seconds from receiving the event to calling the
pflip ioctl, and then the pending flip keeps vblank irqs on until flip
completion. So if there were a off by one bug, it would consistently affect the
flip completion msc and the calculated target_msc used by the check that was
triggered and causing this log message.

2. Don't think this can happen either: vblank irq is enabled before queueing a
flip and vblank irq fires a bit before vblank iirc, and the hw is programmed to
execute and complete pageflips only at leading edge of vblank since Linux 3.16,
so the order of interrupt events in the interrupt ring should be so that the
vblank handler gets called before the corresponding pflip irq handler. Unless
the hw wouldn't fire a vblank irq .

A variation could in theory happen: The vblank irq fires shortly before vblank
(about 2 scanlines iirc) -> msc++ , then a glXSwapBuffers swap gets scheduled,
ddx reads the already incremented msc for the upcoming vblank and bases its
reference value for expected msc on it, queues vblank event to the kernel ->
gets dispatched immediately, triggers the pageflip ioctl and the flip gets
programmed into the hw before leading edge of the upcoming vblank -> flip
completes and delivers a completion msc that's one smaller than the expected
minimum msc -> This warning gets logged. But i don't think this is likely. All
this would have to happen within a tiny time-window of maybe at most 30
microseconds at exactly the right moment, about 2 scanlines before start of
vblank. From tracing this a few month ago, i seem to remember that the sequence
of actions takes longer than 30 usecs.

1. Shouldn't happen if everything works correctly. But if for some reason the
pageflip wouldn't be synchronized to vblank, we'd get a tearing flip and these
warning messages, because the flip might get queued in the middle of the
scanout and then complete immediately and report the msc of the current refresh
cycle, as the pflip irq would execute long before the vblank irq.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20141126/56466212/attachment-0001.html>