adding-new-intel-cpuids #334

rrwinterton · 2025-10-21T00:37:56Z

this PR is to add new Intel Processors that are not included in the cpuinfo. This includes the detection of Alder Lake, Meteor Lake, Arrow Lake, Lunar Lake and Panther Lake mobile platforms as well as Sapphire Rapids and Granite Rapid Server/Workstations

Changed the processor names to the microarchtecture names for consistency and accuracy.

fbarchard · 2025-10-28T22:20:31Z

src/x86/uarch.c

-						case 0xBE: // Alder Lake-N
-							return cpuinfo_uarch_gracemont;
+						case 0x8F: // Sapphire Rapids (Golden Cove)
+							return cpuinfo_uarch_golden_cove;


remove - all golden cove can share one return

fbarchard · 2025-10-28T22:20:51Z

src/x86/uarch.c

+						case 0xBE: // Alder Lake N / Raptor Lake N (Golden Cove)
+						    return cpuinfo_uarch_gracemont;
+						case 0xAD: // Granite Rapids (Redood Cove)
+							return cpuinfo_uarch_redwood_cove;


remove. ditto

fbarchard · 2025-10-28T22:21:42Z

src/x86/uarch.c

+						case 0xB5: // Arrow Lake U
+						case 0xC5: // Arrow Lake P
+						case 0xC6: // Arrow Lake S/HX
+							return cpuinfo_uarch_lion_cove;


fbarchard · 2025-10-28T22:22:13Z

tools/cpu-info.c

+			return "Lion Cove";
+		case cpuinfo_uarch_cougar_cove:
+			return "Cougar Cove";
+		case cpuinfo_uarch_skymont:


hmmm... there are no skymont stand alone soc?
I guess code aiming at lunarlake could check for skymont or lioncove

Removed redundant return for Lunar Lake and adjusted case order.

fbarchard · 2025-11-04T20:15:54Z

Needs another reviewer to approve

GregoryComer · 2025-11-06T23:03:56Z

@rrwinterton Can you resolve the clang format errors and rebase? I can merge once checks are green. The CMake failures are caused by CMake 4.x dropping support for older versions and should be resolved on the latest main. Thanks!

clang-format job: https://github.com/pytorch/cpuinfo/actions/runs/19049667827/job/54608194604?pr=334

fbarchard · 2025-11-14T22:05:12Z

@rrwinterton Can you resolve the clang format errors and rebase? I can merge once checks are green. The CMake failures are caused by CMake 4.x dropping support for older versions and should be resolved on the latest main. Thanks!

clang-format job: https://github.com/pytorch/cpuinfo/actions/runs/19049667827/job/54608194604?pr=334

In your link clang format points to the end of line:

./include/cpuinfo.h:358:64: error: code should be clang-formatted [-Wclang-format-violations]
        /** Intel Golden Cove microarchitecture (Alder Lake P-Core) */
                                                                      ^

Failed on file: ./include/cpuinfo.h
./src/x86/uarch.c:202:49: error: code should be clang-formatted [-Wclang-format-violations]
                                                case 0xBF: // Raptor Lake HX (Golden Cove)
                                                                                          ^
./src/x86/uarch.c:204:63: error: code should be clang-formatted [-Wclang-format-violations]
                                                case 0xBE: // Alder Lake N / Raptor Lake N (Golden Cove)
                                                                                                        ^
./src/x86/uarch.c:216:33: error: code should be clang-formatted [-Wclang-format-violations]
                                                case 0xCC: // Panther Lake 
                                                                          ^

Failed on file: ./src/x86/uarch.c

Do you know specifically if the issue is CR/LF vs NL?
Or the trailing space on Panther Lake?
Or does it want a . (pediod) at the end of each comment?
The code for lunar lake etc is developed on and tested on Windows, so I suspect it is white space/line feeds?

Does cpuinfo provide a script / command to format?
Or is it simply clang-format -i src/x86/uarch.c

GregoryComer · 2025-11-14T22:08:22Z

@rrwinterton Can you resolve the clang format errors and rebase? I can merge once checks are green. The CMake failures are caused by CMake 4.x dropping support for older versions and should be resolved on the latest main. Thanks!
clang-format job: https://github.com/pytorch/cpuinfo/actions/runs/19049667827/job/54608194604?pr=334

In your link clang format points to the end of line:
./include/cpuinfo.h:358:64: error: code should be clang-formatted [-Wclang-format-violations]
        /** Intel Golden Cove microarchitecture (Alder Lake P-Core) */
                                                                      ^

Failed on file: ./include/cpuinfo.h
./src/x86/uarch.c:202:49: error: code should be clang-formatted [-Wclang-format-violations]
                                                case 0xBF: // Raptor Lake HX (Golden Cove)
                                                                                          ^
./src/x86/uarch.c:204:63: error: code should be clang-formatted [-Wclang-format-violations]
                                                case 0xBE: // Alder Lake N / Raptor Lake N (Golden Cove)
                                                                                                        ^
./src/x86/uarch.c:216:33: error: code should be clang-formatted [-Wclang-format-violations]
                                                case 0xCC: // Panther Lake 
                                                                          ^

Failed on file: ./src/x86/uarch.c
Do you know specifically if the issue is CR/LF vs NL? Or the trailing space on Panther Lake? Or does it want a . (pediod) at the end of each comment? The code for lunar lake etc is developed on and tested on Windows, so I suspect it is white space/line feeds?

Does cpuinfo provide a script / command to format? Or is it simply clang-format -i src/x86/uarch.c

Yeah, running clang-format -i [path] should be the easiest way.

formatting changes to compile with clang-formatting.

fbarchard · 2025-11-18T18:19:26Z

src/x86/uarch.c

 						case 0x9C: // Jacobsville
 							return cpuinfo_uarch_tremont;
-						case 0xBE: // Alder Lake-N
+						case 0x8F: // Sapphire Rapids (Golden Cove)


nit starting at line 171 is little cores... consider moving to line 170, just after Icelake

Just submitted fix for p-core order and spelling error.

dlenski · 2025-11-18T22:53:20Z

src/x86/uarch.c

 							return cpuinfo_uarch_gracemont;
+						case 0xAA: // Meteor Lake P/M (Redwood Cove)
+						case 0xAC: // Meteor Lake S (Redwood Cove)
+						case 0xAD: // Granite Rapids (Redood Cove)


Typo, should be *Redwood

dlenski · 2025-11-18T22:59:41Z

On my laptop with this Lunar Lake CPU, I get the following result.

This appears to be incorrect, because Lunar Lake processors contain a mixture of Lion Cover cores (P-cores) and Skymont (E-cores).

$ ./cpu-info
Packages:
        0: Intel Core Ultra 5 236V
Microarchitectures:
        8x Lion Cove
Cores:
        0: 1 processor (0), Intel Lion Cove
        1: 1 processor (1), Intel Lion Cove
        2: 1 processor (2), Intel Lion Cove
        3: 1 processor (3), Intel Lion Cove
        4: 1 processor (4), Intel Lion Cove
        5: 1 processor (5), Intel Lion Cove
        6: 1 processor (6), Intel Lion Cove
        7: 1 processor (7), Intel Lion Cove
Clusters:
        0: 8 processors (0-7),  0: 8 cores (0-7), Intel Lion Cove
Logical processors (System ID):
        0 (0): APIC ID 0x00000000
        1 (1): APIC ID 0x00000001
        2 (2): APIC ID 0x00000002
        3 (3): APIC ID 0x00000003
        4 (4): APIC ID 0x00000004
        5 (5): APIC ID 0x00000005
        6 (6): APIC ID 0x00000006
        7 (7): APIC ID 0x00000007

rrwinterton · 2025-11-19T20:31:19Z

On my laptop with this Lunar Lake CPU, I get the following result.

This appears to be incorrect, because Lunar Lake processors contain a mixture of Lion Cover cores (P-cores) and Skymont (E-cores).

$ ./cpu-info
Packages:
        0: Intel Core Ultra 5 236V
Microarchitectures:
        8x Lion Cove
Cores:
        0: 1 processor (0), Intel Lion Cove
        1: 1 processor (1), Intel Lion Cove
        2: 1 processor (2), Intel Lion Cove
        3: 1 processor (3), Intel Lion Cove
        4: 1 processor (4), Intel Lion Cove
        5: 1 processor (5), Intel Lion Cove
        6: 1 processor (6), Intel Lion Cove
        7: 1 processor (7), Intel Lion Cove
Clusters:
        0: 8 processors (0-7),  0: 8 cores (0-7), Intel Lion Cove
Logical processors (System ID):
        0 (0): APIC ID 0x00000000
        1 (1): APIC ID 0x00000001
        2 (2): APIC ID 0x00000002
        3 (3): APIC ID 0x00000003
        4 (4): APIC ID 0x00000004
        5 (5): APIC ID 0x00000005
        6 (6): APIC ID 0x00000006
        7 (7): APIC ID 0x00000007

This is because the infrastructure doesn't support threading to do CPUID for hybrid. The way it works right now is it assume non-hybrid cores. I can fix this by adding affinity to the CPUID when called or we could use a table for the microarchitectures but this is less desirable since it isn't guarenteed to be static.

Ping pytorch#334, pytorch#247

dlenski · 2025-11-20T00:05:14Z

@rrwinterton wrote:

@dlenski wrote:

On my laptop with this Lunar Lake CPU, I get the following result.
This appears to be incorrect, because Lunar Lake processors contain a mixture of Lion Cover cores (P-cores) and Skymont (E-cores).
…

This is because the infrastructure doesn't support threading to do CPUID for hybrid. The way it works right now is it assume non-hybrid cores.

Additionally, the x86-specific code doesn't even use a data structure which allows it to store multiple uarchs, even though ARM + RISC-V code do use that.

I've updated that very basic part for x86 in dlenski/cpuinfo@pr-334...x86_multi_uarch

I can fix this by adding affinity to the CPUID when called or we could use a table for the microarchitectures but this is less desirable since it isn't guarenteed to be static.

Agreed. A table would have to be updated for literally every single hybrid SKU in order to not be incorrect.

The only way to do this for hybrid CPUs is to run CPUID on each of the cores and record the uarch for that core: "As the Intel docs say: CPUID, by design, returns different values depending on the core it is executed on. On hybrid cores more of the CPUID leaves will have data that varies,"

Ping pytorch#334, pytorch#247

adding-new-intel-cpuids

a2a10e9

meta-cla bot added the cla signed label Oct 21, 2025

Update CPU architecture names in cpu-info.c

f6c8ad7

Changed the processor names to the microarchtecture names for consistency and accuracy.

fbarchard reviewed Oct 28, 2025

View reviewed changes

Refactor CPU architecture case handling in uarch.c

2b5f34d

Removed redundant return for Lunar Lake and adjusted case order.

fbarchard approved these changes Nov 3, 2025

View reviewed changes

GregoryComer approved these changes Nov 5, 2025

View reviewed changes

fix clang-formatting for cpu info

47c9549

formatting changes to compile with clang-formatting.

fbarchard reviewed Nov 18, 2025

View reviewed changes

fbarchard approved these changes Nov 18, 2025

View reviewed changes

dlenski reviewed Nov 18, 2025

View reviewed changes

dlenski added a commit to dlenski/cpuinfo that referenced this pull request Nov 19, 2025

Detect Intel CPUs with hybrid cores and warn about missing support

74b915d

Ping pytorch#334, pytorch#247

dlenski added a commit to dlenski/cpuinfo that referenced this pull request Nov 20, 2025

Detect Intel CPUs with hybrid cores and warn about missing support

a620955

Ping pytorch#334, pytorch#247

dlenski added a commit to dlenski/cpuinfo that referenced this pull request Nov 20, 2025

Detect Intel CPUs with hybrid cores and warn about missing support

37a9f9b

Ping pytorch#334, pytorch#247

dlenski added a commit to dlenski/cpuinfo that referenced this pull request Nov 21, 2025

Detect Intel CPUs with hybrid cores and warn about missing support

1febc77

Ping pytorch#334, pytorch#247

adding-new-intel-cpuids #334

Are you sure you want to change the base?

adding-new-intel-cpuids #334

Uh oh!

Conversation

rrwinterton commented Oct 21, 2025

Uh oh!

fbarchard Oct 28, 2025

Choose a reason for hiding this comment

Uh oh!

fbarchard Oct 28, 2025

Choose a reason for hiding this comment

Uh oh!

fbarchard Oct 28, 2025

Choose a reason for hiding this comment

Uh oh!

fbarchard Oct 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fbarchard commented Nov 4, 2025

Uh oh!

GregoryComer commented Nov 6, 2025

Uh oh!

fbarchard commented Nov 14, 2025

Uh oh!

GregoryComer commented Nov 14, 2025

Uh oh!

fbarchard Nov 18, 2025

Choose a reason for hiding this comment

Uh oh!

rrwinterton Nov 19, 2025

Choose a reason for hiding this comment

Uh oh!

dlenski Nov 18, 2025

Choose a reason for hiding this comment

Uh oh!

dlenski commented Nov 18, 2025

Uh oh!

rrwinterton commented Nov 19, 2025

Uh oh!

dlenski commented Nov 20, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

fbarchard Oct 28, 2025 •

edited

Loading