[PATCH] Add freesync ioctl interface

Wed Aug 10 03:19:19 UTC 2016

On 09/08/16 07:44 PM, Christian König wrote:
> Am 09.08.2016 um 12:03 schrieb Michel Dänzer:
>> On 09/08/16 06:31 PM, Christian König wrote:
>>> Am 09.08.2016 um 10:27 schrieb Michel Dänzer:
>>>> On 09/08/16 05:12 PM, Christian König wrote:
>>>>> Am 09.08.2016 um 04:44 schrieb Michel Dänzer:
>>>>>
>>>>>> I was basically thinking out loud that doing this via different modes
>>>>>> might be quite natural, *if* games allowed choosing a specific mode.
>>>>>> But unfortunately they don't. For the video playback case, how do you
>>>>>> envision the video player app communicating the refresh rate of the
>>>>>> currently playing video to the kernel?
>>>>> Again the kernel doesn't need to know the refresh rate. All the kernel
>>>>> needs to know is when to do the page flip.
>>>>>
>>>>> So coming back to my example of a mode with 1920x1080 and 20-100Hz
>>>>> refresh rate a classic modeline would then look something like this:
>>>>>
>>>>> Modeline "1920x1080_dynamic"  302.50  1920 2072 2280 2640  1080 1083
>>>>> 1088 5735 -hsync +vsync
>>>>>
>>>>> Note the high vertical total scan lines. Those basically reduce the
>>>>> refresh rate from 100Hz (which this mode normally would have) down to
>>>>> only 20Hz.
>>>>>
>>>>> Now what userspace does on each page flip is specifying when this flip
>>>>> should happen, e.g. when the frame should be started to be scanned
>>>>> out.
>>>>> We can either specify this as frame counter + vertical line of the
>>>>> previous frame or as something like CLOCK_MONOTONIC (I think I would
>>>>> prefer CLOCK_MONOTONIC, but that's not a strong opinion).
>>>>>
>>>>> In other words you put the whole concept upside down. It's no
>>>>> longer the
>>>>> kernel which tells userspace when a vblank happened, but rather
>>>>> userspace tells the kernel when it should happen (together with the
>>>>> frame that should be displayed then).
>>>> I guess that could work. Do video players set the VDPAU presentation
>>>> time accurately enough for this?
>>> Yes, of course. We actually get a precise time stamp from the
>>> application and need to calculate on which vblank to display it from
>>> that.
>>>
>>>> This would require extensive changes across the stack though, when more
>>>> or less the same result could be achieved by just letting the kernel
>>>> know what the current refresh rate is supposed to be, e.g. via output
>>>> properties.
>>> The problem is that you don't have a refresh rate any more.
>> Maybe not below the video decoding API level, but the video player app
>> certainly knows the refresh rate?
> 
> Sure, but as I said that isn't a constant refresh rate any more.
> 
> E.g. the refresh rate from the video header doesn't need to be a
> multiple of the time a vertical line takes to display.
> 
> This results in sightly different display times for each frame. So you
> don't have a constant frame rate any more but rather alternate between
> two (or maybe more) different display times for each frame.

And do you think we'll be able to program flips that accurately?

>>> When we add freesync support we just extend vblank_mode with a new enum
>>> to enable it optionally for existing applications.
>> "Just"... this will only be possible after the first 3 steps above.
> 
> Checking the present extension again we already got PresentOptionAsync
> in there as well.
> 
> So the whole thing boils down implementing a new vblank_mode enume which
> sets PresentOptionAsync and then doing the right thing on the X side
> with those information.

PresentOptionAsync isn't for this. It's for not waiting for the vertical
blank period before performing a flip, which may result in tearing. This
distinction still applies with variable refresh rate, so this option
cannot be re-purposed to distinguish between variable and fixed refresh
rate.

BTW, the only presentation time we can use for the vblank_mode override
is "now" / "as soon as possible". So for that case (which is currently
the case for basically all games, and will likely continue to be for the
vast majority for a long time), the whole exercise doesn't provide any
net benefit over using the existing vblank-based presentation
infrastructure and just force-enabling variable refresh rate somehow.

Note that I'm not questioning the value of time-based presentation for
video playback, and thus the need to implement it. I'm only questioning
the point of delaying variable refresh rate for games by gating it on
the time-based presentation infrastructure.

> I'm going to give the UST option a try with VDPAU, let's see how well
> that works and if it is implemented correctly or not.

It's not implemented at all yet.

BTW, it probably doesn't make sense to add support for time-based
presentation to the pre-atomic KMS API. So another item to add to the
list is adding support for the atomic KMS API to the DDX drivers.

-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer