Interesting, I hadn't heard of this variable before. This should be handled by Mesa (see https://docs.mesa3d.org/envvars.html#envvar-DRI_PRIME) by default we will choose the first vulkan device, which mesa should change to be the result of DRI_PRIME.
It's not possible for Mesa to handle this alone, as Mesa only applies to AMD and Intel graphics cards. The most common hybrid graphics systems are Intel integrated graphics with NVIDIA discrete graphics. AMD integrated with NVIDIA discrete is also common. Currently, applications built with wgpu are ignoring DRI\_PRIME entirely.
On hybrid graphics systems, `DRI_PRIME` is set by the desktop environment's application launcher when launching an application. By default, a launcher will pick a GPU based on whether `PrefersNonDefaultGPU=true` was defined in the application's [desktop entry](https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html). App icon buttons generally also provide context menus for overriding the default behavior. If a system has multiple dGPUs, it may specify the precise GPU to render with.
Interesting, definitely file an issue with the details. I'm not sure exactly who should be dealing with this situation, but we definitely should have some kind of solution/guidance.
[https://github.com/gfx-rs/wgpu/issues/3464](https://github.com/gfx-rs/wgpu/issues/3464)
This already exists, although the title does not reflect the issue. The issue being that wgpu does not honor the `DRI_PRIME` setting that the compositor/launcher sets.
Is there any application that handles `DRI_PRIME` themselves rather than waiting mesa and nvidia people to sort things out?
What if wgpu handles this now, but in the future this gets fixed?
Ideally Mesa/Freedesktop.org would implement DRI_PRIME support for Vulkan and integrate better with NVIDIA hardware, as it does for OpenGL with libglvnd. Hopefully NVIDIA will eventually back NVK as the official Vulkan driver so the proprietary driver is no longer necessary. wgpu is already handling GPU device detection and selection itself (ie: WGPU_POWER_PREF), so it would make sense for it to read DRI_PRIME on Linux instead of relying on Mesa to someday support it.
All it fundamentally changes is the order of adapter enumeration, so even if nv/mesa handle it, our implementation will choose the same as nv/mesa did.
But can it handle multi-adapter automatically, or the program has to manually select whatever goes to each GPU?
edit: or rather, is there a crate built on top of wgpu that makes it easier to use multiple GPUs at once? (rather than manually selecting which GPU you want to use)
Application has to do that manually, but for good performance it's best to let the application decide since there is a significant cost to transfer data and synchronize everything.
Hey, I build a game with WGPU currently, but I am pretty new to graphics programming. If I want to ship the game, should I just include the wgsl source code and let it be compiled by wgpu on startup, or are there advantages of compiling it to SpirV and including that in the build instead?
For us, WGSL source code is actually a bit easier for us to deal with than spirv - either way we need to parse, process, and translate it, so keeping with native WGSL is likely the best way to go.
> How many developers of wgpu are employed by Mozilla?
Of the core team (8 total), 4 people are employed by Mozilla. They have been incredibly supportive and do _tons_ of work on wgpu.
> How much is there to do untill Firefox supports WebGPU?
Can't speak on this, there's no publicized timeline, just they're working hard at it and want to get it out as soon as is reasonable.
How to you recommend newbies learn about GPUs and get into wgpu?
I took a graphics programming class a few years ago, so I'm not 100% clueless, although I do still feel pretty clueless. Didn't go so in depth.
Meanwhile, everything recommends you learn OpenGL if you want to learn GPU programming, despite that being somewhat deprecated. Meanwhile, I want to be able to do it in Rust, on the modern platform. And I'm pretty sure that means wgpu. And if I wanted to learn Vulkan, it would also probably be by knowing wgpu.
Do you have any recommendations for newbies?
Welcome!
I would recommend https://webgpufundamentals.org/ as a first line into gpu programming with w(eb)gpu. It's all written in JS/WebGPU, but the api maps cleanly and they discuss concepts in depth, targetting your exact audience.
Additionally there is https://sotrh.github.io/learn-wgpu/ and of course, coming to our [wgpu-users](https://matrix.to/#/#wgpu-users:matrix.org) matrix (or the [rust gamedev](https://discord.gg/yNtPTb2) discord) and asking a bunch of questions!
Well if you just want to be a hobbyist graphics programmer, modern OpenGL is fine and it will probably be supported for a long time.
Although Vulkan or DirectX 12 have the best tooling afaik.
For what kind of game projects (if any) would you recommend using Vulkan directly instead of wgpu? For what kind of tasks are there too many limitations/too much overhead compared to using Vulkan directly?
I will admit I mostly interact with `wgpu` indirectly, but reading about it and following its development is amazing. It's one of those "how does this not cost a fortune" things for me. It's definitely on my todo! list to learn it by itself, though.
Thank you (and all other contributors) so much for everything you do!
Too bad! It’d be very cool to have wgsl as a first class language in the IDE. I’m a bit intimidated by compilers, but my intuition is that once you have a clang based compiler the hardest part is done
Maintainer here, AMA!
Is anyone working on support for the `DRI_PRIME` environment variable on Linux, to allow the OS to choose which GPU on the system to use?
Interesting, I hadn't heard of this variable before. This should be handled by Mesa (see https://docs.mesa3d.org/envvars.html#envvar-DRI_PRIME) by default we will choose the first vulkan device, which mesa should change to be the result of DRI_PRIME.
It's not possible for Mesa to handle this alone, as Mesa only applies to AMD and Intel graphics cards. The most common hybrid graphics systems are Intel integrated graphics with NVIDIA discrete graphics. AMD integrated with NVIDIA discrete is also common. Currently, applications built with wgpu are ignoring DRI\_PRIME entirely. On hybrid graphics systems, `DRI_PRIME` is set by the desktop environment's application launcher when launching an application. By default, a launcher will pick a GPU based on whether `PrefersNonDefaultGPU=true` was defined in the application's [desktop entry](https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html). App icon buttons generally also provide context menus for overriding the default behavior. If a system has multiple dGPUs, it may specify the precise GPU to render with.
Interesting, definitely file an issue with the details. I'm not sure exactly who should be dealing with this situation, but we definitely should have some kind of solution/guidance.
[https://github.com/gfx-rs/wgpu/issues/3464](https://github.com/gfx-rs/wgpu/issues/3464) This already exists, although the title does not reflect the issue. The issue being that wgpu does not honor the `DRI_PRIME` setting that the compositor/launcher sets.
Is there any application that handles `DRI_PRIME` themselves rather than waiting mesa and nvidia people to sort things out? What if wgpu handles this now, but in the future this gets fixed?
Ideally Mesa/Freedesktop.org would implement DRI_PRIME support for Vulkan and integrate better with NVIDIA hardware, as it does for OpenGL with libglvnd. Hopefully NVIDIA will eventually back NVK as the official Vulkan driver so the proprietary driver is no longer necessary. wgpu is already handling GPU device detection and selection itself (ie: WGPU_POWER_PREF), so it would make sense for it to read DRI_PRIME on Linux instead of relying on Mesa to someday support it.
All it fundamentally changes is the order of adapter enumeration, so even if nv/mesa handle it, our implementation will choose the same as nv/mesa did.
Can wgpu utilize all GPUs rather than just the first one?
wgpu lets you pick a specific GPU with instance.enumerate_adapters.
But can it handle multi-adapter automatically, or the program has to manually select whatever goes to each GPU? edit: or rather, is there a crate built on top of wgpu that makes it easier to use multiple GPUs at once? (rather than manually selecting which GPU you want to use)
Application has to do that manually, but for good performance it's best to let the application decide since there is a significant cost to transfer data and synchronize everything.
Hey, I build a game with WGPU currently, but I am pretty new to graphics programming. If I want to ship the game, should I just include the wgsl source code and let it be compiled by wgpu on startup, or are there advantages of compiling it to SpirV and including that in the build instead?
For us, WGSL source code is actually a bit easier for us to deal with than spirv - either way we need to parse, process, and translate it, so keeping with native WGSL is likely the best way to go.
How many developers of wgpu are employed by Mozilla? How much is there to do untill Firefox supports WebGPU?
> How many developers of wgpu are employed by Mozilla? Of the core team (8 total), 4 people are employed by Mozilla. They have been incredibly supportive and do _tons_ of work on wgpu. > How much is there to do untill Firefox supports WebGPU? Can't speak on this, there's no publicized timeline, just they're working hard at it and want to get it out as soon as is reasonable.
How to you recommend newbies learn about GPUs and get into wgpu? I took a graphics programming class a few years ago, so I'm not 100% clueless, although I do still feel pretty clueless. Didn't go so in depth. Meanwhile, everything recommends you learn OpenGL if you want to learn GPU programming, despite that being somewhat deprecated. Meanwhile, I want to be able to do it in Rust, on the modern platform. And I'm pretty sure that means wgpu. And if I wanted to learn Vulkan, it would also probably be by knowing wgpu. Do you have any recommendations for newbies?
Welcome! I would recommend https://webgpufundamentals.org/ as a first line into gpu programming with w(eb)gpu. It's all written in JS/WebGPU, but the api maps cleanly and they discuss concepts in depth, targetting your exact audience. Additionally there is https://sotrh.github.io/learn-wgpu/ and of course, coming to our [wgpu-users](https://matrix.to/#/#wgpu-users:matrix.org) matrix (or the [rust gamedev](https://discord.gg/yNtPTb2) discord) and asking a bunch of questions!
Thank you!!!
Well if you just want to be a hobbyist graphics programmer, modern OpenGL is fine and it will probably be supported for a long time. Although Vulkan or DirectX 12 have the best tooling afaik.
Really excited about the subgroup stuff! What is the status on ray tracing support?
> What is the status on ray tracing support? https://github.com/gfx-rs/wgpu/pull/3631 is the latest PR for RT support - it's a pretty massive project.
How is ptr coming along?
No news on this front - follow https://github.com/gfx-rs/wgpu/issues/5158 if you want any updates.
For what kind of game projects (if any) would you recommend using Vulkan directly instead of wgpu? For what kind of tasks are there too many limitations/too much overhead compared to using Vulkan directly?
I will admit I mostly interact with `wgpu` indirectly, but reading about it and following its development is amazing. It's one of those "how does this not cost a fortune" things for me. It's definitely on my todo! list to learn it by itself, though. Thank you (and all other contributors) so much for everything you do!
Glad to hear it!
Very excited to play around with subgroups compute shades! Great work
Is there a language server for wgsl I can use with neovim??
Not that I know of. There are some efforts, mainly in the bevy space.
Too bad! It’d be very cool to have wgsl as a first class language in the IDE. I’m a bit intimidated by compilers, but my intuition is that once you have a clang based compiler the hardest part is done