Wayland support for GPU

[RedNeath]

Hey! :D

Since I changed to elementaryOS 8.0 with Wayland, I couldn't see the GPU anymore. I had seen an issue (#355) where @stsdc talked about the GPU stats not beeing supported in Wayland yet, so I tried to add it back to the list of hardware components.

This is probably not the best way to do it, so if you have recommendations on how to improve the code, I'd be happy to make the required changes :)

Here's a screenshot, for reference:

About the implementation

A great part of the code I wrote is heavily inspired from the code used to display the GPU(s) name in elementaryOS system settings (from here).

Also, I changed my GPU when upgrading from elmentaryOS 7.1 to 8.0, so I'm not too sure the name displayed in the UI is correct. That is something to take into account as well.

[RedNeath]

Also, it may be worth trying it out with an X11 session before merging, to make sure I didn't break anything... ^^'

[stsdc]

Hi! Thanks for this PR! Indeed there is a need for a proper GPU detection. Maybe there is something in sysfs?

I'm not against Switcheroo, but I see that detected name is not short and clear.

It is worth to check Mission Center and Resources, how they do this.

[RedNeath]

Actually, looking at the debug messages, it is the split that makes the name that long.

The full name returned by Switcheroo is:

Advanced Micro Devices, Inc. [AMD®/ATI] Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT] (RX 5700 XT RAW II)

What is between the parenthesis at the end corresponds to the model of the GPU.

I've just tested in an X11 session (still elementaryOS 8.0) and it appears to still be using the Switcheroo.

Can you tell me what you would expect to be displayed in the interface (like what it looks like with a 5700XT GPU in an X11 session)?

[stsdc]

This is how master branch shows for me.

[stsdc]

Ah, sorry here is the master:

[RedNeath]

Mmh... Yeah, sysfs seems like a more reliable way of handling this.

Just in case you already sought for it, do you know any sort of database to identify the vendors and the devices?

Edit

Nevermind, I actually found it: http://pci-ids.ucw.cz/

[stsdc]

Well, this is why this issue sits there for a while ;)

But I'm wondering how Resources does it? Maybe we could replicate 🤔

[RedNeath]

Ok, so from what I've read, they base themselves on the pci.ids file.

They first parse it into a binary tree, and then use that tree to find the vendor and the device, and the subvendor and subdevice if needed as well.

https://github.com/nokyan/resources/blob/7ee450d43f93be7b6688e0c31d88f75571fc790f/src/utils/pci.rs#L218

Now though, one thing I noticed when looking at the pci.ids file: Switcheroo actually returns the concatenation of informations that can be found in the file.

Advanced Micro Devices, Inc. [AMD®/ATI] Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT] (RX 5700 XT RAW II)
^                                     ^ ^                                                 ^  ^               ^
|---------- VENDOR (0x1002) ----------| |---------------- DEVICE (0x731f) ----------------|  |               |
                                                                                             SUBVENDOR & SUBDEVICE (0x1682 ; 0x5701)

That means we are going to need to polish the output anyway if we want someting like AMD Radeon RX .... And looking at the file contents, polish is not necessarily going to be that easy to implement 🙃

	731f  Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT]
		1002 0b36  Reference RX 5700 XT
		1458 2313  Radeon RX 5700 XT Gaming OC
		1458 231d  Radeon RX 5600 XT/REV 2.0 [Windforce 6GB OC]
		148c 2398  AXRX 5700 XT 8GBD6-3DHE/OC [PowerColor Red Devil Radeon RX 5700 XT]
->		1682 5701  RX 5700 XT RAW II
		1849 5102  RX5700 CLD 8GO [ASRock Challenger D RX 5700 OC]
->		1849 5120  Radeon RX 5600 XT

[stsdc]

I think what we want to display is subvendor+subdevice.

If there is no simple way to retrieve those, then I think we need to implement PCI parser. It will be useful later for detecting multiple GPUs.

[stsdc]

Actually it doesn't show GPU on classic session too 🤯

[RedNeath]

Actually it doesn't show GPU on classic session too 🤯

You mean on eOS 8 with this "fix" or without?

Without wouldn't surprise me much, since when I was testing my code on the classic session, the Switcheroo code would get executed and my GPU being added from there instead of being added with the GNOME Session Manager. (#410 (comment))

Btw, sorry that I'm not much active on that at the moment, I just have a ton of work to do right now and I can't really focus on anything else because being late on that would penalise other people too...
If you want to move on that faster, you can ask me for any access you'd need 👍️

[stsdc]

eOS 8 without the fix on classic session.
I have not yet moved to Circe, so I didn't knew about that issue 😬
No problem there is no rush :)

[stsdc]

Mission Center uses Vulkan.

https://registry.khronos.org/vulkan/specs/latest/man/html/VK_EXT_pci_bus_info.html

Not sure if it is available in Vala 😬

[RedNeath]

From what I read, Vulkan is available in Vala (although I'm not a hundred percent confident in the source, and I haven't tested it on my own). However I'm not sure this is a good option. We could certainly gather information about the GPU (and other PCI devices) using it, but it isn't really the purpose of Vulkan.

Although it would probably be interesting later on if we want to implement some GPU control inside Monitor 🤔

Overall, unless we consider adding GPU control in the future, I think our two best options are:

1. sysfs, which would make Monitor distro-independant;
2. and Switcheroo, which will work on elementaryOS (as @danirabbit said there), but not on any other distribution that doesn't use the switcheroo-control service by default.

Now, if we want to implement the sysfs version, we'll have to figure out a right way to do it, because the pci-ids file is rather long (39k lines as of now) and will keep on getting longer as time passes, and I'm not sure that parsing it every time Monitor starts is a good idea.
Trying to identify the different use cases I get:

• Starting Monitor for the first time
• Starting Monitor for the nth time
• Starting Monitor for the nth time, having added a new GPU
• Starting Monitor for the nth time, having removed a GPU
• Starting Monitor for the nth time, having replaced a GPU for another

Tell me if you see any other (or if you think one or more are wrong too) :D

P.S.

By the way, about the switcheroo-service, I also don't know when it was added to elementaryOS, so if we decide to use it exclusively, Monitor may fail even on older versions of eOS?

[stsdc]

I don't know much about switcheroo, but I'm not sure if it also allows to get other PCI devices.

I think that sysfs is the way. And, probably, we will need to create some sort of a cache.

[danirabbit]

I would highly recommend using existing services and libraries over manually parsing files yourself 😬

[RedNeath]

Yep, I was actually reading about pci-utils (and more specifically the pcilib/libpci), thinking it probably was a better way to go than doing everything ourselves ^^'

I'm relatively new to Vala and meson though, so I was wondering if I add a dependency in the meson.build file at the root of the repo, would that be enough? Are the libraries compiled with the programme's code or does it work differently?

[danirabbit]

We have to pull in dependencies in packaging. It looks like libpci is available: https://packages.ubuntu.com/noble/libpci-dev

[stsdc]

Yes, it would be really nice to be able use this pci.h. They handle a lot of corner cases and have all these seasoned data structs. But it would need vapi file to be created.

[stsdc]

I managed to print pcilib version in Monitor in #440.
@RedNeath

[stsdc]

There is also usr/share/libdrm/amdgpu.ids. Which has more granular list of GPU names.

[stsdc]

Since Monitor is not relaying on SessionManager anymore, but it is using PCI to retrieve necessary information, it also gained Wayland support.

[RedNeath]

Do you think we could close this PR by now? 🤔

[stsdc]

yes, indeed!