The former principal software Engineer on PS5 is implying a narrow and fast design could be an advantage in some cases for RT.
Playstation 5 [PS5] [Release November 12 2020]
- Thread starter BRiT
- Start date
D
Deleted member 13524
Guest
For a hypothetical PS3 BC sake, is there anything a Cell SPE or a PPE does at 3.2GHz that couldn't be emulated by a Zen2 core and its much more powerful 256bit FPU at 3.5GHz?
That's not to say they're impossible. If yields wouldn't substantially hurt their bottom line, I'd see no problem in enabling the extra CUs.
It wouldn't take them a respin to do that. The CUs that end up being disabled have the exact same layout and connections as the active ones, because they don't know which CUs end up being disabled during production.
And if Sony/AMD apparently found a way to disable 18 CUs out of 36 for base PS4 BC and up to 35CUs out of 36 for dashboard, then there's no reason to believe they wouldn't be able to disable 4 CUs out of 40 for PS4 Pro BC.
I also don't believe they'd need any substantial software work to enable those CUs. AMD makes firmwares that set the number of active CUs on GPUs and APUs, and drivers that just accept those differences on the fly, all the time. There's a chance the PS5 devkits already have 40 CUs enabled too, like the One X devkits.
Again: this seems unlikely at this point.
The memory bandwidth could be the bigger bottleneck, though. Sony deciding to go with 36 active CUs instead of 40 might have been influenced by their inability to secure enough 16Gbps/18Gbps chips on time. For example. more raw compute with reduced bandwidth-per-TFLOPs - with the possible GPU downclock it would require - wouldn't result in a large-enough real performance delta that would justify slightly lower yields.
Other than clock speeds, specs are unlikely to change.
That's not to say they're impossible. If yields wouldn't substantially hurt their bottom line, I'd see no problem in enabling the extra CUs.
It wouldn't take them a respin to do that. The CUs that end up being disabled have the exact same layout and connections as the active ones, because they don't know which CUs end up being disabled during production.
And if Sony/AMD apparently found a way to disable 18 CUs out of 36 for base PS4 BC and up to 35CUs out of 36 for dashboard, then there's no reason to believe they wouldn't be able to disable 4 CUs out of 40 for PS4 Pro BC.
I also don't believe they'd need any substantial software work to enable those CUs. AMD makes firmwares that set the number of active CUs on GPUs and APUs, and drivers that just accept those differences on the fly, all the time. There's a chance the PS5 devkits already have 40 CUs enabled too, like the One X devkits.
Again: this seems unlikely at this point.
The memory bandwidth could be the bigger bottleneck, though. Sony deciding to go with 36 active CUs instead of 40 might have been influenced by their inability to secure enough 16Gbps/18Gbps chips on time. For example. more raw compute with reduced bandwidth-per-TFLOPs - with the possible GPU downclock it would require - wouldn't result in a large-enough real performance delta that would justify slightly lower yields.
You linked to a personality on Twitter. That doesn't form the basis of an argument, even if you link to Lord Cerny himself! Link not to the account, but to the evidence - the quote or article. In this case, we have someone calling it a SPU like a SPU from PS3, and yes, I acknowledged that some people may be referring it to that. However, it's not a PS3 SPU (as you recognise)
Again, I don't understand what exactly the argument is here. I'm saying Tempest is a CU with the caches replaced with a DMA solution so the compute capabilities of the CU can be better used for streaming data.And scratchpad without cache is now a little bit exotic.
But at the end the programmer use it differently than a CU in a GPU. This is why Mark Cerny present it like this. If the programmer try to use it like in a GPU it will not work well. That's all I said and it is exotic and something not seen inside console since 2013. This DMA model was the reason many devs hated the CELL because it let the burden of memory management to the developer. Here it will be tolerated because it is easier to do with audio workload.
But I think make the CELL come back for backward compatibility is not a good idea from a cost point of view and worse for use it for new development out of Audio the most trivial case. I imagine what devs will think about another ISA, a different endianess and an in order PPU.
Most of the devs are happy with a PS4 it is a better console than the exotic PS3. At the end there are enough problem with huge budget in AAA games and it is more important to be indie friendly and not make life of dev problematic. A good old x86 or if one day they change an ARM CPU works perfectly.
Sony is again a bit more custom at least for things out of the CPU and GPU. From the SSD to the Tempest Engine and adding some new functionality to the controller. Will all of this will pay? Time will tell.
Edit:
Ex Frosbite technical director one of the multiple CELL hater:
Last edited:
Contrary to Cell they probably have easy APIs available to work with the Tempest CU.But at the end the programmer use it differently than a CU in a GPU. This is why Mark Cerny present it like this. If the programmer try to use it like in a GPU it will not work well. That's all I said and it is exotic and something not seen inside console since 2013. This DMA model was the reason many devs hated the CELL because it let the burden of memory management to the developer. Here it will be tolerated because it is easier to do with audio workload.
But I think make the CELL come back for backward compatibility is not a good idea from a cost point of view and worse for use it for new development out of Audio the most trivial case. I imagine what devs will think about another ISA, a different endianess and an in order PPU.
Most of the devs are happy PS4 is a better console than the exotic PS3. At the end there are enough problem with huge budget in AAA games and it is more important to be indie friendly and not make life of dev problematic. A good old x86 or if one day they change an ARM CPU works perfectly.
Sony is again a bit more custom at least for things out of the CPU and GPU. From the SSD to the Tempest Engine and adding some new functionality to the controller. Will all of this will pay? Time will tell.
Edit:
Ex Frosbite technical director one of the many CELL hater:
Modified compute GPU API probably...
AMD already has an audio SDK for the GPU. I imagine it's going to be very similar to that.
Quite possibly not even that. If the engine is an audio processor, Sony will provide the Audio library. There's a reason they bought up the makers of WWise.
Quite possibly not even that. If the engine is an audio processor, Sony will provide the Audio library. There's a reason they bought up the makers of WWise.
Yes Audiokinetic the biggest Audio middleware, I forget this. For sure developer friendly out of Sony devs working on the library but for some like Jaymin Kessler it is a dream.
This is ok if the burden is not on third party devs but on Audiokinetics, ICE Team and Sony ATG devs.
Last edited:
So the Wwise stack is already integrated into the workflow and GPU architecture (e.g., ray tracing hardware) ?
https://www.audiokinetic.com/products/wwise-spatial-audio/
... and then the custom CU for rendering the audio efficiently (SPU style) for the perceivable objects and environmental sound sources ?
https://www.audiokinetic.com/products/wwise-spatial-audio/
... and then the custom CU for rendering the audio efficiently (SPU style) for the perceivable objects and environmental sound sources ?
Last edited:
May be ? Honestly it’s probably better to wait for Sony to say more. They have bits and pieces of relevant technologies in the new system. The RPCS3 project sounds interesting too.
But it may be a business decision first and foremost, which is out of scope in Console Technology.
This seems logical.
If the can release a PS3 emulator on x86 and AMD GPU architecture it makes maybe an economical sense for PSNow.
Last edited:
https://github.com/GPUOpen-LibrariesAndSDKs/TAN
AMD has already optimized the most expensive audio processing functions for their GPUs.
AMD has already optimized the most expensive audio processing functions for their GPUs.
Yes, but it needs to be done again because this is not working exactly the same on PS5 tempest Engine and I think Sony probably did it optimizing WWise API for PS5. This is logic.
If you read the wiki for “AMD TrueAudio”, you’ll find brief mentions of Wwise’s value adds (and further optimization) over it.
And specifically for PS5, Sony will need to optimize it some more for their custom hardware, and potentially fit into (or at least don’t disturb) their streaming system.
Wwise also has software to help author and manage sound objects during development.
Last edited:
Let's put it in a very naive view: almost all processors we see these days are von Neumann architecture — they load instructions, they do work as instructed, and they write results back. "A modified CU" makes no difference other than the work it specialized in, and what memory it operates with. Perhaps it has more instructions catering to the heavy low-precision matrix maths that audio DSPs favor. Perhaps it has a scratchpad SRAM like SPUs given the emphasis on a DMA programming model. But these do not constitute a fundemental need of change to the general-purpose AMD CU microarchitecture, and how they fit into the system architecture.
For example, AMD and Nvidia both have been experienced in customizing CUs for different market segments. Also, a DMA based model is, eh, what GPUs have been accustomed to, especially considering Xbox One X and its scratchpad SRAM (exotic for GPUs but common in DSPs). The Tempest CU may totally work like a normal CU at the grand system level, differing only in its resources: e.g. being controlled by a dedicated ACE pipe (priority queues like TAN), implementing a slightly different instruction set with matrix math additions, having neither L0/L1 cache nor LDS nor "graphics stuff" (TMU/export/GDS), and being physically close to a DMA-addressable large scratchpad SRAM.
Cost-effective for both AMD and Sony, and still matches the profile of the Tempest CU as described by Cerny.
What I expect was the Tempest CU to be controlled like TrueAudio Next, through AMD's compute front-end, and I acknowledged the fact that PS5 does not crave out a pie from the main pool of CU like TAN does.
It is important to stress that I am not disputing any communicated information — I am merely trying to interpret them from a software engineer angle, and perhaps highlight IMO the unnecessity of a "Yes SPU Not SPU" merry-go-round.
Last edited:
When I said reserved a CU in GPU I don't speak about a technical solution but why they created the Tempest. They could have gone with more CUs and give the possibility to dev to reserved some CUs for audio but like on PS3 and PS4 audio would have received a fraction of the CPU or GPU power out of VR. This the reason Ninja Theory told too they are happy to have an audio DSP inside the XSX.
I talk because I know an audio guy working on a Ps5 exclusive and he told me rendering dev were always winning the argument against the audio engineer. But after VR, the possibility to promote 3d audio using youtube and using it to differentiate the PS5 to the XSX, they decided to dedicated some horsepower to it.
This is not perfect because it does not use personalized HRTF but using headphone this video is impressive. They can now use 3d audio inside trailers.
Might be because the SPUs can be fully autonomous after setup (like a CPU). They fetch their own instructions and run them, handle interrupts (in a limited fashion), etc. e.g., The PS3 secure kernel runs completely off an SPU’s local memory and is “segregated” from the other cores.
Some day, we may find out how autonomous this custom CU is (if at all).
The Wwise acquisition is interesting in the sense that they also have a large library of software-based audio effects (on the CPU). Pretty good for cross platform development. Developers can deploy their audio solution to CPU or GPU or custom units as they see fit.
Last edited:
I think the answer to his question depends highly on memory/latency of data to feed the CUs.
Wow, didn't even know this happened!
Similar threads
- Locked
- Deleted member 7537
- Games Industry
- Sticky