macchina
macchina copied to clipboard
[Idea] Get GPU info
First question, where to get the information from?
I found in the pciutils repository the following:
In runs on the following systems:
Linux (via /sys/bus/pci, /proc/bus/pci or i386 ports) FreeBSD (via /dev/pci) NetBSD (via libpci) OpenBSD (via /dev/pci) GNU/kFreeBSD (via /dev/pci) Solaris/i386 (direct port access) Aix (via /dev/pci and odmget) GNU Hurd (direct port access) Windows (direct port access, see README.Windows for caveats) CYGWIN (direct port access) BeOS (via syscalls) Haiku (via /dev/misc/poke) Darwin (via IOKit) DOS/DJGPP (via i386 ports) SylixOS (via /proc/pci)
There are many possible places to search, depending on the kernel (or operating system). But in some cases it's a matter of reading a plain text file. In order not to make the issue too long, I recommend the first part of this article. As you can see in the article, it is possible to read the vendor identifier, device identifier and class identifier.
Step two: mapping identifiers to GPUs
I quote again the previous repository, the following:
The database of PCI IDs (the pci.ids file) gets out of date much faster than I release new versions of this package, so it is maintained separately.
It lives at https://pci-ids.ucw.cz/, where you can browse the database, download the most recent pci.ids file (e.g., by running the update-ids utility) and also submit new entries.
If we go through that website, we can corroborate that the GPU information (in addition to other devices that are not relevant) can be obtained from these ID's.
At first I thought that the pci.ids
file should be downloaded regularly to keep it updated but, at least in Arch Linux, I found it in /usr/share/hwdata/pci.ids
.
I'm not sure this is the best way to solve it, but I think it can work, without relying on system commands or external crates.
Hey @PandaFoss!
Thank you for the detailed information you've provided and the great article too :smile:
If implemented correctly, I believe this is the best shot we have at correctly identifying GPU information no matter the system. If it turns out to be a lengthy implementation, then we might consider turning this into a separate crate.
My suggestion is we start with Linux, it's the first one to get new features and it's where I do all my work.
I'm a Linux user myself, so I think it's best to start there. I'm not an experienced Rust user but I'd love to contribute as much as I can.
I'm going to start working on this, most likely in a different repository, once I have a good bit of code setup, I'll share it with you and we can commence the real work.
Hey! It's been a while, but I've resumed my work on this feature :)
pci_fetch is the library that handles fetching PCI devices and soon enough it'll also integrate with pci.ids
to get the strings associated with the connected PCI devices. So as you can already tell, the library is still a work in progress.
My apologies for the month long delay it took, uni's been hectic :/
Slowly but surely imitating lspci.
@PandaFoss Feel free to take a look around the code if you'd like to contribute, I cleaned it up and made it a lot more library-use friendly.
And here's a nice little demo :smiley:
https://user-images.githubusercontent.com/35816711/123189966-a5fdf900-d496-11eb-821b-3f3563f12bba.mp4
What do you think @uttarayan21?
@PandaFoss Feel free to take a look around the code if you'd like to contribute, I cleaned it up and made it a lot more library-use friendly.
And here's a nice little demo smiley output.mp4
What do you think @uttarayan21?
Incredible work. I've been pretty busy lately but as soon as I can I'll take a closer look at the code (which from what I can see is great). Thank you!
Incredible work.
Thanks! I wish I had the time to do it sooner, this was a great experience :smile:
I've been pretty busy lately but as soon as I can I'll take a closer look at the code
Great, I'd love to hear your feedback when you're free.
@PandaFoss Feel free to take a look around the code if you'd like to contribute, I cleaned it up and made it a lot more library-use friendly.
And here's a nice little demo smiley output.mp4
What do you think @uttarayan21?
Looks really cool :+1:
But since you are using GPL-2.0 for pci_fetch, you might want to change that to MIT or Apache or any permissive license since GPL-2.0 requires you to license macchina under GPL-2.0 as well. see here
But since you are using GPL-2.0 for pci_fetch, you might want to change that to MIT or Apache or any permissive license since GPL-2.0 requires you to license macchina under GPL-2.0 as well. see here
Oh, good catch, will do!
libmacchina v0.5.0 now integrates with aparato (previously named pci_fetch), so I'll move this issue back over to macchina so we can print the new readouts.
I'm afraid the future won't be shipped until I can sort out the performance issues within aparato.
sneak peek
What's the current status on this? I'd love to help, as I have some Rust experience.
Hi @PowerBall253,
Thanks for taking interest!
aparato was originally supposed to help us determine this information, but it's been unmaintained for very long now. If you'd like to contribute, I suggest looking at other pci.ids parsers and hooking them with libmacchina, then we can add support for that readout in macchina.
Hi, I have no experience with this but I would like to work on as I would like to have that output. I would appreciate some guidance if you can point me in the right direction.
So, first I find a library which can parse pci.ids
, maybe like this one? Do I then use some other method to get the currently connected pci vga device or how do I go about this?
Hey there, nice to see you again!
Thanks for taking interest in this :)
You could iterate over the entries in /sys/bus/pci/devices/
, map those to their real name using the pci-ids
parser and filter out the graphics cards.
For example, /sys/bus/pci/devices/0000:00:14.0/class
has a value of 0x0c0330
on my machine, which the pci.ids
database maps to:
C 0c Serial bus controller <----------------- Here
00 FireWire (IEEE 1394)
00 Generic
10 OHCI
01 ACCESS Bus
02 SSA
03 USB controller <----------------- Then here
00 UHCI
10 OHCI
20 EHCI
30 XHCI <----------------- And finally, over here.
That's not a GPU, we should move on to the next PCI device (and so on and so forth).
Ok thanks for the guidance, I'll have a look at it when I have some free time for sure and come back here if I get stuck
You're welcome, thanks for stepping up to work on this feature. (no pressure, though)
I have something working. Does this issue need to be moved to libmacchina first or shall I just open a PR over there? I also have some code ready for macchina
to actually display the GPU.
You can create a PR directly :)
Since that pr has been merged to libmacchina
, is there a version update that needs to happen before I can make a pr here to utilise the new functionality? I have code ready just not sure if the crate needs an update first.
I'll get to that tomorrow.
is there a version update that needs to happen before I can make a pr here to utilise the new functionality?
Yes, the only other alternative is to point libmacchina to the git branch temporarily which you won't need to do.
Ok cool, thank you
this issue was created in may 2021, and I just needed this today, exactly when it is very close to being merged... feeling lucky!
thank you very much for the project Macchina team, and the gpu part too @Rolv-Apneseth
The newest commit related to this issue seems to be broken for me
thread 'main' panicked at 'Could not find opening square bracket for sub device: Reference RX 5700 XT', /home/user/.local/share/cargo/registry/src/index.crates.io-6f17d22bba15001f/libmacchina-6.4.0/src/linux/pci_devices.rs:86:22
It was working before and only the latest commit broke it? That's weird, but I'll have a look as it's just a matter of how the strings are being processed I think
edit: sorry misread the first time, assuming you didn't try it before then, but yes I'll have a look
He's using device 731f 1002 0b36
which doesn't have a subdevice name. We should return the device string when an opening brace can't be located.
He's using device
731f 1002 0b36
which doesn't have a subdevice name. We should return the device string when an opening brace can't be located.
Alright will do
In that case we should rename the get_sub_device_name
function to something more generic, e.g. get_device_name
.