many_foxes stress test example has very visible shadow artifacting

[colepoirier]

Bevy version

bevy main 9eb6928

[Optional] Relevant system information

cargo 1.61.0 (a028ae4 2022-04-29)
stable-x86_64-unknown-linux-gnu

linux mint 20.3 5.18.6-051806-generic

AdapterInfo { name: "AMD RADV RENOIR", vendor: 4098, device: 5708, device_type: IntegratedGpu, backend: Vulkan }

What you did

Run cargo r -r --example many_foxes

What went wrong

Foxes closes to the camera have grey bar artifacts instead of shadows like the foxes further from the camera:

[james7132]

Adding this to 0.8, as this would be a pretty serious shadow rendering regression.

[mockersf]

not reproduced on macOS. A vulkan issue?

[cart]

I can't repro on Linux/Vulkan/Nvidia GTX 1070 (proprietary driver):

[james7132]

This seems isolated to specific Linux drivers, and may be something upstream of Bevy. Marking down as platform specific.

[colepoirier]

Grahpics driver info

inxi -G
Graphics:
  Device-1: AMD driver: amdgpu v: kernel 
  Display: x11 server: X.Org 1.20.13 driver: amdgpu,ati 
  unloaded: fbdev,modesetting,vesa resolution: 1920x1080~60Hz 
  OpenGL: 
  renderer: AMD RENOIR (DRM 3.46.0 5.18.6-051806-generic LLVM 12.0.0) 
  v: 4.6 Mesa 21.2.6

[colepoirier]

Also worth noting that the rendering appears to be shifted down within the window which strikes me as odd/a bug. This screenshot is taken at 1920 x 1080:

[alice-i-cecile]

Clearing from the milestone as this appears to be driver-driven. @colepoirier, have you updated your graphics drivers?

[colepoirier]

Clearing from the milestone as this appears to be driver-driven. @colepoirier, have you updated your graphics drivers?

Indeed. My graphics drivers are up to date with the latest release. Unfortunately testing with dev mesa drivers isn’t something I can do without taking a pretty permanent dependency on them; last time I did this I ended up having to reinstall my whole OS to get back to released mesa deivers because of how apt package depencies seem to work 😢

[rpjohnst]

I also see this, using the v0.8.0 tag, on Windows with an AMD integrated GPU (specifically a Surface Laptop 3, which claims to have some sort of "Microsoft Edition" Ryzen), with both the Vulkan and Dx12 WGPU backends. The relevant log output:

2022-07-30T20:47:34.536221Z  INFO bevy_render::renderer: AdapterInfo { name: "AMD Radeon(TM) RX Vega11 Graphics", vendor: 4098, device: 5592, device_type: IntegratedGpu, backend: Vulkan }

A graphics debugger shows that the shadow map looks reasonably unscathed, though it has some pretty heavy banding along the floor plane that corresponds to the shape of the shadow artifacts. Maybe some sort of precision issue that only shows up on some hardware and/or drivers?

I've tried tweaking the parameters of the light and camera but haven't found any smoking guns- let me know if there's anything else I can try or collect!

[JorgeVV]

Experiencing this in a Macbook Pro 2016 on latest branch.

INFO bevy_render::renderer: AdapterInfo { name: "AMD Radeon Pro 450", vendor: 0, device: 0, device_type: DiscreteGpu, backend: Metal }

[id05]

I have same issue on both drivers + missing textures on radeon-vulkan

Arch Linux
cargo 1.64.0 (387270bc7 2022-09-16)
Kernel: 5.19.13-arch1-1

Are they suppose to be yellow?
AdapterInfo { name: "AMD Radeon Vega 8 Graphics", vendor: 4098, device: 5597, device_type: IntegratedGpu, backend: Vulkan }

AdapterInfo { name: "AMD RADV RAVEN", vendor: 4098, device: 5597, device_type: IntegratedGpu, backend: Vulkan }

[SecretPocketCat]

This issue also happens on Win 11 with RX590 on c4e791d
I updated my driver today for the newest for shadow tech, but no dice

AdapterInfo { name: "Radeon RX 590 Series", vendor: 4098, device: 26591, device_type: DiscreteGpu, driver: "AMD proprietary driver", driver_info: "22.5.1", backend: Vulkan }

many_foxes

shadow_caster_receiver - Using PointLight

shadow_biases

[superdump]

shadow_biases is meant to look like that unless you adjusted the biases to appropriate values.

[SecretPocketCat]

shadow_biases is meant to look like that unless you adjusted the biases to appropriate values.

My bad, the rest still applies though, esp. the many_foxes example.

[Elabajaba]

This was fixed for many_foxes in #7339 (the huge plane with no subdivisions was the root cause), and there's a tracking issue to look into why AMD/Nvidia/etc behave differently in #6542 (AMD iGPUs reproduce this issue at smaller plane sizes than AMD dGPUs, and Nvidia and Apple M1s can reproduce it if you use an even more massive plane than many_foxes used to use).