[PATCH] present: Fix Async swap logic

[Michel Dänzer]

On 05.11.2015 12:05, Michel Dänzer wrote:
> On 05.11.2015 01:51, davyaxel at free.fr wrote:
>> On 04/11/2015 11:01, Chris Wilson wrote:
>>> On Wed, Nov 04, 2015 at 10:48:40AM +0100, Axel Davy wrote:
>>>>
>>>> . Why you check for Async flips first (isn't sync flips better when
>>>> possible) ?
>>>
>>> The choice is between using native async flips or emulating them through
>>> sync flips. Native wins.
>>>  
>>
>> Ok, I think I see to what you refers. I don't know enough of hardware to
>> know if that generalises to other hardware. Also if the async flip is
>> triggered too late, you'd get a tear (though I guess we are very
>> unlikely to be that late). As I expect sync flip emulation with async
>> flips to be very lightweight, I guess it doesn't hurt to try it first.
>> But I'm ok to favor Async if you think we should.
> 
> I think we should:
> 
> If we schedule a sync flip for crtc_msc+1, there's a chance that it'll
> actually miss that and only take effect on crtc_msc+2 (if we're already
> towards the end of the crtc_msc frame). It's probably very unlikely to
> happen, but if an unlucky client triggers that for every frame, this
> would effectively halve the visible frame update rate. But the client
> specifying PresentOptionAsync indicates it would rather risk tearing
> instead.

Hmm. OTOH in a multi-monitor setup, an async flip is likely to tear on
all monitors but the one we're synchronizing to. That puts me back on
the fence, unsure which way is better overall. :}

Anyway, I'll give my R-b: for your v2 patch. We can always revisit this
later.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer