• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.
  • The forums have been upgraded with support for dark mode. By default it will follow the setting on your system/browser. You may override it by scrolling to the end of the page and clicking the gears icon.

AMD Ryzen 9 9950X3D and 9900X3D to Feature 3D V-cache on Both CCD Chiplets

I guess you’ve never heard of thread scheduling and how hit or miss it is. This solves that problem. Even better if clock speeds can also be higher.

It is quite the contrary to what you say. Scheduling will now be even more important to the point it becomes SUPER-DUPER-MEGA-EXTRA-important with cache on both CCDs. For this dual cache setup to work correctly, games/apps (via the scheduler) always need to request the cached data from the "correct" cache on the "correct" CCD or else you will suffer latencies from hell if/when data needs to be fetched from the cache across the CCDs because e.g. Core 3 requests data that was previously stored to the cache by Core 14 on the other CCD. Can't have a scenario like that. Ever.

So, both the scheduler and the CPU always need to "know" exactly "who" (which core) cached something (what) and where it was cached to avoid the dreaded inter-CCD and inter-cache latencies. This is definitely going to be a challenge and very complex on the level of correct scheduling and correct CCD assignment etc.

AMD does not exactly have the best track record when it comes to these scheduling and core assignment shenanigans so I would be quite surprised if they get this to work flawlessly out of the gate.
Personally, I have avoided multi CCD CPUs like the plague due to the Xbox GameBar and 'GameMode On' requirements (I have a PC and not a console, you muppets). It will be interesting to see if the GameBar requirement will be dropped now(?) since core parking will no longer be required.

We'll have to wait and see how well this is gonna work in practice. I would expect some growing pains, to say the least...
 
Last edited:
What's the reliability of this info? Is this a last-minute change? Somehow I'm imagining their testing and validation teams working three shifts. :twitch:

None of it does anything for cross-CCD scheduling problems - Ninja'd @RogueSix
 
Did they get around the clock speed regressions from 3D cache? That was essentially why they haven`t done dual 3D cache,

A lot of applications suffered more from the clock speed regression than the benefits of more cache.
I think AMD did indeed correct it, if they're able to promise overclocking on the new X3D SKUs.
 
It is quite the contrary to what you say. Scheduling will now be even more important to the point it becomes SUPER-DUPER-MEGA-EXTRA-important with cache on both CCDs. For this dual cache setup to work correctly, games/apps always need to request the cached data from the "correct" cache on the "correct" CCD or else you will suffer latencies from hell if/when data needs to be fetched from the cache across the CCDs because e.g. Core 3 requests data that was previously stored to the cache by Core 14 on the other CCD. Can't have a scenario like that. Ever.

So, both the scheduler and the CPU always need to "know" exactly "who" (which core) cached something (what) and where it was cached to avoid the dreaded inter-CCD and inter-cache latencies. This is definitely going to be a challenge and very complex on the level of correct scheduling and correct CCD assignment etc.

AMD does not exactly have the best track record when it comes to these scheduling and core assignment shenanigans so I would be quite surprised if they get this to work flawlessly out of the gate.
Personally, I have avoided multi CCD CPUs like the plague due to the Xbox GameBar and 'GameMode On' requirements (I have a PC and not a console, you muppets). It will be interesting to see if the GameBar requirement will be dropped now(?) since core parking will no longer be required.

We'll have to wait and see how well this is gonna work in practice. I would expect some growing pains, to say the least...
Why is it a challenge, though? Shouldn't it be as simple as assigning CCD 1 to any foreground program that requires 8 cores + 96 MB (edited) cache or less, while background tasks get CCD 2, and anything that needs more than the above is spread out across the two CCDs?
 
Last edited:
It is quite the contrary to what you say. Scheduling will now be even more important to the point it becomes SUPER-DUPER-MEGA-EXTRA-important with cache on both CCDs. For this dual cache setup to work correctly, games/apps always need to request the cached data from the "correct" cache on the "correct" CCD or else you will suffer latencies from hell if/when data needs to be fetched from the cache across the CCDs because e.g. Core 3 requests data that was previously stored to the cache by Core 14 on the other CCD. Can't have a scenario like that. Ever.

So, both the scheduler and the CPU always need to "know" exactly "who" (which core) cached something (what) and where it was cached to avoid the dreaded inter-CCD and inter-cache latencies. This is definitely going to be a challenge and very complex on the level of correct scheduling and correct CCD assignment etc.

AMD does not exactly have the best track record when it comes to these scheduling and core assignment shenanigans so I would be quite surprised if they get this to work flawlessly out of the gate.
Personally, I have avoided multi CCD CPUs like the plague due to the Xbox GameBar and 'GameMode On' requirements (I have a PC and not a console, you muppets). It will be interesting to see if the GameBar requirement will be dropped now(?) since core parking will no longer be required.

We'll have to wait and see how well this is gonna work in practice. I would expect some growing pains, to say the least...
If the cores can get data from the wrong L3 cache, shouldn't this problem exist now? The L3 is spread to two CCD even now
 
So I guess they worked around the issue of Dual CCD traffic killing gains like it did for the 5900X prototype that had v-cache on both.

So the question that reminds is clock speed affected or did they solve this problem also.
 
If the cores can get data from the wrong L3 cache, shouldn't this problem exist now? The L3 is spread to two CCD even now

No. Because currently the solution is outright core parking. One CCD (the one w/o the 3D cache) gets put to sleep when you are gaming on a multi CCD X3D CPU.
 
I actually think with the inter-CCD latency at ~70ns this isn't far from the truth.

I'd still prefer this setup over the 7950X3D though you can always tie games to the stonger ccd either way and my guess is even when cores do jump ccd it won't be a large hit.... Oddly when I tie games to all 16 cores I see higher avg framerates than I do if I just tie it to the non cache ccd in games that don't behave so this should still be a bit better than that.

I'd still like both options available just becuase I want to see the actual difference not on games that do well on the current 7950X3D already but in games that don't behave without user intervention.

So I hope AMD releases both options with the single ccd option being slightly cheaper for academic reasons of course lol.
 
So I guess they worked around the issue of Dual CCD traffic killing gains like it did for the 5900X prototype that had v-cache on both.

So the question that reminds is clock speed affected or did they solve this problem also.
I'm not sure if inter die requests were ever a factor. If they were, then EPYC X would suffer much more than a hypothetical 5950X3D with 192 MB of L3 cache.
 
My work is assigning me CAD and rendering work. So I guess I’m upgrading my 7700x to a 9950x3d on my gaming rig. Thread assignment won’t be an issue if both CCDs have 3D cache.

Adobe Dimensions and Solid works needs some fast PC specs. I have a 7900xt so GPU spec is already there.

Indeed, 3D V-Cache was initially intended to be developed for server/workstation environments (for both CCD).
I don't know IF I will sell my 9950x
Let's wait for it on January 2025 :laugh:
 
Old enough to remember when this amount of L3 was a LOT of system RAM to have--more than the PC I had in college about 25 years ago. These CPUs could theoretically run NT4 and all associated programs without any system RAM, provided running RAMless was even be possible. Just think of the FPS and load times I'd get in Quake II. :D
 
Old enough to remember when this amount of L3 was a LOT of system RAM to have--more than the PC I had in college about 25 years ago. These CPUs could theoretically run NT4 and all associated programs without any system RAM, provided running RAMless was even be possible. Just think of the FPS and load times I'd get in Quake II. :D
500hz true gaming.
 
I'm not sure if inter die requests were ever a factor. If they were, then EPYC X would suffer much more than a hypothetical 5950X3D with 192 MB of L3 cache.
I always said that if inter-CCD communication is an issue, then you don't need more than 8-cores. And if you do, then the benefits of having more cores outweigh the detriment of inter-CCD latency anyway. :)
 
Yea but the glaring disappointment might ensue because are we still getting 1 Good CCD and 1 Meh CCD? I suppose core uniformity now is a big plus and the lower TDP required by X3D cache.
 
Since I went with the RyZen 3950X and later the 7950X (when released) due to wanting / needing more cores I was willing to forgo the benefits of X3D. I should point out that I didn't want to deal with core parking. The 9950X3D seems like a no compromise part and will likely be priced aggressively. I suspect that the clock speeds will be slightly reduced and the stacking usually means slightly less heat tolerance but this is minor. Still probably wont be worth it to me to upgrade to this gen but AMD is setting a precedent that I can get behind. Next gen I'll likely wait for the 16 core 32 thread X3D offering, the successor to the 9950X3D,....
 
More cache more misses. Not only more hits. :D.
In either case 100% hits are still being taken to the wallet or the mattress depending on where you are from. Prepare to fork out the cash for Dual X3D is my prediction.
 
It’s probably just me, but I see this as a loss if X3D parts are frequency limited again. It would’ve been more beneficial if they had implemented some sort of hardware scheduler as opposed to just dropping in another 3D cache chiplet.
 
It’s probably just me, but I see this as a loss if X3D parts are frequency limited again. It would’ve been more beneficial if they had implemented some sort of hardware scheduler as opposed to just dropping in another 3D cache chiplet.
Zen 6.
 
Consoles have similar latency issues with their double CCX design, I'm sure that ways to mitigate this latency penalty already exist there.
If we are lucky, we could see them come to PC in 5 to 10 years.
 
It’s probably just me, but I see this as a loss if X3D parts are frequency limited again. It would’ve been more beneficial if they had implemented some sort of hardware scheduler as opposed to just dropping in another 3D cache chiplet.
It's the usual "X3D if you game, normal if you don't" narrative again. Personally, I don't mind. Those higher clocks don't give you that much more performance anyway - only more power consumed and heat.
 
Old enough to remember when this amount of L3 was a LOT of system RAM to have--more than the PC I had in college about 25 years ago. These CPUs could theoretically run NT4 and all associated programs without any system RAM, provided running RAMless was even be possible. Just think of the FPS and load times I'd get in Quake II. :D
My 7950x3d gets 940fps on crusher.dm2
 
Back
Top