vsync broken and freesync missing

[aufkrawall]

Continuation from #16 , as I think situation is too unsatisfying to have no open ticket for it.

1. Vsync in amdvlk is basically broken. It tears when fps fall below refresh rate. When setting UseFlipHint,1 in amdPalSettings.cfg, it doesn't tear anymore, but looks way too stuttery compared to radv. This seems to be a general issue, as every game I tested shows the same behavior.
   Like I said in the original ticket, use amdgpu.dc=0 or modesetting Xorg DDX for testing, as there is an issue with xf86-video-amdgpu + amdgpu.dc=1:
   https://bugs.freedesktop.org/show_bug.cgi?id=110659

2. FreeSync is missing. It is implemented in radv since Mesa 19.1 and doesn't comprise many lines of code.

[aufkrawall]

Any feedback, please?

With the default setting without pageflipping, there is always tearing as soon as fps drop below refreshrate and it looks even more stuttery than without vsync at the same time.

With pageflipping enabled via UseFlipHint,1, there is no more tearing, but the result is much more stuttery than with radv. This is also visible in DXVK's frametime graph, it shows more spikes:

You are also wasting performance by not enabling pageflipping by default: Even when vsync is disabled, fps are ~3% higher with UseFlipHint,1 (as long as amdgpu.dc=0 is used).

[ghost]

I know the Windows driver got broken vsync too.
I don't have a Freesync monitor though.
I reported about this here on AMD Vulkan forums : https://community.amd.com/thread/240310

[aufkrawall]

There seems to be something broken in the recent Windows drivers, I'm getting uneven presentation in Serious Sam Fusion. But I think that must be an actual regression, it it used to work without issues before (Edit: The issue on Windows is the application's fault, it incorrectly sets backbuffers).
Though the Linux amdvlk situation on Xorg has always been as bad as it is today.

[aufkrawall]

Good to see an assignment for this.
The bug regarding amdgpu.dc=1 which I mentioned in the opening post turned out to be a bug in Wine that can be "fixed" by reverting this Wine commit:
wine-mirror/wine@c6b6935

But: As expected, this doesn't touch this amdvlk issue.
Pageflipping being disabled in amdvlk driver by default also affects the native Linux version of Rise of the Tomb Raider, there is tearing despite of the vsync option enabled in the game.
When setting UseFlipHint,1, the tearing is gone, but frame output looks extremely stuttery.
With radv, there is no tearing when enabling vsync and it also looks as smooth as the Windows DX11/12 version on native Windows.

[JacobHeAMD]

Got it, hopefully I can take a look at the stuttery issue with vsync enabled next week.

[aufkrawall]

Fantastic, thank you. :)
As a side note: It already stutters without vsync when UseFlipHint,1 is used in fullscreen with amdgpu.dc=1.

[JacobHeAMD]

Hi @aufkrawall , is this issue only with dxvk? It's not seen on my end, native Linux. Did you install amdgpu-pro driver? And also, amdgpu.dc = 0 or 1? I'm little confused because it's a long thread continious from #16 . Could you describe again about how to reproduce this issue step by step, including OS, HW, and how to proceed with the Game (I tried with Rise Tomb benchmark, but the issue is not seen)? It will be helpful if there is any simple demo, such as modified vkcube, to reproduce this issue.

[aufkrawall]

@JacobHeAMD
Here it's also 100% reproducible with native Linux version of Rise of the Tomb Raider by Feral.
With the driver default of UseFlipHint,0, I'm having constant tearing with vsync, despite of always achieving the 75fps for my display's 75Hz refresh rate.
When I set UseFlipHint,1, there is no more tearing, but framerate suffers and it runs at very stuttery ~67fps instead of 75fps:

Without vsync, it runs with stable 82fps in that scene:

This is with amdgpu.dc=1. As I mentioned before, this issue does not occur with radv.
I don't know what else to describe. I load any game and the issue is always there with amdvlk.

[JacobHeAMD]

Is it 4k resolution of your monitor? Mine is 2k, that's probably the reason why I don't see it. I'll try 4k monitor later.

[aufkrawall]

I'm on a 1440p display and the games' render resolution is also set to it and fullscreen mode (so there should be no problem with fullscreen windows to trigger pageflipping on xorg).
It seems pageflipping never kicks in here with amdvlk and driver default of UseFlipHint,0, and enforcing it in the driver via UseFlipHint,1 just leads to something bad. At least that would be my layman interpretation.

[JacobHeAMD]

Could you please tell me which gpu are you using? You can get it by "lspci | grep VGA" in cosole.

[aufkrawall]

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev ef)

[JacobHeAMD]

I still didn't see this issue, probably I missed something important. Our CQE will try to reproduce it, will take a look if it's reproduced.

[aufkrawall]

Still broken with v-2019.Q4.1.

[JacobHeAMD]

Hi @aufkrawall , could you please clarify if the tearing happens to "UseFlipHint,1" + vsync on ? Or it just happens to UseFlipHint=0 or vsync off?

[aufkrawall]

@JacobHeAMD
"UseFlipHint,1" + vsync on: No tearing, but very stuttery result when fps are below refresh rate
"UseFlipHint,1" + vsync off: tearing, but still bad stutter at the same time
"UseFlipHint,0" + vsync on: tearing (might occur close to the top or bottom of the screen)
"UseFlipHint,0" + vsync off: works normally

[JacobHeAMD]

Hi @aufkrawall , may I know which kernel are you testing with? Is it 5.0?

[aufkrawall]

@JacobHeAMD It is 5.3.7. I'd be surprised if it made a difference, as radv just works.

[aufkrawall]

As expected, the Shadow of the Tomb Raider port by Feral shows tearing with amvlk + vsync, while radv + vsync does not.

Edit: That was with amdvlk-proprietary. amdvlk-open just crashes the game.

[ghost]

Now that they fixed AMDVLK on Hybrid Graphics I can see the tearing issues too when playing NI No Kuni Remastered.

[aufkrawall]

Are you rendering on a different GPU than the one that outputs to display? If yes, that might be a very similar, but actually different issue. I'm also getting tearing with radv/anv when rendering on the IGP of my 6700k while outputting via Polaris dGPU. That might be an Xorg limitation.

But this amdvlk issue is not, it's an amdvlk limitation. ;)

[ghost]

Ya but the thing is when i use "UseFlipHint,1" like you said the tearing stops and gets replaced by stutters (unless that's also part of "very similar issue" you meant).
The Intel GPU renders the desktop while the game uses the dgpu ya (its a laptop).
Also the tearing does not happen on RADV.

[JacobHeAMD]

Hi @aufkrawall , would you mind to try the latest amdvlk driver?

[aufkrawall]

As broken as ever with 2019.Q4.5-1 from Arch repo.

[JacobHeAMD]

Do you mean it's same as before no matter if UseFlipHint is turned on or off?

[aufkrawall]

Ok, it definitely has improved with UseFlipHint,1, it seems to look normal now without vsync in fullscreen.

However, despite of having improved, UseFlipHint,1 + vsync still looks more choppy than radv. It's not that obvious anymore, but still definitely worse. Also DXVK's frame time graph still mirrors this:

[JacobHeAMD]

Thanks! I'll take a look the issue of "UseFlipHint,1 + Vsync".

[aufkrawall]

You likely need to get into frame rates below the display's maximum refresh rate to trigger it. In my layman terms, it appears to me like an issue of the logic that decides how frame draws are repeated to match the refresh rate as good as possible.

[ghost]

The issue with tearing on fixed referesh rate displays is still a thing :X (at least on Windows) .

[aufkrawall]

However, despite of having improved, UseFlipHint,1 + vsync still looks more choppy than radv. It's not that obvious anymore, but still definitely worse. Also DXVK's frame time graph still mirrors this:

@JacobHeAMD May I ask if this is fixed, now that page flipping is turned on by default in amdvlk?

[JacobHeAMD]

@aufkrawall , I think it's not fixed since it's not seen at my end. I will try to add timestamp log to check the issue when I have time. The flip is enabled by default now.

[Degerz]

Adaptive refresh can now be manually enabled in the PAL settings.

[aufkrawall]

Could somebody please retest the situation with vsync and page flipping when frame rate is below refresh rate (see Hitman 2 screenshots above)?

[aufkrawall]

@JacobHeAMD
Vsync still badly affects rendering frame times as shown above. This is with amdvlk 2020.Q3.2 & RX 480 on Xorg.
It's nice that FreeSync works well once activated, but vsync triple buffer/flipping should be fixed regardless.

[ghost]

Enabling vsync still gives me tearing no matter the game.

[aufkrawall]

@mojojojodojo Perhaps you have an amdPalSettings.cfg at some path you forgot and in which you set UseFlipHint,0? I think since it's set to 1 by default in more recent drivers, it shouldn't tear anymore.

But unlike with radv, vsync with amdvlk still gives me oscillating frame time graph and thus more stutter in any game when fps are below maximum refresh rate and FreeSync is disabled:

Some competitor btw. fixed their Vulkan triple buffered fifo mode in a recent driver. ;)

[ghost]

Is there a way to set UseFlipHint,1 on the Windows Vulkan driver?
Would be helpful to stop the tearing I get there (LInux driver is fine ofc).
Opened another issue about this just in case #182.
Vsync works good on the WIndows intel gpu driver.

[aufkrawall]

@JacobHeAMD If I understood you right, you said you couldn't reproduce. So does your DXVK frame time graph (DXVK_HUD=frametimes) look flat with vsync enabled and fps below refresh rate? It certainly doesn't here. Please check if you have EnableAdaptiveSync set, having adaptive sync enabled completely masks the issue.

Recent test with RX 480, amdvlk v-2020.Q3.4, Linux 5.8/5.9-rc, xorg-server 1.20.8, xf86-video-amdgpu 19.1.0, Proton 5.0-9 and latest Hitman 2 version via Steam, compositor entirely disabled, fullscreen:

amdvlk with vsync capping fps at refresh rate (85Hz) as GPU can deliver enough fps = flat:

amdvlk when dropping below 85fps GPU bound = spiky:

radv when dropping below 85fps GPU bound = flat (minor variance in GPU frame time like without vsync):

amdvlk definitely feels more stuttery than radv when fps are below refresh rate when vsync is enabled (the result of both drivers is entirely free of tearing), it's not just a cosmetic issue in DXVK frame time graph. Could you please have another look?

[aufkrawall]

I'm starting to think that vsync is notoriously broken in Windows version of amdvlk as well. This is with Adrenalin 20.9.1 & DXVK:

Vsync off:

Vsync on:

Does anybody even care?

[ghost]

I guess they are banking on people using Freesync monitors and not using non-freesync/laptop monitors.
I guess I am stuck with using RADV for awhile.

[aufkrawall]

sigh, fifo vsync is still flawed with fps below refresh rate with amdvlk v-2021.Q1.1, despite of backbuffer queue length of 3:

amdvlk:

-> looks very stuttery

RADV (or amdvlk without vsync):

-> looks normally smoth

Though mailbox present mode looks also normal with amdvlk, at least if a game uses a backbuffer queue length of 3. This can be forced in DXVK, but not in native Vulkan games if the game developer doesn't do it.

Example:
Hitman 2 frame time graph is flat and the game looks normally smooth when forcing mailbox vsync mode via libstrangle and a backbuffer queue length of 3 via DXVK. But mailbox vsync mode stops working correctly when setting a backbuffer queue length of 2 in DXVK, it then looks again stuttery with fps below refresh rate. This is not the case with Mesa/RADV, with it mailbox vsync mode also looks smooth with a backbuffer queue length of 2 via DXVK. So, mailbox vsync mode can be used as a workaround for the flawed fifo mode of amdvlk, but only if the application is configured with a backbuffer queue length of 3 (which e.g. doesn't apply to native Path of Exile Vulkan renderer).

Could you please rework vsync for amdvlk?

[aufkrawall]

With recent amdvlk-open 2021.q1.6 and amdvlk-pro 20.50.1232447 drivers, it seems mailbox vsync mode now also seems to work correctly when the application doesn't have a backbuffer queue length of at least 3 configured.

But: Fifo vsync is still bad on both Linux on Windows when it comes to frame rates below refresh rate, despite of a backbuffer queue length of 3. :(
I mentioned in August that a competitor had fixed a similar issue for their Linux drivers (and their Windows driver doesn't have this issue either)...