AMD Adding Experimental Video Mode Optimization To FreeSync

[jayaura]

How does the patch make that possible?
The patch skips on rates that are outside the monitor's reported range. And too low refresh rates (for the panel) are handled by the driver through LFC, but that requires the monitor to have a wide enough freesync range to begin with.

The skipping in the patch is the part where the blanking is avoided when applying a mode whose timing only differs in its front porch value compared to the current mode its in. Although the patch series adds a few predefined mode to the list exposed by the driver, userspace is free to add its own mode using xrandr. Then userspace can apply that mode without flicker/blanking.

[ripper81]

This statement is incorrect for FreeSync as is, as discussed before in this very thread (and others before).

According to this it seems not incorrect:

https://wiki.archlinux.org/index.php/Variable_refresh_rate

https://www.amd.com/en/support/kb/faq/gpu-754

Since my brother runs a setup with two monitors i can tell that freesync is in fact not working with two active displays.

[microcode]

Awesome, I've been thinking about this since VRR entered the picture. Being able to run the display at a multiple of the video frame rate makes video players way better. Hope to see this talking in MPV sometime soon.

[microcode]

Linux needs freesync with multi screen setups and within windows (provided their drawn on the freesync screen). I hear that can only happen under wayland, but when I last tested wayland (couple weeks ago), it left allot to be desired! (mostly window and app drawing artefact issues),.

That's not wayland, that's other software being broken.

[microcode]

I find that I get screen tearing with high refresh rates. Content with 23.98 fps or 29.97 or even 59.94 are the worst offenders.

I enable tear free and I don't experience tearing in anything anymore, I don't even use a compositor.

[xnor]

The skipping in the patch is the part where the blanking is avoided when applying a mode whose timing only differs in its front porch value compared to the current mode its in. Although the patch series adds a few predefined mode to the list exposed by the driver, userspace is free to add its own mode using xrandr. Then userspace can apply that mode without flicker/blanking.

I think you misunderstood and also didn't respond to what I was asking.
I asked fenixex how he thinks the patch is doing what he thinks it does. The question was kinda rhetorical, because it doesn't.

So the point wasn't about skipping blanking, but the patch adding modes limited to the range of the monitor.

[xnor]

Awesome, I've been thinking about this since VRR entered the picture. Being able to run the display at a multiple of the video frame rate makes video players way better. Hope to see this talking in MPV sometime soon.

It doesn't do that. Also see #8 and #17.

[fenixex]

@xnor What are you talking about? Also see #14

[xnor]

@xnor What are you talking about? Also see #14

Learn to read. I've already responded to that. I've even pointed to the reply just above your post.

[jayaura]

I think you misunderstood and also didn't respond to what I was asking.
I asked fenixex how he thinks the patch is doing what he thinks it does. The question was kinda rhetorical, because it doesn't.

So the point wasn't about skipping blanking, but the patch adding modes limited to the range of the monitor.

You're correct that with that patch, the driver skips adding modes with refresh rates that are outside of the monitor's reported VRR range. Thats the most logical thing to do. As with how the patch makes it possible, we need to come up with an API to express the userspace's desire to the kernel for this to work gracefully. With the current experimental path, there is an MPV script which can find compatible mode to switch to, when playing a video. So with a 40 - 90 Hz VRR monitor, mpv can ask to go to 48hz when playing the video. But its on the userspace to do this. With this kernel patch, it guarantees that a full modeset will not be triggered when such a mode change is requested.