Suspected VUID-VkComputePipelineCreateInfo-layout-07988 false positive when assigning large binding location values

[bitsauce]

Environment:

• OS: Window 11
• GPU and driver version: RTX 2070 Super, driver 556.14
• SDK version: 1.3.296.0
• Options enabled (synchronization, best practices, etc.): Standard validation layer options

Describe the Issue

I have a two-line compute shader in my project that takes in two buffers and computes a simple sum like this:

// ... bunch of buffers
RWStructuredBuffer<uint> MinIndexInCellBufW;
// ... bunch of buffers ...
StructuredBuffer<uint> ScannedSumsSortBufR;

[numthreads(THREADS_PER_GROUP, 1, 1)]
void AddScannedCountInCellBufSums(uint id : SV_DispatchThreadID, uint gid : SV_GroupID) {
    if (id >= GRID_WIDTH * GRID_HEIGHT) return;
    MinIndexInCellBufW[id] += ScannedSumsSortBufR[gid];
}

In this particular case, the MinIndexInCellBufW is the 181th buffer in this file, and ScannedSumsSortBufR is the 192th buffer. When passed to dxc to create SPIR-V, dxc will assign binding 181 and 192 to these resources.

Later, I'm trying to create a compute pipeline with a descriptor set layout that uses these bind locations, however, I'm getting:

Validation Errors

VUID-VkComputePipelineCreateInfo-layout-07988(ERROR / SPEC): msgNum: -675326064 - Validation Error: [ VUID-VkComputePipelineCreateInfo-layout-07988 ] Object 0: handle = 0x9389c50000000061, name = Sim_CS, type = VK_OBJECT_TYPE_SHADER_MODULE; Object 1: handle = 0x2e4b120000000a13, type = VK_OBJECT_TYPE_PIPELINE_LAYOUT; | MessageID = 0xd7bf5790 | vkCreateComputePipelines(): pCreateInfos[0].stage SPIR-V (VK_SHADER_STAGE_COMPUTE_BIT) uses descriptor [Set 0, Binding 181, variable "MinIndexInCellBufW"] (type VK_DESCRIPTOR_TYPE_STORAGE_BUFFER or VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC) but was not declared in the pipeline layout.
The Vulkan spec states: If a resource variables is declared in a shader, a descriptor slot in layout must match the shader stage (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-VkComputePipelineCreateInfo-layout-07988)
    Objects: 2
        [0] 0x9389c50000000061, type: 15, name: Sim_CS
        [1] 0x2e4b120000000a13, type: 17, name: NULL
VUID-VkComputePipelineCreateInfo-layout-07988(ERROR / SPEC): msgNum: -675326064 - Validation Error: [ VUID-VkComputePipelineCreateInfo-layout-07988 ] Object 0: handle = 0x9389c50000000061, name = Sim_CS, type = VK_OBJECT_TYPE_SHADER_MODULE; Object 1: handle = 0x2e4b120000000a13, type = VK_OBJECT_TYPE_PIPELINE_LAYOUT; | MessageID = 0xd7bf5790 | vkCreateComputePipelines(): pCreateInfos[0].stage SPIR-V (VK_SHADER_STAGE_COMPUTE_BIT) uses descriptor [Set 0, Binding 192, variable "ScannedSumsSortBufR"] (type VK_DESCRIPTOR_TYPE_STORAGE_BUFFER or VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC) but was not declared in the pipeline layout.
The Vulkan spec states: If a resource variables is declared in a shader, a descriptor slot in layout must match the shader stage (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-VkComputePipelineCreateInfo-layout-07988)
    Objects: 2
        [0] 0x9389c50000000061, type: 15, name: Sim_CS
        [1] 0x2e4b120000000a13, type: 17, name: NULL
VUID-VkWriteDescriptorSet-dstBinding-00315(ERROR / SPEC): msgNum: -1181565859 - Validation Error: [ VUID-VkWriteDescriptorSet-dstBinding-00315 ] Object 0: handle = 0xcc632c0000000a15, type = VK_OBJECT_TYPE_DESCRIPTOR_SET; Object 1: handle = 0xcd8e500000000a12, type = VK_OBJECT_TYPE_DESCRIPTOR_SET_LAYOUT; | MessageID = 0xb992bc5d | vkUpdateDescriptorSets(): pDescriptorWrites[0].dstBinding (181) is larger than VkDescriptorSetLayout 0xcd8e500000000a12[] binding count (2).
The Vulkan spec states: dstBinding must be less than or equal to the maximum value of binding of all VkDescriptorSetLayoutBinding structures specified when dstSet's descriptor set layout was created (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-VkWriteDescriptorSet-dstBinding-00315)
    Objects: 2
        [0] 0xcc632c0000000a15, type: 23, name: NULL
        [1] 0xcd8e500000000a12, type: 20, name: NULL
VUID-VkWriteDescriptorSet-dstBinding-00315(ERROR / SPEC): msgNum: -1181565859 - Validation Error: [ VUID-VkWriteDescriptorSet-dstBinding-00315 ] Object 0: handle = 0xcc632c0000000a15, type = VK_OBJECT_TYPE_DESCRIPTOR_SET; Object 1: handle = 0xcd8e500000000a12, type = VK_OBJECT_TYPE_DESCRIPTOR_SET_LAYOUT; | MessageID = 0xb992bc5d | vkUpdateDescriptorSets(): pDescriptorWrites[1].dstBinding (192) is larger than VkDescriptorSetLayout 0xcd8e500000000a12[] binding count (2).
The Vulkan spec states: dstBinding must be less than or equal to the maximum value of binding of all VkDescriptorSetLayoutBinding structures specified when dstSet's descriptor set layout was created (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-VkWriteDescriptorSet-dstBinding-00315)
    Objects: 2
        [0] 0xcc632c0000000a15, type: 23, name: NULL
        [1] 0xcd8e500000000a12, type: 20, name: NULL
VUID-vkCmdDispatch-None-08114(ERROR / SPEC): msgNum: 817291879 - Validation Error: [ VUID-vkCmdDispatch-None-08114 ] Object 0: handle = 0xcc632c0000000a15, type = VK_OBJECT_TYPE_DESCRIPTOR_SET; | MessageID = 0x30b6e267 | vkCmdDispatch():  VkDescriptorSet 0xcc632c0000000a15[] [Set 0, Binding 181, variable "MinIndexInCellBufW"] is invalid.
The Vulkan spec states: Descriptors in each bound descriptor set, specified via vkCmdBindDescriptorSets, must be valid as described by descriptor validity if they are statically used by the VkPipeline bound to the pipeline bind point used by this command and the bound VkPipeline was not created with VK_PIPELINE_CREATE_DESCRIPTOR_BUFFER_BIT_EXT (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-vkCmdDispatch-None-08114)
    Objects: 1
        [0] 0xcc632c0000000a15, type: 23, name: NULL

Yet, the program runs fine and with no issues (indicating that the shader runs as expected).

Expected behavior

No validation error when using large binding locations (as long as it falls within any relevant limits of the current device)

Additional context

I tried adding a buffer bound to binding 0 as a test, and in that case, where I bind resource locations [0, 181, 192], this validation error disappears (even though buffer in bind location 0 is unused).

Also, here is an API dump for the relevant section of code (with validation errors shown as they appear):

API dump

Thread 1, Frame 0:
vkCreateDescriptorSetLayout(device, pCreateInfo, pAllocator, pSetLayout) returns VkResult VK_SUCCESS (0):
    device:                         VkDevice = 00000203B2B1AD30
    pCreateInfo:                    const VkDescriptorSetLayoutCreateInfo* = 000000F8CC4FCC38:
        sType:                          VkStructureType = VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_CREATE_INFO (32)
        pNext:                          const void* = NULL
        flags:                          VkDescriptorSetLayoutCreateFlags = 0
        bindingCount:                   uint32_t = 2
        pBindings:                      const VkDescriptorSetLayoutBinding* = 00000203EE775540
            pBindings[0]:                   const VkDescriptorSetLayoutBinding = 00000203EE775540:
                binding:                        uint32_t = 181
                descriptorType:                 VkDescriptorType = VK_DESCRIPTOR_TYPE_STORAGE_BUFFER (7)
                descriptorCount:                uint32_t = 1
                stageFlags:                     VkShaderStageFlags = 32 (VK_SHADER_STAGE_COMPUTE_BIT)
                pImmutableSamplers:             const VkSampler* = UNUSED
            pBindings[1]:                   const VkDescriptorSetLayoutBinding = 00000203EE775558:
                binding:                        uint32_t = 192
                descriptorType:                 VkDescriptorType = VK_DESCRIPTOR_TYPE_STORAGE_BUFFER (7)
                descriptorCount:                uint32_t = 1
                stageFlags:                     VkShaderStageFlags = 32 (VK_SHADER_STAGE_COMPUTE_BIT)
                pImmutableSamplers:             const VkSampler* = UNUSED
    pAllocator:                     const VkAllocationCallbacks* = NULL
    pSetLayout:                     VkDescriptorSetLayout* = EF58CF00000009EC

Thread 1, Frame 0:
vkCreatePipelineLayout(device, pCreateInfo, pAllocator, pPipelineLayout) returns VkResult VK_SUCCESS (0):
    device:                         VkDevice = 00000203B2B1AD30
    pCreateInfo:                    const VkPipelineLayoutCreateInfo* = 000000F8CC4FD910:
        sType:                          VkStructureType = VK_STRUCTURE_TYPE_PIPELINE_LAYOUT_CREATE_INFO (30)
        pNext:                          const void* = NULL
        flags:                          VkPipelineLayoutCreateFlags = 0
        setLayoutCount:                 uint32_t = 1
        pSetLayouts:                    const VkDescriptorSetLayout* = 000000F8CC4FD9C0
            pSetLayouts[0]:                 const VkDescriptorSetLayout = EF58CF00000009EC
        pushConstantRangeCount:         uint32_t = 0
        pPushConstantRanges:            const VkPushConstantRange* = NULL
    pAllocator:                     const VkAllocationCallbacks* = NULL
    pPipelineLayout:                VkPipelineLayout* = C1BFD600000009ED

Thread 1, Frame 0:
vkCreateComputePipelines(device, pipelineCache, createInfoCount, pCreateInfos, pAllocator, pPipelines) returns VkResult[00:06:12] [error] [vulkanValidationLayerCallback()] [Hexaflake\Hexaflake\Source\Rendering\Vulkan\VulkanRenderer.cpp:77]
Validation Error: [ VUID-VkComputePipelineCreateInfo-layout-07988 ] Object 0: handle = 0x2d93ac000000006f, name = Sim_CS, type = VK_OBJECT_TYPE_SHADER_MODULE; Object 1: handle = 0xc1bfd600000009ed, type = VK_OBJECT_TYPE_PIPELINE_LAYOUT; | MessageID = 0xd7bf5790 | vkCreateComputePipelines(): pCreateInfos[0].stage SPIR-V (VK_SHADER_STAGE_COMPUTE_BIT) uses descriptor [Set 0, Binding 181, variable "MinIndexInCellBufW"] (type VK_DESCRIPTOR_TYPE_STORAGE_BUFFER or VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC) but was not declared in the pipeline layout.
The Vulkan spec states: If a resource variables is declared in a shader, a descriptor slot in layout must match the shader stage (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-VkComputePipelineCreateInfo-layout-07988)
[00:06:12] [error] [vulkanValidationLayerCallback()] [Hexaflake\Hexaflake\Source\Rendering\Vulkan\VulkanRenderer.cpp:77]
Validation Error: [ VUID-VkComputePipelineCreateInfo-layout-07988 ] Object 0: handle = 0x2d93ac000000006f, name = Sim_CS, type = VK_OBJECT_TYPE_SHADER_MODULE; Object 1: handle = 0xc1bfd600000009ed, type = VK_OBJECT_TYPE_PIPELINE_LAYOUT; | MessageID = 0xd7bf5790 | vkCreateComputePipelines(): pCreateInfos[0].stage SPIR-V (VK_SHADER_STAGE_COMPUTE_BIT) uses descriptor [Set 0, Binding 192, variable "ScannedSumsSortBufR"] (type VK_DESCRIPTOR_TYPE_STORAGE_BUFFER or VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC) but was not declared in the pipeline layout.
The Vulkan spec states: If a resource variables is declared in a shader, a descriptor slot in layout must match the shader stage (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-VkComputePipelineCreateInfo-layout-07988)
 VK_SUCCESS (0):
    device:                         VkDevice = 00000203B2B1AD30
    pipelineCache:                  VkPipelineCache = 0000000000000000
    createInfoCount:                uint32_t = 1
    pCreateInfos:                   const VkComputePipelineCreateInfo* = 000000F8CC4FCFC8
        pCreateInfos[0]:                const VkComputePipelineCreateInfo = 000000F8CC4FCFC8:
            sType:                          VkStructureType = VK_STRUCTURE_TYPE_COMPUTE_PIPELINE_CREATE_INFO (29)
            pNext:                          const void* = NULL
            flags:                          VkPipelineCreateFlags = 0
            stage:                          VkPipelineShaderStageCreateInfo = 000000F8CC4FCFE0:
                sType:                          VkStructureType = VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO (18)
                pNext:                          const void* = NULL
                flags:                          VkPipelineShaderStageCreateFlags = 0
                stage:                          VkShaderStageFlagBits = 32 (VK_SHADER_STAGE_COMPUTE_BIT)
                module:                         VkShaderModule = 2D93AC000000006F [Sim_CS]
                pName:                          const char* = "AddScannedCountInCellBufSums"
                pSpecializationInfo:            const VkSpecializationInfo* = NULL
            layout:                         VkPipelineLayout = C1BFD600000009ED
            basePipelineHandle:             VkPipeline = 0000000000000000
            basePipelineIndex:              int32_t = -1
    pAllocator:                     const VkAllocationCallbacks* = NULL
    pPipelines:                     VkPipeline* = 000000F8CC4FD0D0
        pPipelines[0]:                  VkPipeline = EC129D00000009EE

And here is the SPIR-V disassembly for reference:

SPIR-V disassembly

; SPIR-V
; Version: 1.0
; Generator: Google spiregg; 0
; Bound: 630
; Schema: 0
               OpCapability Shader
               OpCapability SampledBuffer
               OpCapability ImageBuffer
               OpMemoryModel Logical GLSL450
               OpEntryPoint GLCompute %AddScannedCountInCellBufSums "AddScannedCountInCellBufSums" %gl_GlobalInvocationID %gl_WorkGroupID
               OpExecutionMode %AddScannedCountInCellBufSums LocalSize 512 1 1
               OpSource HLSL 600
               OpName %type_RWStructuredBuffer_uint "type.RWStructuredBuffer.uint"
               OpName %type_StructuredBuffer_uint "type.StructuredBuffer.uint"
               OpName %MinIndexInCellBufW "MinIndexInCellBufW"
               OpName %ScannedSumsSortBufR "ScannedSumsSortBufR"
               OpName %AddScannedCountInCellBufSums "AddScannedCountInCellBufSums"
               OpDecorate %gl_GlobalInvocationID BuiltIn GlobalInvocationId
               OpDecorate %gl_WorkGroupID BuiltIn WorkgroupId
               OpDecorate %MinIndexInCellBufW DescriptorSet 0
               OpDecorate %MinIndexInCellBufW Binding 181
               OpDecorate %ScannedSumsSortBufR DescriptorSet 0
               OpDecorate %ScannedSumsSortBufR Binding 192
               OpDecorate %_runtimearr_uint ArrayStride 4
               OpMemberDecorate %type_RWStructuredBuffer_uint 0 Offset 0
               OpDecorate %type_RWStructuredBuffer_uint BufferBlock
               OpMemberDecorate %type_StructuredBuffer_uint 0 Offset 0
               OpMemberDecorate %type_StructuredBuffer_uint 0 NonWritable
               OpDecorate %type_StructuredBuffer_uint BufferBlock
       %uint = OpTypeInt 32 0
  %uint_9504 = OpConstant %uint 9504
        %int = OpTypeInt 32 1
      %int_0 = OpConstant %int 0
     %v3uint = OpTypeVector %uint 3
%_runtimearr_uint = OpTypeRuntimeArray %uint
%type_RWStructuredBuffer_uint = OpTypeStruct %_runtimearr_uint
%_ptr_Uniform_type_RWStructuredBuffer_uint = OpTypePointer Uniform %type_RWStructuredBuffer_uint
%type_StructuredBuffer_uint = OpTypeStruct %_runtimearr_uint
%_ptr_Uniform_type_StructuredBuffer_uint = OpTypePointer Uniform %type_StructuredBuffer_uint
%_ptr_Input_v3uint = OpTypePointer Input %v3uint
       %void = OpTypeVoid
        %580 = OpTypeFunction %void
       %bool = OpTypeBool
%_ptr_Uniform_uint = OpTypePointer Uniform %uint
%MinIndexInCellBufW = OpVariable %_ptr_Uniform_type_RWStructuredBuffer_uint Uniform
%ScannedSumsSortBufR = OpVariable %_ptr_Uniform_type_StructuredBuffer_uint Uniform
%gl_GlobalInvocationID = OpVariable %_ptr_Input_v3uint Input
%gl_WorkGroupID = OpVariable %_ptr_Input_v3uint Input
     %uint_0 = OpConstant %uint 0
%AddScannedCountInCellBufSums = OpFunction %void None %580
        %581 = OpLabel
        %585 = OpLoad %v3uint %gl_GlobalInvocationID
        %586 = OpCompositeExtract %uint %585 0
        %587 = OpLoad %v3uint %gl_WorkGroupID
        %588 = OpCompositeExtract %uint %587 0
               OpSelectionMerge %629 None
               OpSwitch %uint_0 %617
        %617 = OpLabel
        %619 = OpUGreaterThanEqual %bool %586 %uint_9504
               OpSelectionMerge %621 None
               OpBranchConditional %619 %620 %621
        %620 = OpLabel
               OpBranch %629
        %621 = OpLabel
        %623 = OpAccessChain %_ptr_Uniform_uint %ScannedSumsSortBufR %int_0 %588
        %624 = OpLoad %uint %623
        %626 = OpAccessChain %_ptr_Uniform_uint %MinIndexInCellBufW %int_0 %586
        %627 = OpLoad %uint %626
        %628 = OpIAdd %uint %627 %624
               OpStore %626 %628
               OpBranch %629
        %629 = OpLabel
               OpReturn
               OpFunctionEnd

[spencer-lunarg]

thanks for all the good, simplified, details. Will try to reproduce tomorrow!

[spencer-lunarg]

So this error is happening here

I added a test in #8925 and tried with last 2 SDK and ToT main and it doesn't have the error on Window nor Linux

The only thing I could really ask here is to the have you either provide another way I can reproduce or take a look what the values were that caused binding to be null in that checking

(or set VK_LAYER_DEBUG_ACTION="VK_DBG_LAYER_ACTION_BREAK"

(also the code has since been inline here since 1.3.296 SDK )

[bitsauce]

So, I want to preface by saying that I certainly am not familiar with the internals of the validation layer, but I decided to give it a go and did a debug build of the main branch, and I've been stepping through it a bit to see what may be the source of the first validation error (the one coming from the line you linked)

So, when I get to the part of the code that calls the first vkCreateDescriptorSetLayout shown in the API dump, I see that it is passing the expected VkDescriptorSetLayoutCreateInfo argument along to DescriptorSetLayoutDef. Stepping through the DescriptorSetLayoutDef constructor also seems fine.

Then, the DescriptorSetLayoutDef is passed to descriptor_set_layout_dict.LookUp(), and stepping further it appears to reach the case InsertionState::key_found: case in the dictionary insert, though, interestingly, the retrieved node does not seem to have the same binding_to_index_map_ values as the one passed to LookUp(). Here is the first entry in both of the binding_to_index_map_ tables (for the new one with [(181, 0), (192, 1)], and the one that is already in the dict):

When I step out of the LookUp() function, and look at the binding_to_index_map_ for the retrieved element, I see that its state is now different from what is expected given the input to GetCanonicalId:

(note: these screenshots are from different runs, so addresses may differ)

So it might seem like this error only occurs whenever descriptor_set_layout_dict has a particular state before vkCreateDescriptorSetLayout is called. In fact, I did notice that it is the call(s) right before that originally overwrites idx=6 in the underlying table, so I will add those calls to this post

[bitsauce]

This is the descriptor set layout that is created right before the one that produces the validation error (along with its compute pipeline):

API dump

Thread 1, Frame 0:
vkCreateDescriptorSetLayout(device, pCreateInfo, pAllocator, pSetLayout) returns VkResult VK_SUCCESS (0):
    device:                         VkDevice = 0000017E48620110
    pCreateInfo:                    const VkDescriptorSetLayoutCreateInfo* = 000000695ADFC7F0:
        sType:                          VkStructureType = VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_CREATE_INFO (32)
        pNext:                          const void* = NULL
        flags:                          VkDescriptorSetLayoutCreateFlags = 0
        bindingCount:                   uint32_t = 2
        pBindings:                      const VkDescriptorSetLayoutBinding* = 0000052FAE090788
            pBindings[0]:                   const VkDescriptorSetLayoutBinding = 0000052FAE090788:
                binding:                        uint32_t = 1
                descriptorType:                 VkDescriptorType = VK_DESCRIPTOR_TYPE_STORAGE_BUFFER (7)
                descriptorCount:                uint32_t = 1
                stageFlags:                     VkShaderStageFlags = 32 (VK_SHADER_STAGE_COMPUTE_BIT)
                pImmutableSamplers:             const VkSampler* = UNUSED
            pBindings[1]:                   const VkDescriptorSetLayoutBinding = 0000052FAE0907A0:
                binding:                        uint32_t = 0
                descriptorType:                 VkDescriptorType = VK_DESCRIPTOR_TYPE_STORAGE_BUFFER (7)
                descriptorCount:                uint32_t = 1
                stageFlags:                     VkShaderStageFlags = 32 (VK_SHADER_STAGE_COMPUTE_BIT)
                pImmutableSamplers:             const VkSampler* = UNUSED
    pAllocator:                     const VkAllocationCallbacks* = NULL
    pSetLayout:                     VkDescriptorSetLayout* = 0000017E60AB25E0

Thread 1, Frame 0:
vkCreatePipelineLayout(device, pCreateInfo, pAllocator, pPipelineLayout) returns VkResult VK_SUCCESS (0):
    device:                         VkDevice = 0000017E48620110
    pCreateInfo:                    const VkPipelineLayoutCreateInfo* = 000000695ADFD408:
        sType:                          VkStructureType = VK_STRUCTURE_TYPE_PIPELINE_LAYOUT_CREATE_INFO (30)
        pNext:                          const void* = NULL
        flags:                          VkPipelineLayoutCreateFlags = 0
        setLayoutCount:                 uint32_t = 1
        pSetLayouts:                    const VkDescriptorSetLayout* = 0000052FAE0C0AE8
            pSetLayouts[0]:                 const VkDescriptorSetLayout = 0000017E60AB25E0
        pushConstantRangeCount:         uint32_t = 0
        pPushConstantRanges:            const VkPushConstantRange* = NULL
    pAllocator:                     const VkAllocationCallbacks* = NULL
    pPipelineLayout:                VkPipelineLayout* = 0000017E138D3B00

Thread 1, Frame 0:
vkCreateComputePipelines(device, pipelineCache, createInfoCount, pCreateInfos, pAllocator, pPipelines) returns VkResult VK_SUCCESS (0):
    device:                         VkDevice = 0000017E48620110
    pipelineCache:                  VkPipelineCache = 0000000000000000
    createInfoCount:                uint32_t = 1
    pCreateInfos:                   const VkComputePipelineCreateInfo* = 0000052FAE1304D8
        pCreateInfos[0]:                const VkComputePipelineCreateInfo = 0000052FAE1304D8:
            sType:                          VkStructureType = VK_STRUCTURE_TYPE_COMPUTE_PIPELINE_CREATE_INFO (29)
            pNext:                          const void* = NULL
            flags:                          VkPipelineCreateFlags = 0
            stage:                          VkPipelineShaderStageCreateInfo = 0000052FAE1304F0:
                sType:                          VkStructureType = VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO (18)
                pNext:                          const void* = NULL
                flags:                          VkPipelineShaderStageCreateFlags = 0
                stage:                          VkShaderStageFlagBits = 32 (VK_SHADER_STAGE_COMPUTE_BIT)
                module:                         VkShaderModule = 0000017E4CF3FBF0
                pName:                          const char* = "ScanSums"
                pSpecializationInfo:            const VkSpecializationInfo* = NULL
            layout:                         VkPipelineLayout = 0000017E138D3B00
            basePipelineHandle:             VkPipeline = 0000000000000000
            basePipelineIndex:              int32_t = -1
    pAllocator:                     const VkAllocationCallbacks* = NULL
    pPipelines:                     VkPipeline* = 000000695ADFCF70
        pPipelines[0]:                  VkPipeline = 0000017E1E74D080

In my debugging session, it seemed like this vkCreateDescriptorSetLayout call also inserted to idx=6 in the descriptor_set_layout_dict, although it was inserted as overwrite_node instead of key_found like in the case above.

[spencer-lunarg]

so this is actually likely an issue with the RobinHood hashing (our "drop in" replacement for STD unordered maps), we JUST had some other issues around this... basically you get strange behavior like this... this is great information and thanks again for trying to debug this for us!

Likely will be after Thanksgiving, but we are going to find an alternative solution to this hashing to prevent these bizarre issues