strange VRR issue on games with newer versions of proton

[hamburg3rz]

So I've found a strange issue with VRR on Jay with newer builds of proton-em 11 and proton-cachyos 11 where Jay seems to adjust my refresh rate incorrectly. I've been able to recreate this bug with all the games that I've tried but this bug doesn't happen on kwin, so I decided to report it here. I'm also using the color pipeline branch of Jay but this bug happens even when color pipelines and direct scanout are turned off.

Overwatch as an example:

• Refresh rate is set to 280hz. Game FPS is capped to 273, and menus are capped to 60.
• When playing on recent builds of proton-em and proton-cachyos the refresh rate remains at 280hz most of the time, not adjusting to my frame cap or frame drops, in the menus it jumps randomly between 80-280hz. Leads to the game feeling like it's stuttering.
• When playing on Proton-EM 10.0-37 the refresh rate correctly adjusts itself around 273hz while in game and lower when the frames drop. It also remains around 60hz in the game menus. Feels smooth to play.

I mentioned this to a winewayland dev who said that VRR has nothing to do with Proton, so I thought I should report here even though it's a strange issue. I'm using a 9070xt gpu and a XG27AQWMG asus monitor.

workingvrr.log
brokenvrr.log

Here are 2 logs from overwatch, I'm not sure if they'll be helpful. Let me know if I can give any other info

[mahkoh]

Those logs don't contain any WAYLAND_DEBUG logs so I don't know what I'm supposed to do with those.

There are a few things that might cause this:

• the application spams frame requests
• the application uses a cursor and you haven't set up the cursor-hz setting
• you have tearing enabled

[hamburg3rz]

apologies here are better logs
brokenvrr2.log
workingvrr2.log

I don't believe it's the applications fault as I've tried many games and they all have strange VRR behaviour on Jay that I don't get with kwin. I also tried with my cursor-hz set to 60 and tearing disabled and the issue is still present. Overwatch doesn't have a cursor in-game so it shouldn't be a problem anyway

[mahkoh]

You can try with https://github.com/Nixola/VRRTest. Run make and then love build/vrrTest.love. On my system Jay and KWin have about the same stability.

[hamburg3rz]

vrr works well with this tool. I also just tried turning off winewayland and just running the games with xwayland and vrr also works fine. so this seems to be just a problem with recent versions of the winewayland driver?

[mahkoh]

I've looked at the broken logs and here was what is happening:

[1734711.958] {overwatch.exe}  -> wl_subsurface#57.set_position(0, 0)
[1734711.965] {overwatch.exe}  -> wl_subsurface#57.place_above(wl_surface#3)
[1734711.967] {overwatch.exe}  -> wp_viewport#55.set_destination(2560, 1440)
[1734711.969] {overwatch.exe}  -> wl_surface#3.commit()
[1734711.980] {mesa vk display queue}  -> wp_linux_drm_syncobj_surface_v1#88.set_acquire_point(wp_linux_drm_syncobj_timeline_v1#68, 0, 495)
[1734711.983] {mesa vk display queue}  -> wp_linux_drm_syncobj_surface_v1#88.set_release_point(wp_linux_drm_syncobj_timeline_v1#97, 0, 495)
[1734711.985] {mesa vk display queue}  -> wl_surface#47.attach(wl_buffer#54, 0, 0)
[1734711.986] {mesa vk display queue}  -> wl_surface#47.damage_buffer(0, 0, 2147483647, 2147483647)
[1734711.988] {mesa vk display queue}  -> wl_surface#47.commit()

This happens for every single frame. All of the commits from the overwatch.exe queue should be removed. They cause full surface damage for wl_surface#3.

[Etaash-mathamsetty]

I've looked at the broken logs and here was what is happening:

[1734711.958] {overwatch.exe}  -> wl_subsurface#57.set_position(0, 0)
[1734711.965] {overwatch.exe}  -> wl_subsurface#57.place_above(wl_surface#3)
[1734711.967] {overwatch.exe}  -> wp_viewport#55.set_destination(2560, 1440)
[1734711.969] {overwatch.exe}  -> wl_surface#3.commit()
[1734711.980] {mesa vk display queue}  -> wp_linux_drm_syncobj_surface_v1#88.set_acquire_point(wp_linux_drm_syncobj_timeline_v1#68, 0, 495)
[1734711.983] {mesa vk display queue}  -> wp_linux_drm_syncobj_surface_v1#88.set_release_point(wp_linux_drm_syncobj_timeline_v1#97, 0, 495)
[1734711.985] {mesa vk display queue}  -> wl_surface#47.attach(wl_buffer#54, 0, 0)
[1734711.986] {mesa vk display queue}  -> wl_surface#47.damage_buffer(0, 0, 2147483647, 2147483647)
[1734711.988] {mesa vk display queue}  -> wl_surface#47.commit()

This happens for every single frame. All of the commits from the overwatch.exe queue should be removed. They cause full surface damage for wl_surface#3.

why? It just puts the subsurface at the same position it was before. I don't have any problem with doing what you suggest, but trying to explain this to upstream will be annoying

[mahkoh]

Because actually changing the subsurface placement or viewport size does require full surface damage. And since no application makes such changes on every frame, it is not worth tracking in detail if the operation actually changes anything. Tracking if the viewport size differs would be easy. Doing the same thing for the subsurface changes would be much more difficult.

[mahkoh]

Another solution would be to make wl_surface#47 a synchronous subsurface of wl_surface#3 and swap the order of the commits. Then both commits would be applied at the same time and the damage rate would be controlled by the slower of the two.

[Etaash-mathamsetty]

Because actually changing the subsurface placement or viewport size does require full surface damage. And since no application makes such changes on every frame, it is not worth tracking in detail if the operation actually changes anything. Tracking if the viewport size differs would be easy. Doing the same thing for the subsurface changes would be much more difficult.

I'm not sure if Rémi will approve this for upstream, so maybe have some sort of plan for that, but at least for custom Proton we don't need to care about upstream's approval.

Another solution would be to make wl_surface#47 a synchronous subsurface of wl_surface#3 and swap the order of the commits. Then both commits would be applied at the same time and the damage rate would be controlled by the slower of the two.

win32u's architecture doesn't make this possible, iirc.

[hamburg3rz]

Etaash-mathamsetty/wine-valve@cda1537
new proton build with this commit completely fixes VRR in jay 👍