PlayStation 4 (codename Orbis) technical hardware investigation (news and rumours)

[Shifty Geezer]

There's clearly need for a high-level explanation of GCN to inform the mainstream so they have a point of context for their understanding of all these quotes and rumours. I'll post one later if no-one beats me to it. A lot of what Sony+AMD have been talking about is just GCN. AMD are clearly using Orbis as an opportunity to embiggen their mindshare, talking 18 month old info on their superior compute abilities to a fresh audience that's ready to listen. There's very little specific to Liverpool that's different to any other GCN APU, but that should be obvious once it's all spelt out.

 

[patsu]

It sounds like Sony specialized and customized GCN in the following ways:

* Support a SPURS-like run-time (GPU h/w tweaks and software framework)
e.g.,
+ Onion+ access and cache tweaks
+ 8 compute queues

* Support PS4 OS (ditto)
+ High priority VSHELL GPU queue
+ Using TrustZone for loading/unloading BR and PSN contents in the background
+ Running BSD drivers and kernel

* Others
+ dedicated decompression unit, assuming audio and video decoding/encoding is done by the standard GCN AV h/w

- 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?

According to the TrustZone architecture, the ARM CPU may access DDR memory as well as Flash RAM. I assume it can access the GDDR5 main memory to establish secure regions in the memory space. The Flash RAM should be private to the OS.

 

[Exophase]

According to the TrustZone architecture, the ARM CPU may access DDR memory as well as Flash RAM. I assume it can access the GDDR5 main memory to establish secure regions in the memory space. The Flash RAM should be private to the OS.

TrustZone has nothing to do with the kinds of memory an ARM CPU can access. Which isn't part of an ARM CPU design anyway, it's something you add externally to it. Although ARM supplies various memory controller IP if you want to use theirs.

The GDDR5 controller is almost certainly on the APU chip. If a sounthbridge chip wants to access the GDDR5 it will have to talk to the APU.

Running the OS on a separate chip with a separate architecture and everything sounds like a bad idea and not likely. You need low latency and low overhead access access to OS functions. Having it control anything graphical is especially weird given all the graphics capabilities are on the other chip.

The description by Cerny seems pretty clear and doesn't really invite fanciful ideas about what it's being used for. It has the I/O (HDD, SD, USB, wifi, etc) and has an embedded processor that can independently work the internet connection and perform updates to the main storage in the background. It doesn't need access to a huge pool of memory, it can probably make due with a fairly small amount of on-chip SRAM as is standard for embedded microcontrollers.

 

[Lucid_Dreamer]

What's the distinction?

That if it wasn't a part of the graphics pipeline, it wouldn't be counted.

 

[Pete]

The whole GPU tends to be for graphics, hence the G. But FLOPs deals with the ALUs. The same ALUs that are used for shaders or physics or, you know, in general.

 

[onQ]

By the way why does VGLeak show the GPU as being 1.843 Tflops, 922 GigaOps/s?


I never seen a GPU Performance shown in GOPS.

 

[ERP]

By the way why does VGLeak show the GPU as being 1.843 Tflops, 922 GigaOps/s?


I never seen a GPU Performance shown in GOPS.

Because the ops are a MADD which is 2 flops per op

 

[onQ]

Because the ops are a MADD which is 2 flops per op

Ok thanks.

 

[Averagejoe]

No. Jesus. How would you run compute and graphics tasks simultaneously on the same hardware? If you run compute tasks, you CANNOT run graphics stuff on those same execution units. They only do one thing at a time.

No! If some execution units run compute tasks then there will be fewer units available to run graphics tasks. So there will be a penalty to performance.

Where is all this fairytale nonsense about unrestricted simultaneous execution coming from? Jesus! Since when has that ever been possible on any piece of hardware, much less an el cheapo APU?!!!

There's no magic involved here. Pretty much no complex processor ever made can come close to 100% utilization all the time. That's just the way it is.


...And he's been talking out of his ass for weeks now, imagining this kind of nonsense which you are now repeating and perpetuating.


Batches, really. "Waves", or wavefronts, or whatever (this is an nvidia term I believe, not AMD) is just a gimmicky label someone invented because it sounded cool to him I suppose.


No. Quite the opposite really. Commands are batched up to utilize as much as possible of the hardware. Before the hardware is finished with one set of batches you would normally send it new batches to work on, if there's still anything left to process.


Not sure what you're trying to say.

So what sony told developers was a lie.?

 

[pjbliverpool]

So what sony told developers was a lie.?

Compute and graphics jobs can be run on the GPU simultaneously. This is what Sony meant. You cannot however (quite obviously if you stop and think about it) fully utilise every single ALU in the GPU for graphics tasks "all 1.84 TFLOPS" and then still run compute workloads on those same ALU's.

Surely you can see this? There is 1.84 TFLOPS to be spent on jobs. You can spend it all on graphics, all on compute, or split it between the two. You can't spend it twice.

 

[tunafish]

So what sony told developers was a lie.?

Nope. A lot of the people reading their releases, including a lot of the press, just have insufficient technical background to understand what they are hearing.

What the sony statement was about is the granularity of switching between different workloads. In most earlier gpus, switching between tasks is a very large job, making planning of their use a much more serious problem and in general making gpgpu use in games hard. GCN is much better at this, basically being able to issue instructions from different workloads back to back.

 

[Shifty Geezer]

So what sony told developers was a lie.?

No, it was just a more complicated situation than people are understanding. Would you say a multi-threaded CPU is capable of running 2 programs concurrently? That's what we have with GCN. It can run 2 (8 on Liverpool) programs at the same time, but it either performs calculations on one program at a time, interleaving operations, or it can run one program on one set of CUs and another program on another set of CUs just like a multicore CPU. Think of the CUs as cores. If the core is busy processing graphics, it can't run compute, and vice versa, but the whole chip can run compute and graphics simultaneously.

 

[Grall]

So what sony told developers was a lie.?

No.
(Just to jump on the bandwagon! )

People - read: fanboys, poorly educated laypersons and so on - simply misinterpreted what Sony told developers and assumed things that are not true. ...And reasonably cannot in fact be true either by the way.

 

[Averagejoe]

Oh now i see thanks to all of you for answering my question..

 

[patsu]

TrustZone has nothing to do with the kinds of memory an ARM CPU can access. Which isn't part of an ARM CPU design anyway, it's something you add externally to it. Although ARM supplies various memory controller IP if you want to use theirs.

The GDDR5 controller is almost certainly on the APU chip. If a sounthbridge chip wants to access the GDDR5 it will have to talk to the APU.

Running the OS on a separate chip with a separate architecture and everything sounds like a bad idea and not likely. You need low latency and low overhead access access to OS functions. Having it control anything graphical is especially weird given all the graphics capabilities are on the other chip.

The description by Cerny seems pretty clear and doesn't really invite fanciful ideas about what it's being used for. It has the I/O (HDD, SD, USB, wifi, etc) and has an embedded processor that can independently work the internet connection and perform updates to the main storage in the background. It doesn't need access to a huge pool of memory, it can probably make due with a fairly small amount of on-chip SRAM as is standard for embedded microcontrollers.

Found better diagrams in:
http://www.arm.com/products/processors/technologies/trustzone.php
The ARM CPU in TrustZone indeed only access SRAM and Flash.

In the general TrustZone architecture, it is possible that the Secure World in TrustZone run a separate "secure OS" for handling bootup, asynchronous/background checks and general synchronous security operations. The secure OS and kernel is small. In PS3, they reserved an SPU (plus PPU part-time) to implement its GameOS security kernel + hypervisor.

The Normal World CPU calls TZAPI to deal with the Secure World synchronously, or asynchronously for secure services.

This is assuming PS4 uses TZ "as is".

 

[MrFox]

+ dedicated decompression unit, assuming audio and video decoding/encoding is done by the standard GCN AV h/w

I'm curious how they connected the ZLib hardware. I assume it's only used for the I/O and installs, and it could be useful for background tasks, so maybe they put it in the south bridge?

 

[Exophase]

Found better diagrams in:
http://www.arm.com/products/processors/technologies/trustzone.php
The ARM CPU in TrustZone indeed only access SRAM and Flash.

In the general TrustZone architecture, it is possible that the Secure World in TrustZone run a separate "secure OS" for handling bootup, asynchronous/background checks and general synchronous security operations. The secure OS and kernel is small. In PS3, they reserved an SPU (plus PPU part-time) to implement its GameOS security kernel.

The Normal World CPU calls TZAPI to deal with the Secure World synchronously, or asynchronously for secure services.

This is assuming PS4 uses TZ "as is".

That diagram is an example configuration to try to illustrate behavior. Nothing about Trust Zone has anything to do with SDRAM (not SRAM, none of the diagrams even have it) or flash interfaces. Without more information there's no reason to believe Sony is using Trust Zone to begin with, even if we assume they'd be using ARM. Most ARM devices aren't using Trust Zone for anything.

I said it already but the GDDR5 controller is almost guaranteed to be on the APU. So you can't do anything about securing access to it with a separate I/O chip.

Sure feels like a lot of people here like to misapply press release tidbits on topics they don't really understand :/

 

[patsu]

That diagram is an example configuration to try to illustrate behavior. Nothing about Trust Zone has anything to do with SDRAM (not SRAM, none of the diagrams even have it) or flash interfaces. Without more information there's no reason to believe Sony is using Trust Zone to begin with, even if we assume they'd be using ARM. Most ARM devices aren't using Trust Zone for anything.

My bad. SDRAM ! (Typing over iPad !)
Most ARM vendors are not as paranoid as game platform owners.

AMD licensed TrustZone in mid 2012:
http://www.anandtech.com/show/6007/...cortexa5-processor-for-trustzone-capabilities

TrustZone uses an ARM CPU to implement the required security services.

We have only read rumors about Sony using TrustZone thus far. It is not unreasonable to assume that whatever security they come up with, the ARM CPU in the Southbridge will come in handy in the TrustZone sense. They will need to lock down everything because the hackers will target the weakest link(s).

The simplest TrustZone implementation will probably consist of just synchronous security operations. At this point, we know the custom ARM CPU is used for additional background jobs in PS4.

I said it already but the GDDR5 controller is almost guaranteed to be on the APU. So you can't do anything about securing access to it with a separate I/O chip.

Yap. The APU will need to run part of the security services to protect its memory. The PS3 security is jointly enforced by a dedicated SPU and a part-time PPU. In PS4, the ARM CPU can help secure/authorize the boot sequences, I/O and "PowerNap" operations. In general, the more things they get the ARM CPU to do autonomously, the more they need to secure it independently.

Sure feels like a lot of people here like to misapply press release tidbits on topics they don't really understand :/

It's a learning process. IMHO, the techies may be overly dramatic over a few misunderstandings and individuals.

 

[Exophase]

Maybe Sony is using TrustZone on their southbridge chip (that probably but doesn't necessarily use ARM). But this doesn't have any bearing whatsoever on what sort of memory this chip will see. There's no reason to believe it'll have its own pool of external flash or SRAM or DRAM, including direct access to any GDDR5. It simply doesn't need it to perform the functions we are currently aware of. Think of any other southbridge chip you've seen in a motherboard. These things aren't there.

If direct security between the APU and GDDR5 is required then it will be the memory controller on the APU that must facilitate it. That's different from things like secure booting or anything that involves talking to I/O.

Hopefully Sony has enough sense to stop dedicating entire cores to system tasks but I'm not optimistic..

I'm in no way opposed to learning but a big part of that is listening and not constantly stringing things together in the hope of landing on a point, while trying to inform people.

 

[patsu]

Hopefully Sony has enough sense to stop dedicating entire cores to system tasks but I'm not optimistic...

AMD licensed TrustZone. If Sony used other non-ARM chips for TrustZone, they will have to pay extra -- unless they roll their own completely.

PS4 has a custom ARM chip according to Cerny's presentation. It does a bunch of background jobs that needs to be secured (loading/unloading stuff from BR, HDD and network). Besides TrustZone rumor, there was/is also a rumor regarding 16GB Flash RAM associated with PS4. It's hard to exclude the rumor at this moment because Sony built-in 4GB of Flash RAM in PS Vita, but they never mentioned it in any PR.

I agree the ARM CPU won't have direct access to the GDDR5. During bootup, the APU itself may layout and protect part of its memory. I remember the PPU in PS3 does that, and the dedicated SPU runs off with its own LocalStore so that no one can attack it by corrupting memory and other external facilities.