Panic when using a high sample count

[a1phyr]

Description Creating a texture with a high sample_count results in a panic in gpu-alloc ('attempt to subtract with overflow')

Repro steps

Run this code (using pollster):

fn main() {
    pollster::block_on(async {
        let instance = wgpu::Instance::new(wgpu::Backends::all());
        let adapter = instance.request_adapter(&wgpu::RequestAdapterOptions::default()).await.unwrap();
        let (device, _queue) = adapter.request_device(&wgpu::DeviceDescriptor::default(), None).await.unwrap();

        let _depth = device.create_texture(&wgpu::TextureDescriptor {
            label: None,
            size: wgpu::Extent3d {
                height: 600,
                width: 800,
                depth_or_array_layers: 1,
            },
            mip_level_count: 1,
            sample_count: 16,
            dimension: wgpu::TextureDimension::D2,
            format: wgpu::TextureFormat::Depth24PlusStencil8,
            usage: wgpu::TextureUsages::TEXTURE_BINDING | wgpu::TextureUsages::RENDER_ATTACHMENT,
        });
    });
}

Expected vs observed behavior This code should not panic, or at least from wgpu validation.

Extra materials This only happens with my AMD card, with NVIDIA or llvmpipe I don't get the panic. Using 4 as sample_count works as expected.

Backtrace:

thread 'main' panicked at 'attempt to subtract with overflow', /home/alphyr/.cargo/registry/src/github.com-1ecc6299db9ec823/gpu-alloc-0.5.3/src/buddy.rs:321:26
stack backtrace:
   0: rust_begin_unwind
             at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/panicking.rs:498:5
   1: core::panicking::panic_fmt
             at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/core/src/panicking.rs:116:14
   2: core::panicking::panic
             at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/core/src/panicking.rs:48:5
   3: gpu_alloc::buddy::BuddyAllocator<M>::alloc
             at /home/alphyr/.cargo/registry/src/github.com-1ecc6299db9ec823/gpu-alloc-0.5.3/src/buddy.rs:321:26
   4: gpu_alloc::allocator::GpuAllocator<M>::alloc_internal
             at /home/alphyr/.cargo/registry/src/github.com-1ecc6299db9ec823/gpu-alloc-0.5.3/src/allocator.rs:365:34
   5: gpu_alloc::allocator::GpuAllocator<M>::alloc
             at /home/alphyr/.cargo/registry/src/github.com-1ecc6299db9ec823/gpu-alloc-0.5.3/src/allocator.rs:130:9
   6: wgpu_hal::vulkan::device::<impl wgpu_hal::Device<wgpu_hal::vulkan::Api> for wgpu_hal::vulkan::Device>::create_texture
             at /home/alphyr/rust/wgpu/wgpu-hal/src/vulkan/device.rs:848:21
   7: wgpu_core::device::Device<A>::create_texture
             at /home/alphyr/rust/wgpu/wgpu-core/src/device/mod.rs:731:13
   8: wgpu_core::device::<impl wgpu_core::hub::Global<G>>::device_create_texture
             at /home/alphyr/rust/wgpu/wgpu-core/src/device/mod.rs:3389:33
   9: <wgpu::backend::direct::Context as wgpu::Context>::device_create_texture
             at /home/alphyr/rust/wgpu/wgpu/src/backend/direct.rs:1424:27
  10: wgpu::Device::create_texture
             at /home/alphyr/rust/wgpu/wgpu/src/lib.rs:1850:17
  11: gub::main::{{closure}}
             at ./src/main.rs:14:22
  12: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/core/src/future/mod.rs:84:19
  13: pollster::block_on
             at /home/alphyr/.cargo/registry/src/github.com-1ecc6299db9ec823/pollster-0.2.5/src/lib.rs:125:15
  14: gub::main
             at ./src/main.rs:2:5
  15: core::ops::function::FnOnce::call_once
             at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/core/src/ops/function.rs:227:5

Platform Debian testing with Xorg

[heavyrain266]

Wgpu doesn't support more than 4 as sample count value because thats the max supported value in the browsers, also hardware support for more than 4/8 samples is really really rare and usually exists in cards like nvidia tesla.

[cwfitzgerald]

We definitely still shouldn't be panicking though and definitely not within the allocator, we should give a normal wgpu error.