• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.

What's in a name? Reduced PS1, 2, 3 game load times. By any other name would be just as sweet.

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:

[0004]
The present invention has been conceived in view of the above-described situation, and an object of the invention is to provide an information processing device, data transfer method and information storage medium that can commence data transfer to an I/O device immediately, and can stably exhibit data transfer performance.

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:

The CELL Broadband Engine is an "information processing device" consisting of (focusing on CPUs only) a main processor and sub-processors connected via an on-chip coherent bus (i.e., the EIB)

[0013]

As shown in FIG. 1, this information processing device 10 includes a main processor 12 and a plurality of sub-processors 24-1 to 24-n, and is constructed as an asymmetric multi-core processor... The main processor 12 and the plurality of sub-processors 24-1 to 24-n are all connected to a bus 22,...

Zen 2 + I/O complex + SSD controller system:

The Zen 2 + I/O complex (referred to as the "host unit") is part of an "information processing device" consisting of (focusing on CPUs only) a main CPU and sub-CPUs connected via a coherent bus:

[0019]
An information processing device 10 includes a host unit 12,

[0050]

The host unit 12 includes a main CPU 30, a sub-CPU 32, and a memory controller 34 connected together by a coherent bus 36.

Summary:

The CELL + NIC server board and Zen + I/O complex patent applications refer to both devices as an "information processing device", with main and sub CPUs. CELL's PPE is its main processor (i.e., main-CPU) and its SPEs are its sub-processors (i.e., sub-CPUs). Zen 2 is the I/O complex's main CPU (i.e., main processor) and the two I/O co-processors inside the I/O complex along with the SSD controller outside the I/O complex are sub-CPUs (i.e., sub-processors).

CELL + NIC server board:

The DMAC inside a CELL's SPE (sub-processor) is used to bypass the main processor (i.e., PPE) when accessing data stored in main memory (i.e. system memory):

[0015]
The sub-processors 24 (24-1 to 24-n) are ancillary program execution means containing local memory 24 a, a memory management section 24 b and a DMAC (Direct Memory Access Controller)... The DMAC 24 c is also a control unit for direct access to the main memory 14, without going via the main processor 12.


Zen 2 + I/O complex + SSD controller system:

The DMAC inside the I/O complex in conjunction with an adjacent I/O co-processor (specifically the one "dedicated to SSD I/O") is used to bypass the main CPU (Zen 2) when accessing the requested data stored in system memory:

[0068]

When the data passes the ECC check, the data in question is stored in a kernel area 70 of the system memory 14 reserved in advance by the sub-CPU 32, for example, by a DMAC not illustrated, and the sub-CPU 32 is notified to that effect (S44).

Summary:

The SPE (equipped with an internal DMAC) facilitates high-speed data transfers so that the main processor (i.e., PPE) doesn't have to. The I/O-coprocessor inside the I/O complex that's dedicated to SSD I/O along with an adjacent DMAC facilitate high speed data transfers so that the main CPU (i.e., Zen 2) doesn't have to.

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,...

systems-and-technology-group-6-l.jpg

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.


CELL + NIC server board:

The benefit of using CELL's SPE (sub-processor) to handle data transfers from system memory rather than its PPE (main-processor) is high-speed data transfer:

[0019]
According to the above described information processing device 10, since a single sub-processor 24-1 constituting a multi-core processor is allocated solely to data transfer, it is possible to implement data transfer at high speed and with low latency regardless of the operating state of the main processor 12.


Zen 2 + I/O complex + SSD controller system:

The benefit of using the I/O complex's SSD I/O co-processor (sub-CPU) to access system memory and a flash controller (sub-CPU) to access data in flash memory rather than Zen 2 (main-CPU), is high speed data transfer:

[0052]

The sub-CPU 32 divides a file read request issued by the main CPU 30 into read requests for data of a given size, storing the requests in the system memory 14. Thus, in the present embodiment, hardware other than the main CPU 30 handles the major part of data access to the flash memory 20, and the read unit is reduced to a finer one immediately after issuance of a file access request. This allows for parallel access to a plurality of NAND devices, thus providing a high transfer rate.

Summary:

Offloading read requests from the main CPU (i.e the PPE or Zen 2) onto a sub CPU (i.e a SPE or a dedicated SSD I/O co-processor) speeds up data transfers.

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:

OrionNebula

Member
This post is the third of three that started off as a reply to a member in the now shuttered PS5/XSX tech thread. Since I couldn't post my reply before the closure, I decided to "thread" the reply and post it at a time of my choosing as my final bit of PS5-related tech speculation. With that out the way...

Back when the tech thread was still open LiquidRex posted a pic of PS5's SSD controller and asked why it carried the name 'YAMAZAKI', after a brand of Japanese whisky. The question prompted Hashi to guess that maybe the SSD controller was named after Takeshi Yamazaki. An SIE engineer who was at the forefront of R&D'ing the Emotion Engine and CELL Broadband Engine architectures.

I'm inclined to think that Hashi guessed right because one of the original I/O complex + SSD patents filed by Hideyuki Saito (an SIE engineer who helped IBM test CELL's functional correctness (under 7. ACKNOWLEDGEMENTS)) and devised the I/O complex + SSD's data access request and address translation schemes) cites another patent (US8504736B2) for a file input/output scheduler (FIOS) that runs on CELL (specifically its SPUs).

Interestingly, that FIOS patent cites another patent for a CELL-accelerated NIC server board of which Yamazaki is listed as a co-inventor (for those who care, these server boards were used by Sony/SIE for their streaming services; the link to the intro of the server board whitepaper can be found in this OP embedded in the words 'network processing'). Although the patent details the specific invention of data transfer from a CELL to a NIC, language in one of the patent entries encapsulates two defining characteristics of Yamazaki's SSD controller which are in the bolded text below:



To piggy-back off Hashi's guess, my guess is that Yamazaki's expertise in developing devices and methods for high-speed data management led Masayasu Ito (SVP of hardware engineering/operations) to entrust him with the responsibility of customizing PS5's SSD controller, hence 'YAMAZAKI' tattooed on its silicon.

And given the configuration and overall operation of the Zen 2 + I/O complex + SSD controller system, I'd also hazard a guess that he was responsible for the I/O complex too. Yamazaki knows CELL inside-out and there are two patent entries (i.e. [0004], [0015]) in his CELL + NIC patent that jibe with five patent entries (i.e. [0051], [0052], [0053], [0064], [0074]) in Saito's I/O complex + SSD patent. These seven entries blur the line between CELL and the Zen 2 + I/O complex + SSD controller system. Below is a like-for-like comparison of the aforementioned patent entries highlighting similarities between the two inventions. The comparison gets into the weeds so those still reading please bear with me:






To summarize the comparisons...

  • the respective patents refer to both CELL and the Zen + I/O complex as an "information processing device". CELL's PPE is its main processor (or main-CPU) and its SPEs are its sub-processors (or sub-CPUs). Zen 2 is the I/O complex's main CPU (or main processor) and the two I/O co-processors inside the I/O complex along with the SSD controller outside the I/O complex are sub-CPUs (or sub-processors).

  • the SPE (equipped with an internal DMAC) facilitates high-speed data transfers so that the main processor (PPE) doesn't have to. The I/O-coprocessor inside the I/O complex dedicated to SSD I/O along with an adjacent DMAC facilitate high speed data transfers so that the main CPU (Zen 2) doesn't have to.

  • 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.

Other comparisons not part of the larger patent comparison are:





Extremely long story short, it seems someone had CELL on the brain when designing PS5's I/O complex (something I've thought in the past) and how it works with Zen 2 and the SSD controller. As I said earlier in the post, Yamazaki is the someone who comes to my mind given how CELL-like the unit is. And I have a feeling his SSD controller and likely I/O complex were probably designed/customized to do more than just access and transfer data off PS5's SSDs.

In another post of mine, I raised the prospect of a CELL/RSX-based compatibility adaptor. Fast-feeding PS1, 2 or 3 game file data from PS5's SSDs to the internal storage of that presumed compatibility adaptor might also be a secondary function of the I/O complex. Basically, a CELL-inspired system that rapidly feeds a CELL-based device in the service of backwards compatibility.

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.

From there the data is quickly accessed under a scheme similar to PS5's (using two or more priority levels) and processed according to the legacy console it belongs to. Possibly resulting in quicker load times because the data reads coming from PS5's SSD are already chunked how CELL likes it. After frames of the legacy game have been rendered, they are then sent via ethernet cable to PS5's system memory, pulled out by Oberon and are 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?
Nah he tweaking
 

JimboJones

Member
You can decrease load times on emulators just by holding down a button, think it's tab on dolphin which makes the game run 2 x speed or I think as fast as your computer can allow if you select unlimited. I'm sure lots of emulators have similar options.
 
Last edited:

GAF machine

Member
Are you that guy who was always going on about the PS3 (or was it PS4) web browser and stuff? I don't remember his name or what his actual theory was, but this sure reminds me of that.

I think you're talking about Shifty Geezer. I'm not him but I can understand why you drew that parallel. :messenger_tears_of_joy:
 

cormack12

Gold Member
This post is the third of three that started off as a reply to a member in the now shuttered PS5/XSX tech thread. Since I couldn't post my reply before the closure, I decided to "thread" the reply and post it at a time of my choosing as my final bit of PS5-related tech speculation. With that out the way...

Back when the tech thread was still open LiquidRex posted a pic of PS5's SSD controller and asked why it carried the name 'YAMAZAKI', after a brand of Japanese whisky. The question prompted Hashi to guess that maybe the SSD controller was named after Takeshi Yamazaki. An SIE engineer who was at the forefront of R&D'ing the Emotion Engine and CELL Broadband Engine architectures.

I'm inclined to think that Hashi guessed right because one of the original I/O complex + SSD patents filed by Hideyuki Saito (an SIE engineer who helped IBM test CELL's functional correctness (under 7. ACKNOWLEDGEMENTS) and devised the I/O complex + SSD's data access request and address translation schemes) cites another patent (US8504736B2) for a file input/output scheduler (FIOS) that runs on CELL (specifically its SPUs).

Interestingly, that FIOS patent cites another patent for a CELL-accelerated NIC server board of which Yamazaki is listed as a co-inventor (for those who care, these server boards were used by Sony/SIE for their streaming services; the link to the intro of the server board whitepaper can be found in this OP embedded in the words 'network processing'). Although the patent details the specific invention of data transfer from a CELL to a NIC, language in one of the patent entries encapsulates two defining characteristics of Yamazaki's SSD controller which are in the bolded text below:



To piggy-back off Hashi's guess, my guess is that Yamazaki's expertise in developing devices and methods for high-speed data management led Masayasu Ito (SVP of hardware engineering/operations) to entrust him with the responsibility of customizing PS5's SSD controller, hence 'YAMAZAKI' tattooed on its silicon.

And given the configuration and overall operation of the Zen 2 + I/O complex + SSD controller system, I'd also hazard a guess that he was responsible for the I/O complex too. Yamazaki knows CELL inside-out and there are two patent entries (i.e. [0004], [0015]) in his CELL + NIC patent that jibe with five patent entries (i.e. [0051], [0052], [0053], [0064], [0074]) in Saito's I/O complex + SSD patent. These seven entries blur the line between CELL and the Zen 2 + I/O complex + SSD controller system. Below is a like-for-like comparison of the aforementioned patent entries highlighting similarities between the two inventions. The comparison gets into the weeds so those still reading please bear with me:






To summarize the comparisons...

  • the respective patents refer to both CELL and the Zen + I/O complex as an "information processing device". CELL's PPE is its main processor (or main-CPU) and its SPEs are its sub-processors (or sub-CPUs). Zen 2 is the I/O complex's main CPU (or main processor) and the two I/O co-processors inside the I/O complex along with the SSD controller outside the I/O complex are sub-CPUs (or sub-processors).

  • the SPE (equipped with an internal DMAC) facilitates high-speed data transfers so that the main processor (PPE) doesn't have to. The I/O-coprocessor inside the I/O complex dedicated to SSD I/O along with an adjacent DMAC facilitate high speed data transfers so that the main CPU (Zen 2) doesn't have to.

  • 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.

Other comparisons not part of the larger patent comparison are:





Extremely long story short, it seems someone had CELL on the brain when designing PS5's I/O complex (something I expressed in the past) and how it works with Zen 2 and the SSD controller. As I said earlier in the post, Yamazaki is the someone who comes to my mind given how CELL-like the unit is. And I have a feeling his SSD controller and likely I/O complex were probably designed/customized to do more than just access and transfer data off PS5's SSDs.

In another post of mine, I raised the prospect of a CELL/RSX-based compatibility adaptor. Fast-feeding PS1, 2 or 3 game file data from PS5's SSDs to the internal storage of that presumed compatibility adaptor might also be a secondary function of the I/O complex. Basically, a CELL-inspired system that rapidly feeds a CELL-based device in the service of backwards compatibility.

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.

From there the data is quickly accessed under a scheme similar to PS5's (using two or more priority levels) and processed according to the legacy console it belongs to. Possibly resulting in quicker load times because the data reads coming from PS5's SSD are already chunked how CELL likes it. After frames of the legacy game have been rendered, they are then sent via ethernet cable to PS5's system memory, pulled out by Oberon and are 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?
Yes.
 

Aldynes

Member
OP I got a question, if I've understood the PS5 got something very useful in regard of running PS1/2/3 titles in emulation with the benefits that comes with the use of an SDD for loading times and could possibly run theses old titles at twice the speed / framerate ?

So in short something similar to Xbox FPS boost program but with the PS catalog of stuff you already bought on the PS store for exemple?

Maybe this was the plan when they talked about retro-compatibility, I was so let down when this got scrapped for the PS5, that's the main reason I choose a Series X first.
 

GAF machine

Member
No, I found him, it was Jeff Rigby.

Ahh, you beat me to it! Jeff Rigby, that's the guy. No, I'm not him and how I got him confused with Shifty Geezer is crazy to me. I knew exactly the character you described, knew his name and was familiar with his posts; yet somehow his name escaped me and I got him twisted with Shifty Geezer... 🤦‍♂️

Good stuff RoadHazard.(y)
 
Last edited:

RoadHazard

Gold Member
Ahh, you beat me to it! Jeff Rigby, that's the guy. No, I'm not him and how I got him confused with Shifty Geezer is crazy to me. I knew exactly the character you described, knew his name and was familiar with his posts; yet somehow his name escaped me and I got him twisted with Shifty Geezer... 🤦‍♂️

Good stuff RoadHazard.(y)

Good job filling his shoes! Haha.
 

GAF machine

Member
OP I got a question, if I've understood the PS5 got something very useful in regard of running PS1/2/3 titles in emulation with the benefits that comes with the use of an SDD for loading times and could possibly run theses old titles at twice the speed / framerate ?

So in short something similar to Xbox FPS boost program
but with the PS catalog of stuff you already bought on the PS store for exemple?

Maybe this was the plan when they talked about retro-compatibility, I was so let down when this got scrapped for the PS5, that's the main reason I choose a Series X first.

Not for running emulation by itself. For quickly retrieving PS1, 2 or 3 game file data in 4KB, 64KB, 1MB or 16MB chunks from the SSD, and sending that game file data over to a separate CELL/RSX-based compatibility adapter connected to PS5 with an ethernet cable.

After sending the game file data over to the adapter's internal storage, the PS5 would wait for the adapter to process it and send fully rendered frames of the legacy title (e.g.Jak 2) back over to it through the ethernet cable. At that point the PS5 would do one of two things with the rendered frame: Either display the frame as is or enhance/upscale the frame before displaying it.

If a FPS boost is to be achieved, it would most likely have to be done by the adapter. The 4 PPE/32 SPE Quad CELL + butterflied RSX I mentioned in this OP would have enough giddyap to do it. SIE could probably implement a system level FPS boost feature, but with the adapter I described the resolution would likely be capped at 2K because of all the other processing it would have to do. An adapter with 64 SPEs could overcome this though.
 
Last edited:

Aldynes

Member
Not for running emulation by itself. For quickly retrieving PS1, 2 or 3 game file data in 4KB, 64KB, 1MB or 16MB chunks from the SSD, and sending that game file data over to a separate CELL/RSX-based compatibility adapter connected to PS5 via an ethernet cable.

After sending the game file data over to the adapter's internal storage, the PS5 would wait for the adapter to process it and send fully rendered frames of the legacy title (e.g.Jak 2) back over to it through the ethernet cable. At that point the PS5 would do one of two things with the rendered frame: Either display the frame as is or enhance/upscale the frame and display it.

If a FPS boost is to be achieved, it would most likely have to be done by the adapter. The 4 PPE/32 SPE Quad CELL + butterflied RSX I mentioned in this OP would have enough giddyap to do it. SIE could probably implement a system level FPS boost feature, but with the adapter I described the resolution would likely be capped at 2K because of all the other processing it would have to do. An adapter with 64 SPEs could overcome this though.
This is interesting stuff good job! There's several options for SONY to have backward compatibility via either a adapter/add-on to buy separately or a new PS5 model/revision with this stuff integrated based on that PS3 patent you've mentioned?

So it could happen on a technical level and it's doable, but will SONY do it? Based on their backward mentality (no pun intended) on game preservation and Jim Ryan views on old games...
 

RoadHazard

Gold Member
Not for running emulation by itself. For quickly retrieving PS1, 2 or 3 game file data in 4KB, 64KB, 1MB or 16MB chunks from the SSD, and sending that game file data over to a separate CELL/RSX-based compatibility adapter connected to PS5 via an ethernet cable.

After sending the game file data over to the adapter's internal storage, the PS5 would wait for the adapter to process it and send fully rendered frames of the legacy title (e.g.Jak 2) back over to it through the ethernet cable. At that point the PS5 would do one of two things with the rendered frame: Either display the frame as is or enhance/upscale the frame and display it.

If a FPS boost is to be achieved, it would most likely have to be done by the adapter. The 4 PPE/32 SPE Quad CELL + butterflied RSX I mentioned in this OP would have enough giddyap to do it. SIE could probably implement a system level FPS boost feature, but with the adapter I described the resolution would likely be capped at 2K because of all the other processing it would have to do. An adapter with 64 SPEs could overcome this though.

So basically you want 4 (or 8) PS3s in a tiny box? I don't really see the need for this given that the PS5 could easily emulate all of these consoles at 4K if Sony just gave a damn. Maybe you covered this in your original post though, it was too long to read...
 

GAF machine

Member
So basically you want 4 (or 8) PS3s in a tiny box? I don't really see the need for this given that the PS5 could easily emulate all of these consoles at 4K if Sony just gave a damn. Maybe you covered this in your original post though, it was too long to read...

I covered it in "1)" of this OP. Comments by the RPCS3 team members I referenced leave me with the impression that PS5's CPU won't be able to emulate CELL one-to-one. Even CPUs clocked higher than 3.5 GHz can't do it, so how on earth can PS5's CPU do it.

It seems to me that the only real solution is a hardware one. Whether that be the equivalent of 4 (or 8) PS3s in a tiny box or customizations to PS5's CPU that allow it to perfectly emulate the "quirks" of the SPE's Memory Flow Controller (MFC), which I doubt PS5's CPU has.

In the case of CELL perfect emulation isn't just about brute-force, it's about finesse too.
 
Last edited:

Drew1440

Member
There was speculation that the Tempest engine was basically the PS3 cell CPU, not sure it that's true. The last Cell that IBM released was the PowerXCell 8i
 
Last edited:

GAF machine

Member
There was speculation that the Tempest engine was basically the PS3 cell CPU, not sure it that's true. The last Cell that IBM released was the PowerXCell 8i

It isn't true. Many erroneously claim that the Tempest Engine is basically a CELL, but Cerny said it's basically an SPU...

20200329172205.jpg

If the Tempest Engine was basically a CELL, it would've had an integrated main CPU of its own to run an OS and control the "SPU-like Architecture".

I've seen my share of speculation on the Tempest Engine emulating CELL, and none of it is convincing. For one thing, I just can't wrap my noodle around the notion of a slower GPU compute unit clocked at 2.23 GHz accurately emulating a faster CPU clocked at 3.2 GHz.
 
Last edited:

GAF machine

Member
That is the worst thread title I may have ever seen on this forum.

Really? I didn't think it would be that bad. Given the nods to Shakespeare that Cerny (or whoever) made by naming PS5's APU 'Oberon' and its audio chip 'Tempest', I figured I'd keep with the Shakespearean theme for my OP. The title is my spin on an often recited line from one of Shakespeare's plays:

"What's in a name? That which we call a rose
By any other name would smell as sweet." --
Juliet

Maybe you caught that, or maybe you didn't. If you didn't, then the following may give you a different perspective on the title:

The OP is about the name of an engineer who designed PS5's SSD controller and was most likely responsible for designing PS5's I/O complex, which I suspect works with a yet to be announced backwards compatibility adapter to reduce PS1, 2, 3 game load times. If this turns out to be the case, then I think that would be "sweet" (as in fantastic) and I'll credit Takeshi Yamazaki for that. And even if I'm wrong about the name of who should be credited, jumping into a PS1, 2 or 3 game (be it on disc or download) in half the time or less would be "sweet" regardless of the engineer's name who made it possible.
 
Last edited:

thatJohann

Member
Really? I didn't think it would be that bad. Given the nods to Shakespeare that Cerny (or whoever) made by naming PS5's APU 'Oberon' and its audio chip 'Tempest', I figured I'd keep with the Shakespearean theme for my OP. The title is my spin on an often recited line from one of Shakespeare's plays:



Maybe you caught that, or maybe you didn't. If you didn't, then the following may give you a different perspective on the title:

The OP is about the name of a engineer who designed PS5's SSD controller and was most likely responsible for designing PS5's I/O complex, which I suspect works with a yet to be announced backwards compatibility adapter to reduce PS1, 2, 3 game load times. If this turns out to be the case, then I think that would be "sweet" (as in fantastic) and I'll credit Takeshi Yamazaki for that. And even if I'm wrong about the name of who should be credited, jumping into a PS1, 2 or 3 game (be it on disc or download) in half the time or less would be "sweet" regardless of the engineer's name who made it possible.
64-C92668-B4-A6-4097-A6-E2-FBEB2-D188-E5-C.gif
 

sn0man

Member
OP, would this only make sense if there was a plan for a PS5 PRO or whatever. If your talking about some cheap add-on to make backwards compatible PS1–3 games on PS5 then wouldn’t Sony rather prefer to have it all built into the same system?

my thinking is that on a pro you could overcome the MHz gulf by just having a mods the cpu goes into to run with less stuff turned on but at a higher rate.
 

GAF machine

Member
OP, would this only make sense if there was a plan for a PS5 PRO or whatever. If your talking about some cheap add-on to make backwards compatible PS1–3 games on PS5 then wouldn’t Sony rather prefer to have it all built into the same system?

my thinking is that on a pro you could overcome the MHz gulf by just having a mods the cpu goes into to run with less stuff turned on but at a higher rate.

Love the idea of a PS5 pro or "plus" having the hardware built in. It makes good sense to me and would be much preferred over having to deal with more wires and an adapter taking up more space alongside PS5.

PS5's Zen 2 CPU already overcame the GHz gulf between PS4's Jaguar and CELL (i.e. Jaguar at 1.6 GHz vs. CELL at 3.2 GHz vs. Zen 2 at up to 3.5 GHz), so I don't think the issue is clock speed. More than anything else, the issue seems to be a problem of emulating the way the SPE's Memory Flow Controller handles accesses to system memory. If SIE were to build a PS5 pro or "plus" that's backwards compatible with PS1– 3, it would likely have to add hardware to each CPU core that precisely mimics each SPE's MFC. But I have no clue how that can be done without breaking the CPU SIE would plan to use for a PS5 pro or "plus".
 
Last edited:
Top Bottom