Source2 games appear to be mishandling Vulkan's memoryTypes on Intel Linux (Mesa)

[pzanoni-intel]

Hello

I work on the Intel Linux Graphics (Mesa) team and we're testing Dota 2 and CS2 on our next platform codenamed Lunar Lake (LNL) and we're seeing both of them crashing right when the game starts. The relevant error messages seem to be:

Buffer allocation failed for DEVICE_LOCAL memory indicating video memory is full, trying again in system memory as a fallback.
ERROR! VK call failed! result = Unknown VkResult value ( vmaCreateBufferWithAlignment )
vmaCreateBufferWithAlignment failed fallback system memory allocation.  Fatal error: out of video and system memory.

What's different about LNL, and the likely reason behind the crash, is that its memory types are different from previous platforms:

• We have a memory type that can only be used by VkImages (it supports Intel's compression feature), but not for VkBuffers.
• We have additional memory types that can be used by both buffers and images, and they all have the HOST_COHERENT bit.

vulkaninfo reports:

memoryTypes: count = 5
		memoryTypes[0]:
				heapIndex     = 0
				propertyFlags = 0x0001: count = 1
						MEMORY_PROPERTY_DEVICE_LOCAL_BIT
				usable for:
						IMAGE_TILING_OPTIMAL:
								color images
								FORMAT_S8_UINT
						IMAGE_TILING_LINEAR:
								color images
		memoryTypes[1]:
				heapIndex     = 0
				propertyFlags = 0x0007: count = 3
						MEMORY_PROPERTY_DEVICE_LOCAL_BIT
						MEMORY_PROPERTY_HOST_VISIBLE_BIT
						MEMORY_PROPERTY_HOST_COHERENT_BIT
				usable for:
						IMAGE_TILING_OPTIMAL:
								color images
								FORMAT_D16_UNORM
								FORMAT_X8_D24_UNORM_PACK32
								FORMAT_D32_SFLOAT
								FORMAT_S8_UINT
								FORMAT_D24_UNORM_S8_UINT
								FORMAT_D32_SFLOAT_S8_UINT
						IMAGE_TILING_LINEAR:
								color images
		memoryTypes[2]:
				heapIndex     = 0
				propertyFlags = 0x000f: count = 4
						MEMORY_PROPERTY_DEVICE_LOCAL_BIT
						MEMORY_PROPERTY_HOST_VISIBLE_BIT
						MEMORY_PROPERTY_HOST_COHERENT_BIT
						MEMORY_PROPERTY_HOST_CACHED_BIT
				usable for:
						IMAGE_TILING_OPTIMAL:
								color images
								FORMAT_D16_UNORM
								FORMAT_X8_D24_UNORM_PACK32
								FORMAT_D32_SFLOAT
								FORMAT_S8_UINT
								FORMAT_D24_UNORM_S8_UINT
								FORMAT_D32_SFLOAT_S8_UINT
						IMAGE_TILING_LINEAR:
								color images
		memoryTypes[3]:
				heapIndex     = 0
				propertyFlags = 0x0007: count = 3
						MEMORY_PROPERTY_DEVICE_LOCAL_BIT
						MEMORY_PROPERTY_HOST_VISIBLE_BIT
						MEMORY_PROPERTY_HOST_COHERENT_BIT
				usable for:
						IMAGE_TILING_OPTIMAL:
								None
						IMAGE_TILING_LINEAR:
								None
		memoryTypes[4]:
				heapIndex     = 0
				propertyFlags = 0x000f: count = 4
						MEMORY_PROPERTY_DEVICE_LOCAL_BIT
						MEMORY_PROPERTY_HOST_VISIBLE_BIT
						MEMORY_PROPERTY_HOST_COHERENT_BIT
						MEMORY_PROPERTY_HOST_CACHED_BIT
				usable for:
						IMAGE_TILING_OPTIMAL:
								None
						IMAGE_TILING_LINEAR:
								None

The relevant code for our driver is here:

• https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/intel/vulkan/xe/anv_device.c?ref_type=heads#L151
• https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/intel/vulkan/anv_physical_device.c?ref_type=heads#L1846

It is memoryTypes[0] that is the one that's only supported for VkImages but not VkBuffers.

I have been testing Dota 2 and modifying our memory types and I'm able to see a few configurations that make Dota 2 work, but this seems like an application bug. Basically, the game only launches once it is able to successfully find a memoryType where it can store both VkBuffers and VkImages, otherwise it crashes. Also, I can see that it's the third buffer buffer creation that seems to be failing, which leads to some questions:

• Could the engine be trying to allocate the buffer in some kind of image memory pool and failing?
• Or maybe the engine is just trying memoryType[0] for the buffer because it's forgetting to get the initialize the value somhhwere so it's zero?

Putting some printfs in the driver helps highlight the issue. Please see printf-debug.patch for the patch and printf-debug-output.txt for the result on an unpatched tree. One of the simplest ways to fix this issue is by removing the special memoryType for compression. Doing that, we get the output printf-debug-output-works.txt (this file contains only the first memory allocations done).

On our side we've been discussing this issue here:

• https://gitlab.freedesktop.org/mesa/mesa/-/issues/11520

And I've proposed the following workaround patch while we don't have a permanent fix:

• https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30433

I am limited in my debugging of this issue due to not knowing exactly what the Source2 engine is trying to do. You guys have more information than I do, so if you believe this is an Intel driver issue please tell us.

printf-debug-output.txt
printf-debug-output-works.txt
vulkaninfo.txt
printf-debug.patch.txt

Thanks,
Paulo