Could next gen consoles focus mainly on CPU?
- Thread starter Theeoo
- Start date
Real life performance seems on par with GDDR ram and since you no longer need traces out to memory you can reduce the layers of your board also. It should reduce costs of the console greatly. As for cooling I don't know if it will be a huge issue on a console SOC if they are able to do it on a fury and vega board with gpu's running at much higher wattage
itsmydamnation
Veteran
So a few things to think about:
1. I think something like the Samsung low cost hbm option could be something that is viable for consoles and APU's over the mid term.
2. Remember the HBCC, AMD(as is everyone) is well aware that memory performance scaling isn't keeping up with SOC performance scaling, especially when considering cost ($/power/etc). I think the next consoles will have 2 tiers of memory minimum maybe even 3:
So Something like:
1. bank of very high throughput memory ,2-4GB, 1 stack HBM3 or 2 stacks of HBM2/low cost HBM ~ 400-500GB/s ,GPU high throughput target
2. 8GB GDDR6, low/middle of the road GDDR6, take the cost to GB sweet spot 128bit bus? ~256GB/s , GPU low throughput target
3. 8GB DDR5, low/middle of the road DDR5, take the cost to GB sweet spot 128bit bus? ~100GB/s , primary CPU target
Have two modes of operation ( dev selectable on game load etc) , 1. HBCC handles data movement , maybe possible to give hints 2. each memory type is mapped to ranges and devs have full control.
It looks to me like AMD already have a lot of the infrastructure to facilitate this:
1. The interconnect that supports multiple memory controllers
2. The memory controllers and the packaging technologies needed
3. The black magic to decide when to move things around
What would be interesting in this type of solution is what the exact topology is, ideally all these memory types should be connected to the global fabric directly but this doesn't align to what we normally see with standard Dgpu typologies, but given that GPU's can handle latency well maybe it doesn't matter either way so long as the interconnects can scale throughput.
I dont see consoles getting a large amount of a single high performance memory regardless of what it is, to expensive across the board, by making a high cost investment in a small amount of memory, you can take the fish that John West rejects for the bulk of your memory requirements.
my assumption is DDR5 will be significantly cheaper then GDDR6, if its not then 16gb 256bit GDDR6 makes more sense.
1. I think something like the Samsung low cost hbm option could be something that is viable for consoles and APU's over the mid term.
2. Remember the HBCC, AMD(as is everyone) is well aware that memory performance scaling isn't keeping up with SOC performance scaling, especially when considering cost ($/power/etc). I think the next consoles will have 2 tiers of memory minimum maybe even 3:
So Something like:
1. bank of very high throughput memory ,2-4GB, 1 stack HBM3 or 2 stacks of HBM2/low cost HBM ~ 400-500GB/s ,GPU high throughput target
2. 8GB GDDR6, low/middle of the road GDDR6, take the cost to GB sweet spot 128bit bus? ~256GB/s , GPU low throughput target
3. 8GB DDR5, low/middle of the road DDR5, take the cost to GB sweet spot 128bit bus? ~100GB/s , primary CPU target
Have two modes of operation ( dev selectable on game load etc) , 1. HBCC handles data movement , maybe possible to give hints 2. each memory type is mapped to ranges and devs have full control.
It looks to me like AMD already have a lot of the infrastructure to facilitate this:
1. The interconnect that supports multiple memory controllers
2. The memory controllers and the packaging technologies needed
3. The black magic to decide when to move things around
What would be interesting in this type of solution is what the exact topology is, ideally all these memory types should be connected to the global fabric directly but this doesn't align to what we normally see with standard Dgpu typologies, but given that GPU's can handle latency well maybe it doesn't matter either way so long as the interconnects can scale throughput.
I dont see consoles getting a large amount of a single high performance memory regardless of what it is, to expensive across the board, by making a high cost investment in a small amount of memory, you can take the fish that John West rejects for the bulk of your memory requirements.
my assumption is DDR5 will be significantly cheaper then GDDR6, if its not then 16gb 256bit GDDR6 makes more sense.
Aren't we forgetting HDMI 2.1 VRR? Would we not see more unlocked framerate option in games and perhaps a middle-ground, let's say 45FPS framerate target (30FPS on non VRR TV's), with the next generation of consoles? I think XBO-X already supports it.
Last edited:
cheapchips
Veteran
Cerny made this comment to DF at the Pro launch*, which at least suggests they'll make a good CPU leap over PS4.
* In the context of Pro not being next gen
* In the context of Pro not being next gen
Last edited:
Do we even know if Cerny is involved with PS5 development?
cheapchips
Veteran
Don't know actually. Can't imagine Knack 3 is taking up all his time.
So a few things to think about:
1. I think something like the Samsung low cost hbm option could be something that is viable for consoles and APU's over the mid term.
2. Remember the HBCC, AMD(as is everyone) is well aware that memory performance scaling isn't keeping up with SOC performance scaling, especially when considering cost ($/power/etc). I think the next consoles will have 2 tiers of memory minimum maybe even 3:
So Something like:
1. bank of very high throughput memory ,2-4GB, 1 stack HBM3 or 2 stacks of HBM2/low cost HBM ~ 400-500GB/s ,GPU high throughput target
2. 8GB GDDR6, low/middle of the road GDDR6, take the cost to GB sweet spot 128bit bus? ~256GB/s , GPU low throughput target
3. 8GB DDR5, low/middle of the road DDR5, take the cost to GB sweet spot 128bit bus? ~100GB/s , primary CPU target
Have two modes of operation ( dev selectable on game load etc) , 1. HBCC handles data movement , maybe possible to give hints 2. each memory type is mapped to ranges and devs have full control.
It looks to me like AMD already have a lot of the infrastructure to facilitate this:
1. The interconnect that supports multiple memory controllers
2. The memory controllers and the packaging technologies needed
3. The black magic to decide when to move things around
What would be interesting in this type of solution is what the exact topology is, ideally all these memory types should be connected to the global fabric directly but this doesn't align to what we normally see with standard Dgpu typologies, but given that GPU's can handle latency well maybe it doesn't matter either way so long as the interconnects can scale throughput.
I dont see consoles getting a large amount of a single high performance memory regardless of what it is, to expensive across the board, by making a high cost investment in a small amount of memory, you can take the fish that John West rejects for the bulk of your memory requirements.
my assumption is DDR5 will be significantly cheaper then GDDR6, if its not then 16gb 256bit GDDR6 makes more sense.
I think, with a tiered memory, it could be smart to offload a lot of the memory management to an off-chip controller, to save space on the cpu/gpu soc. This doesnt help with an HDM combo, but if you have multiple types of external memories, you can just have the biggest bus possible between the apu and the controller and not care where the data is coming from, while the controller doesn't have to house much else on it, and can afford to use up most of its area with 3 different huge ass buses alowing a dev to maximise the use of either memory type whenever necessary, or find tbe best balance between the bandwith of each, without many gotchas.
The question is sort of "backward" to me, it will mostly come down to whatever AMD can provide.
I can't see the CPU being a "focus", the thing is that AMD CPUs have made strides in serial performances and power efficiency. Zen architecture is still being worked on and they already whip the floor with Jaguar cores, I see no point for either Sony or MSFT to stick with that old architecture. Clearly AMD could use lower power, tinier cheaper cores but it does not look like they have the means to support the R&D of a second line of CPU at the moment no matter their financials.
I've more "concerns" (not really yet the architecture show its age) about AMD catching up with Nvidia last GPU when it comes to lots of metrics (perfs per watts, per GB/s, geometry, what about "AI" cores).
I can't see the CPU being a "focus", the thing is that AMD CPUs have made strides in serial performances and power efficiency. Zen architecture is still being worked on and they already whip the floor with Jaguar cores, I see no point for either Sony or MSFT to stick with that old architecture. Clearly AMD could use lower power, tinier cheaper cores but it does not look like they have the means to support the R&D of a second line of CPU at the moment no matter their financials.
I've more "concerns" (not really yet the architecture show its age) about AMD catching up with Nvidia last GPU when it comes to lots of metrics (perfs per watts, per GB/s, geometry, what about "AI" cores).
Last edited:
Yes i agree.... Back then AMD was very competitive in the GPU sphere... much less today imo. Especially in the perf/watt metric.
HBRU
Regular
backward is not the question... It will come anyway... Its the forward compatibility the real question... Specially for Sony loosing the Ps4 installed base will be bad... Specially now that online is growing up and montly Subscription fees will change the market... (and in case of MS is already here).... So I guess vanilla PS4 on 720p even for most of the future games till -at least- 2025. Also consider that with the cripto boom silicon is not getting cheap soon.
Well X86 cpu cores can run X86, having BC up and running should not proove a "huge" (not trivial either) an issue now definitely I agree with your point Sony will be behind MSFT on that front Aand will have to paly catch-up and scale up the BC offering.
I don't think HBM and GDDR and DDR makes sense. Cheaper and simpler to use more, faster HBM (8gb, 1TB/s) and lots of relatively fast DDR (32gb, 120GB/s). Maybe some NAND flash as well.So a few things to think about:
1. I think something like the Samsung low cost hbm option could be something that is viable for consoles and APU's over the mid term.
2. Remember the HBCC, AMD(as is everyone) is well aware that memory performance scaling isn't keeping up with SOC performance scaling, especially when considering cost ($/power/etc). I think the next consoles will have 2 tiers of memory minimum maybe even 3:
So Something like:
1. bank of very high throughput memory ,2-4GB, 1 stack HBM3 or 2 stacks of HBM2/low cost HBM ~ 400-500GB/s ,GPU high throughput target
2. 8GB GDDR6, low/middle of the road GDDR6, take the cost to GB sweet spot 128bit bus? ~256GB/s , GPU low throughput target
3. 8GB DDR5, low/middle of the road DDR5, take the cost to GB sweet spot 128bit bus? ~100GB/s , primary CPU target
Have two modes of operation ( dev selectable on game load etc) , 1. HBCC handles data movement , maybe possible to give hints 2. each memory type is mapped to ranges and devs have full control.
It looks to me like AMD already have a lot of the infrastructure to facilitate this:
1. The interconnect that supports multiple memory controllers
2. The memory controllers and the packaging technologies needed
3. The black magic to decide when to move things around
What would be interesting in this type of solution is what the exact topology is, ideally all these memory types should be connected to the global fabric directly but this doesn't align to what we normally see with standard Dgpu typologies, but given that GPU's can handle latency well maybe it doesn't matter either way so long as the interconnects can scale throughput.
I dont see consoles getting a large amount of a single high performance memory regardless of what it is, to expensive across the board, by making a high cost investment in a small amount of memory, you can take the fish that John West rejects for the bulk of your memory requirements.
my assumption is DDR5 will be significantly cheaper then GDDR6, if its not then 16gb 256bit GDDR6 makes more sense.
itsmydamnation
Veteran
8GB @ 1TB/s is 4 stacks of HBM2, that is not cheap, maybe 2 stacks of HBM3 if it existing as a mass manufactured product in time. Thats going to be way more expensive then my two 1-2 Hi stack proposal. Also i said providing both DDR and GDDR comes down to cost difference between the two and to take the advantage the HBCC/HBM gives you to really drive down the spec/price of the GDDR/DDR.
Your solution is large expensive fast memory and large expensive slow memory....... If you were making a console better pray that memory prices crash hard......
