Vulkan推送常量颜色传递异常：第三个三角形未显示白色

你的问题出在推送常量的内存布局在C++和GLSL中不一致，导致颜色数组的第三个元素传递错位。

具体原因 #

Vulkan推送常量的内存布局遵循GLSL的std140规则，其中：

• vec3类型的对齐要求与vec4相同，为16字节，也就是说数组中每个vec3元素会占用16字节的空间（即使实际只用到12字节，剩下4字节会被自动填充）。
• 但C++中glm::vec3的大小是12字节，数组是连续存储，三个vec3仅占用36字节，加上glm::mat4的64字节，整个结构体大小为100字节。

而GLSL中，mat4占64字节，三个vec3每个占16字节，总大小为64 + 3×16 = 112字节。这种布局不匹配导致推送的数据错位，第三个颜色元素自然无法正确传递。

你之前添加的alignas(16)仅保证了数组的起始地址对齐16字节，但没有改变每个vec3元素的存储间隔，因此无法解决问题。

解决方案 #

有两种可靠的修正方式，任选其一即可：

方案1：在C++结构体中手动添加填充字节，匹配std140布局 #

修改C++的结构体，给每个vec3补充4字节的padding，让每个元素占用16字节：

struct MatrixesPushConstants
{
    glm::mat4 MVPmatrix;
    // 每个颜色元素带padding，匹配GLSL的16字节对齐
    struct AlignedVec3 {
        glm::vec3 color;
        float pad; // 补4字节填充
    } vertexColors[3];
};

赋值时直接操作color成员：

pushConstants[2].vertexColors[0].color = glm::vec3(1.0f, 1.0f, 1.0f);
pushConstants[2].vertexColors[1].color = glm::vec3(1.0f, 1.0f, 1.0f);
pushConstants[2].vertexColors[2].color = glm::vec3(1.0f, 1.0f, 1.0f);

GLSL代码无需修改，因为它会自动忽略padding部分，读取正确的vec3数据。

方案2：改用vec4替代vec3，统一两端类型 #

将C++和GLSL中的颜色数组都改为vec4，利用vec4天然的16字节对齐特性：

C++结构体修改：

struct MatrixesPushConstants
{
    glm::mat4 MVPmatrix;
    glm::vec4 vertexColors[3]; // 用vec4代替vec3
};

赋值时补充w分量（不影响颜色，可设为0或1）：

pushConstants[2].vertexColors[0] = glm::vec4(1.0f, 1.0f, 1.0f, 1.0f);
pushConstants[2].vertexColors[1] = glm::vec4(1.0f, 1.0f, 1.0f, 1.0f);
pushConstants[2].vertexColors[2] = glm::vec4(1.0f, 1.0f, 1.0f, 1.0f);

GLSL代码修改：

layout(push_constant) uniform MatrixesPushConstants
{
    mat4 MVPmatrix;
    vec4 vertexColors[3];
} pushConstants;

void main() {
    gl_Position = pushConstants.MVPmatrix * vec4(inPosition, 1.0);
    fragColor = pushConstants.vertexColors[gl_VertexIndex].xyz; // 取xyz分量作为颜色
}

额外验证 #

修改后，你可以打印sizeof(MatrixesPushConstants)，确认其大小为112字节（64 + 3×16），与GLSL中的布局一致，此时推送常量的数据就能正确对齐传递了。

内容的提问来源于stack exchange，提问作者lokains