Re: [PATCH v5 2/4] drm: Add vrr_enabled property to drm CRTC

[Pekka Paalanen <ppaalanen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 3805 bytes --]

On Mon, 15 Oct 2018 12:06:52 +0200
Michel Dänzer <michel-otUistvHUpPR7s880joybQ@public.gmane.org> wrote:

> On 2018-10-15 11:47 a.m., Christian König wrote:
> > Am 15.10.2018 um 11:40 schrieb Michel Dänzer:  
> >> On 2018-10-13 7:38 p.m., Christian König wrote:  
> >>> Am 12.10.2018 um 18:44 schrieb Nicholas Kazlauskas:  
> >>>> This patch introduces the 'vrr_enabled' CRTC property to allow
> >>>> dynamic control over variable refresh rate support for a CRTC.
> >>>>
> >>>> This property should be treated like a content hint to the driver -
> >>>> if the hardware or driver is not capable of driving variable refresh
> >>>> timings then this is not considered an error.
> >>>>
> >>>> Capability for variable refresh rate support should be determined
> >>>> by querying the vrr_capable drm connector property.
> >>>>
> >>>> It is worth noting that while the property is intended for atomic use
> >>>> it isn't filtered from legacy userspace queries. This allows for Xorg
> >>>> userspace drivers to implement support.  
> >>> I'm honestly still not convinced that a per CRTC property is actually
> >>> the right approach.
> >>>
> >>> What we should rather do instead is to implement a target timestamp for
> >>> the page flip.  
> >> You'd have to be more specific about how the latter could completely
> >> replace the former. I don't see how it could.  
> > 
> > Each flip request send by an application gets a timestamp when the flip
> > should be displayed.
> > 
> > If I'm not completely mistaken we already have something like that in
> > both DRI2 as well as DRI3.  
> 
> Certainly not DRI2, but for now we're not enabling VRR with that anyway.
> 
> While the X11 Present extension specifies PresentOptionUST for this,
> support for it isn't implemented yet in xserver (as in setting the
> option has no effect, the X server interprets the target value as an MSC
> anyway).
> 
> So this couldn't work before the next major release of xserver, which
> based on recent history could be at least about one year away.

Hi

> In contrast, the CRTC property based solution for the gaming use-case
> can work even with older xserver versions.

This is probably the heaviest reason.

Coming up with a KMS UABI for target timestamps could get complicated.
Do you need a flip queue deeper than one? Do you need to be able to
cancel flips?

> > So as far as I can see we only need to add an extra flag that those
> > information are trust worth in the context of VRR as well.
> > 
> > If we don't set this flag we always get the always working fallback
> > behavior, e.g. VRR is disabled and we have a fixed refresh rate.
> > 
> > If we set this flag and the timestamp is in the past we get the VRR
> > behavior to display the next frame as soon as possible.
> > 
> > If we set this flag and specific a specific timestamp then we get the
> > VRR behavior to display the frame as close as possible to the specified
> > timestamp.  
> 
> Apart from the above, another issue is that this would give direct
> control to the client on whether or not VRR should be used. But we want
> to allow the user to disable VRR even if a client wants to use it, via
> an RandR output property. This requires that the Xorg driver can control
> whether or not VRR can actually be used, via the CRTC property added by
> this patch.

It would not imply direct control to clients. The target timestamps go
through the X server, the X server can mangle them or remove them
before calling KMS any way it wants. The X server can invent a RandR
property to disable/enable VRR.

One would need a video-DDX update the very minimum to start passing the
timestamps to the kernel, so there is no way VRR would be enabled
unwanted.


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx