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: > >>> Common sense suggests that there need to be two side to FreeSync / VESA >>> Adaptive Sync support: >>> >>> 1. Query the display capabilities. This means querying minimum / maximum >>> refresh duration, plus possibly a query for when the earliest/latest >>> timing of the *next* refresh. >>> >>> 2. Signal desired present time. This means passing a target timer value >>> instead of a target vblank count, e.g. something like this for the KMS >>> interface: >>> >>> int drmModePageFlipTarget64(int fd, uint32_t crtc_id, uint32_t fb_id, >>> uint32_t flags, void *user_data, >>> uint64_t target); >>> >>> + a flag to indicate whether target is the vblank count or the >>> CLOCK_MONOTONIC (?) time in ns. >> >> drmModePageFlip(Target) is part of the pre-atomic KMS API, but adapative >> sync should probably only be supported via the atomic API, presumably >> via output properties. > > +1 > > At least now that DC is on track to land properly, and you want to do this > for DC-only anyway there's no reason to pimp the legacy interfaces > further. And atomic is soooooo much easier to extend. > > The big question imo is where we need to put the flag on the kms side, > since freesync is not just about presenting earlier, but also about > presenting later. But for backwards compat we can't stretch the refresh > rate by default for everyone, or clients that rely on high precision > timestamps and regular refresh will get a bad surprise. The idea described above is that adaptive sync would be used for flips with a target timestamp. Apps which don't want to use adaptive sync wouldn't set a target timestamp. > I think a boolean enable_freesync property is probably what we want, which > enables freesync for as long as it's set. The question then becomes under what circumstances the property is (not) set. Not sure offhand this will actually solve any problem, or just push it somewhere else. > 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. -- 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
