Re: [PATCH] Add freesync ioctl interface

2016-08-10 Thread Christian König 

Am 10.08.2016 um 05:19 schrieb Michel Dänzer:

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:
[SNIP]
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?


Yes, why not?

Even if the hardware can't do the flip at a specific vblank position 
(which as far as I know our hardware can) we can still use an HR timer 
for this.






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.


Ok that makes sense. But we can still use PresentOptionUst for 
controlling this.


E.g. when you want to display a frame as fast as you can we send the 
PresentOptionUst flag and a zero timestamp (or in general something in 
the past/now).


When we want a constant frame rate of some value we send the 
PresentOptionUst flag and a monotonic increasing timestamp when the 
frame should be displayed.



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.


Sure it does. My basic problem here is that just force-enabling it 
somehow is a really crude hack to just get it working fast and doesn't 
represent at all how the underlying hardware works.


This surely will get us into problems when we move forward because of 
the required backward compatibility. Or isn't an output property 
something we want to keep for backward compatibility?


Additional to that my fear is that when we allow such a flawed design in 
once at least the closed source driver will try to stick with that. 
Making things like DAL even harder to get merged upstream.



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.


Yeah, unfortunately. Leo already tried it and it is indeed not 
implemented at all.


But at least we don't need to extend the spec in any way.


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.


struct drm_mode_crtc_page_flip is used only as an IOCTL parameter with 
size checks as far as I can see. So we could extend the structure 
without breaking backward compatibility.


But I agree that using the atomic API would indeed be a good idea here.

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

Re: [PATCH] Add freesync ioctl interface

2016-08-10 Thread Ernst Sjöstrand 
I thought I'd add some notes as a someone who also plays games on Windows
with Freesync...

I have a 4K monitor with Freesync, the range is 45 to 60 Hz. It might
sounds narrow but it allows you
to have a smooth experience even at very high resolutions and settings. If
the game can't hit 60 fps
exactly it's still fine, it seems smooth and you don't get tearing.
This is shown in all games as a 60 Hz monitor even though Freesync is
enabled.

In the Windows gaming world there's a couple of different combinations at
play:

1) Vsync disabled.
The game renders frames simply as fast as it can. If the fps is below 45 I
get tearing.
If it's above 60 I get tearing. Not very good solution.

2) Vsync enabled.
Fps stays capped to 60, so no tearing on that end. Also 50 fps is smooth
and uses Freesync fine.
This is AFAIK done behind the scene by the AMD DX11 implementation and not
something the game
is involved in.
If fps goes below 45 it starts locking to 30 fps instead, not so nice.

3) Vsync disabled + AMD Frame Rate Target Control (FRTC).
You set FRTC to 1-2 fps below your max refresh rate. That means that if fps
goes below 45 you get
tearing (at 45 Hz refresh or 60?), but at least it renders frames as fast
as it can in that case still. This is a
solution many people like. However FRTC doesn't work all the time.

Regards
//Ernst

2016-08-10 9:49 GMT+02:00 Michel Dänzer :

> On 10/08/16 12:19 PM, Michel Dänzer wrote:
> > 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:
> 
>  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.
>
> Also, we still haven't covered how a variable refresh rate mode would
> actually get set in this case, assuming it can't be set all the time
> (because either there is no compositor, or it doesn't use OpenGL, or it
> doesn't work well with variable refresh rate).
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] Add freesync ioctl interface

2016-08-09 Thread 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?


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


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

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?


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


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] Add freesync ioctl interface

2016-08-09 Thread Christian König 

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. E.g. taking 
video playback as an example, the information you got here is that a 
certain frame should be displayed at a certain timestamp.


Since our minimum granularity is still a vertical refresh line you 
usually alternate between two or three different vertical positions when 
you start with the next frame.


Mostly the same applies for games as well, e.g. when you render a frame 
you usually render it for a certain timestamp.


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.



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.


When we add freesync support we just extend vblank_mode with a new enum 
to enable it optionally for existing applications.


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

RE: [PATCH] Add freesync ioctl interface

2016-08-02 Thread Deucher, Alexander 
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Zhang, Hawking
> Sent: Tuesday, August 02, 2016 12:14 AM
> To: Michel Dänzer
> Cc: amd-gfx@lists.freedesktop.org
> Subject: RE: [PATCH] Add freesync ioctl interface
> 
> The kernel branch has already merged the ioctl implementation. I'm okay to
> keep it internal although.

The kernel bits are in dal.  You can see them publically in my public mirror of 
amd-staging-4.6 IIRC.

Alex

> 
> 
> Regards,
> Hawking
> 
> -Original Message-
> From: Michel Dänzer [mailto:mic...@daenzer.net]
> Sent: Tuesday, August 02, 2016 11:32
> To: Zhang, Hawking <hawking.zh...@amd.com>
> Cc: amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] Add freesync ioctl interface
> 
> On 02.08.2016 12:12, Zhang, Hawking wrote:
> > The implementation is as [PATCH] Enable/disable freesync when
> > enter/exit fullscreen game.
> 
> I mean an implementation of the ioctl in the kernel driver.
> 
> 
> P.S. Please run the following command in each Git repository, so that the
> [PATCH] prefix includes which repository a patch is for:
> 
>  git config format.subjectprefix "PATCH $(basename $PWD)"
> 
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH] Add freesync ioctl interface

2016-08-01 Thread Zhang, Hawking 
The implementation is as [PATCH] Enable/disable freesync when enter/exit 
fullscreen game. Please take a review

Regards,
Hawking

-Original Message-
From: Michel Dänzer [mailto:mic...@daenzer.net] 
Sent: Tuesday, August 02, 2016 11:11
To: Zhang, Hawking <hawking.zh...@amd.com>
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] Add freesync ioctl interface


This cannot go upstream without an implementation making use of it.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] Add freesync ioctl interface

2016-08-01 Thread Michel Dänzer 

This cannot go upstream without an implementation making use of it.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx