gfx-rs
Some Sokol WebGPU demos have wildly misplaced vertex geometry on macOS
Description copied from https://bugzilla.mozilla.org/show_bug.cgi?id=1947823, filed by @ErichDonGubler:
Some entries from the Sokol demos' WebGPU variants have some wildly misplaced vertices.
Steps to reproduce
Open a demo that is known to exhibit this behavior in Firefox. Observe broken geometry.
The sbuftex and ozz-storagebuffer entries are the two examples I'm currently aware of that follow this.
Compare the entry selected in the previous step in Chrome. Observe that the demo functions as expected.
I looked at this while working on #7410 to see if it could be the same or a closely related issue, but that doesn't appear to be the case -- it looks like these samples are not providing vertex buffer definitions at all. It seems like we need to do bounds checks against the runtime-determined bound buffer size, but are instead doing a bounds check against a fixed size of 1 (in the case of the sbuftex vertex shader, at least).
Is this reproducible with WGPU? It's not clear if this is a Firefox problem, or a WGPU-specific problem. That's why I hadn't filed an equivalent issue here yet. 😅
It seemed likely to me to be a naga issue (the bounds check against a fixed size of 1 seems pretty clearly incorrect), but I don't have a standalone test case for the actual rendering. I was thinking that the interaction with bounds check modes could be a reason that other wgpu users haven't run into it.
Please check my most recent comment: https://bugzilla.mozilla.org/show_bug.cgi?id=1947823#c14
I think that comment identifies the problem (the problem occurs when the WGSL struct size used in a storage buffer array isn't a multiple of 16 - not sure if aligning the whole struct to 16 bytes would have the same effect - at least SPIRVCross just fills up the MSL struct with explicit padding bytes to make the size of multiple of 16 bytes).
This appears to be resolved on the latest Firefox Nightly for macOS. Is there any scope left to handle in this bug report? Maybe this was fixed by #7804, which got consumed in Firefox just a few days ago?
I can confirm that those issues are fixed in FF Nightly on macOS (testing here with version 142.0a1 (2025-07-05) (aarch64).