[PATCH] Add freesync ioctl interface

[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 <michel at daenzer.net>:

> 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20160810/dda34220/attachment.html>