-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2020-02-07 10:19 p.m., Keith Packard wrote:
> Michel Dänzer 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
-BEGIN PGP SIGNATURE-
iF0EARECAB0WIQSwn681vpFFIZgJURRaga+OatuyAAUCXkEoYwAKCRBaga+Oatuy
AEHbAJ42gnXFAJ1j+znHDt68kS1k+BrrUwCgolxHui7Mqux37yjbfGZMmCUlFGo=
=ZVoG
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
