fastfetch icon indicating copy to clipboard operation
fastfetch copied to clipboard

[FEAT] CPU "code name" option

Open Marzal opened this issue 1 year ago • 10 comments

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

Marzal avatar Jan 11 '25 15:01 Marzal

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.

IAmTheNerdNextDoor avatar Jan 11 '25 15:01 IAmTheNerdNextDoor

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.

x-zvf avatar Apr 17 '25 18:04 x-zvf

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

Marzal avatar Apr 17 '25 19:04 Marzal

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.

x-zvf avatar Apr 18 '25 08:04 x-zvf

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.

Marzal avatar Apr 18 '25 09:04 Marzal

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

x-zvf avatar Apr 18 '25 09:04 x-zvf

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

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

Marzal avatar Apr 18 '25 11:04 Marzal

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 avatar Apr 18 '25 11:04 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

CarterLi avatar Apr 18 '25 11:04 CarterLi

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.

x-zvf avatar Apr 18 '25 12:04 x-zvf