Rendering examples crashing on AMD Radeon 5700XT (Vulkan validation)

[mpalomas]

trafficstars

Bevy version

v0.8.0

[Optional] Relevant system information

• cargo 1.62.1 (a748cf5a3 2022-06-08)
• Windows 10 Pro up to date
• AdapterInfo { name: "AMD Radeon RX 5700 XT", vendor: 4098, device: 29471, device_type: DiscreteGpu, backend: Vulkan } (latest stable Radeon Adrenaline drivers 22.7.1)

What you did

• cargo run --example sprite
• cargo run --example many_animated_sprites
• cargo run --example many_foxes

What went wrong

It crashed, both in debug and release, with some errors clearly mentioning Vulkan validation issues.

Additional information

First please note I have other apps/games using Vulkan and they work fine on my workstation/setup (Godot 4.0, Vulkan SDK...).

Here is the Bevy example crash logs:

D:\dev\gamedev\rust\bevy [main ≡]> cargo run --example sprite Finished dev [unoptimized + debuginfo] target(s) in 0.32s Running target\debug\examples\sprite.exe 2022-07-31T11:28:10.699280Z INFO bevy_render::renderer: AdapterInfo { name: "AMD Radeon RX 5700 XT", vendor: 4098, device: 29471, device_type: DiscreteGpu, backend: Vulkan } 2022-07-31T11:28:10.702256Z ERROR wgpu_hal::vulkan::instance: VALIDATION [VUID-VkDeviceCreateInfo-pNext-02830 (0x211e533b)] Validation Error: [ VUID-VkDeviceCreateInfo-pNext-02830 ] Object 0: handle = 0x230c51f0510, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0x211e533b | If the pNext chain includes a VkPhysicalDeviceVulkan12Features structure, then it must not include a VkPhysicalDevice8BitStorageFeatures, VkPhysicalDeviceShaderAtomicInt64Features, VkPhysicalDeviceShaderFloat16Int8Features, VkPhysicalDeviceDescriptorIndexingFeatures, VkPhysicalDeviceScalarBlockLayoutFeatures, VkPhysicalDeviceImagelessFramebufferFeatures, VkPhysicalDeviceUniformBufferStandardLayoutFeatures, VkPhysicalDeviceShaderSubgroupExtendedTypesFeatures, VkPhysicalDeviceSeparateDepthStencilLayoutsFeatures, VkPhysicalDeviceHostQueryResetFeatures, VkPhysicalDeviceTimelineSemaphoreFeatures, VkPhysicalDeviceBufferDeviceAddressFeatures, or VkPhysicalDeviceVulkanMemoryModelFeatures structure The Vulkan spec states: If the pNext chain includes a VkPhysicalDeviceVulkan12Features structure, then it must not include a VkPhysicalDevice8BitStorageFeatures, VkPhysicalDeviceShaderAtomicInt64Features, VkPhysicalDeviceShaderFloat16Int8Features, VkPhysicalDeviceDescriptorIndexingFeatures, VkPhysicalDeviceScalarBlockLayoutFeatures, VkPhysicalDeviceImagelessFramebufferFeatures, VkPhysicalDeviceUniformBufferStandardLayoutFeatures, VkPhysicalDeviceShaderSubgroupExtendedTypesFeatures, VkPhysicalDeviceSeparateDepthStencilLayoutsFeatures, VkPhysicalDeviceHostQueryResetFeatures, VkPhysicalDeviceTimelineSemaphoreFeatures, VkPhysicalDeviceBufferDeviceAddressFeatures, or VkPhysicalDeviceVulkanMemoryModelFeatures structure (https://vulkan.lunarg.com/doc/view/1.3.204.0/windows/1.3-extensions/vkspec.html#VUID-VkDeviceCreateInfo-pNext-02830) 2022-07-31T11:28:10.702535Z ERROR wgpu_hal::vulkan::instance: objects: (type: INSTANCE, hndl: 0x230c51f0510, name: ?) thread 'main' panicked at 'called Result::unwrap() on an Err value: Os { code: -2147417850, kind: Uncategorized, message: "Cannot change thread mode after it is set." }', C:\Users\Michael.cargo\registry\src\github.com-1ecc6299db9ec823\cpal-0.13.1\src\host\wasapi\com.rs:13:77 note: run with RUST_BACKTRACE=1 environment variable to display a backtrace error: process didn't exit successfully: target\debug\examples\sprite.exe (exit code: 101)

[pkupper]

This appears to be a duplicate of #5416.

[mpalomas]

The validation error looks similar indeed. By the way I was able to run wgpu examples from their repo without issue.

[mpalomas]

Ok, just FYI I tried to switch to the dx12 wgpu backend, and it's still failing

D:\dev\gamedev\rust\bevy [main ≡]> $env:WGPU_BACKEND="dx12" D:\dev\gamedev\rust\bevy [main ≡]> cargo run --example sprite Finished dev [unoptimized + debuginfo] target(s) in 0.33s Running target\debug\examples\sprite.exe 2022-07-31T12:41:44.395606Z INFO bevy_render::renderer: AdapterInfo { name: "AMD Radeon RX 5700 XT", vendor: 4098, device: 29471, device_type: DiscreteGpu, backend: Dx12 } thread 'main' panicked at 'called Result::unwrap() on an Err value: Os { code: -2147417850, kind: Uncategorized, message: "Cannot change thread mode after it is set." }', C:\Users\Michael.cargo\registry\src\github.com-1ecc6299db9ec823\cpal-0.13.1\src\host\wasapi\com.rs:13:77 note: run with RUST_BACKTRACE=1 environment variable to display a backtrace error: process didn't exit successfully: target\debug\examples\sprite.exe (exit code: 101)

And it seems to be the same final error message than in my log with Vulkan above.

So maybe the Vulkan validation errors are one issue, and this last error is a different one ?

[mockersf]

thread 'main' panicked at 'called Result::unwrap() on an Err value: Os { code: -2147417850, kind: Uncategorized, message: "Cannot change thread mode after it is set." }', C:\Users\Michael.cargo\registry\src\github.com-1ecc6299db9ec823\cpal-0.13.1\src\host\wasapi\com.rs:13:77

It seems the Vulkan validation errors have no actual impact and can be ignored.

The exception you have comes from the audio library cpal. Audio should run in its own thread which somehow has issues on your setup

[mpalomas]

Indeed. For the record I own a SoundblasterX G6 (it's a USB device) with latest firmware and drivers.

After a bit of Googling, it's a known issue :

• https://github.com/RustAudio/rodio/issues/214
• https://github.com/RustAudio/cpal/pull/330

With my very limited Rust and Bevy knowledge, I don't quite get it. Seems like Rodio/cpal must be on its own thread. They also say Winit behavior changed in 0.20 and could be related.

Anyway, let me know if you need me to test stuff. Strange to see only few people impacted with a rather common device.

[mockersf]

From the exception it seems you have cpal 0.13.1 (from November 2020) but the 0.13.5 has been out since January 2022 and should be compatible with Bevy.

Could you run cargo update and check if you get the latest version? Maybe that would fix it

[mpalomas]

How stupid of me... I had this local repo for months indeed, just did a git pull after the 0.8 announcement, but completely forgot about the Cargo.lock file 🤦 Well I confirm everything now works as expected with the right version of dependencies... Sorry for the trouble.

[mockersf]

Great that it works! And thanks for reporting back. Have fun with your not-crashing project now 🙂