macOS metal panic: GPU got stuck on a frame

[lordnoriyuki]

When I leave my app running a while, it sometimes (rarely) panics.

macOS, metal backend. Additionally, I'm running using wgpu-rs.

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `Ok(false)`,
 right: `Ok(true)`: GPU got stuck on a frame (image 0) :(', /Users/ln/.cargo/git/checkouts/wgpu-53e70f8674b08dd4/cf1bee3/wgpu-native/src/swap_chain.rs:190:5
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /Users/vsts/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/backtrace-0.3.29/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /Users/vsts/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/backtrace-0.3.29/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:47
   3: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:36
   4: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:200
   5: std::panicking::default_hook
             at src/libstd/panicking.rs:214
   6: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:477
   7: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:384
   8: std::panicking::begin_panic_fmt
             at src/libstd/panicking.rs:339
   9: wgpu_swap_chain_get_next_texture
             at /Users/ln/.cargo/git/checkouts/wgpu-53e70f8674b08dd4/cf1bee3/wgpu-native/src/swap_chain.rs:190
  10: wgpu::SwapChain::get_next_texture
             at /Users/ln/.cargo/git/checkouts/wgpu-rs-40ea39809c03c5d8/79b5342/src/lib.rs:1283

[DagAgren]

I have seen this happen too.

[paulkernfeld]

I've gotten this in the past. As far as I can tell, this tends to happen when I try to send too much geometry to the GPU. I am able to reproduce this on my machine by modifying create_vertices in examples/cube/main.rs from wgpu-rs to return a large number of indices: (vertex_data.to_vec(), index_data.into_iter().cycle().take(10_000_000).cloned().collect()). The stack trace that I see in debug mode is:

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `Ok(false)`,
 right: `Ok(true)`: GPU got stuck on a frame (image 1) :(', /Users/paul/.cargo/git/checkouts/wgpu-53e70f8674b08dd4/40fb3fc/wgpu-native/src/swap_chain.rs:236:5
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /Users/vsts/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/backtrace-0.3.29/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /Users/vsts/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/backtrace-0.3.29/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:47
   3: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:36
   4: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:200
   5: std::panicking::default_hook
             at src/libstd/panicking.rs:214
   6: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:477
   7: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:384
   8: std::panicking::begin_panic_fmt
             at src/libstd/panicking.rs:339
   9: wgpu_native::swap_chain::swap_chain_get_next_texture
             at /Users/paul/.cargo/git/checkouts/wgpu-53e70f8674b08dd4/40fb3fc/wgpu-native/src/swap_chain.rs:236
  10: wgpu_swap_chain_get_next_texture
             at /Users/paul/.cargo/git/checkouts/wgpu-53e70f8674b08dd4/40fb3fc/wgpu-native/src/swap_chain.rs:265
  11: wgpu::SwapChain::get_next_texture
             at src/lib.rs:1333
  12: cube::framework::run::{{closure}}
             at examples/cube/../framework.rs:148
  13: <winit::platform_impl::platform::app_state::EventLoopHandler<F,T> as winit::platform_impl::platform::app_state::EventHandler>::handle_nonuser_event
             at /Users/paul/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/winit-0.20.0-alpha3/src/platform_impl/macos/app_state.rs:61
  14: winit::platform_impl::platform::app_state::Handler::handle_nonuser_event
             at /Users/paul/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/winit-0.20.0-alpha3/src/platform_impl/macos/app_state.rs:169
  15: winit::platform_impl::platform::app_state::AppState::cleared
             at /Users/paul/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/winit-0.20.0-alpha3/src/platform_impl/macos/app_state.rs:293
  16: winit::platform_impl::platform::observer::control_flow_end_handler
             at /Users/paul/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/winit-0.20.0-alpha3/src/platform_impl/macos/observer.rs:136
  17: <unknown>
  18: <unknown>
  19: <unknown>
  20: <unknown>
  21: <unknown>
  22: <unknown>
  23: <unknown>
  24: <unknown>
  25: <unknown>
  26: <unknown>
  27: <() as objc::message::MessageArguments>::invoke
             at /Users/paul/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/objc-0.2.6/src/message/mod.rs:128
  28: objc::message::platform::send_unverified
             at /Users/paul/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/objc-0.2.6/src/message/apple/mod.rs:27
  29: objc::message::send_message
             at /Users/paul/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/objc-0.2.6/src/message/mod.rs:178
  30: winit::platform_impl::platform::event_loop::EventLoop<T>::run
             at ./<::objc::macros::msg_send macros>:14
  31: winit::event_loop::EventLoop<T>::run
             at /Users/paul/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/winit-0.20.0-alpha3/src/event_loop.rs:140
  32: cube::framework::run
             at examples/cube/../framework.rs:112
  33: cube::main
             at examples/cube/main.rs:358
  34: std::rt::lang_start::{{closure}}
             at /rustc/eae3437dfe991621e8afdc82734f4a172d7ddf9b/src/libstd/rt.rs:64
  35: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:49
  36: std::panicking::try::do_call
             at src/libstd/panicking.rs:296
  37: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:82
  38: std::panicking::try
             at src/libstd/panicking.rs:275
  39: std::panic::catch_unwind
             at src/libstd/panic.rs:394
  40: std::rt::lang_start_internal
             at src/libstd/rt.rs:48
  41: std::rt::lang_start
             at /rustc/eae3437dfe991621e8afdc82734f4a172d7ddf9b/src/libstd/rt.rs:64
  42: cube::main

Is there any more information that I could provide?

[kvark]

@paulkernfeld it is exactly the expected behavior: wgpu-rs aims to be portable, and we can't afford GPU being busy arbitrary amount of time. We have to have a timeout, and this workload triggers it.

[kvark]

@lordnoriyuki if the problem lies somewhere in the swapchain implementation (and not due to your program doing wrong stuff), then there is a high chance this will be addressed when #330 lands.

[lordnoriyuki]

@kvark you are likely right. What I'm doing is super simple and matches most of the examples. It definitely isn't a case like the @paulkernfeld example, I'm rendering a few thousand vertices right now.