Problems Running WGPU with Vulkan on Discreet GPU

[hendrik-s-debruin]

Hi,

I'm having trouble running WGPU with Vulkan on my discreet nvidia graphics card. As best I can tell, it doesn't seem to be a driver issue.

I am running an ArchLinux intallation, and have both an integrated Intel graphics card and a discreet Nvidia graphics card, as evidenced by running the following on my system:

$ lspci -k | grep -A 2 -E "(VGA|3D)"

Which produces:

00:02.0 VGA compatible controller: Intel Corporation CoffeeLake-H GT2 [UHD Graphics 630]
	DeviceName: Onboard - Video
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device 127e
--
01:00.0 3D controller: NVIDIA Corporation GP107M [GeForce GTX 1050 Ti Max-Q] (rev a1)
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device 127e
	Kernel driver in use: nvidia

I use PRIME GPU offloading on my system. It is verified to work by the output of the following two commands:

$ lxinfo | grep "OpenGL renderer"

Which prints:

OpenGL renderer string: Mesa Intel(R) UHD Graphics 630 (CFL GT2)

And:

$ prime-run glxinfo | grep "OpenGL renderer"

Which prints:

OpenGL renderer string: NVIDIA GeForce GTX 1050 Ti/PCIe/SSE2

Vulkan is installed and seems to be working. The command:

$ vkcube --gpu_number 0

Produces a spinning cube and prints:

Selected GPU 0: Intel(R) UHD Graphics 630 (CFL GT2), type: IntegratedGpu

While

$ vkcube --gpu_number 1

Produces a much faster spinning cube with the output:

Selected GPU 1: NVIDIA GeForce GTX 1050 Ti, type: DiscreteGpu

The above would lead me to believe that all necessary dependencies are in order. I am able to run the examples on the integrated GPU. For instances, running

$ cargo run --example cube

Produces the expected cube with fractal pattern and prints out

Using Mesa Intel(R) UHD Graphics 630 (CFL GT2) (Gl)

I am able to explicitly choose this GPU as expected by running:

$ WGPU_ADAPTER_NAME=intel cargo run --example cube

However, if I attempt to run it on the discreet GPU with:

$ WGPU_ADAPTER_NAME=nvidia cargo run --example cube

I obtain the following error message:

thread 'main' panicked at 'WGPU_ADAPTER_NAME set but no matching adapter found!', wgpu/src/util/init.rs:58:25 stack backtrace:
0: rust_begin_unwind
          at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/std/src/panicking.rs:584:5
1: core::panicking::panic_fmt
          at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/core/src/panicking.rs:142:14
2: core::panicking::panic_display
          at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/core/src/panicking.rs:72:5
3: core::panicking::panic_str
          at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/core/src/panicking.rs:56:5
4: core::option::expect_failed
          at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/core/src/option.rs:1854:5
5: core::option::Option<T>::expect
          at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/core/src/option.rs:718:21
6: wgpu::util::init::initialize_adapter_from_env
          at ./wgpu/src/util/init.rs:58:10
7: wgpu::util::init::initialize_adapter_from_env_or_default::{{closure}}
          at ./wgpu/src/util/init.rs:76:11
8: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
          at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/core/src/future/mod.rs:91:19
9: cube::framework::setup::{{closure}}
          at ./wgpu/examples/cube/../framework.rs:182:95
10: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
          at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/core/src/future/mod.rs:91:19
11: pollster::block_on
          at /home/nidhogg/.cargo/registry/src/jackfan.us.kg-1ecc6299db9ec823/pollster-0.2.5/src/lib.rs:125:15
12: cube::framework::run
          at ./wgpu/examples/cube/../framework.rs:439:17
13: cube::main
          at ./wgpu/examples/cube/main.rs:406:5
14: core::ops::function::FnOnce::call_once
          at /rustc/a8314ef7d0ec7b75c336af2c9857bfaf43002bfc/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

I've attempted to enumerate the graphics cards that WGPU finds, though I'm not very proficient with this library so I'm not fully certain this snippet is correct, with the following:

let adapters = wgpu::Instance::new(wgpu::Backends::all());
for adapter in adapters.enumerate_adapters(wgpu::Backends::all()) {
    println!("{:?}", adapter.get_info())
}

This prints out the following:

AdapterInfo { name: "Mesa Intel(R) UHD Graphics 630 (CFL GT2)", vendor: 32902, device: 0, device_type: IntegratedGpu, backend: Gl }

I would expect this to list out also my discreet GPU, and also have versions for the Vulkan backend, though these are absent here.

I found this issue by trying to run the examples from the Bevy game engine, which uses WGPU for its rendering. These failed due to Bevy's inability to find an appropriate GPU, and debugging that lead to tracing the issue upstream to WGPU. I am, however, certain that this is not an issue my with GPUs not being supported, as I have previously successfully run the same Bevy examples on the same machine on an Ubuntu partition.

At this point I don't know how to further debug this issue, since prior issues on WGPU or Bevy don't seem to solve my problem, and I haven't spotted anything of use in the Arch wiki. Any help would be greatly appreciated.

[hendrik-s-debruin]

Ok, I have found a temporary workaround for now.

I was unable to get WGPU working properly with PRIME, so I have opted for now to disable that from my system by uninstalling the package nvidia-prime. It seems that there's a lot of wrong/outdated information on the Arch wiki regarding this type of configuration.

I found the workaround by attempting to follow the wiki's guide on how to Use Nvidia graphics only.

I currently have no /etc/X11/xorg.conf. Inside /etc/X11/xorg.conf.d there is a singular file named /etc/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf with the contents:

section "outputclass"
    identifier "intel"
    matchdriver "i915"
    driver "modesetting"
endsection

section "outputclass"
    identifier "nvidia"
    matchdriver "nvidia-drm"
    driver "nvidia"
    option "allowemptyinitialconfiguration"
    option "primarygpu" "yes"
    modulepath "/usr/lib/nvidia/xorg"
    modulepath "/usr/lib/xorg/modules"
endsection

Paradoxically, this does not seem to have disabled my intel GPU, since running

 $ glxinfo | grep "OpenGL renderer"

returns

 OpenGL renderer string: Mesa Intel(R) UHD Graphics 630 (CFL GT2)

Of course, I can now no longer choose the Nvidia GPU with prime-run. Perhaps I had misunderstood the wiki, but it was my understanding that this configuration would default to Nvidia for programmes such as glxinfo.

Be that as it may, the rust snippet from before:

let adapters = wgpu::Instance::new(wgpu::Backends::all());
for adapter in adapters.enumerate_adapters(wgpu::Backends::all()) {
    println!("{:?}", adapter.get_info())
}

now returns the following output:

AdapterInfo { name: "Intel(R) UHD Graphics 630 (CFL GT2)", vendor: 32902, device: 16027, device_type: IntegratedGpu, backend: Vulkan }
AdapterInfo { name: "NVIDIA GeForce GTX 1050 Ti", vendor: 4318, device: 7311, device_type: DiscreteGpu, backend: Vulkan }
AdapterInfo { name: "Mesa Intel(R) UHD Graphics 630 (CFL GT2)", vendor: 32902, device: 0, device_type: IntegratedGpu, backend: Gl }

Perhaps as expected, the following call

$ WGPU_ADAPTER_NAME=intel cargo run --example cube

now crashes with the error:

Using Intel(R) UHD Graphics 630 (CFL GT2) (Vulkan)
thread 'main' panicked at 'index out of bounds: the len is 0 but the index is 0', wgpu/examples/cube/../framework.rs:272:17
stack backtrace:
   0: rust_begin_unwind
             at /rustc/e092d0b6b43f2de967af0887873151bb1c0b18d3/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/e092d0b6b43f2de967af0887873151bb1c0b18d3/library/core/src/panicking.rs:142:14
   2: core::panicking::panic_bounds_check
             at /rustc/e092d0b6b43f2de967af0887873151bb1c0b18d3/library/core/src/panicking.rs:84:5
   3: <usize as core::slice::index::SliceIndex<[T]>>::index
             at /rustc/e092d0b6b43f2de967af0887873151bb1c0b18d3/library/core/src/slice/index.rs:242:10
   4: core::slice::index::<impl core::ops::index::Index<I> for [T]>::index
             at /rustc/e092d0b6b43f2de967af0887873151bb1c0b18d3/library/core/src/slice/index.rs:18:9
   5: <alloc::vec::Vec<T,A> as core::ops::index::Index<I>>::index
             at /rustc/e092d0b6b43f2de967af0887873151bb1c0b18d3/library/alloc/src/vec/mod.rs:2591:9
   6: cube::framework::start
             at ./wgpu/examples/cube/../framework.rs:272:17
   7: cube::framework::run
             at ./wgpu/examples/cube/../framework.rs:440:5
   8: cube::main
             at ./wgpu/examples/cube/main.rs:406:5
   9: core::ops::function::FnOnce::call_once
             at /rustc/e092d0b6b43f2de967af0887873151bb1c0b18d3/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

However, explicitly choosing the Nvidia card with:

WGPU_ADAPTER_NAME=nvidia cargo run --example cube

works as expected and produces a cube with the Mandelbrot set.

I find the failure to select the Intel card a bit perplexing, as I can still run vkcube on both cards with

$ vkcube --gpu_number 0

and

$ vkcube --gpu_number 1

Both of these still produce the same output from before. I'm not sure whether this is an issue with my configuration, or a bug in WGPU.

I have verified that with my configuration described here the Bevy examples are also working. I am therefore opting for now to stick to my current configuration and forgo my use of prime-run.

That said, I would be very happy if anyone with any experience with prime-run would help debug my original issue.

Thanks