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

[Nicolai Hähnle]

On 17.10.2017 12:28, 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).

Agreed. The point is that a lot of implementation work needs to be done, 
and the protocol docs need to be fixed (the doc claims that every 
implementation will treat PresentOptionUST reasonably, rounding to the 
nearest MSC when PresentCapabilityUST is missing, but that's false as 
far as I can tell).


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

Time for xf86-video-amdgpu to grow atomic support, then? ;)

How is a target vblank count communicated via the atomic API? Or is that 
simply not part of the design and up to user space?

Cheers,
Nicolai
-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.