According to AMD product pages, the upcoming 7950X3D and 7800X3D are Unlocked for Overclocking.

Well I am not sure who you are replying to or what you mean by "3DCache has zero effect on CCD's", but my point still stands... this new 3D cache is only on one of the CCDs of the new dual CCD CPUs like 7950X3D. This means that all 16 cores of this CPU are no longer equal in performance like they were in previous AMD CPUs like the 5950X . You now have 8 faster cores (16 threads) on 3D cache CCD, and 8 slower cores (16 threads) on normal CCD. So there is a big difference there compared to older CPUs. And probably something they don't want buyers of new 3D cache CPUs to know about.

 

What games use more than 8 cores? But plenty of apps use 16 cores so a win win. 8 fast game core and 16 fast productivity cores all for a lower price, less power draw and less heat.

 

I believe AMD is trying to get the best of both worlds. With the design used on the 5800x3d the max speed is limited when compared to the 5800x due to the heat issues with the shared cache. This reduces the performance for games that use primarily one core and is evident in the test results.

With the new design AMD is trying to offer the best of both, the huge cache for one CCD for games that benefit at a reduced max frequency and one CCD with the standard cache that can boost to it's max of 5.2GHz-5.6GHZ.

Question is, can you manage the heat to allow this to actually happen?

 

not accurate afaik.
what documentation do you have on different frequencies on differing CCD's?
your conclusion is specious regarding (cache-less) CCD's vs. cached CCD's as there are no frequency limitations created by the cache, especially now the cache has it's own regulated power supply heat throttling is a non-issue.

 

THAT is the question

 

well i wasn't talking about frequency differences making the "speed" difference, if that is what you were asking... I meant the extra 3D cache speeding up processes/programs running on one CCD more than the other CCD. Assuming both CCDs run at same frequency. I was not aware the non-cache CCD could be run at higher frequencies now though... that makes things more complicated to figure out - will be almost impossible for any large application to know where it should run best then - very difficult job for Windows scheduler.

No idea what "your conclusion is specious" means?!?

 

AMD is working with MS on this very issue. Same growing pains from several years ago. Could also be part of the delay in releasing this cpu.

 

Thats why you get 7800x3d with one v-cached ccd.

 

its really not that complicated the easy solution is a whitelist, also zen 3/4 provides a bunch of profiling abilities for tuning your workload, which do not require root permissions (administrator mode/ring0) so its possible they could use some heuristics from the cpu to dynamically decide which ccd to run an application on.

(link for those interested in amd's profiling software https://www.amd.com/en/developer/uprof.html )

 

Everything they said is correct.

 

Yes it does appear this would be only way... every program would just have to be tested on both CCDs and see which runs faster for that particular "operation". And then marked somehow to always run on faster CCD in future automatically. Messy. Any non-profiles apps would basically just be run randomly. eg. say a Futuremark 3DMark program and benchmark run was not profiled... then it could randomly run on CacheCCD or NonCacheCCD... and get two completely different results for benchmark, one probably much faster than the other. Same with loads of other GPU + CPU intensive "mixed" apps like most games. Also would this be user settable or automatic in OS so no user control? Since this is a very niche CPU there probably wouldn't be much effort to get it right.

 

Remember when people said Dual Core CPUs would never work efficiently, this wont even be a problem.
if the Ukrainians can work out how to operate US HARM missles from their Mig 29's, im sure the brains at AMD and MS can work this out.

 

I remember that apps often took a performance penalty at the same ipc and clocks on dual core processors vs single core of the same architecture design and feature set.

windows itself benefitted mostly.

 

Is there a 3D CPU without any CCD nonsense? Or any Ryzen CPU with only a single CCD?

 

Yes but before they actually came to be, when they were in the conceptual stage. Humanity always finds a way and necessity is the mother of invention. Humans have a history steeped in making the impossible possible.

 

The CPUs with a single CCD and 3D cache are the 5800X3D, and the 7800X3D afaik

 

1) "faster" = frequency as that's the literal meaning and usage.
2) the operation of processes running from 3D CCDs are not typically the same as processes run from another CCD (i.e. gaming) so any differential would most likely be found in productivity applications where the difference does not amount to much.
3) synthetic benches will highlight any such difference, but the result is not useful in RL.
4) most importantly, all of the concerns regarding performance are belied by Epyc processors in the real world handling far more complicated work.

these "concerns" have never surfaced in the Pro IT Cloud.

 

It's a question of incentive - every cpu was going to be multi-core so devs had to make it work. Ukraine really needs those missiles to work, they will save Ukrainian lives and help them win the war.
A tiny number of people will end up with cpu's that have this behaviour, and the extra performance (a few % probably) isn't much. There just isn't enough payback to put much effort in.

 

Necessity is the mother of invention.

 

I think you're making a bit of a mountain out of a mole hill so to speak, whitelists are pretty easy , since you litterally just have to run the application twice, would take a single person maybe a week or 2 to test all of the most popular games. secondly if they were to use heuristics its probably not very difficult , I'd imagine even just checking l3 occupancy and or hit rate would be enough, ie, "this application doesn't hit the l3 cache very often --> move to ccd 1" , the part where it could get messy is if an application can use more than 16 threads, but that's probably an edge case for the vast majority of users.