VKD3D 1.9 Released With HLSL Compiler Improvements, Ability To Inspect DXBC Blobs

[skeevy420]

@skeevy420

Thanks for taking a look!

That's strange, it worked out of the box for me after I uninstalled amdvlk. Do you have that package?
pacman -Qi amdvlk

Yeah tried DWM, i3, bspwm in X11 plus Hyprland, River and Sway

When the fps is the same as the refresh rate I don't notice the problem which makes vblank update rate the most likely source of perceived stuttering. Coincidentally playing for a while makes it less apparent (or maybe I'm just getting used to stuttering at that that point hehe)

I also tried 2 different VRR displays and only having one plugged in while testing

I have a hard time seeing the bottheneck here as I don't get this problem in other heavy games like DOOM Eternal :/

I'm using the latest X570-E Gaming BIOS, fTPM disabled, mitigations disabled, no thermal throttling, gamemoderun, amd pstate and performance governor

Well, I know there's a lot of strangness around VRR with AMDGPU right now like direct scanout tricking the display to run att full refresh rate, mouse polling rate interfering with the refresh rate and kernel not seeing VRR at launch unless overridden with a kernel parameter

Can't think of anything else other than trying KDE at this point

I'm 95% sure that it's AMDVLK that's your problem. That's AMD's Vulkan renderer and once that package is installed it takes precedence over Mesa's RADV Vulkan renderer which is what Valve and other open source developers target. I don't like to trash talk AMD, but AMDVLK is total ass and shouldn't be used as the default renderer. You'd think the people who created Mantle and donated it towards Vulkan would have a better renderer than what they do...

For the most part, you don't want AMDVLK installed. If you want to keep it around, you'll have to run games with AMD_VULKAN_ICD=RADV so the games will use RADV. There's also an amdvlk-opt package you can compile and install AMDVLK in a manner where RADV has precedence. I'd recommend using that amdvlk-opt package and only activating AMDVLK for testing reasons when/if RADV isn't working very well for games.

And, no, I don't have AMDVLK installed right now. The way it takes precedence causes nothing but problems and headaches as you've been experiencing. You can tell that I had it installed in the past since my command line above includes AMD_VULKAN_ICD=RADV.

All that said, I wouldn't rule out some VRR setting, a bug, or even your monitor since it isn't officially a Freesync compatible monitor; only G-Sync Ultimate. I'd consider the fact that Freesync even activates to be luck on your part.

[Kjell]

I'm 95% sure that it's AMDVLK that's your problem.

I don't use it - just made sure you weren't using it since you mentioned that Halo Infinite wouldn't start without a few tweaks which wasn't the case on my end

All that said, I wouldn't rule out some VRR setting, a bug, or even your monitor since it isn't officially a Freesync compatible monitor; only G-Sync Ultimate. I'd consider the fact that Freesync even activates to be luck on your part.

From what I've gathered this is true for the old generation of GSYNC modules (v1). However, new monitors have a updated GSYNC implementation (v2 & v3+) which is DRM free and uses the VESA adaptive sync standard (which is what FreeSync is based on). The specification of GSYNC Ultimate's should be equivalent to FreeSync 2. I know that my AW3821DW doesn't mention FreeSync anywhere. Although if I fire up AMD Adrenalin in Windows, my FreeSync Range shows as 1 - 144 hz which is correct for the capability of a GSYNC Ultimate monitor. The same can be observed with edid-decode in Linux. Also I'm using a DisplayPort 1.4 (as last time I checked HDMI is closed source and had issues with VRR in Linux, but maybe that's fixed by now).

Btw, I've also tried MSI MAG27CQ (2560x1440) which is a native FreeSync Premium monitor with a range of 48-144 HZ. Although the lag is present with that monitor too!

Debugging this DX12 issue feels like looking for needle in a haystack for months now
Thanks for taking a minute to help though!

[skeevy420]

I don't use it - just made sure you weren't using it since you mentioned that Halo Infinite wouldn't start without a few tweaks which wasn't the case on my end

According to some ProtonDB posts, the game randomly crashes on X.org sessions and that was what was happening to me. After those tweaks it didn't crash a single time. I was using those in addition to the command line from earlier. I never tested on KDE Wayland.

From what I've gathered this is true for the old generation of GSYNC modules (v1). However, new monitors have a updated GSYNC implementation (v2 & v3+) which is DRM free and uses the VESA adaptive sync standard (which is what FreeSync is based on). The specification of GSYNC Ultimate's should be equivalent to FreeSync 2. I know that my AW3821DW doesn't mention FreeSync anywhere. Although if I fire up AMD Adrenalin in Windows, my FreeSync Range shows as 1 - 144 hz which is correct for the capability of a GSYNC Ultimate monitor. The same can be observed with edid-decode in Linux. Also I'm using a DisplayPort 1.4 (as last time I checked HDMI is closed source and had issues with VRR in Linux, but maybe that's fixed by now).

Btw, I've also tried MSI MAG27CQ (2560x1440) which is a native FreeSync Premium monitor with a range of 48-144 HZ. Although the lag is present with that monitor too!

Debugging this DX12 issue feels like looking for needle in a haystack for months now
Thanks for taking a minute to help though!

If you didn't have that BTW part my first thought would have been:

This might be an off the wall idea, but have you thought about "overclocking" the monitor, editing the EDID, so the VRR range is 30-144 or 48-144 like most other FreeSync monitors tend to use? Or even 60-144 like the VESA standard?

Do the monitor and games work on Windows? I'm assuming yes since you mentioned the AMD Control Panel reporting the monitor's correct range. Ideally, Halo Infinite should have the exact same stuttering from shader compilation on Windows and Linux.

While I assume this is also yes: Have you tried wiping both the Steam shader cache and vkd3d cache for Halo? Perhaps even wipe the Mesa cache, too (~/.cache/mesa_shader_cache/*), although the Mesa cache is an all or nothing wipe. I also have the Steam shader cache enabled if that helps.

I hate suggesting this because of all the crud it'll pull into your seemingly minimalist system, but trying KDE might be beneficial just to rule out that it isn't a Sway or wlroots problem. There seem to be a lot of VRR issues for Sway. KDE should just work and enable VRR for full screen programs...but if it's just DX12 programs while DX11, Vulkan, etc work just fine, that's weird and I wouldn't necessarily expect it to be Sway or wlroots.

Have you tried wiping the affected games' Proton prefixes? I was having weird issues after I upgraded my hardware week before last and some games would not launch until I wiped their prefix. It's also been my experience that changing DXVK, VKD3D, Proton versions, etc over and over again can sometimes make prefixes need the nuclear option. Thank goodness for game save syncing.

I hope someone comes along with actual VRR experience.

[Kjell]

@skeevy420

Made a discovery yesterday!
There's a patch which tries to prevent cursor movement from breaking vblank update rate, it made a huge difference as most of the heavy-stuttering is now gone! Well, it's not perfect but the difference is massive and consistent:

https://github.com/swaywm/sway/issues/6832#issuecomment-1698442549

Other than that, I'm doing all of my testing on a fresh installation of Arch Linux so I don't have any old cached objects (in steam/vkd3d/mesa/proton prefixes).
Went ahead and tried KDE (I updated the: resolution, refresh rate, enabled vrr, set flat mouse acceleration profile and selected prefer best latency without tearing in compositor settings (as I found it to work the best)) and unfortunately I noticed there's higher input latency versus Sway. Cursor movements are delayed, I'd describe it as "walking in water" and the overall experience is the same as *unpatched Sway (meaning KDE seems to suffer from the same cursor related issue as unpatched Sway/wlroots: https://gitlab.freedesktop.org/drm/amd/-/issues/2186)
I went ahead and tried Windows 10 LTSC as well and it actually has less lag spikes but overall the game movements are the same as *patched Sway so we've probably hit the ceiling for how good VRR experience can get for now!

Although I'm thinking there's still room for improvement as I've noticed that the crosshair in DX12 games is "moving in a grid" (it looks like it moves between blocks instead of fluidly). I'm not sure if there's anything that can be done about this if it's the same in Windows 10 LTSC and CachyOS. I got a 1000Hz mouse and I've also tried a lowerend 125Hz mouse but surprisingly the results are the same, makes me wonder if using a Intel CPU/Motherboard would make a difference since a lot of people are complaining about poor USB performance with AMD.

Thanks for all of your ideas!

[skeevy420]

Kjell

I assume you're G******D on Github? I was about to suggest trying out Gamescope's embedded mode, but I think you've done that already. If not, someone else in the world has the same system and monitors you have access to

Well, there is one thing you can do, but you probably won't like it because it defeats the purpose of your very expensive monitor: Switch to gaming at a fixed FPS to rule out VRR itself. See if these issues persist at constant a 1440p60+ or 1080p120/144; V Sync on and off.

bridgman agd5f Sorry for the bother, but I assume one of y'all will know the answer to this question:

Does FreeSync Premium Pro/FreeSync 2, RDNA 2/6800 XT, or AMDGPU itself support going as low as 1hz for variable refresh rate with a G-Sync Ultimate monitor?

[Kjell]

I assume you're G******D on Github? I was about to suggest trying out Gamescope's embedded mode, but I think you've done that already. If not, someone else in the world has the same system and monitors you have access to

That's correct
Haven't gotten around to updating my username here

It's strange because Sway without direct scanout and with deferred cursor move patch is the only way to get VRR to work properly, the difference is day-and-night.. Not even Gamescope works properly. I've tried it with my old monitor (MSI MAG27CQ) and got the same result! Strange how few people complain about this, feels like my setup is cursed

See if these issues persist at constant a 1440p60+ or 1080p120/144; V Sync on and off.

This was actually a good idea!
With lowest settings in Halo Infinite and lower resolution the game is stuck at 120 FPS (so vsync is disabled ingame but it's mandatory in Wayland until tearing protocol is finished)
The lower frametime due to higher fps is noticeably "snappier" but the frame "smoothness" is very similar to VRR in patched Sway
I'd say VRR works correctly now as long as I use patched Sway

What's interesting is that there's still micro stuttering (occasional micro hiccups) if I move right-and-left with arrow keys (even when the mouse is disconnected) at stable 120 with no VRR.
If I look around it still feels like the crosshair is moving in a grid.
The remaining source of lag is neither caused by VRR, fluctuations in FPS nor the mouse in that case.
I have fTPM disabled as well as Above 4G Decoding
Hmm..

[bridgman]

Does FreeSync Premium Pro/FreeSync 2, RDNA 2/6800 XT, or AMDGPU itself support going as low as 1hz for variable refresh rate with a G-Sync Ultimate monitor?

I don't know for sure but my impression was that the range of refresh rates was much narrower than that, maybe 25 Hz on the low end.

[skeevy420]

I don't know for sure but my impression was that the range of refresh rates was much narrower than that, maybe 25 Hz on the low end.

That was my assumption since practically every FS monitor I've considered buying started at either 30hz or 48hz and why my first suggestion was to OC the minimum frequency of the monitor up to one of those. Thanks.

Kjell Your setup sounds cursed. You think you're getting your ducks in a row only to see a goose egg. At least you seem to be getting somewhere with the patched Sway, so that's something nice.

Apparently Halo Infinite has all sorts of VRR issues regardless of the platform. It doesn't seem like it's the best game to be using to figure out your VRR issues. It might be one of those games that's best to lock at 60fps of whatever and call it a day if that happens to work adequately enough.

Good Luck