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

[Kazlauskas, Nicholas]

On 10/29/18 4:36 AM, Pekka Paalanen wrote:
> On Fri, 26 Oct 2018 17:34:15 +0000
> "Kazlauskas, Nicholas" <Nicholas.Kazlauskas at amd.com> 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
There are two issues that can manifest when enabling variable refresh 
rate - "stuttering" and luminance flickering. Luminance flickering is
dependent on the panel, but stuttering will occur on anything (and will 
be worse on panels with a wider range). Both of these issues can occur 
for content that flips on demand or at random. The large and frequent 
fluctuations in flip times remove any sort of consistency for user input 
and rendering.

The stuttering is actually the primary reason the mesa patches exist
(with luminance flickering removal being a bonus). Whether variable 
refresh rate should be enabled or not will depend on whether the 
userspace content is appropriate or not.

A skewing algorithm would address both issues but would still make the
user experience worse for those applications. Using a fixed rate for 
consistency is likely still preferable for those applications.

This is why I'd prefer to define a baseline like:

"When the vrr_enable property is set to true for vrr_capable hardware 
the vertical front porch will be extended until either flip or timeout 
occurs.

The vertical front porch timing and timeout duration are determined by 
the driver based on the panel's reported minimum and maximum variable 
refresh range."

The patches don't presently expose the minimum/maximum range but this 
does guarantee bounds.

The inner bounds would then be determined by the driver to allow 
flexibility in implementing algorithms that can improve the user experience.

An example of such an algorithm would be low framerate compensation for 
flip rates below the range. The amdgpu driver has an implementation for 
this that can do frame doubling and tripling for monitors with an 
appropriate range.

You could also implement some sort of skewing for luminance flickering 
reduction for panels that really need it on top of this.

Future properties that utilize variable refresh rate would be compatible 
with this baseline - everything is based on the determination of the 
inner bounds on minimum and maximum refresh.

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

Nicholas Kazlauskas