Upstream support for FreeSync / Adaptive Sync

Nicolai Hähnle nicolai.haehnle at
Tue Oct 17 09:34:42 UTC 2017

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]

2. There's a VK_GOOGLE_display_timing extension which similarly allows 
providing a desiredPresentTime (in ns).

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]

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 

   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.

These two sides then need to be plumbed through the entire stack.

I guess for now the main questions are: Is there more "prior art" that 
we should be aware of? Does anybody have partial prototypes or very 
strong feelings about what the interfaces and protocols should look like?





More information about the dri-devel mailing list