I think Sony somehow managed to make something that none of the current gen PC can't perform inimitably.
Should PC Master Race freak out for this? What do you guys think?
Is there any desktop PC can load fast travel in 0.8 sec on a modern open world game?
@acepilot said:
@Gatygun: Yes it was a demonstration on the low-speed devkit according to the Wired article, which means that it will even perform better on the commercial hardware.
U don't understand what was demonstrated. The number means nothing. It's about the performance increase over a 5400 rpm discs and how developers can now snowball more data without the endless load times that moves forwards drastically. This generation was particular bad with load times through more and more data without a faster harddrive.
Devs needed with the PS5 a better harddrive solution as it wasn't going to work well with larger data files. Sony fixes this. The demonstration of spiderman just means that devs have more room to work with and can push loading times down while increasing data push through it at the same time.
For example, Ps3/xbox360 games could run entirely in the memory pool of the PS4 and not have loading as a result. yet we now sit with even more data then before, because data gets pushed forwards for reasons.
This generation spidy is 5gb that needs to be readed out in load solutions, next generation spidy is 40gb. Loads the same, quality goes up.
But if you want to compare some useless data vs other useless data, that means absolutely nothing. here you go.
The question is only will microsoft use the same solution or will they basically be the crippling factor for next gen multiplatform solutions. PC will adopt whatever is best and move further on it if the tech is actually infront of PC right now.
Personally i am not a fan of SSD's in consoles. This means SSD's could become the requirement of next generation games. which will result in longer load times across the board for everybody involved.
Sadly its needed as consoles are hitting a limit now on this front without it.
@Gatygun said:
@acepilot said:
@Gatygun: Yes it was a demonstration on the low-speed devkit according to the Wired article, which means that it will even perform better on the commercial hardware.
U don't understand what was demonstrated. The number means nothing. It's about the performance increase over a 5400 rpm discs and how developers can now snowball more data without the endless load times that moves forwards drastically. This generation was particular bad with load times through more and more data without a faster harddrive.
Devs needed with the PS5 a better harddrive solution as it wasn't going to work well with larger data files. Sony fixes this. The demonstration of spiderman just means that devs have more room to work with and can push loading times down while increasing data push through it at the same time.
For example, Ps3/xbox360 games could run entirely in the memory pool of the PS4 and not have loading as a result. yet we now sit with even more data then before, because data gets pushed forwards for reasons.
This generation spidy is 5gb that needs to be readed out in load solutions, next generation spidy is 40gb. Loads the same, quality goes up.
But if you want to compare some useless data vs other useless data, that means absolutely nothing. here you go.
The question is only will microsoft use the same solution or will they basically be the crippling factor for next gen multiplatform solutions. PC will adopt whatever is best and move further on it if the tech is actually infront of PC right now.
Personally i am not a fan of SSD's in consoles. This means SSD's could become the requirement of next generation games. which will result in longer load times across the board for everybody involved.
Sadly its needed as consoles are hitting a limit now on this front without it.
PS3 games are much bigger in size than 360,i don't know why you round them together but PS3 games can be much longer than 360 ones,in fact 30GB or more while 360 ones were 7.2GB DVD9 i think.
Spider man is 45GB without patches,on ram on PS4 you can only use about 5GB for video memory but not all of the is for textures and assets, as effects and other process as well require memory,so your argument is quite wrong.
I don't know how sony loaded this game so fast,but is not the way you are describing.
How can SSD been a requirement increase loading time across the board? Are you high?
@son-goku7523 said:
Here you go, an article linking to the Custom SSD and Patent discovered by a Resetera user.
Unlike clowns on SW I don't post anything without confirming it first. People here like talking out of their butts and don't post any links to back up their claim. I don't...
As demonstrated in the meeting, PlayStation 5 takes full advantage of a new SSD that allows it to load entire levels in Spider-Man 0.83 seconds.
According to a new patent discovered by ResetEra user gofreak, Sony’s SSD for the PlayStation 5 isn’t a casual one. The patent shows just how much Sony has customized PS5’s SSD.
Gofreak detailed some of the interesting points from Sony’s patent in his ResetEra thread:
– SRAM instead of DRAM inside the SSD for lower latency and higher throughput access between the flash memory controller and the address lookup data. The patent proposes using a coarser granularity of data access for data that is written once, and not re-written – e.g. game install data. This larger block size can allow for address lookup tables as small as 32KB, instead of 1GB. Data read by the memory controller can also be buffered in SRAM for ECC checks instead of DRAM (because of changes made further up the stack, described later).
– The SSD’s read unit is ‘expanded and unified’ for efficient read operations.
– A secondary CPU, a DMAC, and a hardware accelerator for decoding, tamper checking and decompression.
Of course, the main differences in SRAM and DRAM are the modes of integrated-circuit. SRAM is comparatively faster than DRAM; hence SRAM is used for cache memory while DRAM is used for main memory.
The whole patent...
This will be one for people interested in some potentially more technical speculation. I posted in the next-gen speculation thread, but was encouraged to spin it off into its own thread.
I did some patent diving to see if I could dig up any likely candidates for what Sony's SSD solution might be.
I found several Japanese SIE patents from Saito Hideyuki along with a single (combined?) US application that appear to be relevant.
The patents were filed across 2015 and 2016.
Caveat: This is an illustrative embodiment in a patent application. i.e. Maybe parts of it will make it into a product, maybe all of it, maybe none of it. Approach it speculatively.
That said, it perhaps gives an idea of what Sony has been researching. And does seem in line with what Cerny talked about in terms of customisations across the stack to optimise performance.
http://www.freepatentsonline.com/y2017/0097897.html
There's quite a lot going on, but to try and break it down:
It talks about the limitations of simply using a SSD 'as is' in a games system, and a set of hardware and software stack changes to improve performance.
Basically, 'as is', an OS uses a virtual file system, designed to virtualise a host of different I/O devices with different characteristics. Various tasks of this file system typically run on the CPU - e.g. traversing file metadata, data tamper checks, data decryption, data decompression. This processing, and interruptions on the CPU, can become a bottleneck to data transfer rates from an SSD, particularly in certain contexts e.g. opening a large number of small files.
At a lower level, SSDs typically employ a data block size aimed at generic use. They distribute blocks of data around the NAND memory to distribute wear. In order to find a file, the memory controller in the SSD has to translate a request to the physical addresses of the data blocks using a look-up table. In a regular SSD, the typical data block size might require a look-up table 1GB in size for a 1TB SSD. A SSD might typically use DRAM to cache that lookup table - so the memory controller consults DRAM before being able to retrieve the data. The patent describes this as another potential bottleneck.
Here are the hardware changes the patent proposes vs a 'typical' SSD system:
- SRAM instead of DRAM inside the SSD for lower latency and higher throughput access between the flash memory controller and the address lookup data. The patent proposes using a coarser granularity of data access for data that is written once, and not re-written - e.g. game install data. This larger block size can allow for address lookup tables as small as 32KB, instead of 1GB. Data read by the memory controller can also be buffered in SRAM for ECC checks instead of DRAM (because of changes made further up the stack, described later). The patent also notes that by ditching DRAM, reduced complexity and cost may be possible, and cost will scale better with larger SSDs that would otherwise need e.g. 2GB of DRAM for 2TB of storage, and so on.
- The SSD's read unit is 'expanded and unified' for efficient read operations.
- A secondary CPU, a DMAC, and a hardware accelerator for decoding, tamper checking and decompression.
- The main CPU, the secondary CPU, the system memory controller and the IO bus are connected by a coherent bus. The patent notes that the secondary CPU can be different in instruction set etc. from the main CPU, as long as they use the same page size and are connected by a coherent bus.
- The hardware accelerator and the IO controller are connected to the IO bus.
An illustrative diagram of the system:
At a software level, the system adds a new file system, the 'File Archive API', designed primarily for write-once data like game installs. Unlike a more generic virtual file system, it's optimised for NAND data access. It sits at the interface between the application and the NAND drivers, and the hardware accelerator drivers.
The secondary CPU handles a priority on access to the SSD. When read requests are made through the File Archive API, all other read and write requests can be prohibited to maximise read throughput.
When a read request is made by the main CPU, it sends it to the secondary CPU, which splits the request into a larger number of small data accesses. It does this for two reasons - to maximise parallel use of the NAND devices and channels (the 'expanded read unit'), and to make blocks small enough to be buffered and checked inside the SSD SRAM. The metadata the secondary CPU needs to traverse is much simpler (and thus faster to process) than under a typical virtual file system.
The NAND memory controller can be flexible about what granularity of data it uses - for data requests send through the File Archive API, it uses granularities that allow the address lookup table to be stored entirely in SRAM for minimal bottlenecking. Other granularities can be used for data that needs to be rewritten more often - user save data for example. In these cases, the SRAM partially caches the lookup tables.
When the SSD has checked its retrieved data, it's sent from SSD SRAM to kernel memory in the system RAM. The hardware accelerator then uses a DMAC to read that data, do its processing, and then write it back to user memory in system RAM. The coordination of this happens with signals between the components, and not involving the main CPU. The main CPU is then finally signalled when data is ready, but is uninvolved until that point.
A diagram illustrating data flow:
Interestingly, for a patent, it describes in some detail the processing targets required of these various components in order to meet certain data transfer rates - what you would need in terms of timings from each of the secondary CPU, the memory controller and the hardware accelerator in order for them not to be a bottleneck on the NAND data speeds:
Though I wouldn't read too much into this, in most examples it talks about what you would need to support a end-to-end transfer rate of 10GB/s.
The patent is also silent on what exactly the IO bus would be - that obviously be a key bottleneck itself on transfer rates out of the NAND devices. Until we know what that is, it's hard to know what the upper end on the transfer rates could be, but it seems a host of customisations are possible to try to maximise whatever that bus will support.
Once again, this is one described embodiment. Not necessarily what the PS5 solution will look exactly like. But it is an idea of what Sony's been researching in how to customise a SSD and software stack for faster read throughput for installed game data.
Didn't see this coming so sony is not using a standard SSD,is using a custom one built for lower latency and seek times,and there is even talk about a second CPU connected to the first one by coherent bus?
Apparently they were serious about ending load times,i still wait and see mode.
Log in to comment