Writing to storage image views on 2DArray images in compute shader only writes to the first slice

[Wallinator]

image and view binding

    height.out_img = sg.make_image({
            usage = { storage_image = true },
            width = OFFSCREEN_WIDTH,
            height = OFFSCREEN_WIDTH,
            pixel_format = .R32UI,
            type = .ARRAY,
            //type = ._3D,
            num_slices = mip_levels
        })

    height.clear.bind.views[VIEW_out_clear] = sg.make_view({
        storage_image = { image = height.out_img }
    })

    height.mipmap.bind.views[VIEW_out_height_map] = sg.make_view({
        storage_image = { image = height.out_img }
    })

shader

layout(binding=1, r32ui) uniform uimage2DArray out_height_map;
    
void main() {
    ivec3 pos = ivec3(gl_GlobalInvocationID.xyz);

	uvec4 height = texelFetch(usampler2D(in_height_draw, cs_smp), pos.xy, 0);
    
    if (pos.x >= resolution.x || pos.y >= resolution.y || pos.z >= mip_levels) {
        return;
    }

    int mip = pos.z;

    float mult = pow(2., float(mip));

    ivec2 mip_pos = pos.xy >> mip;

    imageAtomicMax(out_height_map, ivec3(mip_pos, mip), height.r);

	return;
}

Hi im pretty new to graphics programming so im not sure if this is a limit of one of the backends or a bug or im using the API wrong.

I'm using the Odin bindings for SOKOL and im trying to write to multiple slices of a image2dArray in a single dispatch of a compute shader, using the Z to switch 2DArray slices, However, only the first slice is being written to.

I can change which slice is being written to using the slice parameter in the storage image Image_View_desc, but it seems like I don't have access to the entire 3rd dimension

I've tried using the _3D type instead, but it still only writes to the slice Z=0, and I can't specify a slice in the storage image Image_View_desc for a 3D image.

Is this a bug? or a limitation I just have to work around by using multiple dispatches and binding each slice to separate views

[floooh]

Accessing multiple slices in the same dispatch call / shader invocation currently isn't supported since storage-image-views cannot select a slice range, only pick a single slice - and I'm not sure if that feature would be portable across all backends.

You'll basically need to create a view object for each slice you want to access in the compute shader and for each slice do a separate sg_apply_bindings() / sg_dispatch() call.

In the GLSL shader you'd use a regular 2D image, e.g.:

layout(binding=0, rgba8) uniform writeonly image2D cs_out_tex;

...with the matching image*() call, e.g. I think this would be the correct one:

uint imageAtomicMax(gimage2D image, ivec2 P, uint data);

E.g. storage image views for array-, cube- and 3D-textures are used as image2D in the shader since you need to pick a single 2D slice when creating the storage image view object.

Having said that - there's currently no sample code which uses a compute shader to write to array or 3d slices, so there's also still the possibility of implementation bugs.

[Wallinator]

Thanks for the fast reply!
Given what you said, it sounds like expected behaviour and not a bug in my case.

I wonder if either the validation layer or the shader tool should produce an error/warning when attempting to reference an array or 3D writeonly image in the shader, basically enforce the texture to be accessed as a 2Dimage to make it clear?
EDIT: This can't work, the image type in the shader needs to match the storage image type, you just need to zero the Z coordinate for functions that work with it.

Or even updating the documentation around compute shaders or storage image views to state the limitation.