I don't really see how this is a bad thing and why it would make Intel (and only Intel) run that much worse.

That’s a fair question, and it’s something I’ve been asking myself as well, " why this seems to affect Intel specifically ? ".

Part of me wonders whether this could be related to the shared-memory nature of older Intel iGPUs, which do not have dedicated VRAM and instead rely entirely on system memory. In that context, the memory management strategy might end up having a negative performance impact rather than an improvement.

If the introduced feature, less wasteful memory management results in a consistent performance drop on Intel iGPUs, I was wondering whether it might still be worth investigating why this behavior appears to impact Intel GPUs in particular, even if the change itself is intentional.

To rule out this being game-specific, I tested a few additional titles and observed the same behavior across them.

While a 1–2 FPS difference wouldn’t be a concern, the performance drop I’m seeing is closer to 7–10 FPS, which has a noticeable impact on overall performance,and especially on an integrated GPU this makes the impact much more noticeable.

Greetings, @VigneshR387

You can try to disable memory defragmentation in DXVK by adding config option dxvk.enableMemoryDefrag = False to dxvk.conf config file or DXVK_CONFIG environment variable.

Also, you can check, if d3d11.cachedDynamicResources = a and d3d9.cachedDynamicBuffers = True have any effect.

Link with information about Vulkan Memory Types and memory management on different GPU vendors (including Intel iGPUs with Intel(R) UHD Graphics 600 as an example) authored by Adam Sawicki, which explains why these actions may help in your situation: https://asawicki.info/news_1740_vulkan_memory_types_on_pc_and_how_to_use_them

Hey @Digger1955, thanks for the advice.

You can try to disable memory defragmentation in DXVK by adding config option dxvk.enableMemoryDefrag = False to dxvk.conf config file or DXVK_CONFIG environment variable.

Isn't Memory Defragmentation is disabled by default on Intel ANV drivers? link

Also, you can check, if d3d11.cachedDynamicResources = a and d3d9.cachedDynamicBuffers = True have any effect.

I tried setting these options in dxvk.conf but didn't see any noticable difference.

Whats confusing me is that the memory heap reported and budgeted by Vulkan is actually pretty sufficient

info:  Memory:
info:    Heap 0: 8.68 GiB (DEVICE_LOCAL)
info:    Budget: 6.86 GiB
info:      Type  0: DEVICE_LOCAL
info:      Type  1: DEVICE_LOCAL | HOST_VISIBLE | HOST_COHERENT
info:      Type  2: DEVICE_LOCAL | HOST_VISIBLE | HOST_COHERENT | HOST_CACHED
info:      Type  3: DEVICE_LOCAL
info:      Type  4: DEVICE_LOCAL | HOST_VISIBLE | HOST_COHERENT
info:      Type  5: DEVICE_LOCAL | HOST_VISIBLE | HOST_COHERENT | HOST_CACHED

Logs for reference:
dxvk 2.4.1 log.txt
dxvk 2.7.1 log.txt

I’m not entirely sure how DXVK utilizes the video memory heap exposed via VK_EXT_memory_budget internally.
As @doitsujin mentioned earlier, increasing the vidememory heap shoudn't be reallly affecting the performance but somehow thats the case here.

One thing i like to point out is that if you look at these two screenshots:

I'm not sure whether the circled one's are the actual vram usage. If so, it's clearly being underutilized in 2.7.1 compared to 2.4.1. Which may explain the lower performance. Again, I might be wrong here.

Things would be alot easier, If users with similiar GPU as mine could chime in to confirm whether the issue really exist in the first place.

@VigneshR387

Isn't Memory Defragmentation is disabled by default on Intel ANV drivers? link

On Linux with MESA-ANV drivers, on devices that have minSubgroupSize >= 16 - yes, commit link.

If you have Windows, you can check the behaviour there. If the behaviour will be different it may point to a problem in Linux driver stack, if not - then it is Intel-specific (hardware/software).

As a workaround to conceal the problem, you may enable preffered FPS Limiter with FPS limit value that you hit in any case (30 FPS, for example, in your images).

Was the lower perf actually root caused to memory allocation?

Because there might be a bunch more changes between 2.6.2 & 2.4.1 versions.

Was the lower perf actually root caused to memory allocation?

Maybe. But the performance difference is between 2.4.1 and 2.5 (I forgot to change the tile). Based on the release note in 2.5

Was the lower perf actually root caused to memory allocation?

Maybe. But the performance difference is between 2.4.1 and 2.5 (I forgot to change the tile). Based on the release note in 2.5

But if dxvk.enableMemoryDefrag is disabled on Intel/Anv, then it might be another change that trigger this regression.

then it might be another change that trigger this regression.

Yeah, you’re right. After bisecting between DXVK 2.4.1 (good) and 2.5 (bad), the regression points to this specific commit:

af4ec3c63d65da50ca8be6fd65a031b3301b979b

Testing immediately before and after this commit shows reproducible performance regression.

So the regression seems to only affect D3D11 titles. The game I’ve currently tested this on is Divinity: Original Sin – Enhanced Edition.

@doitsujin Any thoughts on this?

Yeah GENERAL on anything prior to DG2 I think will get sideband compression disabled.

You could print out the layouts used in the driver in :

https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/intel/vulkan/genX_cmd_buffer.c?ref_type=heads#L6120 (color attachment)

https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/intel/vulkan/genX_cmd_buffer.c?ref_type=heads#L6311 (depth attachment)

And see if you see different values before/after the DXVK change.

You could print out the layouts used in the driver in :

https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/intel/vulkan/genX_cmd_buffer.c?ref_type=heads#L6120 (color attachment)

https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/intel/vulkan/genX_cmd_buffer.c?ref_type=heads#L6311 (depth attachment)

And see if you see different values before/after the DXVK change.

Just to confirm, should I be building Mesa from source and adding the logging you suggested? If you have any references for building Mesa, that would be helpful.

I added logging in DXVK (I don't have an Intel GPU).

When replaying my Assassins Creed 2 apitrace (that's the game from the original issue), I never got any layout other than COLOR_ATTACHMENT_OPTIMAL or VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL. (DXVK master)

Though admittedly I only added logging for actual DXVK render passes and not for things like e.g. meta blit render passes.

Just to clarify, this regression appears to only affect D3D11 titles; DX9 paths seem unaffected. Apologies for the earlier confusion around AC2.

Can you name some D3D11 titles that are affected?

The one i just tested now was "Divinity Original Sin Enhanced Edition".
Also had the same issue with Hitman Absolution.

Is the latest DXVK still affected?

Tested till v2.7.1. I'll try with the latest build and let you know 👍.

Is the latest DXVK still affected? There have been some major changes to how it handles image layouts of render targets.

You can find a build here: https://github.com/doitsujin/dxvk/actions/runs/20706111823 ('artifacts')

[..] images that are configured to have GENERAL as their common layout. Back then that would've only been the case for images that can also be bound as storage image [..]

That can actually happen with d3d11 games.

On older GPUs Anv performs decompression on layout transition so that the storage operation is performed on uncompressed data (since HW cannot access compressed data for storage).

So if you switched from color_attachment_optimal to general that would prevent compressed writes from fragment writes to happen.

Xe2 and DG2 GPUs are not affected by this since HW gained compression support for storage.

You could print out the layouts used in the driver in :

https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/intel/vulkan/genX_cmd_buffer.c?ref_type=heads#L6120 (color attachment)

https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/intel/vulkan/genX_cmd_buffer.c?ref_type=heads#L6311 (depth attachment)

And see if you see different values before/after the DXVK change.

@llandwerlin-intel @K0bin
So i added the print statement as you suggested.

src/intel/vulkan/genX_cmd_buffer.c :

      gfx->color_att[i].vk_format = iview->vk.format;
      gfx->color_att[i].iview = iview;
	  fprintf(stderr,
	          "ANV color attachment %u: layout=%d aux_usage=%d\n",
	          i,
	          att->imageLayout,
	          aux_usage);
	  
      gfx->color_att[i].layout = att->imageLayout;
      gfx->color_att[i].aux_usage = aux_usage;
      gfx->color_att[i].skip_srgb_decode = att_flags_info &&

&

      if (d_att != NULL && d_att->imageView != VK_NULL_HANDLE) {
         d_iview = anv_image_view_from_handle(d_att->imageView);
         initial_depth_layout = attachment_initial_layout(d_att);
         depth_layout = d_att->imageLayout;
         depth_aux_usage =
            anv_layout_to_aux_usage(cmd_buffer->device->info,
                                    d_iview->image,
                                    VK_IMAGE_ASPECT_DEPTH_BIT,
                                    VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT,
                                    depth_layout,
                                    cmd_buffer->queue_family->queueFlags);
         fprintf(stderr,
                 "ANV depth attachment: layout=%d aux_usage=%d\n",
                 depth_layout,
                 depth_aux_usage);
         
         clear_value.depth = d_att->clearValue.depthStencil.depth;
      }

Build flags & Setup:

> meson setup builddir -Dvulkan-drivers=intel -Dgallium-drivers= -Dbuildtype=debug
>meson compile -C builddir 
>meson devenv -C builddir
>lutris

Here's the log:

• v2.4.1 :

DXVK 2.4.1.log

https://privatebin.rinuploads.org/?b1993b60b694bf9c#DMhHpTFJMDtPwJ3wxSSwkhp8M5hdsjczc1SyUcS53txd

• v2.5 :

DXVK 2.5.log

https://privatebin.rinuploads.org/?2fa12560e428ec46#24mSW9zc33oHDKRsc8mkR12RHReu7EgsmejYb8Jma6T8

• v2.7.1 :

DXVK 2.7.1.log

https://privatebin.rinuploads.org/?956ad9ab8cb236b8#2ZrLdcMSE5BFvrwiJ5JyEu9NAuotgadmSMto2PmaLrBg

So the old 2.4.1 log has more than 2x as many lines but roughly a sixth the number of hits for layout=1.

The initial run was on v2.4.1, and I let the game run a bit longer compared to 2.5 and 2.7.1, which likely explains why that log has roughly 2× more lines 😅 .

It would be great if you could also make an apitrace of that test run.

Sure, I'll capture the api trace for all 3 test runs .

I have this problem (performance degradation) on winlator emulator via dxvk above 2.4 on Snapdragon elite android device. but I can't use 2.4.1 as it doesn't work with turnip drivers