-
Notifications
You must be signed in to change notification settings - Fork 963
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
buffer_copy_offset
Not Respected in wgpu-core
#6827
Comments
Further observation: if I make sure that the small copies are each a multiple of 16 texels (64 bytes) long, then the problem apparently does not occur. |
…single texels. This is a workaround for <gfx-rs/wgpu#6827>. However, it should significantly improve throughput too; copying single texels at a time seems to be quite expensive relative to the cost of copying additional texels.
…single texels. This is a workaround for <gfx-rs/wgpu#6827>. However, it should significantly improve throughput too; copying single texels at a time seems to be quite expensive relative to the cost of copying additional texels.
…single texels. This is a workaround for <gfx-rs/wgpu#6827>. However, it should significantly improve throughput too; copying single texels at a time seems to be quite expensive relative to the cost of copying additional texels.
Okay I think this may be a deeper problem. Turning this into a PR failed in CI. I initially thought this was because we were missing the AgilitySDK and the validation was wrong/out of date, but I think that is just masking the problem.
We aren't respecting |
copy_buffer_to_texture()
writes to the wrong location — on Apple Silicon onlybuffer_copy_offset
Not Respected in wgpu-core
Description
I use
copy_buffer_to_texture
to copy data from a buffer to single texels of a 3D texture. On my new Apple Silicon machine, and no others, data is apparently written to incorrect portions of the texture. The same problem does not occur when the entire texture is copied.Repro steps
Run these tests:
Expected vs observed behavior
The two tests should both pass, indicating identical data was written to the texture. Instead I get:
which indicates that every texel with x=0 received the data belonging to y=0 instead of the data from the correct y position. However, changing the test data size suggests that the problem has more to do with 16-byte stride than the coordinates.
In my actual application, where the single-texel writes are to arbitrary locations in a bigger texture, the incorrect writes seem to be deterministic but not following any simple pattern, unlike the output of this test. None of them has ever written garbage data; only valid data to the wrong texel.
Platform
aarch64-apple-darwin
rustc
1.83.0wgpu
23.0.1 or git 7c75ac7 (same results)The same bug does not appear on my other macOS machine with x86 CPU and macOS 14.7, nor does it appear with WebGPU.
The text was updated successfully, but these errors were encountered: