[Mesa-dev] Upstream support for FreeSync / Adaptive Sync

[Michel Dänzer]

On 18/10/17 10:10 AM, Daniel Vetter wrote:
> On Tue, Oct 17, 2017 at 09:01:52PM +0200, Nicolai Hähnle wrote:
>> On 17.10.2017 19:16, Daniel Vetter wrote:
>>> On Tue, Oct 17, 2017 at 5:40 PM, Michel Dänzer <michel at daenzer.net> wrote:
>>>> On 17/10/17 05:04 PM, Daniel Vetter wrote:
>>>>> On Tue, Oct 17, 2017 at 03:46:24PM +0200, Michel Dänzer wrote:
>>>>>> On 17/10/17 02:22 PM, Daniel Vetter wrote:
>>>>>>> On Tue, Oct 17, 2017 at 12:28:17PM +0200, Michel Dänzer wrote:
>>>>>>>> On 17/10/17 11:34 AM, Nicolai Hähnle wrote:
>>>>>>>
>>>>>>> Finally I'm not sure we want to insist on a target time for freesync. At
>>>>>>> least as far as I understand things you just want "as soon as possible".
>>>>>>> This might change with some of the VK/EGL/GLX extensions where you
>>>>>>> specify a precise timing (media playback). But that needs a bit more work
>>>>>>> to make it happen I think, so perhaps better to postpone.
>>>>>>
>>>>>> I don't see why. There's an obvious use case for this now, for video
>>>>>> playback. At least VDPAU already has target timestamps for this.
>>>>>>
>>>>>>
>>>>>>> Also note that right now no driver expect amdgpu has support for a target
>>>>>>> vblank on a flip. That's imo another reason for not requiring target
>>>>>>> support for at least basic freesync support.
>>>>>>
>>>>>> I think that's a bad reason. :) Adding it for atomic drivers shouldn't
>>>>>> be that hard.
>>>>>
>>>>> I thought the primary reason for adaptive sync is the adaptive frame rate
>>>>> to cope with the occasional stall in games. If the intended use-case is
>>>>> vr/media, then I agree going with timestamps from the beginning makes
>>>>> sense. That still leaves the "schedule asap, with some leeway" mode. Or is
>>>>> that (no longer) something we want?
>>>>
>>>> Both are use cases for adaptive sync. Both can be covered by a target
>>>> timestamp. There may be other possible solutions which work for both though.
>>>
>>> Hm, how do you make the "flip as soon as ready" semantics work with
>>> timestamps, without requiring userspace to wait for the fences to
>>> signal before submitting? Set the timestamp to now and force the miss?
>>
>> Like I wrote in my reply to Ville, I think it makes sense to always treat
>> stale timestamps as "flip as soon as ready".
> 
> Makes sense, and matches what we do with the vblank target right now. But
> with stuff like VR it might be that we need a window, and when things are
> delayed too much it's better to re-render a newly distorted frame instead
> of motion sickness. We'll see. VR's real tough anyway :-)

I suspect a VR compositor will have to deal with this before submitting
the flip to the kernel, i.e. wait for the frame to finish rendering, and
if it takes too long, render a reprojected frame and flip to that instead.


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