It's interesting to see that your GPU FPS actually increase (minimally) between those tests, but your CPU FPS decrease a lot, which pinpoints that the bottleneck is there in both cases, but in a more severe way on the second test.

I wonder if this could lift the veil on the other cases where the heaps are not bringing much benefit as expected

I tried to merge the commits from master manually to redo 97a0c5d step by step for testing, but I run into too much merge conflicts and compile error I'm unable to solve.

Ok, found it! I managed to compile and cherry-pick through a lot of commits and found the culprit: 357081fe25cfd4e6d9347390618020dc6613d978
When I revert that commit my fps for this benchmark go back up to 79 fps.

Using this patch also works:

Subject: [PATCH] Revert transfer queue
---
Index: libs/vkd3d/device.c
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/libs/vkd3d/device.c b/libs/vkd3d/device.c
--- a/libs/vkd3d/device.c	(revision 97a0c5d0bfb47321f3a1fd52c1709e58feba7290)
+++ b/libs/vkd3d/device.c	(revision be0682e2097ffc366fc627c37888fba8dcd20277)
@@ -3634,8 +3634,9 @@
     if (info->family_index[VKD3D_QUEUE_FAMILY_COMPUTE] == VK_QUEUE_FAMILY_IGNORED)
         info->family_index[VKD3D_QUEUE_FAMILY_COMPUTE] = info->family_index[VKD3D_QUEUE_FAMILY_GRAPHICS];
 
-    info->family_index[VKD3D_QUEUE_FAMILY_TRANSFER] = vkd3d_find_queue(count, queue_properties,
-            VK_QUEUE_GRAPHICS_BIT | VK_QUEUE_COMPUTE_BIT | VK_QUEUE_TRANSFER_BIT, VK_QUEUE_TRANSFER_BIT);
+/*    info->family_index[VKD3D_QUEUE_FAMILY_TRANSFER] = vkd3d_find_queue(count, queue_properties,
+            VK_QUEUE_GRAPHICS_BIT | VK_QUEUE_COMPUTE_BIT | VK_QUEUE_TRANSFER_BIT, VK_QUEUE_TRANSFER_BIT); */
+    info->family_index[VKD3D_QUEUE_FAMILY_TRANSFER] = info->family_index[VKD3D_QUEUE_FAMILY_COMPUTE];
 
     if (info->family_index[VKD3D_QUEUE_FAMILY_TRANSFER] == VK_QUEUE_FAMILY_IGNORED)
         info->family_index[VKD3D_QUEUE_FAMILY_TRANSFER] = info->family_index[VKD3D_QUEUE_FAMILY_COMPUTE];

edit: Just tested, applying the patch to the descriptor-heap-rebase branch gives me the same performance boost.

Hi,

tested your changes, looking good to me (see results below).
Thanks for all the work and the quick patch!

master (54 fps):

master + nv-fence-hack (75 fps):

descriptor-heap-rebase (55 fps):

descriptor-heap-rebase + nv-fence-hack (79 fps):

For reference, also a benchmark on Windows 11 (same system, dualboot):

Windows 11 (91 fps):

edit: The screenshots show Upscale Quality Balanced/Quality but DLSS ("Upscale method") is off on all benchmarks. So benchmarks are comparable.

That benchmark is interesting because we can see that the GPU FPS between heaps and Windows 11 is 1 FPS (or same, within margin of error).
What clearly is pushing the performance back now between Linux and Windows is a CPU bottleneck. 79 FPS vs 91 FPS. We have an improvement right now versus the past delta, but other bottlenecks must exist. (could be at the driver level)

I wonder if there is some inter-CCD usage impacting the CPU performance, since the 5950X is a dual-CCD CPU. Then OS-specific CPU scheduling could be causing the slower performance on Linux (or more likely: the lack of CPU usage optimization to stick to one CCD on Linux).

@veldenb would it be possible for you to disable one CCD on BIOS/UEFI and compare CPU perf?

Currently running kernel 7.0 which schedules quite well, no meaningful difference running on a single CCD.

1 CCD descriptor-heap-rebase (56 fps):

1 CCD descriptor-heap-rebase + nv-fence-hack (80 fps):

So I've been following this issue and decided to test it myself, but on another game that gives us a detailed CPU/GPU breakdown, SOTTR.

Kernel: CachyOS 7.0.0
Driver: 595.58.03
Proton: proton-cachyos-10.0-20260409-slr (with it master, heaps-rebase, nv-fence-hack as the 3 vkd3d-proton branches)
GPU: Rtx 5080
CPU: Intel 285k

master

heaps-rebase

nv-fence-hack

master with fsync

So based on these results, there's no difference in CPU perf (or at least it's margin of error) in this game when using NTsync at least.
There's 3 things that could be contributing factors:

• It's a HZD specific regression (Most likely)
• AMD cpu's are more susceptible (not likely)
• NTsync makes a difference (seemingly reduces render perf, but boosts games logic perf)

Sorry for adding noise to this thread, but hopefully extra context can guide some investigation

@HansKristian-Work after my last testing and before the PR was merged commit 540c3d93516439a8fcf8b0c53b40076d43adc614 was done, unfortunately that commit regressed my test results again. When I revert 540c3d93516439a8fcf8b0c53b40076d43adc614 the speed in my benchmark goes up again to the original (better) performance:

master (60 fps):

master + revert 540c3d93516439a8fcf8b0c53b40076d43adc614 (76 fps):

descriptor-heap-rebase (62 fps):

descriptor-heap-rebase + revert 540c3d93516439a8fcf8b0c53b40076d43adc614 (79 fps):

I don't have permission to re-open this issue. What's best, continuing in this issue or report this as a new issue?

Unfortunately this hasn't been fixed by the commit that closed the issue as veldenb reported.

Checked it on master, works now 👍

@HansKristian-Work it looks like nvidia fixed the issue in their latest vulkan beta 595.44.07 driver.
I used descriptor-heap-rebase and reverted 33808c06a74beda8e8149f1b6dd180cc272c1aae and 34cd3983667c1a60cfa1a931341889564b88b3e8. After that I tested 595.44.06 and 595.44.07 to check the fix:

Nvidia vulkan beta 595.44.06 (56 fps):

Nvidia vulkan beta 595.44.07 (81 fps):

So I guess the workaround in VKD3D is not necessary anymore and those commits can be reverted again.