Android enters unreachable code: ERROR_FRAGMENTED_POOL

[beicause]

Description
wgpu v30.0.1 on Android panics because enters unreachable code: vk::Result::ERROR_FRAGMENTED_POOL

wgpu/wgpu-hal/src/vulkan/descriptor.rs

Line 208 in c268540

Err(vk::Result::ERROR_FRAGMENTED_POOL) => unreachable!(),

Repro steps
Run bevy 0.20-dev mobile example on Android

Expected vs observed behavior
It panics, while it didn't use to be with wgpu v29

Extra materials

2026-09-04 21:35:03.182 17595-17621 RustStdoutStderr        org.bevyengine.example               I  
2026-09-04 21:35:03.182 17595-17621 RustStdoutStderr        org.bevyengine.example               I  thread 'Compute Task Pool (2)' (17629) panicked at 
/kache
/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wgpu-hal-30.0.1/src/vulkan/descriptor.rs:208:55:
2026-09-04 21:35:03.182 17595-17621 RustStdoutStderr        org.bevyengine.example               I  internal error: entered unreachable code
2026-09-04 21:35:03.182 17595-17621 RustStdoutStderr        org.bevyengine.example               I  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Platform
Android mali G76, wgpu v30.0.1

---

I asked AI about this issue and it said it may be a regression from #9161 and:

AI answer

Title: Vulkan panics with unreachable!() on VK_ERROR_FRAGMENTED_POOL in the v30 descriptor pool allocator

Summary

wgpu-hal v30's new Vulkan descriptor allocator (wgpu-hal/src/vulkan/descriptor.rs, new in v30, still present on trunk) treats VK_ERROR_FRAGMENTED_POOL / VK_ERROR_OUT_OF_POOL_MEMORY from vkAllocateDescriptorSets as unreachable!(), hard-crashing the process. v29 handled both as recoverable errors.

Environment

• wgpu 30.0.1, Bevy 0.20.0-dev (examples/mobile), Android 16 (API 36), Adreno 730
• Driver version: [fill in]

What happened

During pipeline creation on a worker thread:

thread 'Compute Task Pool (2)' panicked at wgpu-hal-30.0.1/src/vulkan/descriptor.rs:208:55:
internal error: entered unreachable code

Why

Err(vk::Result::ERROR_FRAGMENTED_POOL) => unreachable!(),   // descriptor.rs:208
Err(vk::Result::ERROR_OUT_OF_POOL_MEMORY) => unreachable!(), // descriptor.rs:196

The Vulkan spec's "same-shape pools don't fragment" guarantee exists, but the spec also says: "If an allocation failure occurs due to fragmentation, an application can create an additional descriptor pool [and retry]" — and instructs apps to treat unexpected allocation errors as VK_ERROR_FRAGMENTED_POOL and retry with a fresh pool. So the correct recovery is "new pool + retry", not panic. Adreno in particular returns FRAGMENTED_POOL on update-after-bind pools, which drivers cannot defragment.

In v29 this same driver behavior was mapped to a recoverable gpu_descriptor::DeviceAllocationError::FragmentedPool — this looks like a regression from the v30 descriptor-pool rewrite.

Suggested fix

On VK_ERROR_FRAGMENTED_POOL / VK_ERROR_OUT_OF_POOL_MEMORY: create a fresh pool for the bucket and retry the allocation (bounded); if that also fails, return DeviceError::OutOfMemory instead of panicking.

Info requested

• Full backtrace (RUST_BACKTRACE=1)
• Device/driver version (Build.FINGERPRINT / vulkaninfo)