Variable Refresh Rate & flickering screens

Variable Refresh Rate & flickering screens

[Simon Ser]

Hi all,

I've been working on adding VRR support to Sway [1] (a Wayland
compositor). The compositor just sets the VRR_ENABLED property.

This works fine for some screens, but causes flcikering for other
screens as expected [2]. Fixing the flickering is something we've
talked about last XDC [3]. The flickering is caused by physical
limitations of the screen: changing the refresh rate too quickly
results in brightness issues.

The approach taken by xf86-video-amdgpu is to only enable VRR if an app
is fullscreen and not present in a special Mesa blacklist (e.g. Firefox
is in the blacklist because it doesn't render at a fixed interval).

For Wayland, I'd prefer to avoid having a blacklist. I'd like to be
able to use VRR in the general case (not just for fullscreen apps).
A way to fix the flickering would be to implement a slew rate and make
it so refresh rate variations are capped by the slew rate.

The main question is: should this be implemented in the kernel or in
user-space?

I personally think it'd make more sense to implement this in the
kernel. This would de-duplicate the slew rate logic between compositors
and would avoid unnecessarily waking up user-space.

Moreover, it seems Intel hardware supports programming a slew rate
directly. To take advantage of this feature the slew rate needs to be
implemented in the kernel.

Harry, what do you think?

Thanks,

Simon

[1]: https://github.com/swaywm/sway/pull/5063
[2]: https://github.com/swaywm/sway/issues/5076
[3]: https://xdc2019.x.org/event/5/contributions/331/
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Variable Refresh Rate & flickering screens

[Michel Dänzer]

On 2020-03-11 9:09 p.m., Simon Ser wrote:
> Hi all,
> 
> I've been working on adding VRR support to Sway [1] (a Wayland
> compositor). The compositor just sets the VRR_ENABLED property.
> 
> This works fine for some screens, but causes flcikering for other
> screens as expected [2]. Fixing the flickering is something we've
> talked about last XDC [3]. The flickering is caused by physical
> limitations of the screen: changing the refresh rate too quickly
> results in brightness issues.
> 
> The approach taken by xf86-video-amdgpu is to only enable VRR if an app
> is fullscreen and not present in a special Mesa blacklist (e.g. Firefox
> is in the blacklist because it doesn't render at a fixed interval).
> 
> For Wayland, I'd prefer to avoid having a blacklist. I'd like to be
> able to use VRR in the general case (not just for fullscreen apps).
> A way to fix the flickering would be to implement a slew rate and make
> it so refresh rate variations are capped by the slew rate.

One potential issue I see with this is the cursor, which can feel
awkward if it only moves at 30 Hz. I wonder if a slew rate which can
reliably prevent flickering allows the framerate to ramp up quickly
enough for this not to be annoying.


-- 
Earthling Michel Dänzer               |               https://redhat.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Variable Refresh Rate & flickering screens

[Simon Ser]

On Thursday, March 12, 2020 11:45 AM, Michel Dänzer <michel@daenzer.net> wrote:

> On 2020-03-11 9:09 p.m., Simon Ser wrote:
>
> > Hi all,
> > I've been working on adding VRR support to Sway [1] (a Wayland
> > compositor). The compositor just sets the VRR_ENABLED property.
> > This works fine for some screens, but causes flcikering for other
> > screens as expected [2]. Fixing the flickering is something we've
> > talked about last XDC [3]. The flickering is caused by physical
> > limitations of the screen: changing the refresh rate too quickly
> > results in brightness issues.
> > The approach taken by xf86-video-amdgpu is to only enable VRR if an app
> > is fullscreen and not present in a special Mesa blacklist (e.g. Firefox
> > is in the blacklist because it doesn't render at a fixed interval).
> > For Wayland, I'd prefer to avoid having a blacklist. I'd like to be
> > able to use VRR in the general case (not just for fullscreen apps).
> > A way to fix the flickering would be to implement a slew rate and make
> > it so refresh rate variations are capped by the slew rate.
>
> One potential issue I see with this is the cursor, which can feel
> awkward if it only moves at 30 Hz. I wonder if a slew rate which can
> reliably prevent flickering allows the framerate to ramp up quickly
> enough for this not to be annoying.

Thanks for pointing this out, that's a valid concern.

My VRR monitor has a 40-60Hz VRR range. With the current Sway
implementation and drm_monitor [1], I can check that moving my mouse on
the monitor makes the refresh interval go from ~25ms to ~16.6ms (ie.
40Hz to 60Hz). Right now there's no slew rate, so it goes from min to
max instantly. I don't notice any flickering and there's no lag.

Looking at the list of monitors [2] on Wikipedia, it doesn't seem like
there's any monitor supporting less than 35Hz.

We'd need to perform experiments on more hardware, but flickering has
been noticed by our users on higher-end monitors which support 144Hz.
I think the slew rate would prevent going from 35Hz to 144Hz directly,
but probably not from 40Hz to 60Hz. I think that would be acceptable.

If it's not, we can always tweak the minimum refresh rate.

tl;dr need to test on more hardware, but should probably be fine.

[1]: https://github.com/emersion/drm_monitor
[2]: https://en.wikipedia.org/wiki/FreeSync#List_of_supported_monitors
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Variable Refresh Rate & flickering screens

[Harry Wentland]

On 2020-03-12 7:25 a.m., Simon Ser wrote:
> On Thursday, March 12, 2020 11:45 AM, Michel Dänzer <michel@daenzer.net> wrote:
> 
>> On 2020-03-11 9:09 p.m., Simon Ser wrote:
>>
>>> Hi all,
>>> I've been working on adding VRR support to Sway [1] (a Wayland
>>> compositor). The compositor just sets the VRR_ENABLED property.
>>> This works fine for some screens, but causes flcikering for other
>>> screens as expected [2]. Fixing the flickering is something we've
>>> talked about last XDC [3]. The flickering is caused by physical
>>> limitations of the screen: changing the refresh rate too quickly
>>> results in brightness issues.
>>> The approach taken by xf86-video-amdgpu is to only enable VRR if an app
>>> is fullscreen and not present in a special Mesa blacklist (e.g. Firefox
>>> is in the blacklist because it doesn't render at a fixed interval).
>>> For Wayland, I'd prefer to avoid having a blacklist. I'd like to be
>>> able to use VRR in the general case (not just for fullscreen apps).
>>> A way to fix the flickering would be to implement a slew rate and make
>>> it so refresh rate variations are capped by the slew rate.
>>
>> One potential issue I see with this is the cursor, which can feel
>> awkward if it only moves at 30 Hz. I wonder if a slew rate which can
>> reliably prevent flickering allows the framerate to ramp up quickly
>> enough for this not to be annoying.
> 
> Thanks for pointing this out, that's a valid concern.
> 
> My VRR monitor has a 40-60Hz VRR range. With the current Sway
> implementation and drm_monitor [1], I can check that moving my mouse on
> the monitor makes the refresh interval go from ~25ms to ~16.6ms (ie.
> 40Hz to 60Hz). Right now there's no slew rate, so it goes from min to
> max instantly. I don't notice any flickering and there's no lag.
> 
> Looking at the list of monitors [2] on Wikipedia, it doesn't seem like
> there's any monitor supporting less than 35Hz.
> 
> We'd need to perform experiments on more hardware, but flickering has
> been noticed by our users on higher-end monitors which support 144Hz.
> I think the slew rate would prevent going from 35Hz to 144Hz directly,
> but probably not from 40Hz to 60Hz. I think that would be acceptable.
> 
> If it's not, we can always tweak the minimum refresh rate.
> 
> tl;dr need to test on more hardware, but should probably be fine.

Not the main VRR expert and we're still discussing this internally but I
think it'll very much depend on the display whether you'll see flicker
in this case.

The other complication is that for gaming we don't want to use the
cursor as a VRR trigger and only look at page flips in order to allow
for smooth gameplay. For a desktop use-case that's probably not the
right policy.

Harry

> 
> [1]: https://github.com/emersion/drm_monitor
> [2]: https://en.wikipedia.org/wiki/FreeSync#List_of_supported_monitors
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Variable Refresh Rate & flickering screens

[Simon Ser]

On Thursday, March 12, 2020 3:43 PM, Harry Wentland <hwentlan@amd.com> wrote:

> Not the main VRR expert and we're still discussing this internally but I
> think it'll very much depend on the display whether you'll see flicker
> in this case.
>
> The other complication is that for gaming we don't want to use the
> cursor as a VRR trigger and only look at page flips in order to allow
> for smooth gameplay. For a desktop use-case that's probably not the
> right policy.

I think user-space can handle this and correctly synchronize cursor
updates with game updates via the KMS atomic API.

However I still think flickering should be avoided by the hardware.
Flickering is a completely separate issue and user-space shouldn't add
workarounds for screen issues like this.

Do you think that would be acceptable? Do you have any "slew rate
register" in AMD hardware?

Thanks,

Simon
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Variable Refresh Rate & flickering screens

[Harry Wentland]

On 2020-03-17 5:08 a.m., Simon Ser wrote:
> On Thursday, March 12, 2020 3:43 PM, Harry Wentland <hwentlan@amd.com> wrote:
> 
>> Not the main VRR expert and we're still discussing this internally but I
>> think it'll very much depend on the display whether you'll see flicker
>> in this case.
>>
>> The other complication is that for gaming we don't want to use the
>> cursor as a VRR trigger and only look at page flips in order to allow
>> for smooth gameplay. For a desktop use-case that's probably not the
>> right policy.
> 
> I think user-space can handle this and correctly synchronize cursor
> updates with game updates via the KMS atomic API.
> 
> However I still think flickering should be avoided by the hardware.
> Flickering is a completely separate issue and user-space shouldn't add
> workarounds for screen issues like this.
> 
> Do you think that would be acceptable? Do you have any "slew rate
> register" in AMD hardware?
> 

There are no slew rate registers in current AMD HW but I also think
slewing would best be done in kernel space, either directly in HW by HW
that supports it or in SW for HW that doesn't support it.

Harry

> Thanks,
> 
> Simon
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Variable Refresh Rate & flickering screens

[Manasi Navare]

On Tue, Mar 17, 2020 at 09:25:33AM -0400, Harry Wentland wrote:
> 
> 
> On 2020-03-17 5:08 a.m., Simon Ser wrote:
> > On Thursday, March 12, 2020 3:43 PM, Harry Wentland <hwentlan@amd.com> wrote:
> > 
> >> Not the main VRR expert and we're still discussing this internally but I
> >> think it'll very much depend on the display whether you'll see flicker
> >> in this case.
> >>
> >> The other complication is that for gaming we don't want to use the
> >> cursor as a VRR trigger and only look at page flips in order to allow
> >> for smooth gameplay. For a desktop use-case that's probably not the
> >> right policy.
> > 
> > I think user-space can handle this and correctly synchronize cursor
> > updates with game updates via the KMS atomic API.
> > 
> > However I still think flickering should be avoided by the hardware.
> > Flickering is a completely separate issue and user-space shouldn't add
> > workarounds for screen issues like this.
> > 
> > Do you think that would be acceptable? Do you have any "slew rate
> > register" in AMD hardware?
> >

In case of Intel HW, we do have a way to program the maxshift so the max increment or
decrement in the vblank in successive frames. This is designed to be used for
the displays that  have a restriction on the maximum change in refresh rate between two consecutive frames.

But I am still figuring out how the panel indicates this restriction that we need to program
in the HW registers.

Harry/SImon, do you know of any such panels that have these restrictions and if they
indicate this limitation or the maxshift through EDID or DPCD?

Manasi
 
> 
> There are no slew rate registers in current AMD HW but I also think
> slewing would best be done in kernel space, either directly in HW by HW
> that supports it or in SW for HW that doesn't support it.
> 
> Harry
> 
> > Thanks,
> > 
> > Simon
> > 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Variable Refresh Rate & flickering screens

[Simon Ser]

On Wednesday, March 25, 2020 7:53 PM, Manasi Navare <manasi.d.navare@intel.com> wrote:

> But I am still figuring out how the panel indicates this restriction that we need to program
> in the HW registers.
>
> Harry/SImon, do you know of any such panels that have these restrictions and if they
> indicate this limitation or the maxshift through EDID or DPCD?

As far as I've understood, there is no such information exposed by the
connector. This is the main annoying thing with this slew rate: it
seems like we can only guess what slew rate to pick.

Hence Martin's proposal to add some properties to allow user-space to
tune this (with sane default values that work on most screens).

Another idea is to have a hwdb of "bad VRR screens", and only apply
a slew rate to these screens.

Not sure what the best would be yet. Having a lot of VRR screens to
test with could help getting a better understanding. I think AMD has a
certification program for FreeSync, maybe they have a flickering
requirement? (Something like "screen must not flicker if rate increases
or decreases by XXX Hz each vblank"?)

Simon
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel