Open Dinnerbone opened 3 years ago
kvark
commented
3 years ago This is a problem with missing validation in wgpu for texture sizes. WebGPU proper needs to have a limit(s) for this, with a baseline of 8K x 8K. Your texture has one of the sizes more than 16K, so it's not very portable. DX maximum texture size is fixed at 16K.
In wgpu, we need both expose a limit, and add internal validation to check against gfx-hal limits.
parasyte
commented
2 years ago It is the case that attempting to create large textures always panics. There is no non-panicking way to try creating textures. The caller is responsible for testing the texture descriptor against device or adapter limits, which is not obvious and quite error-prone.
Would it be reasonable for Device::create_texture and friends to return Result<Texture>?
FWIW, here's the backtrace with wgpu_hal:
running 1 test
test test_large_textures ... FAILED
failures:
---- test_large_textures stdout ----
thread 'test_large_textures' panicked at 'wgpu error: Validation Error
Caused by:
In Device::create_texture
note: label = `pixels_source_texture`
Dimension 64000 value 64000 exceeds the limit of 16384
', C:\Users\jay\.cargo\registry\src\github.com-1ecc6299db9ec823\wgpu-0.11.1\src\backend\direct.rs:2195:5
stack backtrace:
0: std::panicking::begin_panic_handler
at /rustc/532d2b14c05f9bc20b2d27cbb5f4550d28343a36\/library\std\src\panicking.rs:498
1: core::panicking::panic_fmt
at /rustc/532d2b14c05f9bc20b2d27cbb5f4550d28343a36\/library\core\src\panicking.rs:107
2: wgpu::backend::direct::default_error_handler
at C:\Users\jay\.cargo\registry\src\github.com-1ecc6299db9ec823\wgpu-0.11.1\src\backend\direct.rs:2195
3: core::ops::function::Fn::call<void (*)(enum$<wgpu::Error>),tuple$<enum$<wgpu::Error> > >
at /rustc/532d2b14c05f9bc20b2d27cbb5f4550d28343a36\library\core\src\ops\function.rs:70
4: alloc::boxed::impl$46::call<tuple$<enum$<wgpu::Error> >,dyn$<wgpu::UncapturedErrorHandler,assoc$<Output,tuple$<> > > >,alloc::alloc::Global>
at /rustc/532d2b14c05f9bc20b2d27cbb5f4550d28343a36\library\alloc\src\boxed.rs:1744
5: wgpu::backend::direct::ErrorSinkRaw::handle_error
at C:\Users\jay\.cargo\registry\src\github.com-1ecc6299db9ec823\wgpu-0.11.1\src\backend\direct.rs:2183
6: wgpu::backend::direct::Context::handle_error<enum$<wgpu_core::resource::CreateTextureError> >
at C:\Users\jay\.cargo\registry\src\github.com-1ecc6299db9ec823\wgpu-0.11.1\src\backend\direct.rs:184
7: wgpu::backend::direct::impl$3::device_create_texture
at C:\Users\jay\.cargo\registry\src\github.com-1ecc6299db9ec823\wgpu-0.11.1\src\backend\direct.rs:1375
8: wgpu::Device::create_texture
at C:\Users\jay\.cargo\registry\src\github.com-1ecc6299db9ec823\wgpu-0.11.1\src\lib.rs:1802
9: pixels::builder::create_backing_texture
at .\src\builder.rs:378
10: pixels::builder::impl$0::build_impl::generator$0<pixels_mocks::Rwh>
at .\src\builder.rs:269
11: core::future::from_generator::impl$1::poll<pixels::builder::impl$0::build_impl::generator$0>
at /rustc/532d2b14c05f9bc20b2d27cbb5f4550d28343a36\library\core\src\future\mod.rs:80
12: pollster::block_on<core::future::from_generator::GenFuture<pixels::builder::impl$0::build_impl::generator$0> >
at C:\Users\jay\.cargo\registry\src\github.com-1ecc6299db9ec823\pollster-0.2.4\src\lib.rs:132
13: pixels::builder::PixelsBuilder<pixels_mocks::Rwh>::build<pixels_mocks::Rwh>
at .\src\builder.rs:320
14: pixels::Pixels::new<pixels_mocks::Rwh>
at .\src\lib.rs:199
15: test::test_large_textures
at .\tests\test.rs:8
16: test::test_large_textures::closure$0
at .\tests\test.rs:4
17: core::ops::function::FnOnce::call_once<test::test_large_textures::closure$0,tuple$<> >
at /rustc/532d2b14c05f9bc20b2d27cbb5f4550d28343a36\library\core\src\ops\function.rs:227
18: core::ops::function::FnOnce::call_once
at /rustc/532d2b14c05f9bc20b2d27cbb5f4550d28343a36\library\core\src\ops\function.rs:227
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.No, unfortunately. We settled early on to follow WebGPU error model.
Users would need to understand what limits are, and how they are applied.
Note also that wgpu doesn't internally panic, it produces an error and triggers the default error handler. That handler panics by default.
parasyte
commented
2 years ago Is this how errors are expected to be handled by callers? https://docs.rs/wgpu/latest/wgpu/struct.Device.html#method.on_uncaptured_error
kvark
commented
2 years ago Honestly, errors like this one aren't expected to be handled by callers, since they know in advance (based on limits) which textures can or can't be created. Idiomatic way of handling errors in WebGPU is via pushErrorScope. We have it implemented in Gecko, but not wgpu-rs yet. It wasn't really requested much, but we need to get to it.
Description When creating a new texture, the dx11 and dx12 backends may panic. Vulkan does not and seems to work fine. Not tested Metal.
Repro steps You can reproduce it with our project:
cargo updateto ensure you're on the latest released backends.cargo run --package exporter -- 376149_longcatgame202c.swf -g dx11You may change
-g dx11to-g dx12/etc to try other backends.Expected vs observed behavior Expected gleaming textures, not screaming gestures.
Extra materials Panic in dx11:
Panic in dx12:
Platform Windows 10 x64 gfx-backend-dx11 0.6.11 gfx-backend-dx12 0.6.11