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