cloudhead / cloudhead/rgx.legacy
Threaded example panics on Linux
- Dominant language
- Rust
- Stars
- 193
- Forks
- 13
- PR merge metrics
- No merged PRs in 30d
Description
My engine that I based on rgx is panicing on linux. All of the examples work fine *except* the threaded example. Here's the backtrace:
```
thread '' panicked at 'assertion failed: `(left == right)`
left: `0`,
right: `1`', /home/ecton/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.4.3/src/command/mod.rs:266:23
stack backtrace:
0: backtrace::backtrace::libunwind::trace
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
1: backtrace::backtrace::trace_unsynchronized
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
2: std::sys_common::backtrace::_print_fmt
at src/libstd/sys_common/backtrace.rs:78
3: ::fmt
at src/libstd/sys_common/backtrace.rs:59
4: core::fmt::write
at src/libcore/fmt/mod.rs:1069
5: std::io::Write::write_fmt
at src/libstd/io/mod.rs:1504
6: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:62
7: std::sys_common::backtrace::print
at src/libstd/sys_common/backtrace.rs:49
8: std::panicking::default_hook::{{closure}}
at src/libstd/panicking.rs:198
9: std::panicking::default_hook
at src/libstd/panicking.rs:218
10: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:511
11: rust_begin_unwind
at src/libstd/panicking.rs:419
12: std::panicking::begin_panic_fmt
at src/libstd/panicking.rs:373
13: as core::ops::index::Index>::index
at /home/ecton/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.4.3/src/hub.rs:120
14: wgpu_native::command::command_encoder_begin_render_pass::{{closure}}
at /home/ecton/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.4.3/src/command/mod.rs:266
15: core::option::Option::map
at /home/ecton/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/option.rs:456
16: wgpu_native::command::command_encoder_begin_render_pass
at /home/ecton/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.4.3/src/command/mod.rs:264
17: wgpu_command_encoder_begin_render_pass
at /home/ecton/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.4.3/src/command/mod.rs:739
18: wgpu::CommandEncoder::begin_render_pass
at /home/ecton/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-0.4.0/src/lib.rs:1059
19: rgx::core::Pass::begin
at src/core/mod.rs:837
20: rgx::core::Frame::pass
at ./src/core/mod.rs:794
21: threaded::main::{{closure}}
at examples/threaded.rs:68
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
```
If I enable Vsync, the panic goes away both in the example and in my code. I attempted to investigate updating rgx to wgpu 0.5 to see if that would help, but there are significant API changes that I wasn't sure how to handle.
Contributor guide
Research direction
Run examples/threaded.rs on Linux with Vsync disabled and RUST_BACKTRACE=full, then inspect the call path through src/core/mod.rs at Frame::pass and Pass::begin. Compare the behavior with Vsync enabled and review the reported wgpu 0.4.0/0.4.3 interaction; done means the threaded example no longer panics without requiring Vsync.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- computer-graphics, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100