Re: [PATCH v4 3/4] drm: Document variable refresh properties

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

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

On Fri, 26 Oct 2018 17:34:15 +0000
"Kazlauskas, Nicholas" <Nicholas.Kazlauskas-5C7GfCeVMHo@public.gmane.org> wrote:

> On 10/26/18 10:53 AM, Ville Syrjälä wrote:
> > On Fri, Oct 26, 2018 at 02:49:31PM +0000, Kazlauskas, Nicholas wrote:  
> >> On 10/26/18 7:37 AM, Pekka Paalanen wrote:  

> >>> Hi,
> >>>
> >>> where is the documentation that explains how drivers must implement
> >>> "variable refresh rate adjustment"?
> >>>
> >>> What should and could userspace expect to get if it flicks this switch?
> >>>
> >>> I also think the kernel documentation should include a description of
> >>> what VRR actually is and how it conceptually works as far as userspace
> >>> is concerned.
> >>>
> >>> That is, the kernel documentation should describe what this thing does,
> >>> so that we avoid every driver implementing a different thing. For
> >>> example, one driver could prevent the luminance flickering itself by
> >>> tuning the timings while another driver might not do that, which means
> >>> that an application tested on the former driver will look just fine
> >>> while it is unbearable to watch on the latter.
> >>>
> >>>
> >>> Thanks,
> >>> pq  
> >>
> >> I felt it was best to leave this more on the vague side to not impose
> >> restrictions yet on what a driver must do.
> >>
> >> If you think it's worth defining what the "baseline" expectation is for
> >> userspace, I would probably describe it as "utilizing the monitor's
> >> variable refresh rate to reduce stuttering or tearing that can occur
> >> during flipping". This is currently what the amdgpu driver has enabled
> >> for support. The implementation also isn't much more complex than just
> >> passing the variable refresh range to the hardware.

Hi,

sorry, but that says nothing.

Also, tearing has nothing to do here. VRR reduces stuttering if
userspace is already tear-free. If userspace was driving the display in
a tearing fashion, VRR will not reduce or remove tearing, it just makes
it happen at different points and times. Tearing happens because
framebuffer flips are executed regardless of the refresh cycle, so
adjusting the refresh timings won't help.

However...

> >>
> >> I wouldn't want every driver to be forced to implement some sort of
> >> luminance flickering by default. It's not noticeable on many panels and
> >> any tuning would inherently add latency to the output. It would probably
> >> be better left as a new property or a driver specific feature.

The point is to give userspace guaranteed expectations. If the
expectation is that some displays might actually emit bad luminance
flickering, then userspace must always assume the worst and implement
the needed slewing algorithms to avoid it, even if it would be
unnecessary.

Userspace is farther away from the hardware than the drivers are, and
if userspace is required to implement luminance flickering avoidance,
that implementation must be done in all display servers and KMS apps
that might enable VRR. That would also call for a userspace hardware
database, so that people can set up quirks to enable/disable/adjust the
algorithms for specific hardware with the hopes that other users could
then have a good out-of-the-box experience. Instead, if possible, I
would like to see some guarantees from the kernel drivers that
userspace does not need to worry about luminance flickering.

Unless you would deem all hardware that can exhibit luminance
flickering as faulty and unsupported?

We need a baseline default expectation. You can modify that expectation
later with new properties, but I believe something needs to be defined
as the default. Even if the definition is really just "hardware takes
care of not flickering".

> >>
> >> In general I would imagine that most future VRR features would end up as
> >> new properties. Anything that's purely software could be implemented as
> >> a drm helper that every driver can use. I think the target presentation
> >> timestamp feature is a good example for that.  
> > 
> > Speaking of timestamps. What is the expected behaviour of vblank
> > timestamps when vrr is enabled?
> >  
> 
> When vrr is enabled the duration of the vertical front porch will be
> extended until flip or timeout occurs. The vblank timestamp will vary
> based on duration of the vertical front porch. The min/max duration for
> the front porch can be specified by the driver via the min/max range.

...This is actually useful information, it explains things. Do all VRR
hardware implementations fundamentally work like this?

With that definition, there is only more parameter to be exposed to
userspace in the future: what is the length of the timeout? No need to
expose maximum-refresh-freq because that information is already present
in the programmed video mode.

Btw. even this definition does not give any hint about problems like
the luminance flickering. If possible flickering is an issue that
cannot be simply ignored, then something should be documented about it.

Do you know of any other "hidden" issues that could require userspace
or drivers to be careful in how it will drive VRR?


Thanks,
pq

> No changes to vblank timestamping handling should be necessary to
> accommodate variable refresh rate.
> 
> I think it's probably best to update the documentation for vrr_enable 
> with some of the specifics I described above. That should help clarify 
> userspace expectations as well.
> 
> Nicholas Kazlauskas


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