Wgpu: Storage buffer is almost all zeros on Windows for a mat4 array

[tuzz]

Description

Hello, I've noticed some strange behaviour with storage buffers on Windows. I don't know if there's a bug with my code (there probably is) or if it's something in wgpu.

In short, I have a storage buffer containing mat4 elements:

#version 310 es

layout(set=0, binding=0) buffer _0 { mat4 i_offset[]; };

On macOS, it's working fine. I can write data to the buffer and read it out in the shader.

On Windows, it seems to set data in the first row of the first matrix element only. All other rows contain zeros.

Setting std140 or std430 doesn't seem to help. Setting an explicit array size doesn't seem to help.

I think the alignment is correct since I'm using mat4.

Repro steps

I have a branch of some rendering code I wrote that exhibits the problem here.

You can run it with:

$ git clone https://github.com/tuzz/renderer.git
$ cd renderer
$ git checkout macosx-windows-bug
$ cargo run --example quads --features shader_compilation

The vertex shader code that uses the mat4 is here.

I'm setting the data in the storage buffer here.

(I would obviously use a vec2 for this normally but I'm trying to demonstrate the problem.)

Expected vs observed behavior

On macOS it does the correct thing. Two quads bounce around the screen and their x- and y-coordinates are changed over time:

On Windows, it is incorrect. Only the x-coordinate of the first quad is changed and the second quad doesn't move at all:

Platforms

• macOS Catalina 10.15.6, Intel Iris 640
• Window 10, Nvidia GTX 950

Thanks

[cwfitzgerald]

On my 1080ti on Windows 10 using the vulkan backend, none of the boxes move at all. Using the DX12 backend I get the result you get. I can't easily see any issues from the surface or from renderdoc.

You are currently using an older version of wgpu, so it might be advantageous to upgrade to 0.6 as it adds a lot of validation.

On further poking of renderdoc, it appears you are only binding the first 8 bytes of your buffer. Metal doesn't care about the size of a buffer binding, so that could explain why it's working on metal.

[kvark]

To clarify: your buffer range provided in BindGroupEntry doesn't cover the 2 matrices, it's too small.
In the future, we'll be doing shader sanitation, so the behavior will be exactly the same on all platforms.

[tuzz]

Ahh, thank you both! It all makes sense now.

I'm going to have to learn how to use renderdoc as I'm hopeless at debugging these things. I'll definitely upgrade. More validations sounds great.

Apologies for opening an issue due to my carelessness. Will close now.

Thanks again

[tuzz]

Quick follow up: I upgraded to 0.6.0 which wasn't too difficult and everything is working as expected.