Compute shader throwing validation errors not present in Vulkan

[spencerkohan]

I'm attempting to create a module from the following shader:

#version 450
layout(local_size_x = 16, local_size_y = 16, local_size_z = 1) in;

layout(set = 0, binding = 0) uniform texture2D input_image;
layout(set = 0, binding = 1) uniform sampler input_sampler;
layout(set = 1, binding = 0, rgba8) uniform writeonly image2D output_image;

void main() {

    ivec2 textureSize = imageSize(output_image);
    if (gl_GlobalInvocationID.x >= textureSize.x || gl_GlobalInvocationID.y >= textureSize.y) {
        return;
    }

    ivec2 index = ivec2(gl_GlobalInvocationID.xy);
    vec2 uv = index / textureSize;

    vec4 value = texture(
        sampler2D(input_image, input_sampler),
        uv
    );

    imageStore(output_image, index, value);
}

This shader works perfectly on Vulkan, but throws a few validation errors when used with naga.

The firs is related to early return:

Function [1] 'main' is invalid
    Required uniformity of control flow for IMPLICIT_LEVEL in [31] is not fulfilled because of Return

And if I comment out that section, I get a second error:

Entry point main at Compute is invalid
Uses operations forbidden at this stage

By process of elimination, it seems to come down to the texture sampling:

vec4 value = texture(
    sampler2D(input_image, input_sampler),
    uv
);

Are these known issues, and is there any documentation about how naga's GLSL deviates from the standard?

[cwfitzgerald]

Both of these issues are technically not allowed in normal GLSL either, but compilers don't tell you about them.

Calling texture is technically not allowed in compute shaders because there are no quads (2x2 pixel structures which fragment shaders use for derivatives) to do UV derivatives with. It also isn't allowed where only some members of a quad hit the call to texture - all 4 members of the quad have to hit the point of derivatives.

[spencerkohan]

Oh interesting.

I've been able to get this to work exactly as expected by converting it to SPIR-V via Spirv-Cross before loading it - does SPIR-V have a different approach to sampling textures?

[JCapucho]

Spirv-cross seems to convert the texture call to a textureLoad call with the third argument as 0.

[JCapucho]

The first error I'm not sure but it might be related to the uniform analysis #605