GTK 4.15 Released With Vulkan Renderer By Default

[You-]

All 3 of my displays are hooked up to the iGPU above. It will still default to the discrete GPU as the render device.

I dont know the vkcube code and how it handles these things but see my last two posts. thats now how gnome or gtk handles them.

[Developer12]

I don think you will run into the problem here. I expect the steps to work like this:

1. The GUI (gnome-shell/mutter, or alternative compositor) will specify the GPU and start the program.
2. The program will use gtk to check the capabilities of the GPU and then choose the preferred renderer based on that.

The only way it should work otherwise is if you right click the icon in the shell and choose the option to render using the other GPU.

It's totally possible that we'll see bugs around this. I could see race conditions cropping up depending on whether the dGPU happens to be awake when stuff starts/restarts, or even with configuration since it's not obvious on an arbitrary laptop which GPU is which. Attempts at autoconfig are also probably at some point going to trip over the fact both GPUs support different things. This hardware is just a perfect storm of weirdness.

...so whenever the openGL codepaths get deprecated in the future I can continue to render the desktop on vulkan with acceptable battery life and without touching lavapipe.

The openGL codepaths haven't been deprecated yet, but will some day.

[Jumbotron]

It’s about time this is happening. It’s time to move on from the now dusty history of Unix frameworks like C and the Unix workstation (SGI) frameworks like OpenGL and old ways of doing things like shell scripts for initialization. Rust, Vulkan and Systemd and Wayland are just a few of these new frameworks to take *nix finally into the 21st century. Particularly OpenGL, this should be deprecated as soon as reasonably possible. Apple did it in 2018 with declaring their analogous version of Vulkan called Metal. Just like Apple sealed the doom of Adobe Flash by banning its use on Apple products I think we’ll see 2018 as the time that OpenGL began shuffling off its mortal coil. Long live Vulkan

[You-]

It's totally possible that we'll see bugs around this. I could see race conditions cropping up depending on whether the dGPU happens to be awake when stuff starts/restarts, or even with configuration since it's not obvious on an arbitrary laptop which GPU is which. Attempts at autoconfig are also probably at some point going to trip over the fact both GPUs support different things. This hardware is just a perfect storm of weirdness..

That's the same situation for openGL for gtk apps. Vulkan and GL use the same paths to choose the GPU. (or rather, the GPIU is chosen before gtk decided whether to use OpenGL/GLES or Vulkan).

There is a current bug open in GTK where the dgpu and the igpu have different capabilities, but that is having dmabuf passed from one gpu to another so not identical to the issue you are describing. As software, there will likely be issues all over the show, but the problem you and the others are describing were mostly fixed a very long time ago and would also be an issue if the two gpus supported different versions of OpenGL.

[Quackdoc]

I am pretty sure how gpu selection works on the desktops totally wrong. The DE chooses the GPU, not the app. The app then gets to choose what to do with the GPU it has been given by querying its capabilities.

To do it any other way, the application would require to be custom coded to detect and use all GPUs.

this isn't true at all. The application chooses the GPU. for vulkan you can hint what gpu to load using VK_LOADER_DEVICE_SELECT=0x8086:0x56a5 or even force it using other variables. With opengl it's massively just in the air, if you run glxgears -info on a desktop with multiple dedicated gpus, it will usually use "whatever gpu is first" unless you use DRI_PRIME

[billyswong]

At the end, it should be the OS setting to dominate the GPU decision, not internal codes within individual applications. For laptops, it makes sense to choose the iGPU for all programs except for the most graphically intensive. But for desktops, if one has already connected the monitor to the dGPU, utilizing the tiny iGPU for any programs is unnecessary.

[mangeek]

Big shout-out to folks who insisted that "Vulkan is good for some things, but for most purposes, OpenGL will be the right API to use". That was the consensus just two or three years ago when this idea was floated.

[Quackdoc]

Big shout-out to folks who insisted that "Vulkan is good for some things, but for most purposes, OpenGL will be the right API to use". That was the consensus just two or three years ago when this idea was floated.

I would have said this is still mostly true if wgpu didn't exist. Vulkan is still just a pain to deal with on the "individual hobbiest level". Also you do still have hardware with zero vulkan support. something like wgpu which abstracts that stuff is really nice.

[oleid]

Thankfully triangle is implementing a vulkan driver for terascale 3, so whenever the openGL codepaths get deprecated in the future I can continue to render the desktop on vulkan with acceptable battery life and without touching lavapipe.

It would seem it is progressing:

https://www.reddit.com/r/linux_gaming/comments/1bnel8i/terakan_vulkan_driver_for_terascale_amd_gpu_now/

[dragon321]

How does this work on multi-gpu systems like all AMD laptops where running a Vulkan game automatically uses the dGPU as a renderer? Does the dGPU get fired up just to render a 2D app? If that was the case, having to set MESA_VK_DEVICE_SELECT all over the place would get annoying.

In Vulkan it’s up to application to select which GPU will be used for rendering. Usually they simply choose first GPU that is able to handle what application needs but nothing stops them from adding more logic and pick another GPU. I don’t know how is this handled in GTK but nothing stops it from picking iGPU when iGPU and dGPU are both available or letting user choose by some environmental variable.