News AMD Strix Point engineering sample underwhelms in early Geekbench 6 results

There's a chance Strix Point could feature 12 P-cores, but it's more likely that it will use a mixture of P-cores and Zen 5c E-cores to hit the 12-core target.

Since when does AMD has P and E core configuration like Intel ?

Zen 5c "dense" core is just a highly compacted variant of "Zen 5," which operates at a lower voltage band than its larger sibling, without any change in IPC or instruction sets.
 
AMD confirmed that XDNA 2 will offer twice the performance of its predecessor, translating to over 70 TOPS of performance — well above Microsoft's 40 TOPS requirement for AI PCs.

70 TOPS ? Wrong. You must be joking. It's thrice the performance improvement btw, not twice.

The "TOTAL" TOPS value is a different story though.

As per AMD, XDNA 2 NPU is expected to introduce an over 3 times improvement in performance over the first generation XDNA NPU powering the Ryzen 7040 series "Phoenix" processor.

"Phoenix" offers 10 TOPS of NPU performance, so if AMD mentions an "over 3 times" performance improvement, this would put this figure at roughly 32 TOPS for "Strix Point."

Also, 8040 "Hawk Point" APUs offer up to 16 TOPs of performance, a 3x improvement with Ryzen "Strix Point" APUs means that we could be looking at up to 48 TOPs of AI performance, give or take.

The core CPU specs align with speculation that Strix Point will feature upgraded core counts compared to AMD's current Ryzen 7040 and 8040 series mobile processors

Not entirely correct. The core counts with Strix Point won't see a VERY huge upgrade though. Do you make up your own story while writing articles?

Btw, these are Geekbench 5 entries, and not GB 6 as the article mentions.
 
Last edited by a moderator:
16 MB L3 is wrong. It's probably detecting it wrong because it's dual-CCX this time around.

4x Zen 5 cores with 16 MB L3
8x Zen 5c cores with 8 MB L3

Since when does AMD has P and E core configuration like Intel ?

Zen 5c "dense" core is just a highly compacted variant of "Zen 5," which operates at a lower voltage band than its larger sibling, without any change in IPC or instruction sets.
It might be unfair to call 'C' cores "E-cores", but they do fill similar roles. Greater multi-threaded performance per die area, greater power efficiency in part from limiting the clocks (it's more complicated than that).

Also, 8040 "Hawk Point" APUs offer up to 16 TOPs of performance, a 3x improvement with Ryzen "Strix Point" APUs means that we could be looking at up to 48 TOPs of AI performance.
Yup, should be at least 45 TOPS.

The NPU being capable of outperforming the iGPU+CPU would be a neat trick.

Not entirely correct. The core counts with Strix Point won't see any huge upgrade.
50% increase in core/thread count (caveats not mentioned).
 
16 MB L3 is wrong. It's probably detecting it wrong because it's dual-CCX this time around.

4x Zen 5 cores with 16 MB L3
8x Zen 5c cores with 8 MB L3

Yeah correct, the chip itself might feature a total of 24 MB L3 cache, and 12 MB of L2 cache in total.

View: https://twitter.com/Kepler_L2/status/1782964481322107229


BTW, one more entry was also spotted, running on the Birman Plus-STX reference platform. It says 2 processors here though ! Has the same OPN ID of "100-000000994-14_N".

b5Kyxkp.png
 
AMD used the NPU + GPU + CPU to address the total 33 AI TOPS for the 7040 Series, the NPU can produce 10 TOPS and when combined with the CPU+GPU it can achieve the 33 TOPS, so you'll have the "3 x 10 TOPS from the XDNA 2" + "the upgraded RDNA 3+ (16 CU vs previous 12 CU)" + "the new 12 C Zen5 CPU (+50% threads over zen4 APUs)" to achieve 60~70 TOPS in total.
 
  • Like
Reactions: artk2219
The single thread score is very good for a 1.4Ghz CPU without boost.
It is a +110% referred to a 8640U (3.5/4.9 Ghz).
Something wrong here ?

Strix Point single-core of 1,217 points.
Ryzen 5 8640U over 2,000 points in the single-core

1217 : 1.4 = x : 3.5 -> 3042 -> +50%
1217 : 1.4 = x : 4.9 -> 4260 -> +110%
 
It might be unfair to call 'C' cores "E-cores", but they do fill similar roles.
They are not. E-cores role is to cripple P-cores and create all kinds of headaches for developers who want to optimize their software. Basically, it's an insult of a core.

The 'c' should be called something like 'dense cores' since they are exactly the same as 'normal cores' from software point of view.
 
  • Like
Reactions: SunMaster
I guess the purpose of these C cores are to act as more efficient cores due to some minor cutbacks. Ultimately they are still on the same chip architecture. Intel's approach of E-cores to me are a bunch of cheaper cores that they handily spam to boost their multithread numbers. Overall I think AMD's approach likely causes less issues. Assuming an app utilizes the wrong core, the performance penalty is not as significant. And if you read Anandtech's review on Meteor Lake, those Intel E-cores have very high latency which is not a good sign.
 
They are not. E-cores role is to cripple P-cores and create all kinds of headaches for developers who want to optimize their software. Basically, it's an insult of a core.

The 'c' should be called something like 'dense cores' since they are exactly the same as 'normal cores' from software point of view.
No it creates headaches for devs that don't want to optimize and only do the least amount of work, if they even do that.

And the same will be true for the c cores, the c cores will introduce a lot of sync issues in games and the devs will drag all the cores down to the c core speeds to avoid these sync issues or only run games on full cores losing a lot of performance, or they won't even do that and a lot of games will just have issues until you shut down the c cores or set affinity to only the normal cores.

For apps it's a lot less of an issue since multithreaded apps can just launch different workloads for any type of core there is. Also intel is working on avx10 which will do that automatically for avx.
 
And the same will be true for the c cores, the c cores will introduce a lot of sync issues in games and the devs will drag all the cores down to the c core speeds to avoid these sync issues or only run games on full cores losing a lot of performance, or they won't even do that and a lot of games will just have issues until you shut down the c cores or set affinity to only the normal cores.
I totally disagree with you here. There are sync issues with threads in any case, also if you have exactly the same core, same clock and same workload. Programs runs under a multitasking OS and you have program flow perturbation due to external peripherals and interrupts for example. Add that you have also variable frequency and not all cores have the same max clock...
For apps it's a lot less of an issue since multithreaded apps can just launch different workloads for any type of core there is.
True, but with a programming overhead.
In case of cores with different instruction set, the effort is not trivial.
Not only programmer must produce a code that spawn threads with different codepaths but also all frameworks and libraries involved need to manage such cases.
Also intel is working on avx10 which will do that automatically for avx.
For me avx10 is intended to put some order in the chaos and I do not see how avx10 can automatically solve the problem of "Intel's e-cores".
 
I totally disagree with you here. There are sync issues with threads in any case, also if you have exactly the same core, same clock and same workload. Programs runs under a multitasking OS and you have program flow perturbation due to external peripherals and interrupts for example. Add that you have also variable frequency and not all cores have the same max clock...
Yes to all of that.
Still, if you have drastically different clocks these problems get bigger than if you have one type of core and use the max performance plan were all cores run at max in which case the clock differences are very small.
I say as much in the part you quote. "the devs will drag all the cores down to the c core speeds to avoid these sync issues "

The point was that the c cores will add the same issues as the e-cores do.
 
Going back to the processor's performance, the numbers seem low, but if it indeed stayed at 1.4 GHz, performance should be actually quite good in the 3-4 GHz range.
That depends on if "the curve" is more linear or more curved.
If you look at older zen they scale very well in the start but then level out and don't get much faster no matter how much power you provide to them.
We will have to see how much better the new cores are.

image-23-1.png
 
Yes to all of that.
Still, if you have drastically different clocks these problems get bigger than if you have one type of core and use the max performance plan were all cores run at max in which case the clock differences are very small.
In a good written program the subdivision of jobs between threads should not be done statically but dynamically based on the free threads. If the full task is divided in a good multiple of the available threads, the problem of having a mix of slow and fast cores can be avoided almost completely. This should be a good practice in every environment with a lot of cores.

I say as much in the part you quote. "the devs will drag all the cores down to the c core speeds to avoid these sync issues "

The point was that the c cores will add the same issues as the e-cores do.
Not the biggest problem that is the different instructions to handle.
 
In a good written program the subdivision of jobs between threads should not be done statically but dynamically based on the free threads. If the full task is divided in a good multiple of the available threads, the problem of having a mix of slow and fast cores can be avoided almost completely. This should be a good practice in every environment with a lot of cores.
In that case is there going to be ANY difference between c and/or e cores?!
Not the biggest problem that is the different instructions to handle.
So a well written program can handle speed differences in cores easily but can't issue different workloads to different cores because that's the difficult thing?!

Also as already said the only difference is avx-512 and intel is working on an API that is going to manage this seamlessly.
 
In that case is there going to be ANY difference between c and/or e cores?!
The instruction set.
So a well written program can handle speed differences in cores easily but can't issue different workloads to different cores because that's the difficult thing?!
The right subdivision is a logic problem solved by the programmer while the different CPU target must be handled by the compiler.
Also as already said the only difference is avx-512 and intel is working on an API that is going to manage this seamlessly.
Imho avx10 cannot help to solve this.
 
The instruction set.
Yes, tell us about it, what is the difference other than avx512.
The right subdivision is a logic problem solved by the programmer while the different CPU target must be handled by the compiler.
What?!
All you have to do is to read out the CPUid and then just ignore the e-cores or send different workloads to them, it's the same thing you have to do if you want to send different work to each core because they have different speeds.
Only easier because the c/e cores will always be c/e cores while the speed on each core can change dramatically all the time.
Imho avx10 cannot help to solve this.
Yes, I'm sure you know better than intel.
 
Since when does AMD has P and E core configuration like Intel ?

Zen 5c "dense" core is just a highly compacted variant of "Zen 5," which operates at a lower voltage band than its larger sibling, without any change in IPC or instruction sets.
Exactly.

Calling AMD's C cores by Intel's E-cores (refereed to by some as 'garbage cores') terminology is an insult to C Cores. The two CPUs don't belong in the same category.
 
Going back to the processor's performance, the numbers seem low, but if it indeed stayed at 1.4 GHz, performance should be actually quite good in the 3-4 GHz range.
It's skyrocketing now:

Also, 8040 "Hawk Point" APUs offer up to 16 TOPs of performance, a 3x improvement with Ryzen "Strix Point" APUs means that we could be looking at up to 48 TOPs of AI performance, give or take.
Here's a leak suggesting 50 TOPS for Strix Point, "up to" 60 TOPS for Strix Halo:

The TOPS increase from Phoenix to Hawk Point is from increased clock speeds, so it wouldn't be a surprise to see some variation in the Strix family. But probably going no lower than 40 TOPS for the lowest tier ones (probably Kraken) to meet the Windows "requirement".
 
C-core is the same as E-core, with the same result and behavior. Except AVX-512. But you also probably wouldn't want to spare the AVX-512 code on them, since their clock rate would likely be less than half that of vanilla. The only difference is the way to achieve these - a different arch design for Intel, and a different spatial lithographic design for AMD
 
Here's a leak suggesting 50 TOPS for Strix Point, "up to" 60 TOPS for Strix Halo:
The TOPS increase from Phoenix to Hawk Point is from increased clock speeds, so it wouldn't be a surprise to see some variation in the Strix family. But probably going no lower than 40 TOPS for the lowest tier ones (probably Kraken) to meet the Windows "requirement".

Cool. Interestingly, the HALO variant also appears to have this 32MB MALL cache, and if these are 2 CCD chips then 64MB L3 cache would be enormous.
 
  • Like
Reactions: usertests
And the same will be true for the c cores, the c cores will introduce a lot of sync issues in games and the devs will drag all the cores down to the c core speeds to avoid these sync issues or only run games on full cores losing a lot of performance, or they won't even do that and a lot of games will just have issues until you shut down the c cores or set affinity to only the normal cores.
That's nonsense. Since the era of aggressive boost clocks it's totally normal for different cores to have significantly different freq. And no one sane "drag all the cores down" to the same speed. c-cores change nothing here.
Also intel is working on avx10 which will do that automatically for avx.
Automatically do what? AVX10.1 is just a rebrand for AVX-512 and getting ready for AVX10.2 where some features become optional so poor cores can claim the support of modern extensions.

C-core is the same as E-core, with the same result and behavior. Except AVX-512.
All x86 cores give you the same result.
And "behavior" of E-cores is very different to P-cores. If you look at instructions latency/throughput, P-cores and new Zen-cores look very similar and drastically different from E-cores. Normal Zen and Zen-c behave exactly the same.
 
Cool. Interestingly, the HALO variant also appears to have this 32MB MALL cache, and if these are 2 CCD chips then 64MB L3 cache would be enormous.
I don't think 64 MB matters for most games if it's split between two CCDs, but 32 MB L3 is a major improvement for an "APU".

Then the Infinity Cache is a huge deal. Strix Halo would have up to 2.133x bandwidth of Strix Point before taking into account that cache.

Since these chiplets are shared with desktop/server, it might be possible for AMD to produce an X3D version of Strix Halo, just like it has done with Dragon Range.
 
i have to say the title and writing of the article is pure click bait + throwing shade at AMD for no real reason (technical), why spend the title and 2 paragraph painting Strix as a POS to at the end finally disclose the "ACTUAL" reason of the "low score" results, when in perspective at same clocks is actually much higher??, so at 1.4Ghz is 40% slower (ST) than a sample at 4.9Ghz, really(quick math 60% the perf at ~28% the clocks) can that be called "SLOW and UNDERWHELMING"? Why not title it and disclaim the HW specs in the first sentence instead of just a quick lateral reference on the front pic footnote?. How low has Tom'sHW quality and journalistic professionalism come down over the decades,
 
Last edited: