I completely forgot to mention.
I know my way around programming, I was a Qt developer at another job. So I don't necessary need someone else to do the patch.
A pointer to what to look for (if this is a real issue and not some strange expected behaviour that I fail to understand) could help me make a patch if necessary.

So to a certain extent this is intentional: The GPU plugin uses the DRM device number to determine what each device is. This is because of a previous bug where just blindly iterating "/dev/drm/card*" resulted in cards changing across reboots because the order wasn't necessarily fixed. See https://invent.kde.org/plasma/ksystemstats/-/blob/master/plugins/gpu/LinuxBackend.cpp?ref_type=heads#L35 for the relevant code. The reason you end up with card 2 is most likely that there's an iGPU as card 1 that we don't support.

Ultimately I think the way to solve this isn't to change the indexes or some such, but rather come up with a better way of naming these devices. It's actually rather ugly that we have "GPU x" as names and I'd prefer it if we could instead have something more like a proper device name. We do have a sensor exposing the device name from udev, but I seem to recall we don't use it because it can be rather lengthy. So it might need some extra work to come up with a scheme, but I think it would be a more proper solution.

(In reply to Arjen Hiemstra from comment #2)
> So to a certain extent this is intentional: The GPU plugin uses the DRM
> device number to determine what each device is. This is because of a
> previous bug where just blindly iterating "/dev/drm/card*" resulted in cards
> changing across reboots because the order wasn't necessarily fixed. See
> https://invent.kde.org/plasma/ksystemstats/-/blob/master/plugins/gpu/
> LinuxBackend.cpp?ref_type=heads#L35 for the relevant code. The reason you
> end up with card 2 is most likely that there's an iGPU as card 1 that we
> don't support.

That pretty strange. My CPU (Ryzen 7 3700X) doesn't have any iGPU and I removed my NVIDIA before adding the AMD GPU.
I don't have a /dev/drm/ folder, but I got a /dev/dri/ folder. I only got card1 and renderD128 in it (and a by-path folder)

I think I found something interesting
The return of the command : 
`kstatsviewer --list | grep gpu`
```
gpu/all/usage All GPUs Usage
gpu/gpu1/power1 GPU 2 PPT
gpu/gpu1/totalVram GPU 2 Total Video Memory
gpu/gpu1/temp2 GPU 2 junction
gpu GPU
gpu/gpu1/usage GPU 2 Usage
gpu/all/usedVram All GPUs Used Memory
gpu/gpu1 GPU 2
gpu/gpu1/usedVram GPU 2 Video Memory Used
gpu/gpu1/temperature GPU 2 Temperature
gpu/all/totalVram All GPUs Total Memory
gpu/gpu1/memoryFrequency GPU 2 Memory Frequency
gpu/gpu1/in0 GPU 2 vddgfx
gpu/gpu1/power GPU 2 Power
gpu/all All GPUs
gpu/gpu1/temp3 GPU 2 mem
gpu/gpu1/coreFrequency GPU 2 Frequency
gpu/gpu1/name GPU 2 Name
gpu/gpu1/fan1 GPU 2 Fan 1
```
It seems that the software is correctly detecting my gpu as gpu1, but giving it the name GPU 2

I cloned the project on my desktop and compiled it.
I see that there is three project kstatsviewer, ksystemstats and ksystemstatstest. If I want to investigate why my GPU got the name GPU 2 which one should I use (and with which argument) and do you have pointer or advice on how to set up my environment to investigate and understand why this is happening? ksystemstats seems to have a replace option that could be useful to redo the discovery phase of the sensor, I assume. But I prefer to have your advice before doing random things.

I found this merge request : https://github.com/dylanaraps/neofetch/issues/1646 for neofetch
One person sent this suggestion : glxinfo -B | grep -Po '(?<=^OpenGL renderer string: ).*(?= \(.*\)$)'
(https://github.com/dylanaraps/neofetch/issues/1646)
On my side, it seems to return a reasonable GPU name (https://github.com/dylanaraps/neofetch/issues/1646),
but I don't like the idea of relying on the output of a command to get the GPU name

(In reply to Jonathan Croteau-Dicaire from comment #5)
> I cloned the project on my desktop and compiled it.
> I see that there is three project kstatsviewer, ksystemstats and
> ksystemstatstest. If I want to investigate why my GPU got the name GPU 2
> which one should I use (and with which argument) and do you have pointer or
> advice on how to set up my environment to investigate and understand why
> this is happening?

Generally I'd recommend setting up an environment following https://community.kde.org/Get_Involved/development so that you can build all dependencies as well. That said, if you already managed to build ksystemstats that's probably fine as well, it doesn't necessarily depend on the latest version of everything. If you have a build, there is a "prefix.sh" script in the build dir that, when sourced, sets up the right environment variables so the installed application should run correctly.

>ksystemstats seems to have a replace option that could be useful to redo the discovery phase of the sensor, I assume. 

For development, I generally run with "--replace --remain", replace for replacing any running instance, remain so it doesn't quit when you don't have anything using it. Starting ksystemstats will actually redo any discovery and initialization that it needs to do for its sensors, there is no cached data.

> It seems that the software is correctly detecting my gpu as gpu1, but giving it the name GPU 2

Oh huh. That is rather odd.(In reply to Jonathan Croteau-Dicaire from comment #6)
> I found this merge request :
> https://github.com/dylanaraps/neofetch/issues/1646 for neofetch
> One person sent this suggestion : glxinfo -B | grep -Po '(?<=^OpenGL
> renderer string: ).*(?= \(.*\)$)'
> (https://github.com/dylanaraps/neofetch/issues/1646)
> On my side, it seems to return a reasonable GPU name
> (https://github.com/dylanaraps/neofetch/issues/1646),
> but I don't like the idea of relying on the output of a command to get the
> GPU name

Yeah, we don't want to be running random tools for it, however, it might be possible to figure out where glxinfo gets its name from and use that code directly. Come to think of it, glxinfo just creates an OpenGL context and reads the renderer string from that. We could actually try and do the same, or dig into where the rendering string comes from.

One somewhat more tricky case when using renderer string is dealing with things like the iGPU on my machine, which is just listed as "AMD Radeon Graphics". I also seem to recall some machines end up with even worse things like "AMD Ryzen Processor with Integrated Radeon Graphics" or somesuch, which is a little too long.

> On my side, it seems to return a reasonable GPU name (https://github.com/dylanaraps/neofetch/issues/1646),
but I don't like the idea of relying on the output of a command to get the GPU name

Actually, the name udevadm outputs is the name we already expose as the "name" sensor. Compared to the renderer string it's not the most useful however, my GPU name is currently listed as "Navi 22 [Radeon RX 6700/6700 XT/6750 XT / 6800M/6850M XT]" whereas the renderer string has the right name "AMD Radeon RX 6700 XT".

Note that you can use kstatsviewer to query ksystemstats for sensors, so "kstatsviewer gpu/gpu0/name" outputs the name sensor for me.

(In reply to Jonathan Croteau-Dicaire from comment #4)
> I think I found something interesting
> The return of the command : 
> `kstatsviewer --list | grep gpu`
> ```
> gpu/all/usage All GPUs Usage
> gpu/gpu1/power1 GPU 2 PPT
> gpu/gpu1/totalVram GPU 2 Total Video Memory
> gpu/gpu1/temp2 GPU 2 junction
> gpu GPU
> gpu/gpu1/usage GPU 2 Usage
> gpu/all/usedVram All GPUs Used Memory
> gpu/gpu1 GPU 2
> gpu/gpu1/usedVram GPU 2 Video Memory Used
> gpu/gpu1/temperature GPU 2 Temperature
> gpu/all/totalVram All GPUs Total Memory
> gpu/gpu1/memoryFrequency GPU 2 Memory Frequency
> gpu/gpu1/in0 GPU 2 vddgfx
> gpu/gpu1/power GPU 2 Power
> gpu/all All GPUs
> gpu/gpu1/temp3 GPU 2 mem
> gpu/gpu1/coreFrequency GPU 2 Frequency
> gpu/gpu1/name GPU 2 Name
> gpu/gpu1/fan1 GPU 2 Fan 1
> ```
> It seems that the software is correctly detecting my gpu as gpu1, but giving
> it the name GPU 2

The name is actually correct, the first GPU should actually be "gpu0", it uses 0-based indexing.

> That pretty strange. My CPU (Ryzen 7 3700X) doesn't have any iGPU and I removed my NVIDIA before adding the AMD GPU.
> I don't have a /dev/drm/ folder, but I got a /dev/dri/ folder. I only got card1 and renderD128 in it (and a by-path folder

Oh I confused "/dev/dri" with "/sys/class/drm", dri is the right one. Since you only have "card1" there it's actually udev already that uses the wrong index, since the first card *should* be "card0".

Thank you,
I now have a setup where I can code, compile and debug ksystemstats and the GPU plugin.

I was thinking, maybe we should count graphics card based on vendor. Instead of counting GPU 1..2..3..X we could have AMD 1, NVIDIA 1, INTEL 1 etc. I don't think we should remove the number to keep things consistent with other sensor. This would help people that have an AMD+NVIDIA and INTEL+NVIDIA or INTEL+AMD better identify which GPU is witch. The only setup where it would change "nothing" is an AMD+AMD setup. 

We could maybe also use a sort based on pci port used to keep things consistent between reboot. This solution could be implemented without doing my other suggestion.

I am not sure if I want to change the gpuId (I assume this is the string used by the monitor app to save witch gpu they report). In my case, this is because it broke when I changed my graphics card that I investigated what happened. But at the same time, we could argue that it is an udev issues and not a KDE one. But I also think that it doesn't make any sense to jump number in our numbering.
So, I am asking for your feedback on these two suggestions and if we want to change the gpuId too.

(In reply to Jonathan Croteau-Dicaire from comment #11)
> Thank you,
> I now have a setup where I can code, compile and debug ksystemstats and the
> GPU plugin.
> 
> I was thinking, maybe we should count graphics card based on vendor. Instead
> of counting GPU 1..2..3..X we could have AMD 1, NVIDIA 1, INTEL 1 etc. I
> don't think we should remove the number to keep things consistent with other
> sensor. This would help people that have an AMD+NVIDIA and INTEL+NVIDIA or
> INTEL+AMD better identify which GPU is witch. The only setup where it would
> change "nothing" is an AMD+AMD setup. 
> 
> We could maybe also use a sort based on pci port used to keep things
> consistent between reboot. This solution could be implemented without doing
> my other suggestion.
> 
> I am not sure if I want to change the gpuId (I assume this is the string
> used by the monitor app to save witch gpu they report). In my case, this is
> because it broke when I changed my graphics card that I investigated what
> happened. But at the same time, we could argue that it is an udev issues and
> not a KDE one. But I also think that it doesn't make any sense to jump
> number in our numbering.
> So, I am asking for your feedback on these two suggestions and if we want to
> change the gpuId too.

Same here. And this "GPU X" name changes between reboots on my Dell XPS 9500 with a NV card. 
It ranges randomly from "GPU 1" to "GPU 3",  so my systemmonitor widget keep losing its source.

Hi guys, any updates on this bug fix ?
Or, its fix is already on this way to KDE neon?