AMDGPU & Radeon DDX Updated - Better 2D Performance, Tear Free, DRI3 Default

[starshipeleven]

I rarely use a single monitor, I'm certain I must have mentioned that.

Not in your original claim.

Still, the only place where I've ever seen tearing on Windows is on TVs but that's usually because the TV likes to apply bullshit filters on framerate or something by default to compensate the limitations of the usual non-PC devices you connect to it.
It's usually required to navigate the TV menus to activate the "PC mode" or disable any fancy picture optimization features it has, and hope that it allows you to.

[agd5f]

Thanks for explaining that. I had wondered wth was going on, with only one monitor plugged in it looks great, but with the second monitor and the tv plugged in it definitely does tear. On windows too, even with Aero Glass, which people here swear up and down is impossible to tear, but it most definitely does.

Tearing is a much more complex problem with multiple monitors. You avoid tearing by doing updates during the vertical blanking periods. With multiple monitors, there is little change those periods will align. The best way to handle it is to use the same mode timing on all monitors and hopefully the hardware has a mechanism to synchronize them or use something like freesync so you can adjust the blanking periods to align.

[pq1930562]

There are many choices. gnome-shell (with DRI3 enabled), kwin or compton (with the right configuration), ...

Could you possibly provide a compton.conf that results in proper VSync with the lowest amount of input lag possible? Would be much appreciated.

[MrCooper]

Tearing is a much more complex problem with multiple monitors. You avoid tearing by doing updates during the vertical blanking periods. With multiple monitors, there is little change those periods will align. The best way to handle it is to use the same mode timing on all monitors and hopefully the hardware has a mechanism to synchronize them or use something like freesync so you can adjust the blanking periods to align.

Sounds like you're thinking of a scheme with a single scanout buffer (per CRTC?) which is rendered to during the vertical blank interval. Avoiding tearing is much easier with page flipping, and works reliably in Linux, either with fullscreen apps and compositors using DRI page flipping or with TearFree in all cases.

[MrCooper]

Could you possibly provide a compton.conf that results in proper VSync with the lowest amount of input lag possible? Would be much appreciated.

I'm not much of a compton expert, but these are my basic recommendations:

With DRI3 (recommended):

compton --paint-on-overlay --backend=glx --glx-swap-method=buffer-age

With DRI2:

compton --paint-on-overlay --backend=glx --glx-swap-method=exchange

[agd5f]

Sounds like you're thinking of a scheme with a single scanout buffer (per CRTC?) which is rendered to during the vertical blank interval. Avoiding tearing is much easier with page flipping, and works reliably in Linux, either with fullscreen apps and compositors using DRI page flipping or with TearFree in all cases.

I was referring to cross monitor tearing. E.g., if you have two monitors, one of them may still be displaying an old image until its crtc has flipped if the timings don't align.

[MrCooper]

I was referring to cross monitor tearing. E.g., if you have two monitors, one of them may still be displaying an old image until its crtc has flipped if the timings don't align.

Gotcha, that indeed requires synchronizing the refresh cycle between monitors. FWIW, AFAIK DAL might do that automatically between monitors using identical video mode timings.

[pq1930562]

With DRI3 (recommended):

compton --paint-on-overlay --backend=glx --glx-swap-method=buffer-age

Thank you! Currently testing this with an Intel GPU and xf86-video-modesetting and it runs pretty well. Previously was running xf86-video-intel with DRI3 and TearFree and it was occasionally tearing. With compton and xf86-video-modesetting it's much better.

However, there's still some input lag. Especially compared to Windows 10 or also compared to xf86-video-intel with DRI3 and TearFree.

But that mainly seems to be due to the fact that mouse cursor seems to be quicker than the rest.

When I left click on a window title bar and hold down the left mouse button and move the mouse to move the window, I can see that the mouse cursor is moving faster than the window, which makes the window movement (and with it the input) feel laggy. The moving window is lagging behind the moving mouse cursor.

Do you have any idea how this could be solved? Maybe the mouse cursor is not VSync'ed or something like that (if that's even possible)?

[MrCooper]

When I left click on a window title bar and hold down the left mouse button and move the mouse to move the window, I can see that the mouse cursor is moving faster than the window, which makes the window movement (and with it the input) feel laggy. The moving window is lagging behind the moving mouse cursor.

Do you have any idea how this could be solved?

Quite frankly, the easiest solution would be using a Wayland compositor instead of Xorg.

[pq1930562]

Quite frankly, the easiest solution would be using a Wayland compositor instead of Xorg.

Would love to. But I thought these were not really ready for prime time yet.

Any suggestions for a Wayland compositor?