GAF machine
Member
The name I'm referring to is 'YAMAZAKI'. It's on the back of PS5's SSD controller, and it's the last name of Takeshi Yamazaki. An SIE engineer Ken Kutaragi put at the forefront of Emotion Engine and CELL Broadband Engine R&D. The significance of this is the SSD controller is CELL inspired because one of the original PS5 I/O complex + SSD patent applications filed by Hideyuki Saito (devised the PS5's I/O complex + SSD data access request and address translation schemes; also helped IBM test CELL's functional correctness) cites a patent down in the 'Patent Citations' section (i.e., US8504736B2) for a file input/output scheduler (FIOS) that runs on CELL's SPUs). This FIOS application cites another application for a CELL-accelerated NIC server board of which Yamazaki co-invented (Sony/SIE used these server boards for their streaming services; the link to the intro of the server board whitepaper can be found in this related OP embedded in the words 'network processing'). Although the application details the specific invention of data transfer from a CELL's SPE to a NIC, language in one of the patent entries encapsulates two defining characteristics of Yamazaki's SSD controller, which are:
Given this and the harmonious operation of the Zen 2 + I/O complex + SSD controller system, I'd hazard a guess that Yamazaki was also responsible for designing PS5's I/O complex too. There are so many similarities between the CELL + NIC server board and the Zen 2 + I/O complex + SSD controller system, that it's impossible to ignore the overlap. I will attempt to summarize them from their respective applications, but these summaries will get into the weeds so those still reading please bear with me:
Two other similarities not part of the two patent applications, but which I thought were worth mentioning as they show CELL's heavy influence on the I/O complex's design are:
1) while the SPE is a type of CPU, it's also an accelerator in its own right. As some of you still reading may not know, it was used as an engine to accelerate decompression for PS3 (e.g. the Oodle Beta and subsequent Oodle releases starting with 1.1.0 - April 11, 2013). The Kraken decompression engine (i.e. the accelerator mentioned in entry [0081] of the I/O complex + SSD patent) is essentially a substitute SPE designed to chew on chunks of data the size of an SPE's 256KB local store. Entry [0111] of the CELL FIOS patent and Fabien Giesen's Kraken tweets practically say as much:
[0111]
By way of example, in the certain cell processor architectures, the SPE 206 have a local store capacity of 256 Kbytes. This is often sufficient memory space for the compressed input, the decompressed output and the code for the decompression algorithm
2) PS3's low-level graphics API (GCM) largely runs on SPUs, and treats them as a form of graphics command processor/coherency engine. They can be synchronized with the RSX to give the end-user tight control over when and what commands the RSX executes via the placement and subsequent overwriting of "local stalls" in the command buffer. SPUs can also overwrite previously written data located in a range of addresses stored in VRAM (per section 2.1 Memory Allocation under "RSX local memory", continued here) before the RSX can copy the stale data out of VRAM into its caches. PS5's I/O co-processors, coherency engines and cache scrubbers automate and evolve this process from low-level GPU memory management to low-level GPU cache management. But the main takeaway here is that SPUs free up their main CPU (i.e., PPE) from having to keep tabs on and overwrite address ranges. I/O co-processors and coherency engines in PS5 free up their main CPU (i.e., Zen 2) from having to keep tabs on and overwrite address ranges.
Extremely long story short, I think that Yamazaki designed the I/O system to not only rapidly store and transfer data around inside PS5, but to also rapidly feed an external compatibility adaptor in the service of PS5 backwards compatibility with PS1, 2, 3 games (in this post, I raised the prospect of SIE releasing a CELL/RSX-based compatibility adaptor to run PS1, 2, 3 games "on" PS5).
By this I mean once a user has selected a previously downloaded PS1, 2 or 3 game (purchased from the PS Store in the past or rented from PS Now) to play from an SSD, Zen 2 tells the adaptor to ready itself for the selected game. Once ready, the adaptor tells Zen 2 which then tells the SSD I/O co-processor inside the I/O complex to have the SSD controller read the selected legacy game's file data from an SSD and forward it in 4KB, 64KB, 1MB or 16MB chunks to the adaptor's internal flash storage via ethernet cable.
As the game file data arrives and is stored in the adaptor's flash storage, CELL quickly accesses it under a scheme similar to PS5's (i.e. using two or more priority levels) and processes it according to the legacy console it belongs to. Possibly resulting in quicker load times because the data reads sent from PS5's SSD to the adaptor are already chunked in 4KB, 64KB, 1MB or 16MB sizes the way CELL likes it. After the CELL/RSX-based adaptor renders a frame of the legacy game, the frame is then sent via ethernet cable to PS5's system memory, pulled out by Oberon and is either displayed as is or spruced up/upscaled before being displayed.
Likewise, a similar process would exist for disc-based PS1, 2, 3 titles in which PS5's disc drive reads the disc and sends signals containing game data to the adaptor. Once received, the adaptor extracts the game data from the signal and forwards the data to its internal flash storage to be accessed from there and processed according to the legacy console it belongs to.
How sweet would that be?
Given this and the harmonious operation of the Zen 2 + I/O complex + SSD controller system, I'd hazard a guess that Yamazaki was also responsible for designing PS5's I/O complex too. There are so many similarities between the CELL + NIC server board and the Zen 2 + I/O complex + SSD controller system, that it's impossible to ignore the overlap. I will attempt to summarize them from their respective applications, but these summaries will get into the weeds so those still reading please bear with me:
CELL + NIC server board:
With CELL, the PPE (main-processor) and SPE (sub-processor) page sizes are the same. These pages (data) are strictly 4KB, 64KB, 1MB or 16MB in size (i.e. page granularity levels), and are grouped into an address translation table to be referred to by an SPE:
[0015]
The sub-processors 24 (24-1 to 24-n) are ancillary program execution means containing local memory 24 a, a memory management section
[0014]
The address translation table is a table which associates logical addresses with physical addresses, and is made up of page groups of a specified size such as 4 KB. Therefore, the memory management section 12 a is provided with a memory for storing the necessary pages, of these pages,...
Zen 2 + I/O complex + SSD controller system:
With the Zen 2 + I/O complex + SSD controller system, the Zen 2 (main-CPU), I/O co-processors (sub-CPUs) and SSD controller (a sub-CPU outside the I/O complex) page sizes are the same. These pages (data) are strictly 4KB, 64KB, 1MB or 16MB in size (i.e. page granularity levels), and are grouped into an address translation table to be referred to by the SSD controller:
[0051]
Although it is not necessary for the main and sub-CPUs 30 and 32 to have the same instruction set architecture and operating system, the main and sub-CPUs 30 and 32 are connected by the coherent bus 36 and their page sizes are the same so that data stored in the system memory 14 can be shared between them.
[0062]
The flash controller 18 not only handles the data storage in question but also generates an address conversion table for associating a logical address of compressed data and a physical address of an area where the actual data is stored.
[0030]
A plurality of address spaces different in granularity level are defined in the address conversion table... It should be noted that there may be three or more granularity levels.
[0074]
Summary:
CELL's SPE (sub-CPU) and PPE (main CPU) have the same page (data) sizes which are 4KB, 64KB, 1MB or 16MB (i.e. page granularity levels). The SPE refers to an address translation table to locate data. Zen 2 (main-CPU), the I/O-coprocessor (sub-CPU inside the I/O complex) dedicated to SSD I/O and the SSD controller (sub-CPU outside the I/O complex) have the same page sizes which are 4KB, 64KB, 1MB or 16MB. The SSD controller refers to an address translation table to locate data.
Two other similarities not part of the two patent applications, but which I thought were worth mentioning as they show CELL's heavy influence on the I/O complex's design are:
1) while the SPE is a type of CPU, it's also an accelerator in its own right. As some of you still reading may not know, it was used as an engine to accelerate decompression for PS3 (e.g. the Oodle Beta and subsequent Oodle releases starting with 1.1.0 - April 11, 2013). The Kraken decompression engine (i.e. the accelerator mentioned in entry [0081] of the I/O complex + SSD patent) is essentially a substitute SPE designed to chew on chunks of data the size of an SPE's 256KB local store. Entry [0111] of the CELL FIOS patent and Fabien Giesen's Kraken tweets practically say as much:
[0111]
By way of example, in the certain cell processor architectures, the SPE 206 have a local store capacity of 256 Kbytes. This is often sufficient memory space for the compressed input, the decompressed output and the code for the decompression algorithm
2) PS3's low-level graphics API (GCM) largely runs on SPUs, and treats them as a form of graphics command processor/coherency engine. They can be synchronized with the RSX to give the end-user tight control over when and what commands the RSX executes via the placement and subsequent overwriting of "local stalls" in the command buffer. SPUs can also overwrite previously written data located in a range of addresses stored in VRAM (per section 2.1 Memory Allocation under "RSX local memory", continued here) before the RSX can copy the stale data out of VRAM into its caches. PS5's I/O co-processors, coherency engines and cache scrubbers automate and evolve this process from low-level GPU memory management to low-level GPU cache management. But the main takeaway here is that SPUs free up their main CPU (i.e., PPE) from having to keep tabs on and overwrite address ranges. I/O co-processors and coherency engines in PS5 free up their main CPU (i.e., Zen 2) from having to keep tabs on and overwrite address ranges.
Extremely long story short, I think that Yamazaki designed the I/O system to not only rapidly store and transfer data around inside PS5, but to also rapidly feed an external compatibility adaptor in the service of PS5 backwards compatibility with PS1, 2, 3 games (in this post, I raised the prospect of SIE releasing a CELL/RSX-based compatibility adaptor to run PS1, 2, 3 games "on" PS5).
By this I mean once a user has selected a previously downloaded PS1, 2 or 3 game (purchased from the PS Store in the past or rented from PS Now) to play from an SSD, Zen 2 tells the adaptor to ready itself for the selected game. Once ready, the adaptor tells Zen 2 which then tells the SSD I/O co-processor inside the I/O complex to have the SSD controller read the selected legacy game's file data from an SSD and forward it in 4KB, 64KB, 1MB or 16MB chunks to the adaptor's internal flash storage via ethernet cable.
As the game file data arrives and is stored in the adaptor's flash storage, CELL quickly accesses it under a scheme similar to PS5's (i.e. using two or more priority levels) and processes it according to the legacy console it belongs to. Possibly resulting in quicker load times because the data reads sent from PS5's SSD to the adaptor are already chunked in 4KB, 64KB, 1MB or 16MB sizes the way CELL likes it. After the CELL/RSX-based adaptor renders a frame of the legacy game, the frame is then sent via ethernet cable to PS5's system memory, pulled out by Oberon and is either displayed as is or spruced up/upscaled before being displayed.
Likewise, a similar process would exist for disc-based PS1, 2, 3 titles in which PS5's disc drive reads the disc and sends signals containing game data to the adaptor. Once received, the adaptor extracts the game data from the signal and forwards the data to its internal flash storage to be accessed from there and processed according to the legacy console it belongs to.
How sweet would that be?
Last edited:
