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@xxxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
