False positive VUID-RuntimeSpirv-OpEntryPoint-07754

ziga-lunarg commented 2 weeks ago

Many CTS tests suddenly produce what I believe are false positive VUID-RuntimeSpirv-OpEntryPoint-07754

One of them for example is dEQP-VK.fragment_shading_barycentric.pipeline_library.data.shader_combos.with_tess_shader.type.float

This test uses vertex, tessellation and fragment shaders, but the error I'm getting says:

VUID-RuntimeSpirv-OpEntryPoint-07754(ERROR / SPEC): msgNum: 741748850 - Validation Error: [ VUID-RuntimeSpirv-OpEntryPoint-07754 ] Object 0: handle = 0x53cfee000003b28b, type = VK_OBJECT_TYPE_SHADER_MODULE; Object 1: handle = 0x21a2d2000003b28f, type = VK_OBJECT_TYPE_SHADER_MODULE; | MessageID = 0x2c363072 | vkCreateGraphicsPipelines(): pCreateInfos[0] (SPIR-V Interface) Type mismatch on Location 0 Component 0, between

VK_SHADER_STAGE_VERTEX_BIT stage: pointer to Output -> float32

VK_SHADER_STAGE_FRAGMENT_BIT stage: pointer to Input -> array[3] of struct of {

uint32

float32 }

From a quick look it seems as if the stages in cc_shader_interface.cpp:904 are not sorted propertly

ziga-lunarg commented 2 weeks ago

TEST_F(PositiveShaderSpirv, InterfaceComponents) {
    TEST_DESCRIPTION("Test matching shader interface components with multiple stages");
    AddRequiredFeature(vkt::Feature::geometryShader);
    RETURN_IF_SKIP(Init());
    InitRenderTarget();

    char const *vertSource = R"glsl(
        #version 450
        layout(location = 0) out ivec4 a;
        void main() {
            a = ivec4(1);
        }
    )glsl";

    char const *geomSource = R"glsl(
        #version 450
        layout(triangles) in;
        layout(triangle_strip) out;
        layout(location = 0) in ivec4 a[3];
        layout(location = 0) out vec4 b;
        layout(max_vertices = 3) out;

        void main() {
            b = vec4(a[0]);
            gl_Position = a[0];
            EmitVertex();

            b = vec4(a[1]);
            gl_Position = a[1];
            EmitVertex();

            b = vec4(a[2]);
            gl_Position = a[2];
            EmitVertex();

            EndPrimitive();
        }
    )glsl";

    char const *fragSource = R"glsl(
        #version 450
        layout(location = 0) in vec4 b;
        layout(location = 0) out vec4 c;
        void main() {
            c = b;
        }
    )glsl";

    VkShaderObj vert(this, vertSource, VK_SHADER_STAGE_VERTEX_BIT);
    VkShaderObj geom(this, geomSource, VK_SHADER_STAGE_GEOMETRY_BIT);
    VkShaderObj frag(this, fragSource, VK_SHADER_STAGE_FRAGMENT_BIT);

    CreatePipelineHelper pipe(*this);
    pipe.shader_stages_ = {vert.GetStageCreateInfo(), frag.GetStageCreateInfo(), geom.GetStageCreateInfo()};
    pipe.CreateGraphicsPipeline();
}

spencer-lunarg commented 2 weeks ago

the issue is we have always assumed the order in VkGraphicsPipelineCreateInfo::pStages was the correct order to check the "producer"/"consumer" for the ValidateInterfaceBetweenStages call

The new change here https://github.com/KhronosGroup/Vulkan-ValidationLayers/commit/521850d2ed6cffafa26f9dacd8d7103e873809ed has uncovered what seems like a VVL bug

KhronosGroup / Vulkan-ValidationLayers

False positive VUID-RuntimeSpirv-OpEntryPoint-07754 #8443