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>
