Re: [PATCH] Add freesync ioctl interface

["Christian König" <deathsimple-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>]

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.

I mean we could of course adjust the frame rate the kernel should 
display with each page flip as well, but that certainly isn't how the 
hardware is working now.

>> Mostly the same applies for games as well, e.g. when you render a frame
>> you usually render it for a certain timestamp.
> I can only find the EGL_ANDROID_presentation_time extension providing
> exactly this functionality. GLX_NV_present_video looks like it covers
> this as well, but it also includes a bunch of other stuff.
>
> I think 0 is a good first approximation of the number of applications
> used by an average Linux desktop user which make use of either of those
> extensions.

Yeah, I agree that we don't have proper support for this on Linux 
desktop at the moment. But this is a chicken and egg problem.

The comment that games render a frame for a certain timestamp was more 
on how games usually work internally.

>> Additional to that are you sure it is such a hassle to implement this? I
>> mean let us sum up what we need:
>> 1. A representation for the new mode attributes, e.g. minimum and
>> maximum vertical refresh rate.
>>
>> This is needed anyway to proper communicate the capabilities of the
>> display device to userspace.
>>
>> 2. An extension to the page flip IOCTL to specify when exactly a flip
>> should happen.
>>
>> As far as I can see that is what your patchset already did. The only
>> difference is that you wanted to specify a certain vertical blank when
>> the flip would happen while I would say we should use a monotonic
>> timestamp (64bit ns since boot) for this.
> Right, the patch series you're referring to isn't directly related to this.
>
>
> 3. Expose this new functionality via the X11 Present extension and/or a
> corresponding Wayland extension.
I unfortunately haven't pushed on this, but I already noted to Keith on 
an earlier version of the present extension that we should use a 
timestamps instead of vertical blank counters.

But double checking the present extension, we indeed already have 
support for PresentOptionUST in it. So this should already be there.

> 4. Make use of 3. in the Gallium video state tracker code.
>
> Now we're done for the video playback case, phew!
>
>
> 5. Make use of 3. to implement EGL_ANDROID_presentation_time and/or
> GLX_NV_present_video.
>
> 6. Make game engines use 5.
>
> (A game engine can know when a frame will be ready for presentation when
> it starts rendering it, so I'm not sure this functionality will be very
> useful for games)
>
>
>>> Also, this doesn't address the case of running (existing) games with
>>> variable refresh rate.
>> Sure it does. For the current stack without any change a freesync
>> capable display device just looks like a normal monitor with a high
>> vertical refresh rate.
> You're saying current userspace would just see the maximum vertical
> refresh rate as the refresh rate?

I think so. I mean the minimum is usually rather low, e.g. between 20 
and 30Hz.

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

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.

Regards,
Christian.
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx