bevy: Sprites become corrupted at random as more sprites are spawned
Bevy version
0.6.1
Operating system & version
Pop!_OS 21.10
What you did
I simply had a system to spawn fireballs from a player position on click. After extensive testing, I’ve determined that any sort of sprite spawning at all has a chance to cause this, even on a fixed timestep.
What you expected to happen
Sprites should show up on the screen and work as normal.
What actually happened
The sprites gradually became corrupted at random as more sprites are spawned. As an example:
The affected sprites seem to be completely random - sometimes the fireballs are corrupted, while other times the player sprite is the one corrupted.
Additional information
My graphics card information as given by bevy:
INFO bevy_render::renderer: AdapterInfo { name: "NVIDIA GeForce GTX 960M", vendor: 4318, device: 5019, device_type: DiscreteGpu, backend: Vulkan }
I believe this may be an issue specific to my system, though I have no idea how I’d begin debugging it.
EDIT: Here’s a repo for the code that consistently reproduces the bug for me: link
About this issue
- Original URL
- State: open
- Created 2 years ago
- Comments: 29 (14 by maintainers)
Ok so the good news is … I got a repro:
The bad news is … I got a repro which means this isn’t just a problem on your machine 😃
Likely somehow related to Linux + nvidia mobile gpus with proprietary drivers?
Yeah sadly I can’t repro with your repo either on my machine. I’ll try arch+nvidia 750m+proprietary next (on my apple laptop)
Further down the line, I’ve had suspicion that this is solely with wgpu. Using textures with sizes lower than 64x64 have a high chance that it will produce the artifact, but as said before, try the same test on texture related vulkan examples in c/c++ and it should not have an issue.
The randomness of producing the artifact across runs is due to the unordered generation of textures. Plus we also need to consider that Bevy itself generates some of its own, like fallback images.
Backing this, I forgot to say that I’ve done an additional test of generating checkerboard textures from 1x1 up to 128x128 with only wgpu, and I can confirm that it matches the weird reproduction behavior with multiple textures loaded, in which some are rendered correctly and some don’t, excluding 64x64 and up which are always rendered correctly.
Again, this does not appear to be a texture data corruption, which is confirmed by doing an image to image copy, rather the texture sampler is returning wrong colors for some reason.
With regards to system configuration, I noticed that the artifact changes when using
__NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=NVIDIA_onlyvs overridingVK_ICD_FILENAMES, but I am unsure what that means.Sadly still cannot pinpoint what wgpu does under the hood which results in the artifact, but following the COPY_BYTES_PER_ROW_ALIGNMENT, which has a value of 256, seems to work which is where my theory of a minimum 64x64 texture size came from.