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

[3rrant]

2 minutes ago, leadeater said:

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.

When you have a ton of trophies, friends and notifications if you are in a game let's say CIV VI during an enemy turn and you press the PS Button to check on the game trophies, it can takes upwards of 10-20s to get to the right menu. Maybe it's just a limitation due to the hard drive, but it can get pretty slow on the original PS4 at least.

[leadeater]

Just now, 3rrant said:

When you have a ton of trophies, friends and notifications if you are in a game let's say CIV VI during an enemy turn and you press the PS Button to check on the game trophies, it can takes upwards of 10-20s to get to the right menu. Maybe it's just a limitation due to the hard drive, but it can get pretty slow on the original PS4 at least.

That's the crap main CPU in the PS4 causing that not the secondary processor, and that game eats memory 

 

Main menu is run off the main CPU and when you go in to game a lot of stuff gets unloaded and other functions were on the secondary processor anyway. If you're playing a game and a game update comes out it'll start downloading and that is done on the secondary processor. It's not really fully understood everything that secondary processor does because Sony has never said other than "background tasks and network functions" and quite a lot of things can be covered by that and can also be situational.

 

Either way that slowness is the main CPU, because it's terrible.

[RejZoR]

52 minutes ago, 3rrant said:

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.

  

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.

 

You think that's odd? I had a system (Intel X58 LGA1366) with 18GB of RAM in triple channel consisting of 3x4GB and 3x2GB sticks

[Kisai]

18 hours ago, Zodiark1593 said:

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

All Texture Compression is lossy however, and you don't want lossy HDR compression either. You don't want lossy disk compression at all. It's like compressing everything with JPEG at 80%, or all audio at mpeg-i layer 3 at 96kbits. It's visibly/audiby lossy, but usually with all the other textures/sounds playing you don't notice it unless someone makes the mistake of compressing something you need to actually see clearly, like a map or a UI component, or a sound needing be pitch/speed adjusted.

 

Presumably the reason there is no lossless compression support in hardware is that it's a moving target that scales with CPU/GPU power. To give an example. PNG is really inefficient nowadays, but it's what a lot of indie games use as their image format because the only alternative is BMP/TGA inside a zip file which is roughly the same compression level. There is no hardware support for PNG. PNG is insufficient to store a lossless version of textures for GPU's since it's serialized (Eg can't be decompressed in parallel), and zlib is not the most efficient compression anymore (that would be lz4.) PNG induces latency because it needs to be completely decompressed in memory before it can be converted and compressed into a texture.

 

https://github.com/lz4/lz4

 

Take note, that even lz4 is only 17.5% the speed of straight memory copies. Zlib is less than 1%. So you would need to break the compression into 8 parallel operations for lz4 or 128 for zlib to make it equivalent to a straight memory copy.

 

http://richg42.blogspot.com/2015/12/the-future-of-gpu-texture-compression.html

 

Quote

The engineers working on GPU texture compression don't always have a full mental model of how texture assets are actually utilized by game makers. Their codecs are typically optimized for either highest possible quality (without taking eons to compress), or they optimize for fastest compression time with minimal to no quality loss (relative to offline compression). These tools ignore the key distribution problems that their customers face completely, and they don't allow artists to control the tradeoff between quality vs. filesize like 25 year old standard formats such as JPEG do.

...

These are awesome, high quality GPU texture compression tools/libs, with lots of customers. Unfortunately they solve the wrong problem.

The other side of the problem is that texture compression has to still work on low quality devices. So it's nice if nVidia releases a CUDA lossless texture compression format, but completely useless if it can't run on a 5 year old non-nVidia device. Game devs will just not use it because in order to use it they have to release two sets of textures. See my issue with developing for Android in another thread. Android supports no common texture compression format except on nVidia Tegra platforms. WebGL supports nothing.

https://docs.unity3d.com/Manual/class-TextureImporterOverride.html

So if you want to use compression, you are forced to make two or three separate texture packages, one for Android, and one for everything else, and one for webGL. So that can very well mean making inferior versions for Android and WebGL.

 

The PS5, as we know it, is going to be AMD hardware again. So a game dev working on a game for the PS5, is going to test it on a PC/Windows platform using an AMD GPU presumably so the hardware support and output matches what's on the PS5. Since there isn't a moving target, the "devkit" doesn't need to be updated for the life of the platform. A developer who is building the same game for as many platforms as possible would likely use a middleware (eg Unreal Engine 5, Unity), and assume the middleware is smart enough to select features that are native to the platform. However as stated in the previous paragraph. The game engine still has to make separate texture packages to support the target platform. So it's very possible that a game using UE5 built for the PS5 will look nothing like the same game built for the PC (AMD/Intel/nVidia), Mac (Which will be AMD or Intel hardware) or the Switch (nVidia hardware), or an mobile phone.

 

If the middleware is not smart enough, you will get nonsense like 100GB downloads with no compression primarily due to the same packaging needing to run on everything. That can be a good thing if the target is a PC, but a bad thing if the target is a mobile device.

 

And that doesn't touch on the problem of audio. The only audio compression support in hardware is AAC, which is lossy, and exists primarily to support h.264/h265 video in some containers. You can't really use it for anything else. ALAC/FLAC support is treated much the same way as loading a PNG, it has to be entirely decompressed in memory, not streamed from disk. So that induces latency for playback. You may as well just ship uncompressed wav files.

 

In an ideal situation, a new lossless file format would exist that allows directly storing image and audio data directly in the underlying hardware support so the compressed textures could be loaded directly from disk, but also directly used in the web browser and image viewers, which at present, does not exist. To view compressed textures you typically need the same tool the texture was compressed with, and since some texture types were patented, it's not a common feature.

 

Which comes back to the some of the arguments in this thread. Yes, you can save bandwidth, but you won't save time, as compression in software is going to always be slower than a straight memory copy unless you can somehow do the decompression in parallel. That's why lossy compression tends to win out, because you can divide an image into a bunch of 8x8 blocks as in JPEG/MPEG, and run the decompression in parallel on the GPU. 

[3rrant]

41 minutes ago, RejZoR said:

You think that's odd? I had a system (Intel X58 LGA1366) with 18GB of RAM in triple channel consisting of 3x4GB and 3x2GB sticks

Bro, that's 10+ years ago! But yeah, triple channel was fun.

 

36 minutes ago, Kisai said:

... So a game dev working on a game for the PS5, is going to test it on a PC/Windows platform using an AMD GPU presumably so the hardware support and output matches what's on the PS5...

It doesn't change what you test the game on during production. You can use Intel+Nvidia or full AMD, for production it has no difference at all. Before release, when production is in it's final stages or has already concluded and you move to the testing phase (which doesn't have a specific name) the tests are conducted on a PS5 or PS5 devkit, which are not Windows-based machines.A big studio right now uses 1080/2080+ hardware for pre-release testing, simply because aside from the alpha-stage game you also still have the editor running plus many other softwares for audio, video, graphics or just debugging.

36 minutes ago, Kisai said:

So it's very possible that a game using UE5 built for the PS5 will look nothing like the same game built for the PC (AMD/Intel/nVidia), Mac (Which will be AMD or Intel hardware) or the Switch (nVidia hardware), or an mobile phone.

 Assets are always the same. The quality of assets differs and not all quality levels get passed to a specific end platform, but the project is one and one only. You don't branch off the project for different platforms and you don't change assets. UE5/Unity are "single-editor" solutions. It doesn't matter what you end platform will be, you're using only one project and one assets folder, ever. What changes is the package creation, which is done when the project is complete. All non-proprietary engines like UE-Unity have this built in and require no work for the developer. It simply creates the necessary file structure, format and compression for the platform(s) selected.

 

For multiplatform environment, what you usually do is have a bunch of scripts that dynamically toggle things on and off depending on the platform they run on. The most common thing for example is to check if the game is running on a console and locking the maximum fps or refresh rate to 30fps. If you are developing for a phone, first you detect if it's Android or iOS and use this to toggle on/off certain components of the rendering pipeline, because they don't work exactly the same. 

 

But still, assets are the same. The way they are rendered differs.

[RejZoR]

What PS5 will achieve via clever streaming through fast RAM+SSD interconnect, PC will just do with brute force. I mean, PS5 has 16GB of shared memory. That's almost as much as  my graphic card alone has (GTX 1080Ti with 11GB VRAM). Main RAM is at 32GB. So, 43GB of memory in total on a system that's effectively 5 years old this moment with graphic card just a year younger.

[Zodiark1593]

1 hour ago, Kisai said:

All Texture Compression is lossy however, and you don't want lossy HDR compression either. You don't want lossy disk compression at all. It's like compressing everything with JPEG at 80%, or all audio at mpeg-i layer 3 at 96kbits. It's visibly/audiby lossy, but usually with all the other textures/sounds playing you don't notice it unless someone makes the mistake of compressing something you need to actually see clearly, like a map or a UI component, or a sound needing be pitch/speed adjusted.

 

Presumably the reason there is no lossless compression support in hardware is that it's a moving target that scales with CPU/GPU power. To give an example. PNG is really inefficient nowadays, but it's what a lot of indie games use as their image format because the only alternative is BMP/TGA inside a zip file which is roughly the same compression level. There is no hardware support for PNG. PNG is insufficient to store a lossless version of textures for GPU's since it's serialized (Eg can't be decompressed in parallel), and zlib is not the most efficient compression anymore (that would be lz4.) PNG induces latency because it needs to be completely decompressed in memory before it can be converted and compressed into a texture.

 

https://github.com/lz4/lz4

 

Take note, that even lz4 is only 17.5% the speed of straight memory copies. Zlib is less than 1%. So you would need to break the compression into 8 parallel operations for lz4 or 128 for zlib to make it equivalent to a straight memory copy.

 

http://richg42.blogspot.com/2015/12/the-future-of-gpu-texture-compression.html

 

The other side of the problem is that texture compression has to still work on low quality devices. So it's nice if nVidia releases a CUDA lossless texture compression format, but completely useless if it can't run on a 5 year old non-nVidia device. Game devs will just not use it because in order to use it they have to release two sets of textures. See my issue with developing for Android in another thread. Android supports no common texture compression format except on nVidia Tegra platforms. WebGL supports nothing.

https://docs.unity3d.com/Manual/class-TextureImporterOverride.html

So if you want to use compression, you are forced to make two or three separate texture packages, one for Android, and one for everything else, and one for webGL. So that can very well mean making inferior versions for Android and WebGL.

 

The PS5, as we know it, is going to be AMD hardware again. So a game dev working on a game for the PS5, is going to test it on a PC/Windows platform using an AMD GPU presumably so the hardware support and output matches what's on the PS5. Since there isn't a moving target, the "devkit" doesn't need to be updated for the life of the platform. A developer who is building the same game for as many platforms as possible would likely use a middleware (eg Unreal Engine 5, Unity), and assume the middleware is smart enough to select features that are native to the platform. However as stated in the previous paragraph. The game engine still has to make separate texture packages to support the target platform. So it's very possible that a game using UE5 built for the PS5 will look nothing like the same game built for the PC (AMD/Intel/nVidia), Mac (Which will be AMD or Intel hardware) or the Switch (nVidia hardware), or an mobile phone.

 

If the middleware is not smart enough, you will get nonsense like 100GB downloads with no compression primarily due to the same packaging needing to run on everything. That can be a good thing if the target is a PC, but a bad thing if the target is a mobile device.

 

And that doesn't touch on the problem of audio. The only audio compression support in hardware is AAC, which is lossy, and exists primarily to support h.264/h265 video in some containers. You can't really use it for anything else. ALAC/FLAC support is treated much the same way as loading a PNG, it has to be entirely decompressed in memory, not streamed from disk. So that induces latency for playback. You may as well just ship uncompressed wav files.

 

In an ideal situation, a new lossless file format would exist that allows directly storing image and audio data directly in the underlying hardware support so the compressed textures could be loaded directly from disk, but also directly used in the web browser and image viewers, which at present, does not exist. To view compressed textures you typically need the same tool the texture was compressed with, and since some texture types were patented, it's not a common feature.

 

Which comes back to the some of the arguments in this thread. Yes, you can save bandwidth, but you won't save time, as compression in software is going to always be slower than a straight memory copy unless you can somehow do the decompression in parallel. That's why lossy compression tends to win out, because you can divide an image into a bunch of 8x8 blocks as in JPEG/MPEG, and run the decompression in parallel on the GPU. 

Probably might be a good time to mentioned that the compression I was referring to was for the framebuffer. My derp. A smaller memory footprint for the framebuffer eases the costs of reading/writing to it, allowing for additional overdraw, shader writes or full screen effects to take place without actually increasing memory bandwidth. Framebuffer compress should be lossless (imagine the bleep-storm if vendors  started using lossy compression for the framebuffer). 
 

Nvidia’s Maxwell series framebuffer compression improved considerably upon it’s predecessor, allowing for improved performance despite stagnant (or sometimes even lower) memory bandwidth. 

 

Textures already reside in the game data in compressed form, and are decompressed by the GPU. Don’t think there’s any time savings looking into texture compression, unless the storage is fast enough to serve uncompressed textures on demand (not likely), or main memory can accommodate (expensive). 
 

During my time with Unreal Engine 4, there were texture formats specific for Adreno devices, another specific to Tegra devices, and one for PowerVR devices. And then a couple universal ones depending on what OpenGL level the target device supports. Kind of insane if you wish to support them all. 

[wanderingfool2]

  

20 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 is more of a function of read speed vs decompression speed (and CPU time).  It was more common to use compression on media with very limited space, or very slow read speeds...but again it comes down to whether the CPU (or in this case hardware decoder) could actually handle it.

2 hours 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. 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. 

In reality I would guess around 3-4GB reserved for OS (depends on what Sony has plans for the OS).  Game code itself would be under 0.5GB.  I write it as VRAM mainly because it's easier than GDDR...and it's a better analog than DDR.  It is my point though that the tech being utilized has made it very much an apples to oranges comparison.

 

1 hour ago, Kisai said:

Presumably the reason there is no lossless compression support in hardware is that it's a moving target that scales with CPU/GPU power. To give an example. PNG is really inefficient nowadays, but it's what a lot of indie games use as their image format because the only alternative is BMP/TGA inside a zip file which is roughly the same compression level. There is no hardware support for PNG. PNG is insufficient to store a lossless version of textures for GPU's since it's serialized (Eg can't be decompressed in parallel), and zlib is not the most efficient compression anymore (that would be lz4.) PNG induces latency because it needs to be completely decompressed in memory before it can be converted and compressed into a texture.

The benefit being the PS5 will have a hardware decompressor (that if true can work at 8-9GB/s, at a 2:1 ratio of zlib/karken).

[Zodiark1593]

Question: Why couldn’t a future storage protocol, like a hypothetical NVME 2.0, implement hardware compression/decompression on the the CPU silicon or chipset?

[3rrant]

22 minutes ago, Zodiark1593 said:

Question: Why couldn’t a future storage protocol, like a hypothetical NVME 2.0, implement hardware compression/decompression on the the CPU silicon or chipset?

Because it would require the equivalent of CPU cores. So it needs someone like Intel or amd to license it's use for that purpose. Plus, you are effectively adding another processor which needs to "speak" to the other parts of the system, so you'd need drivers (which add overhead and therefore reduce the performance benefit) or an on-chip interface which would require motherboard makers to do it etc.. so, not gonna happen. Aside from having a licensing agreement with AMD, Sony is a custom silicon designer since the very first PS1 or even before. They have the knowledge to do so, other companies like Asus or MSI just don't. And since they now have claimed to have used custom Zen cores and custom Navi CUs, it appears that the partnership of IPs between Sony and AMD is much bigger than before and also compared to companies like Microsoft as well.

[wanderingfool2]

23 minutes ago, Zodiark1593 said:

Question: Why couldn’t a future storage protocol, like a hypothetical NVME 2.0, implement hardware compression/decompression on the the CPU silicon or chipset?

Cost and changing scopes.  There is a limited scope in the usefulness for hardware decompression, and it adds cost/uses silicon space.  That and when compression tech changes, either the hardware changes (meaning the older hardware gets outdated and unusable...resorting back to CPU/GPU cycles) or things remain on the old compression algo.