Daniel Vetter <daniel@xxxxxxxx> writes: > Quick comments on the i915 kernel part: > - Iirc the w/a database has a bunch of entries about async flips. Those > need to be addressed and annoted with the new w/a tag comment format > Damien recently created. Where does this database live? > - kms_flip needs to be extended to beat on async flips. Obviously the > timing checks don't apply but otherwise I think it won't hurt to enable > all the existing interaction tests with async flips, too. On top of that > I think we should test interactions between async flips and vblank > synced flips. Without the timing checks the other tests will run as fast > as possible, so that should gives us good coverage of the > non-ratelimited nature of async flips - even with vblank flips we've hit > ugly issues by e.g. starving the unpin workers. async flips are still somewhat rate-limited -- the actual buffer flip happens on a scanline boundary instead of a frame boundary, so we still take an interrupt and report an event back to user mode. There are worrying comments in the bspec which say that an async flip queued during vblank may actually take a couple of scanlines *past* the vblank interval before it takes effect. Because of the delay, the code path differences between the two cases are limited to just setting the bits in the hardware, which leaves me fairly confident in our ability to test both cases successfully. > Oh and my little comment about moving all checks into core code is a bit > wrong, we'd still need to check for X-tiling with async flips ofc. From my reading, non-async flips do not have the stride and tiling mode requirements which are currently in the code though. Might be nice to test this? -- keith.packard@xxxxxxxxx
Attachment:
pgpLC6lXaJaiG.pgp
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
