[RFC] Async flips

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Oct 31, 2012 at 4:23 PM, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
>
>> On Tue, Oct 30, 2012 at 01:33:47PM -0500, Jesse Barnes wrote:
>> > The hw supports async flips through the render ring, so why not expose it?
>> > It gives us one more "tear me harder" option we can use in the DDX and
>> > for other cases where simply flipping to the latest buffer is more
>> > important than visual quality.
>>
>> The only reason I can see why anyone would really want async flips is
>> when you're restricted to double buffering. With triple buffering you
>> should be able to override the previous flip w/o tearing.
>>
>> Well, actually if you use the ring based flips, then you can't do the
>> override. My atomic page flip code can do it because it's using mmio
>> flips. There were also other reasons favoring mmio over ring.
>>
>> Once the atomic code is deemed ready, I would suggest we just nuke the
>> ring based flip code (pun intended).
>
> Yeah, I agree.  In fact one of the first versions of the flip code used
> mmio, and I think it's a better way to go.

How are we gonna sync up with outstanding rendering before issuing the
flip? If the answer is involves enabling the render irq, I'm not gonna
like it ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux