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

[Daniel Vetter]

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:
> > Hi all,
> > 
> > I just sent out a patch that enables FreeSync in Mesa for the somewhat
> > hacked implementation of FreeSync that exists in our hybrid (amdgpu-pro)
> > stack's DDX and kernel module. [0]
> > 
> > While this patch isn't meant for upstream, that's as good a time as any
> > to raise the issue of how a proper upstream solution would look like. It
> > needs to cut across the entire stack, and we should try to align the KMS
> > interface with the X11 protocol and the Wayland protocol.
> > 
> > Prior art that I'm aware of includes:
> > 
> > 1. The Present protocol extension has a PresentOptionUST bit for
> > requesting a specific present time, but the reality is that the
> > implementation of that is even less than what the protocol docs claim. [1]
> 
> FWIW, I do think this could be a good way for clients to signal that
> they want a frame to be displayed ASAP. It would also allow for e.g.
> video players to naturally adapt the refresh rate to the video frame
> rate (the VDPAU presentation API has a target timestamp for this).
> 
> 
> > 3. Keith Packard's CRTC_{GET,QUEUE}_SEQUENCE is not specific to Adaptive
> > Sync, but seems like something Adaptive Sync-aware applications would
> > want to use. [2]
> 
> Not sure I can agree with that. Applications should use higher level
> APIs, not low level ones like these directly. (Also, they're basically
> just KMS variants of DRM_IOCTL_WAIT_VBLANK, not directly related to
> adaptive sync)

+1.

We already accidentally exposed the legacy vblank ioctl to clients, and
they abuse it badly (second-guessing the compositor, which works so well).
If you're a client app and want timings, you must query the compositor.
Neither the client nor the kernel know enough to make this happen
directly.

Ofc the compositor will want to query timings through ioctls, but we
provide them all already (flip timestamp and vblank timestamp), Keith's
new ioctl simply provides a bit of an uapi cleanup + nanosecond accuracy
(not that any driver can do that anyway right now).

> > 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.

I think a boolean enable_freesync property is probably what we want, which
enables freesync for as long as it's set.

The other side is communicating to userspace which modes are freesync
capable. We might want to extend the mode struct with a min/max vrefresh
rate, or something similar.

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.

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.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch