On 2025-09-18 04:33, Tseng, Chuan Yu (Max) wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> On 9/16/25 4:56 PM, Xaver Hugl wrote:
>> Am Mo., 15. Sept. 2025 um 17:49 Uhr schrieb Michel Dänzer
>> <[email protected]>:
>>> On 15.09.25 17:37, Derek Foreman wrote:
>>>> On 9/15/25 5:01 AM, Michel Dänzer wrote:
>>>>> On 12.09.25 15:45, Derek Foreman wrote:
>>>>>> On 9/12/25 2:33 AM, Chuanyu Tseng wrote:
>>>>>>> Introduce a DRM interface for DRM clients to further restrict the
>>>>>>> VRR Range within the panel supported VRR range on a per-commit
>>>>>>> basis.
>>>>>>>
>>>>>>> The goal is to give DRM client the ability to do frame-doubling/
>>>>>>> ramping themselves, or to set lower static refresh rates for
>>>>>>> power savings.
>>>>>> I'm interested in limiting the range of VRR to enable HDMI's
>>>>>> QMS/CinemaVRR features - ie: switching to a fixed rate for media
>>>>>> playback without incurring screen blackouts/resyncs/"bonks" during the
>>>>>> switch.
>>>>>>
>>>>>> I could see using an interface such as this to do the frame rate
>>>>>> limiting, by setting the lower and upper bounds both to a media file's
>>>>>> framerate. However for that use case it's not precise enough, as video
>>>>>> may have a rate like 23.9760239... FPS.
>>>>>>
>>>>>> Would it be better to expose the limits as a numerator/denominator pair
>>>>>> so a rate can be something like 24000/1001fps?
>>>>> I was thinking the properties could allow directly specifying the minimum
>>>>> and maximum number of total scanlines per refresh cycle, based on the
>>>>> assumption the driver needs to program something along those lines.
>>>> Surprisingly, this would also not be precise enough for exact media
>>>> playback, as the exact intended framerate might not result in an integer
>>>> number of scan lines. When that happens a QMS/CinemaVRR capable HDMI
>>>> source is expected to periodically post a frame with a single extra scan
>>>> line to minimize the error.
>>> Interesting, maybe your suggestion of numerator / denominator properties is
>>> better then.
>> API wise, I'd much prefer just using nanoseconds instead of two
>> properties that compositors will in practice just use the same way.
>
>> Yeah, I hear you. Period is generally much nicer than frequency, and every
>> other time I'd unconditionally agree, but QMS is awkward in this regard.
>>
>> The media file I start with will have a fraction specified in integers for
>> the rate, eg: something like 24000/1001 fps. That will map to an index in an
>> array of QMS blessed target framerates (24000/1001, 24, 25, 48/1001, 48...)
>> and the index ends up in a bitfield in the HDMI QMS infoframe. That
>> infoframe also has a bit to indicate that the framerate is currently
>> constant, with constant defined as "constant number of scanlines but may be
>> exactly 1 scanline longer occasionally".
>>
>> In the constant state we'd need to maintain that fixed rate within that
>> constraint, and the integer math to do that needs to start from 24000/1001.
>>
>> So if we used a nanosecond period for the interface, we'd need to take the
>> media file's values and convert them to nanoseconds, then in the kernel
>> convert back to something like milliframes per second (so we could get
>> something near 23976), then look that up in the QMS accepted rates array,
>> have some manner of epsilon to decide if we're close enough to one of them
>> to use it, and then use the integer representation (back to 24000/1001) to
>> setup the scanline temporal dithering algorithm to do the +1 extra line
>> every few frames to hit the exact rate.
>>
>> In effect we'd throw away the precise values we started with and try to
>> reconstruct them later.
>>
>> QMS also has the added strange feature of being able to set a fixed rate
>> below the display's normal VRR minimum, so I'm undecided as to whether this
>> range control interface is an ideal match for setting up QMS anyway, or
>> whether I should propose a separate fixed rate property later. I just don't
>> want to ignore this discussion and show up proposing another non-orthogonal
>> property later.
Static video/desktop frame rates was indeed one of the motivations for
proposing this API, so it is worth discussing.
For amdgpu (and I think most HW are like this), hardware VRR granularity is at
# of total vertical scanlines (vtotal). So if that isn't precise enough, then
the driver will have to do record-keeping to alternate between some vtotal and
vtotal+1 to avoid drift.
It's not impossible to do, though I'm not sure at what point the driver is
considered to be doing "unexpected adjustments of refresh rate", which was
something we were also trying to address with this new API. Today, drivers are
free to do unexpected things with the vtotal, such as frame-doubling to handle
rates below the supported vrr min, and frame-ramping to prevent panel flicker.
We discussed at the display hackfest that this was not something compositors
liked, and that compositors would like to handle that themselves.
Now, memory fails me, and I don't remember the exact motivation for why
compositors want transparent vrr control. Was it because of unexpected
driver-reported vblank timestamps messing with compositor internal record
keeping? Or something else entirely?
Another way of putting it: Would the compositor rather:
1. Specify a min_vtotal + 1 == max_vtotal so driver doesn't do any unexpected
adjustments out of the specified range, or
2. Specify a min_frame_ns == max_frame_ns (or some other highly-precise unit),
and have driver correct for drift by alternating between two vtotals, and hence
adjust refresh rate beyond the specified range?
>>
>> Sorry to be speaking in hypotheticals, I do have a working QMS
>> implementation to share soonish, it's just not quite ready for review yet...
>
> Thanks for the input. For the QMS support, it's related to HDMI 2.1 spec.
> From my knowledge, it's not open to everyone.
> We might sperate this QMS support into different discussions.
>
> To support FPS/1.001, I think we can augment 1 more property in this patch,
> once it's set, we can divide this FPS with 1.001, vise versa.
I think whether we want a separate thing for QMS also depends on what unit we
use for specifying the min/max.
Thanks,
Leo
>
> Thanks,
> --
> Chuanyu.
>
>
