[PATCH] Add freesync ioctl interface

[Christian König]

Am 08.08.2016 um 09:43 schrieb Michel Dänzer:
> On 04.08.2016 17:22, Christian König wrote:
>> Am 04.08.2016 um 08:41 schrieb Michel Dänzer:
>>> On 03.08.2016 10:04, Dave Airlie wrote:
>>>> On 2 August 2016 at 12:26, Hawking Zhang <Hawking.Zhang at amd.com> wrote:
>>>>> @@ -706,4 +708,17 @@ struct drm_amdgpu_virtual_range {
>>>>>           uint64_t start;
>>>>>           uint64_t end;
>>>>>    };
>>>>> +
>>>>> +/*
>>>>> + * Definition of free sync enter and exit signals
>>>>> + * We may have more options in the future
>>>>> + */
>>>>> +#define AMDGPU_FREESYNC_FULLSCREEN_ENTER                1
>>>>> +#define AMDGPU_FREESYNC_FULLSCREEN_EXIT                 2
>>>>> +
>>>>> +struct drm_amdgpu_freesync {
>>>>> +        __u32 op;                       /*
>>>>> AMDGPU_FREESYNC_FULLSCREEN_ENTER or */
>>>>> +                                        /*
>>>>> AMDGPU_FREESYNC_FULLSCREEN_ENTER */
>>>>> +        __u32 spare[7];
>>>>> +};
>>>>>    #endif
>>>> Isn't freesync meant to be a generic non-driver useful thing?
>>>>
>>>> This should be integrated with atomic modesetting API or just the KMS
>>>> APIs.
>>> I don't see that as required or even particularly useful until there's
>>> an API which apps can use to control variable refresh rate.
>> VDPAU already does this quite well [...]
> By explicitly specifying the earliest presentation time for each frame
> AFAICT? While that seems very flexible, I'm not sure it's particularly
> good for smooth and stable playback. Seems like overriding the refresh
> rate to (a multiple of) the video frame rate might be better for that.

That's what players like Kodi actually do at the moment.

But try to enable it and the do a bit zapping between PAL and NTSC TV 
channels, believe me you are going to hate it with most current display 
devices.

There are only a very few televisions which can do the frame rate switch 
fast enough that you won't either get multiple seconds blackness or a 
rather bad headache in between.

With freesync you can switch between 50Hz, 60Hz or whatever frame rate 
you like without changing the video mode.


>>> The goal
>>> here is merely to allow running existing apps with variable refresh
>>> rate, which just requires some kind of toggle(s) to enable/disable it.
>>>
>>>
>>> That said, I also see some issues with this patch:
>>>
>>> There's a bit of a conflation between "FreeSync" and "fullscreen"
>>> concepts. I think at this point it's really about a sort of an "is
>>> FreeSync allowed?" state rather than about fullscreen.
>> I would say we first of all need a new flag for drm_mode_modeinfo to
>> note if a certain mode is a freesync mode or not and what the min/max
>> parameters are.
>>
>>> It might be nice to track the "is FreeSync allowed?" state per-CRTC, as
>>> I wonder if FreeSync might be useful e.g. for smoother TearFree
>>> operation.
>>>
>>> And if it's just a per-CRTC state, something like an output property
>>> might be more appropriate than a dedicated ioctl.
>> That will obvious work as well, but essentially freesync is a parameter
>> of the video mode in use if I'm not completely mistaken.
> Hmm, that's an interesting point. Enabling FreeSync via special modes
> sounds quite natural from a user POV. Unfortunately, games tend to only
> let the user choose a resolution, not a specific mode.
Who said that games need to be able to enable/disable it in the kernel side?

Maybe take a step back and look at how freesync works:

1. You have a video mode with a certain resolution and the maximum 
refresh rate the display device can handle. Let's say for example 
1920x1080 at 100.

2. Now the vertical blank period of this mode is extended which 
practically lowers the refresh rate to the minimum the display device 
can handle. E.g. you end up with a mode of 1920x1080 at 20 for example.

3. When a page flip arrives while we are in the vertical blank period 
the blank is aborted and the video hardware starts pushing out the new 
frame immediately.

This practically gives you a mode with a dynamic refresh rate between 20 
and 100Hz.

Now when the game requests a fixed frame rate of 30Hz for example the 
kernel doesn't need to know about that, all it needs to know is when to 
do the next flip. E.g. you say always flip at vertical scan line X and 
so you get 30fps.

Regards,
Christian.