AMD Posts Updated Mesa Patches For Variable Refresh Rate (FreeSync / Adaptive-Sync)

[phoronix]

Phoronix: AMD Posts Updated Mesa Patches For Variable Refresh Rate (FreeSync / Adaptive-Sync)

Earlier this month AMD finally got back on track with issuing new patches for FreeSync / Adaptive-Sync / HDMI Variable Refresh Rate support now that there seems to be a consensus among the Linux DRM (Direct Rendering Manager) driver developers over what this API should look like so it can support the multiple technologies and drivers at play...

http://www.phoronix.com/scan.php?page=news_item&px=Mesa-V2-VRR-FreeSync-Patches

[davidbepo]

after looking the patches i have a question, why is freesync bad for WMs, video players and browsers?

btw, thanks to AMD for working on this, freesync on linux is one of the things i was missing

[kenjo]

after looking the patches i have a question, why is freesync bad for WMs, video players and browsers?

Freesync is by definition a screen event. the entire screen is updated. So when you change from basically the screen being the master to the application it really only works for one application at a time.

so if you have a desktop with multiple windows that is doing animations there is only one that can be the actual master. every one else goes from a predictable 60HZ into something random that they have no control over.

That is probably what they mean its not that its bad for wm's or web it just that there really can only be one application that benefit and for all others its basically much worse than a predictable 60Hz update.

[LinAGKar]

Disabling it for compositors make sense, since those have a bunch of things rendering at different rates, and browsers generally run windowed, but video playback however is something this would be perfect for. That of course includes video playback in browsers.

[theriddick]

If you run a game in a window or fullscreen windowed mode (borderless) will freesync still work or does it need to be fullscreen apps only? I think proton runs everything in borderless mode and not true fullscreen so it will be interesting to test this out.

However I have a 1080Ti MINI but once AMD release a compatible faster card in a semi-sff then I'll be all over it. Could be a LONG while!

[aufkrawall]

Shouldn't it work for compositors when their framerate is defined by the window with the highest fps anyway? It would just be required that the display supports LFC (low framerate compensation) well so that low fps (when compositors reduce framerate because nothing is going on) wouldn't be a problem. This would even save power for notebook displays because higher refreshrate means higher power consumption.
You could also get rid of vsync buffer delay because the compositor could limit its framerate like a game.

Seems like full of win under the right circumstances, or not?

[bridgman]

Not my area of expertise, but AFAIK the issue with compositors is not so much "won't work with compositors" as "games running through the compositor don't get the benefit of variable refresh rate since the compositor runs at a fixed FPS rate" and people round that off to "doesn't work with compositors".

[scix]

If you run a game in a window or fullscreen windowed mode (borderless) will freesync still work or does it need to be fullscreen apps only? I think proton runs everything in borderless mode and not true fullscreen so it will be interesting to test this out.

From what I understand, there is no "true" fullscreen support in X11. So everything fullscreen is just a borderless window, and the variable sync support just relies on that, much like unredirection of fullscreen windows in compositors is supported.

[Zan Lynx]

Freesync is by definition a screen event. the entire screen is updated. So when you change from basically the screen being the master to the application it really only works for one application at a time.

so if you have a desktop with multiple windows that is doing animations there is only one that can be the actual master. every one else goes from a predictable 60HZ into something random that they have no control over.

That is probably what they mean its not that its bad for wm's or web it just that there really can only be one application that benefit and for all others its basically much worse than a predictable 60Hz update.

Ideally your compositor should find a refresh rate that is useful for all displayed windows by finding everyone's Least Common Multiple.

For 24, 30 and 60 that is 120 Hz: 24*5, 30*4 and 60*2. 144 Hz is nice for full-screen games but 120 Hz is perfect for most desktop uses.

Yes I know 30 Hz video is really 29.97 Hz. I don't know anyone who notices if you drag it up to 30 Hz as long as the audio stays in sync. Or you could run the desktop at 119.88 Hz.

[chithanh]

It doesn't have to be multiple. For example, playing back 50 Hz content at 75 Hz refresh rate is also ok, as it is a 3:2 ratio between refresh rate and frame rate.

I think that 300 Hz refresh rate would be optimal for 24 Hz, 25 Hz, 30 Hz, 50 Hz, 60 Hz, 100 Hz and 120 Hz content. As there are no such monitors yet, 150 Hz would be a good compromise.

But! If you have variable refresh that may not even be necessary. If you play back from two different refresh rate sources, just send a frame to the monitor once either of them updates. This just requires a large enough variable refresh range to cover the minimum and maximum time between frames.