CSGO with DXVK binding descriptors with NULL pipeline layout

[llandwerlin-intel]

We have a user of the Intel/Mesa Vulkan driver reporting a crash while playing CSGO.

The user provided a backtrace :

0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
Downloading source file /usr/src/debug/glibc/glibc/nptl/pthread_kill.c
44       return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0;                                                                                   
[Current thread is 1 (Thread 0x7f15eb7fe6c0 (LWP 58880))]
(gdb) bt
#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  0x00007f160bc9f2d3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2  0x00007f160bc4fa08 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3  0x00007f160bc38538 in __GI_abort () at abort.c:79
#4  0x00007f160b8dd3b2 in std::__glibcxx_assert_fail(char const*, int, char const*, char const*)
    (file=file@entry=0x7f15f378ee78 "/usr/include/c++/13.1.1/bits/shared_ptr_base.h", line=line@entry=1349, function=function@entry=0x7f15f37c5280 "std::__shared_ptr_access<_Tp, _Lp, <anonymous>, <anonymous> >::element_type& std::__shared_ptr_access<_Tp, _Lp, <anonymous>, <anonymous> >::operator*() const [with _Tp = const PIPELINE_LAYOUT_STATE; _"..., condition=condition@entry=0x7f15f3793161 "_M_get() != nullptr") at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/debug.cc:61
#5  0x00007f15f2db48d0 in std::__shared_ptr_access<PIPELINE_LAYOUT_STATE const, (__gnu_cxx::_Lock_policy)2, false, false>::operator*() const (this=0x7f15eb7fd5e0)
    at /usr/include/c++/13.1.1/bits/shared_ptr_base.h:1347
#6  std::__shared_ptr_access<PIPELINE_LAYOUT_STATE const, (__gnu_cxx::_Lock_policy)2, false, false>::operator*() const (this=0x7f15eb7fd5e0)
    at /usr/include/c++/13.1.1/bits/shared_ptr_base.h:1347
#7  CoreChecks::PreCallValidateCmdBindDescriptorSets(VkCommandBuffer_T*, VkPipelineBindPoint, VkPipelineLayout_T*, unsigned int, unsigned int, VkDescriptorSet_T* const*, unsigned int, unsigned int const*) const
    (this=0xa1ce000, commandBuffer=0x325ee000, pipelineBindPoint=VK_PIPELINE_BIND_POINT_GRAPHICS, layout=0x0, firstSet=0, setCount=3, pDescriptorSets=0x7f15eb7fd8c0, dynamicOffsetCount=<optimized out>, pDynamicOffsets=0x0)
    at /usr/src/debug/vulkan-validation-layers/Vulkan-ValidationLayers-sdk-1.3.250.0/layers/core_checks/cc_descriptor.cpp:208
#8  0x00007f15f2f5a664 in vulkan_layer_chassis::CmdBindDescriptorSets(VkCommandBuffer_T*, VkPipelineBindPoint, VkPipelineLayout_T*, unsigned int, unsigned int, VkDescriptorSet_T* const*, unsigned int, unsigned int const*)
    (commandBuffer=0x325ee000, pipelineBindPoint=VK_PIPELINE_BIND_POINT_GRAPHICS, layout=0x0, firstSet=0, descriptorSetCount=3, pDescriptorSets=0x7f15eb7fd8c0, dynamicOffsetCount=0, pDynamicOffsets=0x0) at /usr/src/debug/vulkan-validation-layers/Vulkan-ValidationLayers-sdk-1.3.250.0/layers/vulkan/generated/chassis.cpp:2973
#9  0x00007f15f49c6159 in  () at /home/k1gen/.local/share/Steam/steamapps/common/Counter-Strike Global Offensive/bin/linux64/libdxvk_d3d9.so
#10 0x00007f15f49b1f34 in  () at /home/k1gen/.local/share/Steam/steamapps/common/Counter-Strike Global Offensive/bin/linux64/libdxvk_d3d9.so
#11 0x00007f15f49cb6d8 in  () at /home/k1gen/.local/share/Steam/steamapps/common/Counter-Strike Global Offensive/bin/linux64/libdxvk_d3d9.so
#12 0x00007f15f49bce0b in  () at /home/k1gen/.local/share/Steam/steamapps/common/Counter-Strike Global Offensive/bin/linux64/libdxvk_d3d9.so
#13 0x00007f15f49cdfa4 in  () at /home/k1gen/.local/share/Steam/steamapps/common/Counter-Strike Global Offensive/bin/linux64/libdxvk_d3d9.so
#14 0x00007f15f49cee15 in  () at /home/k1gen/.local/share/Steam/steamapps/common/Counter-Strike Global Offensive/bin/linux64/libdxvk_d3d9.so
#15 0x00007f15f4b42003 in  () at /home/k1gen/.local/share/Steam/steamapps/common/Counter-Strike Global Offensive/bin/linux64/libdxvk_d3d9.so
#16 0x00007f160bc9d44b in start_thread (arg=<optimized out>) at pthread_create.c:444
#17 0x00007f160bd20e40 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
(gdb)

It shows the vkCmdBindDescriptorSets entrypoint is called with a NULL pipeline layout which according to the specification is not a valid usage :

VUID-vkCmdBindDescriptorSets-layout-parameter
layout must be a valid VkPipelineLayout handle

Software information

Game : CSGO

System information

• GPU: Intel UHD Graphics 620
• Driver: Mesa/Anv
• Wine version: none
• DXVK version: none

Apitrace file(s)

None

Log files

None, additional information can also be found on the Mesa issue : https://gitlab.freedesktop.org/mesa/mesa/-/issues/9412

[doitsujin]

Do you have any information about what kind of pipeline is currently bound when the crash happens?

We bind descriptor sets with the same pipeline layouts that are used for pipeline compilation, so unless we somehow successfully create a pipeline with a NULL layout without crashing the driver I can't really see a universe in which we would run into this situation.

[llandwerlin-intel]

With pipeline libraries you can omit the layout when doing the link (without link optimization).

So it's possible you can end up in such situation.

But driver will need the layout at bind time I think (at least Anv) to make sense of the dynamic offsets given to vkCmdBindDescriptorSets

[doitsujin]

Hm, again, not sure how we could run into this. We always explicitly assign a pipeline layout with INDEPENDENT_SET_BITS to GPL pipelines, and we unconditionally create one such layout in our pipeline layout abstraction if GPL is supported:

https://github.com/doitsujin/dxvk/blob/4ed147403007fa6e1ffc944ad7cad4d7013272ce/src/dxvk/dxvk_pipelayout.cpp#L354-L361

This cannot spuriously fail either since canUseGraphicsPipelineLibrary() only checks enabled device features and m_layout.getStages() is hard-coded to VK_SHADER_STAGE_ALL_GRAPHICS for linked pipelines specifically.

So, whatever is going on is really weird, and I cannot reproduce it on my end.

[llandwerlin-intel]

The user mentioned they were using a patch on top dxvk. I had a quick look but didn't notice stuff related to layouts.

Maybe that could be why?

[Blisto91]

@llandwerlin-intel Do you agree that like the mesa issue this one seems closable?

[llandwerlin-intel]

@llandwerlin-intel Do you agree that like the mesa issue this one seems closable?

Yeah, it seems like a fairly specific setup. We had nobody else report the same issue.