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
