Trouble with GPU switcher
Opened this issue · 3 comments
After getting my hands on a computer with better specs (see: previous issue with buffer size), there seems to be problems with dual GPU systems. It seems to only identify the switcher (Optimus) rather than either Intel or Nvidia GPUs. I tried setting it manually with WGPU_ADAPTER_NAME and no change in the error message.
$ ./target/release/waragraph ./test/data/A-3105.fa.353ea42.34ee7b1.1576367.smooth.fix.gfa ./test/data/A-3105.layout.tsv
[2024-02-01T15:52:52Z WARN wgpu_hal::vulkan::instance] Disabling presentation on 'Intel(R) Graphics (RPL-S)' (id 0x55c388f227a0) because of NV Optimus (on Linux)
parsed 6793 edges
thread 'main' panicked at /home/lr/.cargo/git/checkouts/raving-wgpu-26431015070e8629/5950d19/src/lib.rs:87:77:
index out of bounds: the len is 0 but the index is 0
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
$ ./target/release/waragraph ./test/data/A-3105.fa.353ea42.34ee7b1.1576367.smooth.fix.gfa ./test/data/A-3105.layout.tsv
[2024-02-01T15:53:06Z WARN wgpu_hal::vulkan::instance] Disabling presentation on 'Intel(R) Graphics (RPL-S)' (id 0x564aa2a704c0) because of NV Optimus (on Linux)
parsed 6793 edges
thread 'main' panicked at /home/lr/.cargo/git/checkouts/raving-wgpu-26431015070e8629/5950d19/src/lib.rs:87:77:
index out of bounds: the len is 0 but the index is 0
stack backtrace:
0: rust_begin_unwind
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:645:5
1: core::panicking::panic_fmt
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/panicking.rs:72:14
2: core::panicking::panic_bounds_check
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/panicking.rs:190:5
3: raving_wgpu::State::prepare_window
4: waragraph::app::window::AppWindowState::init
5: waragraph::app::App::init_viewer_1d
6: waragraph::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
If your graph isn't too big (more than a few GBs), you might want to try the web version (/web in the web branch).
Otherwise, the web version will be updated with support for bigger graphs next week, and should work then. The native version will probably not be updated in a while.
How big will it support? I have multiple >7GB component graphs.
When it's updated, the only limit should be your physical RAM.
The current web version is limited to ~4GB memory due to Webassembly (though it should be able to handle somewhat larger GFAs as it's only the in-memory representation that's stored in the Webassembly memory, not the raw GFA)