[naga/spv-in] Unknown decoration warnings for `Block` decoration

[Imberflur]

Description When naga is parsing SPIRV shaders it seems to regularly produce "Unknown decoration Block" warnings :

log screenshot

This is due to the match here not handling Block decorations. My assumption is that this is just because the spv frontend doesn't need the information from the Block decoration and that the warning could removed by having a no-op match on the Block decoration. Is this the case or is there additional behavior that needs to be implemented here?

Repro steps Provide a SPIRV shader to wgpu containing Block decoration(s).

Expected vs observed behavior Expected: No warnings Observed: Warnings, potentially unhandled decoration behavior?

Platform N/A

[IssacZhuang]

The same warning "Unknown decoration Block" I have met when using CreateShaderModule. The Spirv is generated by DirectXCompliler with the HLSL code following:

[[vk::binding(0,0)]] cbuffer Constants{
    float3 color;
};

[[vk::binding(0,1)]] Texture2D image;
[[vk::binding(1,1)]] SamplerState imageSampler;

struct VertexInput {
    float3 position : POSITION0;
    float3 color : COLOR0;
    float2 texCoord : TEXCOORD0;
};

struct VertexOutput {
    float4 clip_position : SV_POSITION;
    float3 color : COLOR0;
    float2 texCoord : TEXCOORD0;
};

VertexOutput vs_main(VertexInput model) {
    VertexOutput v2f;
    v2f.color = model.color;
    v2f.clip_position = float4(model.position, 1);
    v2f.texCoord = model.texCoord;
    return v2f;
}

float4 fs_main(VertexOutput input) : SV_Target0 {
    float4 result = float4(color, 1.0) * image.Sample(imageSampler, input.texCoord);
    // inverse gamma correction
    result = pow(result, float4(2.2, 2.2, 2.2, 2.2));
    return result;
}

The shader is working fine but has the unknown decoration warning

WGPU version 0.19.1 on Windows platform

[teoxoy]

I think we should treat the Block and BufferBlock decorations the same but we are currently using the presence of BufferBlock to indicate a storage buffer? I don't think that's necessary.

[Imberflur]

I think we should treat the Block and BufferBlock decorations the same but we are currently using the presence of BufferBlock to indicate a storage buffer? I don't think that's necessary.

What alternative approach can be used?

Since BufferBlock is just used to indicate storage buffer right now, if that is removed it won't be used for anything. So I guess this means there could be an empty match arm on Block and BufferBlock?

[teoxoy]

That's what I was thinking as well but I didn't check what issues removing that code might cause.