There is indeed no Cell 2.0, end of the story no matter how I look at it.
Last edited by a moderator:
PlayStation 4 (codename Orbis) technical hardware investigation (news and rumours)
- Thread starter Love_In_Rio
- Start date
- Status
So basically it's nothing at all like Cell.
I kind of like ArsTechnica but that article is bad and doesn't mean much.
There are typos to begin with, Sony is building a CPU based on directx etc. The guys meant GPU.
Anyway, I would prefer to go by the specs sheet or the Japanese interview (now properly translated but even google translation made more sense than that "piece" from Arstechnica).
Yes, the Japanese interview has much more tech details that clear up a few things.
First and foremost, it talks about Cerny's technical ambition: To create a "seamless" programming model + platform for programming the CPU and GPU together, like how they programmed PPU and SPU together.
I took a quick look at the leaked SPURS doc.
The SPUs and PPUs are programmed in C/C++. They load SPURS kernel into the SPUs (and PPU) so that they manage themselves without PPU intervention. They also have some sort of real-time scheduling system in place to hang tasks/jobs in work queues. The system knows about the deadlines and schedule tasks around some set schedule (and if they have already missed it).
You debug the PPUs and SPUs in an integrated graphics debugger.
This is Cerny's goal but they are not there yet. It's not like OpenCL because the GPU doesn't need to switch compute/graphics mode per se. They probably want to schedule the CUs like the SPUs in SPURS in one consistent framework.
[... and I have to go fetch my kid now
]
EDIT:
I think the gist of it is they are trying to hammer away any low level obstacles, and at the same time put in the necessary tweaks to rope the CUs closer to the CPU.
Gotta run now !
First and foremost, it talks about Cerny's technical ambition: To create a "seamless" programming model + platform for programming the CPU and GPU together, like how they programmed PPU and SPU together.
I took a quick look at the leaked SPURS doc.
The SPUs and PPUs are programmed in C/C++. They load SPURS kernel into the SPUs (and PPU) so that they manage themselves without PPU intervention. They also have some sort of real-time scheduling system in place to hang tasks/jobs in work queues. The system knows about the deadlines and schedule tasks around some set schedule (and if they have already missed it).
You debug the PPUs and SPUs in an integrated graphics debugger.
This is Cerny's goal but they are not there yet. It's not like OpenCL because the GPU doesn't need to switch compute/graphics mode per se. They probably want to schedule the CUs like the SPUs in SPURS in one consistent framework.
[... and I have to go fetch my kid now
]EDIT:
I think the gist of it is they are trying to hammer away any low level obstacles, and at the same time put in the necessary tweaks to rope the CUs closer to the CPU.
Gotta run now !
So it's nothing at all like the Cell paradigm. Liverpool is in fact a Toaster Oven, while the Cell was a CPU with accelerating cores.
The way Cerny is presenting the link between the Cell and Liverpool, while at the same time saying they had to ditch BC, seems to be an attempt to help the porting of PS3 games. As long as they can recompile them, and modify them to work on the PS4. They need to prevent having a bottleneck which would change the paradigms used to code against the SPUs. I think he's saying the Cell had some strong advantages in this area (the close coupling and SPU memory model that is micro-managed and doesn't pollute the cache) maybe they wanted to modify the APU to make it at least on par with the SPUs in every aspect, so porting would be much easier. (could this help software BC too?)
Ever since we looked at early leaks with 18 CU's with 4 of them dedicated for CPU assistance, it always seemed to be the case apparently, that there may be an attempt for software BC of PS3 games or at least enhanced ports.
Well I wouldn't say they are aiming for BC at this point. They are shooting for abstraction and general use of the CUs first. The CUs and the SPUs have pretty different characteristics. They may not be able to emulate the SPUs adequately. Presumably they can load their SPURS kernel into the CPU cores and ACEs for the CUs to manage themselves like the SPUs ?
Made a mistake above. Instead of bringing the CUs closer to the CPU, it's probably more accurate in spirit to say they want to bring the CUs closer to the developers. Hence they need to chisel away some of the default h/w behaviors that may be too restrictive or difficult (because of legacy/GPU assumptions) when the dev tries to use them at the abstract level.
Made a mistake above. Instead of bringing the CUs closer to the CPU, it's probably more accurate in spirit to say they want to bring the CUs closer to the developers. Hence they need to chisel away some of the default h/w behaviors that may be too restrictive or difficult (because of legacy/GPU assumptions) when the dev tries to use them at the abstract level.
As for "BC":
Re-coding the SPU "applets" or whatever they're called to something equivalent (that can run on the GPU, possibly, or else on a CPU thread) can't be too horrific a task can it? Each SPU only has 256k RAM available to it, less for actual code. *shrug* I'm not a coder, especially not a PS3 coder, so maybe it would be a huge deal that would require re-engineering most if not all of the rendering code. Who knows.
Maybe ERP or another of our experienced gearheads can offer insights?
Re-coding the SPU "applets" or whatever they're called to something equivalent (that can run on the GPU, possibly, or else on a CPU thread) can't be too horrific a task can it? Each SPU only has 256k RAM available to it, less for actual code. *shrug* I'm not a coder, especially not a PS3 coder, so maybe it would be a huge deal that would require re-engineering most if not all of the rendering code. Who knows.
Maybe ERP or another of our experienced gearheads can offer insights?
By and large, the SPUs are used for graphics related compute jobs. It's probably easier to recode the SPUlets in the CUs' native language and unified memory environment, instead of following the SPUs' way in a split pool setup.
The SPUs also run @ 3.2GHz, twice as high as Jagaur's, 4 times the CUs' clock. OTOH, the CUs pack more power and features.
It sounds more like them improving their practices instead of targeting BC this way.
The SPUs also run @ 3.2GHz, twice as high as Jagaur's, 4 times the CUs' clock. OTOH, the CUs pack more power and features.
It sounds more like them improving their practices instead of targeting BC this way.
Porting anything that ran on a general purpose processor, even one with limited memory to GPU code so it runs with any degree of efficiency is at best hard and sometimes impossible.
GPGPU programming is IME counter intuitive, especially if you've spent any time writing optimal CPU code. Where on a CPU you avoid touching memory or copying it at all costs, often the most efficient thing to do on a GPU is copy and reformat megabytes of memory, so you can get some degree of compute efficiency.
It's also often difficult to determine what the actual bottleneck is in a compute shader, and intuitions tend to not be correct.
It is not uncommon for someone writing their first none trivial compute shader to end up with something slower than a single threaded CPU implementation even though the CPU solution is fp bound and the compute shader has hundreds of times the fp performance.
SPUs also sat behind a very fat, but extremely high-latency bus, AFAIK without direct access to GPU RAM, or at least extremely slow access (something like 25MB/s or such). So to do graphics on GPU assets, you first had to get the GPU to DMA over the stuff to XDR memory to avoid the ridiculous speed penalty (with all the overhead and latency that entails, hits to bandwidth to both pools of RAM etc), have the SPUs fetch it via DMA (more latency), do the actual processing at 3.2GHz, and then transfer back in reverse order. Probably not a net gain, compared to running a compute shader on a modern GPU @800MHz...
- Anyone has idea what kind of CPU will be inserted into southbridge? 1 module Temash or some ARM?
- Who will make it? AMD?
- Will that CPU has its own memory pool or will it access power-hungry GDDR5?
- If it has access to its own memory pool [one or two 512MB DDR3 chips], is there a chance that beefy soutbridge CPU [~5 watts] will be used for running complete OS/UI, leaving central APU and GDDR5 to be [almost] free for gaming?
Yes, but SPUs weren't exactly your average run of the mill general purpose processors, so maybe you could trade one set of Cell SPU complications for GPGPU complications?
(Yeah yeah... Programming doesn't work like that, I know. ) In any case, how many types of SPU jobs do PS3 games include these days, in general? If it's just a couple you could perhaps be able to brute-force it done, since rendering a PS3 game on hardware more than half a decade more recent shouldn't be too taxing one would think.Then again, some games alledgedly massage geometry with SPUs, culling or even outright transforming instead of using GPU vertex shaders I seem to recall reading here on B3D, all that SPU code could of course just be straight dropped without any problems, you'd just let the GPU handle that work like you ordinarily would on any other (decently) modern platform.
All that would remain would be actual graphics processing, like say, DoF, glow effects and stuff like that, and those things should run quite well in a compute shader wouldn't they?
Maybe Sony's additional debug hardware they purportedly included in PS4 will help with that. Surely there has to be performance counters exposed to developers so they can properly examine how their code actually runs on the hardware...?
Yes, the Japanese interview has much more tech details that clear up a few things.
First and foremost, it talks about Cerny's technical ambition: To create a "seamless" programming model + platform for programming the CPU and GPU together, like how they programmed PPU and SPU together.
I took a quick look at the leaked SPURS doc.
The SPUs and PPUs are programmed in C/C++. They load SPURS kernel into the SPUs (and PPU) so that they manage themselves without PPU intervention. They also have some sort of real-time scheduling system in place to hang tasks/jobs in work queues. The system knows about the deadlines and schedule tasks around some set schedule (and if they have already missed it).
You debug the PPUs and SPUs in an integrated graphics debugger.
This is Cerny's goal but they are not there yet. It's not like OpenCL because the GPU doesn't need to switch compute/graphics mode per se. They probably want to schedule the CUs like the SPUs in SPURS in one consistent framework.
[... and I have to go fetch my kid now
EDIT:
I think the gist of it is they are trying to hammer away any low level obstacles, and at the same time put in the necessary tweaks to rope the CUs closer to the CPU.
Gotta run now !
Welcome to the mind of a mad man.
http://forum.beyond3d.com/showpost.php?p=1715734&postcount=9 http://forum.beyond3d.com/showpost.php?p=1722235&postcount=908
http://forum.beyond3d.com/showpost.php?p=1723418&postcount=1107
& it's kinda scary to think how amazing this could be if it all works out as planned, using the APU as a powerful CPU & GPU at the same time, I guess this is why they called it a 'Supercharged PC Architecture' but I think it will take some time for them to take full advantage of this & most developers will probably stick to what they know & use the CPU & GPU the same way they would on a PC game.
SPUs also sat behind a very fat, but extremely high-latency bus, AFAIK without direct access to GPU RAM, or at least extremely slow access (something like 25MB/s or such). So to do graphics on GPU assets, you first had to get the GPU to DMA over the stuff to XDR memory to avoid the ridiculous speed penalty (with all the overhead and latency that entails, hits to bandwidth to both pools of RAM etc), have the SPUs fetch it via DMA (more latency), do the actual processing at 3.2GHz, and then transfer back in reverse order. Probably not a net gain, compared to running a compute shader on a modern GPU @800MHz...
It's rather different.
The SPU uses LocalStore, which offers L1 level access speed and latency. They use DMA to load the LocalStore in double buffer manner (e.g., 1 thread loads the data while the other thread computes). The memory access latency is hidden this way. If the SPUs hit their LocalStores regularly, they can be hard to beat.
Access to XDR is around 16-22GB/s. Read access to GDDR3 is 16MB/s, and write is 4GB/s. Presumably, the SPUs will rely on XDR access more.
The CUs have much more computation power and a more restrictive instruction set. It also has more direct/"closer" access to other graphics h/w and the bulk of graphics data. It doesn't need to shuffle data between 2 pools of memory unnecessarily too.
Going for dinner now !
Lucid_Dreamer
Veteran
I remember a B3D discussion about how GPUs don't/can't use all of it's clock cycles. It had something to do with all the extra power eSRAM could possibly through "efficiency".
Knowing a GPU can't make full use of ALL of it's clock cycles, why couldn't that be an opportunity to stick some compute tasks within those windows? Wouldn't that still leave it's normal graphics tasks uneffected?
Didn't Cerny say they could bypass GPU L2 and L1 cache?
Just so long as you understand that the 1.84TF number is arrived at by using every alu on every cycle.
So yes you could gain efficiency, but just because you're running code that isn't particularly graphics intensive at certain times does not mean that is the time when you will need extra compute just because the GPU would be available.
So yes you could gain efficiency, but just because you're running code that isn't particularly graphics intensive at certain times does not mean that is the time when you will need extra compute just because the GPU would be available.
Lucid_Dreamer
Veteran
If it's impossible to use all the clock cycles for graphics and GPGPU tasks could fill those empty clock cycle, which sayings would still be accurate?
- GPU and GPGPU tasks can be handled, simultaneously, without effecting graphics.
- GPU compute and graphics tasks can co-exist with no penalty to graphics.
It's all still means the same thing onQ was saying. You have all the graphics power + whatever can be pulled from the remaining clock cycles. That should be a HUGE amount of processing capability.
Question: If GPU commands are issued in waves, wouldn't that mean one cycles are naturally not being used? When FLOPs tests are performed, are they still using this "wave" technique?
- Status
