Sony's ReRAM plans - what can and can't ReRAM bring to a console? *spawn

[megre]

If the data is compressed, it has to go through the process of decompression where data is shuffled and bandwidth is eaten even if you have a dedicated asic decompressor (imagine if that is massive amount of data). And then the data have to be transferred to RAM.

If your data is decompressed, APU can simply read directly to the SSD. I assume there are read-only data in the graphics rendering? If there are, then they could stay in the ultra-fast SSD.

GPU direct access is only viable if your data is already ready to be read directly. If it is compressed then it has to go through the hoops of decompression and transferred to RAM. Imagine the latency let alone the decompression process itself.

I assume something like this.

What's the point of having an SSD of 4gb/s -10gb/s (some people's estimation) if the data that is to be read from the SSD is compressed? Can the ASIC decompressor even process that amount of data in real-time? If it can't then what's the point of having that much bandwidth.? If we assume that your decompressor can, how fast can it do it considering the data has to go back and forth and eat some bandwidth.

Ultra-fast SSD only make sense if you can read from it directly. But it entails that you data has to be decompressed. But now you have a problem of storage capacity. Therefore, cache approach makes a lot of sense.

If your doing cache approach then you only really have 4 option:

a. DDR3/4 - expensive
b. SLC Nand - relatively slow
c. 3DXpoint PCM - exclusive to Intel
d. ReRAM - Sony's own baby

It's hard to think that they would choose another technology when they have one they need to promote. Provided that it's ready and it's cost-effective. If not, SLC Nand looks to be the cheapest and most viable.

 

[megre]

Now that I think about it though. Cache approach is not actually a given. A different set-up could work.

1TB 4gb/s - 6gb/s TLC SSD + large HDD

All videos and audio stays in HDD. Important game assets are decompressed in SSD.

Game sizes can be offset by the fact that there's no more duplication of data.

HDD also holds games that are not installed.

But of course you can just have an SSD with 2gb/s bandwith and the game compressed like before.

Or you can have 4gb/s - 6gb/s and win the speed contest but doesn't translate to any tangible advantage because data transfer technique remains the same as before.

 

[milk]

What's the point of having an SSD of 4gb/s -10gb/s (some people's estimation) if the data that is to be read from the SSD is compressed? Can the ASIC decompressor even process that amount of data in real-time? If it can't then what's the point of having that much bandwidth.?

That depends on the kind of compression used. Remember even the Z-buffer that stays in ultra fast caches of the GPU is compressed and decompressed in real time, muliple times PER FRAME and that is a win there.

 

[iroboto]

If the data is compressed, it has to go through the process of decompression where data is shuffled and bandwidth is eaten even if you have a dedicated asic decompressor (imagine if that is massive amount of data). And then the data have to be transferred to RAM.

If your data is decompressed, APU can simply read directly to the SSD. I assume there are read-only data in the graphics rendering? If there are, then they could stay in the ultra-fast SSD.

You use significantly more bandwidth with decompressed data.
As it is currently The data is transferred compressed that saves bandwidth. The data is the decompressed on flight to processing. That takes up processing power but not addition al bandwidth.

 

[JoeJ]

GPU direct access is only viable if your data is already ready to be read directly.

It is not viable for games in any case. For example, discrete PC GPU that does texturing from CPU main memory over AGP is very slow and hurts framerate quickly.
So for console you would need to copy from SSD or even Reram to unified main memory first for performant GPU processing.
(but this may be out of date and i'm noob here - sorrry if it had been discussed already)

 

[megre]

That depends on the kind of compression used. Remember even the Z-buffer that stays in ultra fast caches of the GPU is compressed and decompressed in real time, muliple times PER FRAME and that is a win there.

Right. Maybe I should say read-ready data, whatever that means. But definitely not the kind of compression that comes from the disc or download. It should be decompressed in the SSD just enough to make it read-ready, whatever that means.

You use significantly more bandwidth with decompressed data.
As it is currently The data is transferred compressed that saves bandwidth. The data is the decompressed on flight to processing. That takes up processing power but not addition al bandwidth.

Exactly why you need ultra-fast SSD. If you have an SSD with 4gb/s - 6gb/s but the "decompression system" cannot decompress the data on the fly anyway, what's the point of having that much bandwidth.

So for console you would need to copy from SSD or even Reram to unified main memory first for performant GPU processing. (but this may be out of date and i'm noob here - sorrry if it had been discussed already)

If you're a noob then I don't know what to call myself. I'm just going by what I read and learn from you guys.

I'll point to certain comments from a gaf poster because he seemed to know what's he's saying. If you wouldn't mind elaborating on what he means.

Yep. I expect decompressed but encrypted data. I also expect some sort of tpm and hw decryption engine.
I would also expect loading in-place. I.e. data on disk and in memory being exactly the same data.
Overall I expect PS5 to be a data streaming machine. Like PS2.

Compressed textures are used as-is. I'm obviously talking about other data formats that are decompressed at load time in current gen.
To support partial loading of a game data you would want close to zero (de)serialization steps. Which means: uncompressed memory image on ssd.

And I'll to point you to what you said to me before about how ReRAM can be taken advantage for graphics. This is what you said.

Assuming magic compression exists, CPU could uncompress insane details to ReRam so it is available quickly, e.g. when player turns view.
Then my initial Megatexture argument would make more sense again, if we make some assumptions:
* decompression very expensive, so need to cache full environment around player, not just what's currently on screen. 10 x more data.
* Sub millimeter texture resolutions everywhere. 100x100 more data?

In the scenario you were talking above, are the data transferred from ReRAM to main RAM after it being read? Or only some data are transferred?

Lastly you said the problem is content creation and games ballooning in size. Can that be minimized by having repeated textures and data within the game.

 

[megre]

And although I think a fast 1TB TLC + HDD make sense. I still think we're going to see a cache system or tiered storage in the PS5 because of what the Remedy Dev said:

"If games would stay the same in terms of scope and visual quality it’d make loading times be almost unnoticeable and restarting a level could be almost instant [in PS5 games].

However, since more data can be now used there can also be cases where production
might be cheaper and faster when not optimising content, which will lead into having to load much more data, leading back into a situation where you have about the same loading times as today."

"When it comes to the PS5, faster hardware is always appreciated and will make life easier in the short term, but it's the new SSD that really stands out; essentially streaming will become something that we don't really have to worry so much about and it will free up some extra CPU bandwidth in the process," said Remedy's lead programmer Sean Donnelly while speaking to the Official PlayStation Magazine.

Or maybe PS5 has an unbelievable amount of RAM.

 

[megre]

It is not viable for games in any case. For example, discrete PC GPU that does texturing from CPU main memory over AGP is very slow and hurts framerate quickly.
So for console you would need to copy from SSD or even Reram to unified main memory first for performant GPU processing.
(but this may be out of date and i'm noob here - sorrry if it had been discussed already)

CPU and GPU and their respective memories are separated by the PCIe bus. This PCIe adds a ton of latency, no?
A ReRAM SSD with direct connection to the APU via NVMe 5.0 might be faster, wouldn't it? Or scratch that, ReRAM with custom direct connection to the APU?

 

[JoeJ]

In the scenario you were talking above, are the data transferred from ReRAM to main RAM after it being read? Or only some data are transferred?

Yes, i meant the data would go from storage to main ram, live there for some frames where to GPU processes it, while the next chunk of data is streamed from storage.
So you would have at least 2 or usually 3 and more buffers on main ram in a ping pong / ring buffer manner - one being filled from storage and another being processed, then the buffers are cycled. (Additional buffers necessary for synchronization)
The key here is using the data for multiple frames. For example the BVH we talked about for a city with houses breaking down. The bounding boxes in the BVH would be large enough so they can bound a short duration of moving triangles for 5 frames or so.
The advantage is trading BVH accuracy vs. a virtual increase of SSD speed by a factor of five, and you can still use faster main memory as usual.

But that's just what i had in mind here. I'm not competent to answer if nowadays it makes sense for GPUs to access storage directly. Both AMD and NV have such things for the professional market. I assume it's not meant for realtime applications, but i don't know what's possible here.

Your idea is the same we had with older consoles cartridges where most of games memory was ROM chips on the cartridge. But back then CPUs were running at single digit MHz speeds, not GHZ like now, and memory read speeds did evolve poorly in comparison. Today you can do crazy amounts of math without worries, but accessing memory is costly (30 years ago it was the opposite). This is what makes me skeptical at first - i'm unsure if you propose a step forwards or backwards.

Or scratch that, ReRAM with custom direct connection to the APU?

Maybe, idk, but...:
Would this require additional wide memory controller on the GPU side? (Likely too costly in chip area, engineering effords?)
And most importantly: We still lack an idea of why we would need this in a end user gaming system. (Which does not stop us from having Tensor cores now before we know what to do with it, haha )

 

[megre]

PCIe it is then like AMD SSG using PCIe 4.0. That makes more sense actually. With PCIe 5.0 though, who knows maybe APU direct access with real-time application is possible.

I don't really fully understand some of what you said. Haha. But I get it that nobody has a definitive answer for now. I'm still hoping for ReRAM not only because I want that "no loading times" but the prospect of future games sound exciting.

Not related to ReRAM, but I think the rumored speed of SXS's SSD that is 2gb/s speed is possibly true. XSX might be going the traditional way aka PC-way with their data storage and transfer. (no caching, no direct accessing of decompressed "read-ready" data) But what it could have that PCs don't is a dedicated ASIC decompression chip and more streamlined decompression system. 2gb/s perhaps is where they found the sweet spot and going higher from there doesn't give much benefit.

 

[MrFox]

Doubtful pcie 5.0 is happening here, it's a little tight for making a custom silicon with such a fresh specs. Unless they worked on draft and won't need external compatibility (so soldered on pcb). Even so, it's like saving a couple lanes on a 1000+ pins chip. No that big of a deal to go wider 4.0 and reduce the risk.

I'm pretty sure any pcie revision allows simple dma and virtual addressing. Pcie controllers doing direct memory mapping of flash have been done for a decade with fusionIO cards. The difficult part is dealing with the very large block writes with caching. It's an algorithmic issue which have nothing to do with the hardware protocol of pcie. And reram does help for it, but again there's no reason to have such granular writes with games! Reram is for enterprise databases.

 

[Silent_Buddha]

Well, are there gonna be any incentives for devs to be more mindful of storage or are they gonna be free to pass the bill down to the consumer how they have been this gen?

I suppose if games start approaching the 500 GB to 1 TB (or more) mark because developers decide not to use compression, there might be some issues with distribution and actually getting their games into people's machines.

But, I suppose you could always distribute the game compressed, and then have no compression at all with the installed game.

But that still leaves the problem of a user having at most 1-2 games installed at a time and having to redownload, uncompress, and install a game every time they want to play a different game. IE - a disincentive to buy many games which would lead to less sales of games.

Regards,
SB

 

[megre]

Your idea is the same we had with older consoles cartridges where most of games memory was ROM chips on the cartridge.

Curiously though, I believe one Bluepoint dev said something like we're going back to what consoles used to be when games used to load instantly back in the cartridge days.

I'm sure we can't take it literally though as he might just be referring to fast loading and he's exaggerating a little bit.

 

[Deleted member 11852]

Come on people, Christmas is pretty much over. Y'all need stop drinking!

 

[megre]

I'm quite convinced PS5 will have some sort of storage caching though. But SLC Nand is the cheapest so they might go there. Nand can be quite a performant too. ReRAM is quite crazy talk.

 

[Rootax]

Except if Sony is rreeaaaaally confident in the process / price they can have with ReRam. But otherwise, yeah, I don't see them kind of beta test a product in their number one consumer product.

 

[megre]

Except if Sony is rreeaaaaally confident in the process / price they can have with ReRam.

Confidence of the engineer working on the product is not the same as the confidence of the PR guys or business people hearing about the same though. Amigo Tsushui is not a business guy or a PR guy. He is an engineer specializing in memory technology. He invented Sony's memory stick. He understands what it entails to release a product that is in line with his expertise. He knows what process is, what yield is, what cost is. He was asked when is a major product release with their ReRAM technology. He said 2020.

It doesn't mean his estimations couldn't be wrong though even if he has direct working knowledge of the technology. ReRAM is crazy talk. It's easier to bet on SLC Nand which could be performant too.

 

[dobwal]

What would be the reasons to keep a bunch of uncompressed game data on a SSD ?

Not only does 100% of uncompressed data means less efficient data movement but it also means less efficient use of storage and practically shortening the life span of an SDD.

And unless AMD is horrible at compression techniques in comparison to Nvidia then decompression rates shouldn’t be a problem. Nvidia claims that the TU102 provides 50% more effective bandwidth than GP102 because of better/wider use of compressed data.

More effective use of compression means more data on chip and less data written out to RAM, and more data in RAM and less data written out to the SSD or HDD.

 

[Deleted member 11852]

What would be the reasons to keep a bunch of uncompressed game data on a SSD ?

Woah.. back up there, sunshine. You can't just waltz in here making valid points and observations.

Damn n00bs.

 

[Rootax]

IF they're is an hardware secret sauce, I believe in a kind of "decompressor" chip more than reram (but all in all I don't believe in neither of this thing, just a custom ssd controler or interface, more efficient than you find on the pc space)