Running load_gltf example on integrated gpu panics.

[hymm]

Bevy version

9c79b39. before this commit things work.

Relevant system information

Works when using discrete GPU

AdapterInfo { name: "NVIDIA GeForce RTX 3070 Ti Laptop GPU", vendor: 4318, device: 9376, device_type: DiscreteGpu, driver: "NVIDIA", driver_info: "511.69", backend: Vulkan }

But fails when using integrated GPU

AdapterInfo { name: "AMD Radeon(TM) Graphics", vendor: 4098, device: 5761, device_type: IntegratedGpu, driver: "AMD proprietary driver", driver_info: "22.20.24.02", backend: Vulkan }

What you did

Ran load_gltf on the above commit on my integrated gpu on laptop causes example to crash with

2022-12-03T22:33:38.325662Z ERROR wgpu::backend::direct: Handling wgpu errors as fatal by default
thread 'Compute Task Pool (6)' panicked at 'wgpu error: Validation Error

Caused by:
    In Device::create_render_pipeline
      note: label = `pbr_opaque_mesh_pipeline`
    error matching FRAGMENT shader requirements against the pipeline
    shader global ResourceBinding { group: 0, binding: 6 } is not available in the layout pipeline layout
    storage class Storage { access: LOAD } doesn't match the shader Uniform

', C:\Users\mikeh\.cargo\registry\src\gitproxy.zycloud.tk-1ecc6299db9ec823\wgpu-0.14.2\src\backend\direct.rs:2403:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', C:\Users\mikeh\Documents\Github\bevy\crates\bevy_tasks\src\task_pool.rs:273:45
error: process didn't exit successfully: `target\debug\examples\load_gltf.exe` (exit code: 101)

Running load_gltf on discrete gpu works and running on the commit before the above works.

[mockersf]

Could you run with RUST_LOG=bevy_render=debug and report the value for AVAILABLE_STORAGE_BUFFER_BINDINGS or of max_storage_buffers_per_shader_stage?

[hymm]

 max_storage_buffers_per_shader_stage: 4294967295,
...
 Int("AVAILABLE_STORAGE_BUFFER_BINDINGS", -1)]

[mockersf]

That's... not an expected value.

I'm not sure how to handle that case, the gpu is probably not reporting the correct value. Do we clamp it to 0 and consider the integrated gpu doesn't support those buffers? But it worked before, so it does. Then do we clamp it to i32::MAX? That could lead to issues later when someone tries to use 10000 buffers...
Or add an option to have u32 shader defs and just ignore the problem for now?

[robtfm]

i'd advocate for a ShaderDefVal::UInt (which still just outputs the number, no trailing "u" so it can be used in glsl and wgsl).

it seems fair to me to report "no specific limit on storage buffers" using u32::MAX. obviously there'll be practical limits from total bindings, gpu memory, etc but this card is just saying it doesn't have any lower limit specifically for storage buffers.