[Mesa-dev] Playing with display timing -- VK_MESA_present_period

Michel Dänzer michel at daenzer.net
Mon Feb 10 09:54:50 UTC 2020

Hash: SHA1

On 2020-02-07 10:19 p.m., Keith Packard wrote:
> Michel Dänzer <michel at daenzer.net> writes:
>> With variable refresh rate, it could certainly be useful for the
>> kernel to have this information as early as possible. It
>> shouldn't make any difference with fixed refresh though, since
>> the kernel should always be able to hit the next refresh in that
>> case as long as the fences for the flip signal in time for
>> vertical blank.
> Although, if the application is mixing present_period and
> display_timing operations, things can still get mixed up -- a frame
> with present_period followed by a frame with display_timing can
> invalidate the computed next frame time. Applications doing that
> may not get the best possible result...

Right. Applications should normally stick to one or the other
extension, not flip-flop between them.

> Ok, it sounds like I should at least go clean up the implementation
> and make it into something not quite so embarrassing to me.
> Going forward, how can we provide this to application developers
> for experimentation? Would we consider including it in a release
> once reviewed within the Mesa community?

I think at least the following needs to happen first:

* At least a prototype of plumbing through this information to the
amdgpu kernel driver (or another one which may grow VRR support) and
making use of it for adjusting the refresh periods to allow hitting
the target as closely as possible.

* At least a prototype of a game engine making use of it to control
the variable refresh rate.

This will allow confirming that this approach actually works and
provides the sought benefit.

- -- 
Earthling Michel Dänzer               |               https://redhat.com
Libre software enthusiast             |             Mesa and X developer


More information about the mesa-dev mailing list