Tim Sweeney explains his comments with respect to IO pef on PS5

[hishnash]

1 hour ago, C2HWarrior said:

From my understanding of what he’s saying the ps5 has dedicated decompression hardware (even though zen is really good at decompression?)

so its not about the raw decompression performance its more about the latency, they might well be using the same decompression functions of the Zen2 hardware but (through OS magic) not doing this in user-space so you don't have the massive lag when you need to jump from kernel to user to kernel to user space all the time.

 

1 hour ago, C2HWarrior said:

clear disadvantage such a system has vs a pc, that being that it’s system memory is gddr

This is a big advantage for the GPU, in a normal desktop system were the VRAM and CPU RAM are separate the GPU needs to do one MORE (SLOW) copy of data to the GPUs VRAM before it can use it. by having a unified system as soon as the data has been copied from the ssd to the system memory it is already in the gpus memory since the system memory is also the gpu memory.

The reason you dont do this on a Desktop is it means your gpu and cpu need to be hardwired to the same memory (making swapping a gpu) very very very hard.

Yes it will impact cpu latency but for the PS5 all cpu operations in the end need to talk to the GPU so by sharing the same memory this communication is in the end a lot faster.
 

1 hour ago, C2HWarrior said:

Wouldn’t this work against the ps5 vs pc argument he’s making?

No what he is saying is hey is bypassing the CPU as much as possible the idea is to get data from the SSD to the de-compression system and into VRAM (that happens to also be system ram so one less copy) without needing to jump through the large latency hits you get with using user-space apis as you would on a PC.  The advantage here comes if you are doing lots and lots and lots of very small reads

 

1 hour ago, C2HWarrior said:

ps5 lacks the memory optimisation a tradition pc has.

for AMD the PS5 has been in the works since before first gen Zen cpus started being tested. They will have been doing a massive amount of optimisation, both Sony and MS have basically funded the development of Zen and stoped AMD from going under.
 

1 hour ago, C2HWarrior said:

Unless of course it can some how do it without the devs needing to code specifically for it which would be really cool.

Game engine devs and driver devs need to consider this. Normal day to day devs dont.  All the game engine providers get large amounts of money and help from Sony and AMD to do these sort of optimisations.

 

 

One of the things that i think people are not getting is what having supper low latancy access to compressed data does. In a normal system you need to pre-load anything that might need to be used by the gpu at least a few seconds before it is needed just in case there is hiccup and its not there when you need it (if it is not there the default behvoir of a gpu is to *stop rendring frames* untill it arives,, that is how you get massive framerate drops)

however if you have a stable (predicatble) low latancy means of getting this data you can get this data just before it is needed.
 

So if you have a large high resh mesh that the user can walk around, normaly in a game engine when the user gets close enough you load the full high res mesn (and textures) into the gpu, and 1/2 of that data is wasted as it is data for the other side of the mesh, but the user could at any time move and see that side fo the mesh so you need to have it in VRAM. That means you need a very large VRAM since you end up loading a LOT of data that is of screen into VRAM.

With nanite the aim is to only load data that is needed in frame into the GPU and this means in those demos as you move the camara it needs to pull data supper fast. Withoutthis you would need a muhc much larger amount of VRAM.!

[RejZoR]

9 hours ago, Brooksie359 said:

You never know it could become a toggle setting that you can turn off and on at your own risk. 

Very unlikely. Devs on PC always spend minimum required work necessary and only focus on things a lot of people can use which sort of makes sense (you don't spend resources on things that won't be used a lot). If something will be used by few hundred people only they probably won't even bother. Unless a certain company shills it enough and greases their bottoms with good old greens, then they'll do it even if just 5 people in the whole world will use it. As evident from endless NVIDIA features that never took off, but are there because ones bottoms were greased by some greens.

[3rrant]

  

15 hours ago, StDragon said:

What fixed function? Sure, the CPU is a custom ZEN 2 chip, but I'm genuinely curious as to what compression algorithm they picked to bake on CPU die. ZEN 2 only supports AVX-256 which helps any software based algo, but Intel so far is the only one that supports AVX-512 unless that too is now part of the custom PS5 die. Hmmmm 

We don't know about what they are doing for decompression right now, just that is a custom chip with the same power of "several Ryzen cores" (up to 9, according to Cerny's talk). From the same discussion however, he also specified that AVX-256 heavy workloads will create a lot of heat, so that's not ideal in all situation. They could have used some special instructions for this task, it wouldn't be the first time but is also unlikely.

 

14 hours ago, StDragon said:

Right. So the fundamental question posited is this - How does Sony plan on streaming the asset data from SSD to RAM via hardware based decompression all while avoiding traversal through the kernel (DMA)?

 

I agree with hishnash, Sony will be encrypting this data too. Is that too handled in hardware??

It's all handled by their custom compression-decompression unit. For "very well compressed data" the SSD speed can peak PS3 RAM speed 22.5gbs theorical.

8 hours ago, Zodiark1593 said:

Tim is probably a bit of a hardware geek. I don’t believe there's anything wrong with giving his opinion or showing excitement, even if most end users won’t understand any of it. 

People might dislike him because of Fornite, but Tim is actually a very very programming focused guy. If you listen a bit to his talks or his twitter, he's very knowledgeable in this league. He got very misquoted during his early comments of PS4, that's why a lot of people don't trust what he says (thanks media).

 

5 hours ago, RejZoR said:

Very unlikely. Devs on PC always spend minimum required work necessary and only focus on things a lot of people can use which sort of makes sense (you don't spend resources on things that won't be used a lot). If something will be used by few hundred people only they probably won't even bother. Unless a certain company shills it enough and greases their bottoms with good old greens, then they'll do it even if just 5 people in the whole world will use it. As evident from endless NVIDIA features that never took off, but are there because ones bottoms were greased by some greens.

It depends on the developer. The PC space has been highly disliked by most big developers and publishers because of the HUGE piracy issues. It doesn't make sense to spend a crapton of time to optimize for an extremely variable environment when a stupidly big chunk of people will either not buy your game at all and pirate it or buy it only at extreme discounts. It's not business friendly.

[spartaman64]

does it actually work that way? if you have a drive with x read speed with compressed data and then a  processor with y decompress speed you multiply x and y for the actual speed? then why dont we just compress everything

[Brooksie359]

8 hours ago, RejZoR said:

Very unlikely. Devs on PC always spend minimum required work necessary and only focus on things a lot of people can use which sort of makes sense (you don't spend resources on things that won't be used a lot). If something will be used by few hundred people only they probably won't even bother. Unless a certain company shills it enough and greases their bottoms with good old greens, then they'll do it even if just 5 people in the whole world will use it. As evident from endless NVIDIA features that never took off, but are there because ones bottoms were greased by some greens.

I mean it depends on how fast of an ssd you need and how easy it is to implement. Alot of people have ssds at this point so I would hardly say its niche.

[wanderingfool2]

3 hours ago, spartaman64 said:

does it actually work that way? if you have a drive with x read speed with compressed data and then a  processor with y decompress speed you multiply x and y for the actual speed? then why dont we just compress everything

Lots of games do have things compressed, and then the installs are compressed as well.  But one issue is it is a balance between performance vs space.  If you compress everything, you have to decompress CPU level; so you take a hit in CPU performance.  You also take a hit in latency, as now the data has to be read/fed into the CPU to decompress before getting put into ram..since the CPU is going it, it will likely take more time before the data appear in ram (compared to streaming uncompressed data).  It all depends on what the needs are (sometimes it is even better to compress because the CPU can decode the information faster than the SSD can read on highly compressed data).

  

20 hours ago, StDragon said:

Right. So the fundamental question posited is this - How does Sony plan on streaming the asset data from SSD to RAM via hardware based decompression all while avoiding traversal through the kernel (DMA)?

 

I agree with hishnash, Sony will be encrypting this data too. Is that too handled in hardware??

Not all data channels need to be encrypted.  I suspect that there is probably some chip on the PS5 that would handle the encryption/decryption from the SSD.   There is apparently a hardware decompressor (supporting hardware ZLIB), and a special chip for DMA...so it could be the chip just has limited access to regions it can write to (ie...it is blocked from overwriting OS memory).

 

One reason why benchmarks, and straight comparisons of PS5 hardware to PC hardware is so flawed is because of custom chips.  The decompression chip might be able to do tasks that modern CPU's would struggle with (in terms of IO performance) just because they were specialized.  Specialized hardware in console systems, in my opinion, is why you can never quite count a console out of the running...or classify it as "mid-tier" due to the "raw" performance numbers.

 

The fact is, we aren't talking about a PC with a CPU-GPU in it.  Sony, especially this time from what I have gathered based on the hardware, appears to have actually gone back towards using specialized hardware to reduce bottlenecks/add features that might allow game developers to do clever things (that might not ever be possible on PC without crazy hardware).  It sound like on this one, it has a custom part for 3D sound, dedicated hardware for decompression, DMA chips and other custom chips...if developers go more towards the bare metal, they might find they could pull of things that would be unimaginable on PC's (mainly due to the architecture)

 

One last thing to remember, developers can now target the console as a "minimum", so it might help out the PC market since they could consider the consoles as the "low" point and develop games that don't run well on PC's that don't match it (as that consumer base could just use the console).  As per the Steam developers to reach 80% of the audience would have to target a system as follows:

4 cores

8GB ram + 4GB VRAM (Actually to me, this actually makes Sony's 16GB of shared ram seem really good...especially when you consider consoles have a more fixed number, compared to PC's that aren't guaranteed the "8GB")

HDD (since there are still a fair amount of people who load it onto harddrives due to the economy of it)

 

 

[spartaman64]

27 minutes ago, wanderingfool2 said:

Lots of games do have things compressed, and then the installs are compressed as well.  But one issue is it is a balance between performance vs space.  If you compress everything, you have to decompress CPU level; so you take a hit in CPU performance.  You also take a hit in latency, as now the data has to be read/fed into the CPU to decompress before getting put into ram..since the CPU is going it, it will likely take more time before the data appear in ram (compared to streaming uncompressed data).  It all depends on what the needs are (sometimes it is even better to compress because the CPU can decode the information faster than the SSD can read on highly compressed data).

  

 

I know lots of things are compressed to save on space but I never heard of compression used for increasing working data transfer rates. 

[StDragon]

27 minutes ago, wanderingfool2 said:

There is apparently a hardware decompressor (supporting hardware ZLIB), and a special chip for DMA...so it could be the chip just has limited access to regions it can write to (ie...it is blocked from overwriting OS memory).

 

One reason why benchmarks, and straight comparisons of PS5 hardware to PC hardware is so flawed is because of custom chips. 

Right, ASICs are nothing new in console hardware, but I didn't think it was still relevant in the days of x86 SoC based platforms; even if they have a custom variant. I thought consoles were veering away from custom accelerated execution.

[StDragon]

3 minutes ago, spartaman64 said:

I know lots of things are compressed to save on space but I never heard of compression used for increasing working data transfer rates. 

I too am not aware of it being used for internal throughput on local storage. The only time it ever made sense to me is when dealing with WAN or LAN acceleration where the network is the bottleneck over Ethernet, but you've got lots CPU cycles to compress/decompress at both ends. On the more extreme side, WAN accelerators come to mind.

[Zodiark1593]

9 minutes ago, spartaman64 said:

I know lots of things are compressed to save on space but I never heard of compression used for increasing working data transfer rates. 

Modern GPUs actually do this (use memory compression) frequently to get more out of their memory bandwidth to VRAM. I don’t know about other mobile GPU vendors (presumably they’ve done this too as mobile is heavily bandwidth constrained) but Apple also has used Memory Compression on the GPU starting with the A12 (rather late to the game I’d argue). 
 

https://www.anandtech.com/show/8526/nvidia-geforce-gtx-980-review/3

 

https://www.anandtech.com/show/13392/the-iphone-xs-xs-max-review-unveiling-the-silicon-secrets/2

[hishnash]

4 hours ago, spartaman64 said:

does it actually work that way? if you have a drive with x read speed with compressed data and then a  processor with y decompress speed you multiply x and y for the actual speed? then why dont we just compress everything

you cant compress everything that much, compression is all about finding a pattern in the data and extracting that.  Some data has lots of easly detected paterns other data does not and thus cant be compressed.

 

eg 

1100

1000

1200

1400

 

we could right this data as 1000*x where x = [10, 10, 12, 14] if you write this in bits this saves a lot of space

 

but if i just had 4 random numbers that had nothing to do with eachother i would find it a lot harder.

[hishnash]

25 minutes ago, StDragon said:

I too am not aware of it being used for internal throughput on local storage. The only time it ever made sense to me is when dealing with WAN or LAN acceleration where the network is the bottleneck over Ethernet, but you've got lots CPU cycles to compress/decompress at both ends. On the more extreme side, WAN accelerators come to mind.

It used to be used a lot when we had slower disk speeds (CDs and hardrives) once CPUs speeds speeds up but our harddrives did not.  With a fast modern ssd if you do full compression you will burn your cpu decompressing it and not be able to do anything with that data since your cpu will be flat out.

[CarlBar]

On 5/18/2020 at 8:41 PM, StDragon said:

The only other way possible (that I can think of anyways) is to treat a portion of the NAND flash like another form of addressable RAM.

 

From what they're saying this is basically exactly what they're doing conceptually at least, (actual method of execution we don't know).

 

17 hours ago, hishnash said:

One of the things that i think people are not getting is what having supper low latancy access to compressed data does. In a normal system you need to pre-load anything that might need to be used by the gpu at least a few seconds before it is needed just in case there is hiccup and its not there when you need it (if it is not there the default behvoir of a gpu is to *stop rendring frames* untill it arives,, that is how you get massive framerate drops)

 

As i pointed out in my last post, unless your dealing with truly monumentally sized assets the maximum latency even on a PC is measured in tiny fractions of a second.Latency is a measure of how long it takes for an operation to start, not how fast it proceeds once in flow, (if the operation is prone to sufficient stops and starts the latency might start to matter, but for streaming a piece of data from one location to another latency is only a limiting factor to absolute transfer rates at very extreme rates of transfer, which simply aren't relevant in this case).That doesn't mean there aren't good reason to load as much into ram/vram ahead of time as space allows you to reasonably do so. But the latency difference isn't on the order of seconds typically, (though i'm sure edge case scenarios cna make it that).

 

But yes this technique does let you get away with buffering much less without it biting you in the rear. the basic point your making there IS acurratte, (just to clarify for anyone else reading this that i'm not arguing that isn't true, just the inference that it's a multi-second latency gap outside of special circumstances). But as you pointed out the advantage is that it cuts down the mount of stuff you have to buffer. Mid rnage and better PC's even now have enough VRAM and Ram however to buffer far more than the PS5 can. The PS5 is doing this because it has to to stretch it's available onboard RAM. PC's can brute force it, (and this is only going to become more true with time).

 

It's a solution to a problem PC's don;t have.

[hishnash]

48 minutes ago, CarlBar said:

f the operation is prone to sufficient stops and starts the latency might start to matter

if you are loading data from an SSD to a GPU on a PC there are a lot of steps and each of these can be interrupted with other tings for the cpu to do.

1. Game code (CPU user space):  detects that it needs to load some more data from the SSD

2. Game code (CPU user space): requests the file pointer from the kernel

3. Kernal checks if this file exists and if the game code has permission to read it
4. Kernal returns to the game code informting it of its file pointer
5. Game code (CPU user space) asks to read that file pointer please

6. Kernal asks SSD to please read data...
7. SSD responds saying data is read to be pulled

8. Kernal pulls data and puts it into memory

9. Kenral tells game code data is read

10. game code asks kernel for some memory please so it can put the decompressed data

11. kernel checks that there is memory

12. kernel responds with memory pointer
13. user space code starts to de-compress data from the ssd (it will do this in chucks) this is repeated...
   13.1 aks kernal for next chunk

   13.2 kernal ask ssd

   13.3 ssd here it is 

   13.4 kernal copy to target

   13.5 kernal tells game code its there 

14. when the game code is hapy it has decopressed the data it needs it tells the (userspace gpu driver) dx12.dll to "copy to gpu"
15. user space game driver asks kernal driver to please make this data avdaible for the gpu

16. kernal driver makes data avidable for the gpu

17. kernal driver informs user space driver of the location that the gpu can find the data

18. user space driver ask kernal driver to please tell the gpu to copy the data from that location to its own VRAM

19. kernal driver tells gpu to do this

20. gpu does this

21. gpu tells kernal driver it is done

22. kernal driver tells user space driver it is done

23. user space driver tells game it is done

24. game tells user space driver to please use this data in this way to render this thing

25. user space driver passes on this message to kernal driver

26. kernal driver passes on that message to gpu

27 Gpu uses the data as expected

 

on each one of these steps there is a small `wait` since other tings are happing on the system. The smaller the amount of data you are sending the larger the impact of this is. In the case of nanite there is now way it can load the full mesh so what they will be doing as you move the camara is loading parts fo the mesh int VRAM on demand. if you cant do this on time you end up with massive frame drops (or big holes in the mesh!)

 

48 minutes ago, CarlBar said:

PC's even now have enough VRAM and Ram however to buffer far more than the PS5 can.

PS5 has 16GB of VRAM (shared with cpu yes). Most PCs have a lot less VRAM. maybe at total the avg gaming PC has 24GB of RAM + VRAM.  Sure if you have 64GB of RAM or a large workstation card with enough local VRAM. 

[wanderingfool2]

53 minutes ago, CarlBar said:

Mid rnage and better PC's even now have enough VRAM and Ram however to buffer far more than the PS5 can. The PS5 is doing this because it has to to stretch it's available onboard RAM. PC's can brute force it, (and this is only going to become more true with time).

PS5 has 16GB of shared GDDR6 ram...so it actually has a lot more than most mid-range PC's.  Also remember PC's will have duplicate in ram/vram (which shared ram doesn't) and ontop of that 16GB in the PC space is a lot less than 16GB in console space (Windows 10 overhead, with programs running in the background 16GB is more likely only 12GB).  The majority of games system use comes from graphics, so shared memory makes sense.  Actually, try showing a "mid-range" card that actually has 16GB of memory

 

3 hours ago, StDragon said:

Right, ASICs are nothing new in console hardware, but I didn't think it was still relevant in the days of x86 SoC based platforms; even if they have a custom variant. I thought consoles were veering away from custom accelerated execution.

The PS4 might be different (as I suspected they had specific hardware, but they ultimately didn't do too much variation to it), but from what I've read about the PS5 it really seems like they went back to their classical approach of actually tossing in extra hardware/specializing certain calls to better optimize for game development.

 

I think ultimately they went more towards x86 because it has benefits of being always in development, and it is easy for them to integrate new instruction sets etc that will be for the custom chips.

[cirabarnet4]

13 hours ago, wanderingfool2 said:

PS5 has 16GB of shared GDDR6 ram...so it actually has a lot more than most mid-range PC's.  Also remember PC's will have duplicate in ram/vram (which shared ram doesn't) and ontop of that 16GB in the PC space is a lot less than 16GB in console space (Windows 10 overhead, with programs running in the background 16GB is more likely only 12GB).  The majority of games system use comes from graphics, so shared memory makes sense.  Actually, try showing a "mid-range" card that actually has 16GB of memory

Total ram range: 12-24 GB for the majority, so disagree with: "... a lot more than most mid-range PC's." Regarding duplication of data in ram and Vram. Why would graphical assets be stored in system ram and Vram? Why store superfluous data in ram/Vram? The game data required would be the same whether one has separated ram/Vram or unified, however there is a case for dynamic allocation in regards to unified ram/Vram. Radeon RX 5500XT has 8GB of Vram and 80+% have 8GB or more system ram. Overhead , inefficiencies and others that would diminish this "raw" capacity will be difficult to measure, however there is indeed larger presumed loss of system resources on Windows than Sony's PS operating system. 

 

Edit: https://store.steampowered.com/hwsurvey

Edited May 20, 2020 by cirabarnet4
Link in addition to screenshot

[StDragon]

14 minutes ago, cirabarnet4 said:

Regarding duplication of data in ram and Vram. Why would graphical assets be stored in system ram and Vram? 

If it's shared code, it's much faster for the CPU to execute on system RAM than to attempt traversal through the GPU and back; assuming such a feat could be done with it being an addressable resource in this regard. As for texture mapping, sure, I don't see why it doesn't get loaded in RAM, then to GPU, then dumped from RAM to free up space.

 

Gaming PCs are primarily CPU driven with a GPU as an add-on accessory. Consoles OTOH are GPUs that happen to have the CPU along for the ride. 

[wanderingfool2]

30 minutes ago, cirabarnet4 said:

Total ram range: 12-24 GB for the majority, so disagree with: "... a lot more than most mid-range PC's."

I was specifically talking about VRAM, if you read my post which makes up less than 8% total.  The reason being that I was disputing that the "trick" was being used to make up for a "shortfall" in that department.

Shared memory on PC's vs consoles are very very different.  8GB vram with an additional 8GB of system ram will not perform the same as 16GB of vram (there is a reason for GDDR on graphics cards).

As I stated as well, 16GB on a console is actually a lot larger than even 20GB on a PC.  The reason being the predictability of how much RAM you will have.  (With just light browsing, I am up to 6GB of ram used).

37 minutes ago, cirabarnet4 said:

Why would graphical assets be stored in system ram and Vram?

Simply due to VRAM not being able to store everything, so RAM would have to be used as a cache for textures/unused models etc.  My argument on the amount of RAM point was that mid-range PC's don't have as CarlBar was saying more than the PS5 and the PS5's trick was just to solve a problem PC's don't have...it is that the PS5 does have more to play with than just a mid-range PC in terms of the amount of RAM (for that argument sake).

[3rrant]

7 hours ago, cirabarnet4 said:

Total ram range: 12-24 GB for the majority, so disagree with: "... a lot more than most mid-range PC's." Regarding duplication of data in ram and Vram. Why would graphical assets be stored in system ram and Vram? Why store superfluous data in ram/Vram? The game data required would be the same whether one has separated ram/Vram or unified, however there is a case for dynamic allocation in regards to unified ram/Vram. Radeon RX 5500XT has 8GB of Vram and 80+% have 8GB or more system ram. Overhead , inefficiencies and others that would diminish this "raw" capacity will be difficult to measure, however there is indeed larger presumed loss of system resources on Windows than Sony's PS operating system. 

 

12-16gb+ is 49,62‬% in this chart (also you do not sum VRAM and RAM, you count them separate). Is not even "majority" and is very different from having a 100% userbase with 16gb of ram like consoles will.

Plus, steam survey are not accurate and they do not differentiate between DDR1 and DDR4 or any other generation. Consoles will have a MUCH faster ram than most of these system do. Also, yes assets and not only that do get duplicated. It's done for better performance, but that does not mean it's the BEST way to do it. That's what overhead means on PC, everything you do on PC has a lot of overhead and inefficient usage of resources most of the time because, guess what, gaming is only a fraction of the PC community and at the hardware level most of the changes that get done and evolve over the years for PC are not made to make gaming better but focus on other things. The only similiar example how PC to consoles is in an APU, which on the PC side are extremely underpowered so not worth considering.

 

Also to add, on consoles the RAM usage is significantly lower. Most of the VRAM is used for the GPU and the "workflow" of code on PlayStation in particular has always been different than PCs, even if PS4 is the most similiar. Xbox system instead is more PC-like to the core. Since PS5 is very custom, almost on PS3 level, it's likely that it's code execution will be more exotic than PS4 and PC once again.

[3rrant]

12 hours ago, spartaman64 said:

I know lots of things are compressed to save on space but I never heard of compression used for increasing working data transfer rates. 

It depends on three things: compression ratio, CPU speed and disk speed.

 

If you have raw data, the CPU doesn't have to do any job. Your limit is gonna be the disk speed to transfer or read that file.

If you have compressed data, the CPU is doing more work while the disk is doing less. This idea is very old (at least 30+ years) and it was initially meant for external storage. Since old times external storage was abysmally slow, if you compressed the data on the storage with at least a 2:1 ratio the data would be transferred faster to the machine, processed by the CPU and ultimately resulted in faster read speed.

The same applies today in some cases. Depending on the compression ratio (2:1 might not be ideal, but 5:1 or 10:1 would be great) the CPU would work much more but much faster to read that compressed data than what the disk would be able to do if the data was raw instead. The PS5 is supposed to have dedicated hardware decompression-compression to not kill the CPU while doing it, otherwise whatever benefit you could gain would be too much damaging to the game performance as it would clog the CPU.

 

Multi-core or SMT/HT CPUs can achieve the best results because with the right optimization you can assign 1 core to decode the next part of the file while another reads it, and so on. If created just for this purpose, a GPU-like structure would probably be able to reach insane performances but I don't think any of that exists or needs to.

 

However, this is also a balancing act. You can make compressed data much faster if you use algorithm X (speed optimized) than if you'd use algorithm Y (size optimized), but X files would still be larger than Y. You need to choose a middle ground of good space saved and performance (this is what Cerny was referring to when talking zlib vs Kraken)

 

This is also done in datacenters and many other applications which require compression but also need extremely fast response times rather than best size saving. Google Snappy was an example.

[cirabarnet4]

11 hours ago, wanderingfool2 said:

I was specifically talking about VRAM,

Ah. Then what is the presumed total allocated Vram on the PS5? Do we know how Sony is allocating the unified ram? Is it fixed, I.E. 12 for GPU and 4 for CPU? Or is it dynamic dependent on game being run and system use? Knowing this would allow for a better comparison to PC. 

11 hours ago, wanderingfool2 said:

8GB vram with an additional 8GB of system ram will not perform the same as 16GB of vram (there is a reason for GDDR on graphics cards).

Agreed. However I do not agree with the notion that the PS5 has 16GB of Vram, even with the use of GDDR instead of DDR. Some of the unified ram must be allocated to the cpu for both the running program and the OS. How much this is and/or the efficiencies of it's distribution, is speculation until it is checked. So for my comparison it is oranges to apples in an attempt to quantify a theoretical unified ram with fixed allocation on PC. I.E. 8GB Vram and 8GB ram. This comparison oversimplifies such that it is incorrect if the comparison was about performance. It was just about total ram capacity. 

 

12 hours ago, wanderingfool2 said:

As I stated as well, 16GB on a console is actually a lot larger than even 20GB on a PC.  The reason being the predictability of how much RAM you will have.  (With just light browsing, I am up to 6GB of ram used).

I think we agree on this:

12 hours ago, cirabarnet4 said:

Overhead , inefficiencies and others that would diminish this "raw" capacity will be difficult to measure, however there is indeed larger presumed loss of system resources on Windows than Sony's PS operating system. 

 

12 hours ago, wanderingfool2 said:

Simply due to VRAM not being able to store everything, so RAM would have to be used as a cache for textures/unused models etc.  My argument on the amount of RAM point was that mid-range PC's don't have as CarlBar was saying more than the PS5 and the PS5's trick was just to solve a problem PC's don't have...it is that the PS5 does have more to play with than just a mid-range PC in terms of the amount of RAM (for that argument sake).

Ah, Fair pont.

[cirabarnet4]

5 hours ago, 3rrant said:

12-16gb+ is 49,62‬% in this chart (also you do not sum VRAM and RAM, you count them separate). Is not even "majority" and is very different from having a 100% userbase with 16gb of ram like consoles will.

My comparison was of total ram, this included ram and Vram for the comparison to the unified ram of the PS5 with unknown allocation. I.E. 8GB ram + 4GB Vram. That is is wrong is true, it is an attempt to compare apples to oranges I.E. PC to PS. Regarding majority: ram ~66% have 8GB or 16GB. Vram ~58% 4GB,6GB and 8GB. thus the majority for my comparison of a unified ram/Vram of fixed allocation falls in 12-24GB.

 

6 hours ago, 3rrant said:

Plus, steam survey are not accurate and they do not differentiate between DDR1 and DDR4 or any other generation. Consoles will have a MUCH faster ram than most of these system do.

Agreed. Do you know of a better survey/data gatherer for this, for better future reference?

 

I think I think we agree on this:

6 hours ago, 3rrant said:

Also to add, on consoles the RAM usage is significantly lower. Most of the VRAM is used for the GPU and the "workflow" of code on PlayStation in particular has always been different than PCs, even if PS4 is the most similiar. Xbox system instead is more PC-like to the core. Since PS5 is very custom, almost on PS3 level, it's likely that it's code execution will be more exotic than PS4 and PC once again.

 

13 hours ago, cirabarnet4 said:

Overhead , inefficiencies and others that would diminish this "raw" capacity will be difficult to measure, however there is indeed larger presumed loss of system resources on Windows than Sony's PS operating system. 

 

[leadeater]

26 minutes ago, cirabarnet4 said:

Agreed. However I do not agree with the notion that the PS5 has 16GB of Vram, even with the use of GDDR instead of DDR. Some of the unified ram must be allocated to the cpu for both the running program and the OS

It'll likely be similar to the PS4 which has a secondary processor and 256MB DDR3 ram so a lot of the non game functions will be offloaded to something like that using it's own processor and ram in the PS5. Maybe it won't happen this way again since the CPU isn't all levels of crap this time, but it's not really lack of CPU performance for why it was done.

 

As for the main game memory I wouldn't expect that to be very high, 6GB would be like high top end of my expectation but I don't think many will be that much.

 

Of course you only need as much VRAM as the GPU is capable of actually using performance wise so you could have 100GB but if you load in giant assets and run huge render resolution you'll be right at home in a corporate PowerPoint presentation. Until we know more about the GPU assessing how much is actually needed isn't really possible. Also basically all games on windows allocate VRAM much higher than what is actually in use, consoles don't do that or at least not as badly. Some games just outright allocate all of it so VRAM usage shows 90-100% but in reality far less is actually active or even has data in it.

[3rrant]

11 minutes ago, cirabarnet4 said:

Agreed. Do you know of a better survey/data gatherer for this, for better future reference?

For PC gaming that's the best you can do. The biggest issue with steam survey is that aside from having no separation of generations, it doesn't even separate notebooks, tablets or whatever from desktops. For example, "asymmetric" results in RAM amount is likely to be related to laptops. Many notebooks come pre-equipped with 4 or 8gb RAM which is not enough for many people, so they tend to upgrade that with a single stick. This often results in "odd numbers" like 12GB.

 

Considering how we generally build PCs (we = people who build their own rig), only 8/16/32GB are the combo that can be a little bit more trusted for gaming.

  

3 minutes ago, leadeater said:

It'll likely be similar to the PS4 which has a secondary processor and 256MB DDR3 ram so a lot of the non game functions will be offloaded to something like that using it's own processor and ram in the PS5. Maybe it won't happen this way again since the CPU isn't all levels of crap this time, but it's not really lack of CPU performance for why it was done.

If rumors and patents of Sony about their big focus on "get in the game immediately" are to be trusted. It's unlikely they will go with this kind of approach again. Things like demo-ing a game off the store directly or having "macros" when loading games to join multiplayer directly etc require power to be snappy. Also that would be yet another custom silicon to add in, which hey it might happen but things start to get costly.

 

[leadeater]

4 minutes ago, 3rrant said:

If rumors and patents of Sony about their big focus on "get in the game immediately" are to be trusted. It's unlikely they will go with this kind of approach again. Things like demo-ing a game off the store directly or having "macros" when loading games to join multiplayer directly etc require power to be snappy. Also that would be yet another custom silicon to add in, which hey it might happen but things start to get costly.

That wouldn't prevent this, dropping to PS4 menu and back to game is already very fast. That secondary processor is more for actual background functions like game downloads, game play streaming etc. Plus ARM isn't exactly slow.