Z690 Chipset Motherboards and Alder Lake CPU

[StefanAM]

** It Works! **​

Gigabyte Z690 Aero G + i5-12600K + AMD RX 6800 XT

Has anyone successfully run the Z690 on Mojave? Sometimes I need to use an older music card that doesn't work with Catalina anymore.

www.tonymacx86.com

Yes it works! The culprit was SMCProcessor.kext (nice found @CaseySJ). And here are the benchmarks result after the wizard touch of @vit9696 (right) in comparison with my best before (left):

 

[luchina]

@CaseySJ niiiiice post/guide of activation of P+E+HT!

My result in GB5:

iMacPro1,1 - Geekbench Browser

Benchmark results for an iMacPro1,1 with an Intel Core i9-12900K processor.

browser.geekbench.com

However, my results with PVE stay best in multi-core... (around 16,0k ~ 16,3k, little thing) But I believe that new versions of CpuTopologySync and patches may increase this gap between Opencore versus PVE in my scenario.

Thanks a lot!

 

[etorix]

This suggests that the issue with the number of cores is not cosmetic and some E-cores remain inactive.

i5-12600K (6P+4E) should be 10C/16T, shows as 8C/14T in Geekbench (-2C/-2T). (@CaseySJ )
i7-12700K (8P+4E) should be 12C/20T, @Romanychev reports "+2 E-core", so I guess 10C/18T (-2C/-2T).
i9-12900K (8P+8E) should be 16C/24T, shows as 12C/20T in Geekbench (-4C/-4T). (@StefanAM )

From previous experiments with SSDT-CPUR-Z690, we know that cores/threads appear in MADT in this order:
P1, PHT1, P2, PHT2,… Pn, HTn, E1, E2,…
and are allocated to \_SB_.PR## ACPI devices in this order.
SSDT-CPUR-Z690 wraps the ACPI devices to corresponding \_SB_.CP## processor objects.
SSDT-PLUG-ALT creates processor object stubs, without any reference to the actual ACPI processor devices; but apparently, OS X fills these stubs from MADT (including reading the actual Processor Base Address parameter from MADT rather than from the SSDT declaration).
What we see looks like OS X is creating phantom hyper-threads for the E-cores:
P1, PHT1, P2, PHT2,… E1, EHT1, E2, EHT2,…

@CaseySJ , @StefanAM , @Romanychev Can one of you post an IOReg with CpuTopologySync.kext in use? I'd like to see what the processors look like, especially the inactive ones.

 

[jiangrui1983]

Here is IOReg with CpuTopologySync.kext.My CPU is 12700KF.

 

[etorix]

Thanks!
Not being able to browse and see all properties, CP16 to CP19 at addresses (lapic) 48, 4A, 4C, 4E look like the genuine E-cores.

 

[StefanAM]

Just a thought.......... if we can enable 8 more cores (ex: i9 12900k) we will have 8 e-cores and 8 fake HT e-cores. Don't know if physically this is possible.

 

[StefanAM]

This suggests that the issue with the number of cores is not cosmetic and some E-cores remain inactive.

i5-12600K (6P+4E) should be 10C/16T, shows as 8C/14T in Geekbench (-2C/-2T). (@CaseySJ )
i7-12700K (8P+4E) should be 12C/20T, @Romanychev reports "+2 E-core", so I guess 10C/18T (-2C/-2T).
i9-12900K (8P+8E) should be 16C/24T, shows as 12C/20T in Geekbench (-4C/-4T). (@StefanAM )

From previous experiments with SSDT-CPUR-Z690, we know that cores/threads appear in MADT in this order:
P1, PHT1, P2, PHT2,… Pn, HTn, E1, E2,…
and are allocated to \_SB_.PR## ACPI devices in this order.
SSDT-CPUR-Z690 wraps the ACPI devices to corresponding \_SB_.CP## processor objects.
SSDT-PLUG-ALT creates processor object stubs, without any reference to the actual ACPI processor devices; but apparently, OS X fills these stubs from MADT (including reading the actual Processor Base Address parameter from MADT rather than from the SSDT declaration).
What we see looks like OS X is creating phantom hyper-threads for the E-cores:
P1, PHT1, P2, PHT2,… E1, EHT1, E2, EHT2,…

@CaseySJ , @StefanAM , @Romanychev Can one of you post an IOReg with CpuTopologySync.kext in use? I'd like to see what the processors look like, especially the inactive ones.

 

[Romanychev]

This suggests that the issue with the number of cores is not cosmetic and some E-cores remain inactive.

i5-12600K (6P+4E) should be 10C/16T, shows as 8C/14T in Geekbench (-2C/-2T). (@CaseySJ )
i7-12700K (8P+4E) should be 12C/20T, @Romanychev reports "+2 E-core", so I guess 10C/18T (-2C/-2T).
i9-12900K (8P+8E) should be 16C/24T, shows as 12C/20T in Geekbench (-4C/-4T). (@StefanAM )

From previous experiments with SSDT-CPUR-Z690, we know that cores/threads appear in MADT in this order:
P1, PHT1, P2, PHT2,… Pn, HTn, E1, E2,…
and are allocated to \_SB_.PR## ACPI devices in this order.
SSDT-CPUR-Z690 wraps the ACPI devices to corresponding \_SB_.CP## processor objects.
SSDT-PLUG-ALT creates processor object stubs, without any reference to the actual ACPI processor devices; but apparently, OS X fills these stubs from MADT (including reading the actual Processor Base Address parameter from MADT rather than from the SSDT declaration).
What we see looks like OS X is creating phantom hyper-threads for the E-cores:
P1, PHT1, P2, PHT2,… E1, EHT1, E2, EHT2,…

@CaseySJ , @StefanAM , @Romanychev Can one of you post an IOReg with CpuTopologySync.kext in use? I'd like to see what the processors look like, especially the inactive ones.

12700k

 

[luchina]

Hi Guys!

Share with you some results and also the IOReg.

I noticed that there are the last 4 processors in the IOReg and that they are marked as uninitialized.

In the activity monitor you can also confirm that it doesn't show the consumption of 4 cores, maybe this makes the multicore score a little lower.

My last GB5 scores:

iMacPro1,1 - Geekbench Browser

Benchmark results for an iMacPro1,1 with an Intel Core i9-12900K processor.

browser.geekbench.com

 

[etorix]

@StefanAM, @Romanychev Thanks! I've seen the ghosts!

Throughout the P-cores and their hyperthreads, all is fine. First E-core (from 12900K):

'processor-id' and 'processor-number are in sync. Then the next E-core:

'processor-id' keeps with the sequence (as defined in SSDT) but 'processor-number', which should be an OS X-generated alternate index, has jumped by two units! 'Processor-number' 0x11 is nowhere to be found.
This goes on with the remaining cores, and eventually the last processors are not initialised.

There are no such jumps or loss of synchronicity in a previous IOReg with P+E cores (no HT).

Mad Scientist proposal: What happens if the "effective" numbers are raised in the kernel patch?
Replace: B8 28 00 14 00 31 D2 for i9-12900K
Replace: B8 1C 00 0E 00 31 D2 for i7-12700K
Replace: B8 18 00 0C 00 31 D2 for i5-12600K
(Most likely the hack no longer boots because the patch does not match the actual CPU, or the limiting counter is not there—or is only one of the two patched instances.)