[FEAT] CPU "code name" option

[Marzal]

Wanted features:

Having the option to show the CPU code name like CPU-X or cpufetch

Motivation:

Searching what HW encoding codecs my CPU supports on the Arch Wiki, you need to know the Code Name / Microarchitecture of your CPU.

PD: Thanks for your work in the FLOSS community

[IAmTheNerdNextDoor]

I think this could be really useful. Sometimes I want to know what MA my CPU is but I forget. Just running Fastfetch would be faster. I'd love to see this added honestly.

[x-zvf]

The main issue with implementing this, is that there is no (linux) system metric that directly provides the codenames. Instead all these tools maintain their own list, which FF would need to maintain as well.
Perhaps we can find one of these 3rdparty libraries/tools (maybe http://etallen.com/cpuid.html, but that is GPL ), which is license-compatible and where we can programmatically extract/use the database.

[Marzal]

cpufetch I think that uses that same web
https://github.com/Dr-Noob/cpufetch/blob/master/src/x86/uarch.c

• • cpuid codes are based on Todd Allen's cpuid program
• http://www.etallen.com/cpuid.html

But I also found this library in case is useful:
https://github.com/pytorch/cpuinfo/tree/main
It's BSD-2-Clause licensed

[x-zvf]

Looking more closely at etfallen's CPUID, accurate detection (especially for intel) is not something that can be done simply by checking the model and family parts of cpuid, but requires disambiguation by other values (which is why the pytorch thing is not sufficient). See, cpuid.c:1832 "intel special cases", and cpuid.c:2150 "decode_uarch_intel". Cpufetch only handles part of these, see: uarch.c:get_uarch_from_cpuid

What I believe is most reasonable, is to use ffProcessAppendStdOut and call out to the cpuid tool, if it exists and grab the '(synth) = ' line.
Alternatively, we could do what cpuinfo/cpufetch, do, but that will not be able to distinguish a lot of cpus, eg (Gracemont vs Golden Cove, Kaby Lake vs Coffee Lake), and is logic that will be pretty much impossible to test. IMO, inaccurate data is worse than not having it, which is why I would not prefer this option.

That said,your concrete issue will not be solved by my preferred solution, as this utility will almost certainly not be installed on the vast majority of systems and cpufetch's approach is likely more than good enough for your purpose of looking up stuff on wikis.

Ultimately though, this is something up to the maintainer(s), not some random like me. I can implement either approach, but I don't feel like I can make the decision here.

[Marzal]

Well no matter the decision and the outcome of it, thanks for taking the time to look into it. I see it's a complicated feature to get.

[x-zvf]

For Intel CPUs on Linux, we could use: /sys/devices/cpu/caps/pmu_name

[Marzal]

I my case with a i5-8400 Coffee Lake processor:

cat /sys/devices/cpu/caps/pmu_name
skylake

[CarterLi]

13th Gen Intel(R) Core(TM) i7-13700KF (Raptor Lake)

$ cat /sys/devices/cpu/caps/pmu_name
cat: /sys/devices/cpu/caps/pmu_name: No such file or directory
$ cat /sys/devices/cpu_core/caps/pmu_name 
alderlake_hybrid

[CarterLi]

What I believe is most reasonable, is to use ffProcessAppendStdOut and call out to the cpuid tool, if it exists and grab the '(synth) = ' line.

I'm not a fun of calling 3rd party tools, or you just do it with Command module

[x-zvf]

In that case, cpuid -1S | sed -nE 's/^.*\(synth\) = .*\[(.*)\].*$/\1/p' is probably the best thing users can put into their configurations.
I wish we could at least use the pmu_name for Intel and rely on AMD's somewhat sane uarch naming, but since it's wrong on both of your machines I don't think that's a great idea.