Some vertex attributes and buffers are not displayed in pipeline state window

[shmadchenko]

Description

Some vertex attributes and buffers are not displayed in the pipeline state window. The problem occurs when attribute location value is larger than number of stage inputs.

Steps to reproduce

Open attached capture file capture.zip. Select vkCmdDrawIndexed command in event browser (EID 12) Open pipeline state window Open vertex input stage in pipeline window

Expected

The attributes section displays two entries

in.var.POSITION (location: 0, binding: 0)
in.var.COLOR (location: 2, binding: 1)

The buffers section displays three entries

index buffer
vertex buffers (slot: 0)
vertex buffers (slot: 1)

Actual

The attributes section displays one entry

in.var.POSITION (location: 0, binding: 0)

The buffers section displays two entries

index buffer
vertex buffers (slot: 0)

Environment

RenderDoc version: 1.33 OS: Windows 10 Graphics API: Vulkan (1.3.250.1 VK_API_VERSION_1_3)

[Zorro666]

Please can you double check your application. From what I can see in the capture file : nothing is bound to vertex buffer location 2 which is why it isn't showing. The capture only appears to bind to vertex buffer 0, 1 (unused) and the index buffer.

[shmadchenko]

I apologize in advance, my English is not very good.

EID 5: Bind vertex buffer (Buffer 164) to binding #1 This is the stub vertex buffer with data that is not in the mesh vertex buffer. In this particular case, the color value is taken from it. The stub buffer intended to be reused with different draws, so it is bound in advance.

EID 9: Bind pipeline Note that pipeline was created with vertex input state that contains

2 vertex binidig descriptions
    [0] (binding 0) : mesh vertex buffer
    [1] (binding 1) : stub vertex beffer
2 attribute descriptions
    [0] (location 0 binding 0) : position
    [1] (location 2 binding 1) : color

EID 10: Bind vertex buffer (Buffer 167) to binding #0 This is the mesh vertex buffer. In this particular case, the position value is taken from it. There is no color value in it.

Both buffers are bound and used. You can see red color that come from the stub buffer. But I don't see either the the buffer or the color attribute whose value comes from this buffer.

When I change the location value for the color attribute from 2 to 1, the problem goes away.

I tried to track the problem in the debugger. Not sure if this will be useful, but you can see that the attribute is ignored in VulkanPipelineStateViewer.cpp:1843

if(attrib < state.vertexShader.reflection->inputSignature.size())
{
name = state.vertexShader.reflection->inputSignature[attrib].varName;
usedSlot = true;
}

For your convenience, I have modified code and take an additional capture. In this case, both buffers are bound at the same time (EID 9). But the problem is still there. capture_2.zip

Also I tried looking in Nvidia Nsight. There is no such problem there. Both buffer and attribute are displayed

[shmadchenko]

You can see that both attributes are present, but according to the condition, the second attribute is not displayed

[shmadchenko]

I just realized that the buffer and the attribute are displayed if you enable 'Show Unused Items' option :neutral_face: But even in this case it looks like a bug. Because the buffer and attribute are used in fact. The color value is passed from the stub buffer to the color attribute (red color)

[shmadchenko]

I re-read your message again. Perhaps I didn't fully understand.

nothing is bound to vertex buffer location 2 The capture only appears to bind to vertex buffer 0, 1

Buffers are bound to binding. Location is used to refer to attributes. There are no relation between them. But in the process of creating a pipeline, we specify this relationship with VkPipelineVertexInputStateCreateInfo structure. In this case buffer at binding 0 used for attribute at location 0 buffer at binding 1 used for attribute at location 2

[Zorro666]

Sorry I was mistaken. You were right that code segment was wrong using the location as the attribute index is not correct.

[Zorro666]

Thank you for chasing it down. The commit is pushed and will be available in the next nightly build.