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

Matt weighs in on PS5 I/O, PS5 vs XSX and what it means for PC.

quest

Not Banned from OT
Treating GPU memory (GDDR6) as a virtual disk? I thought the idea was a 100GB of the SSD was virtual RAM?
Im assuming he meant ssd the way the rest was about how much textures he can load now id assume from that 100 gig cache or virtual memory. The important part is they can flush and pull data in mid frame at 120fps. It won't be huge chunks like Sony but shows the io is efficient and not much latency like suggested.
 

THE:MILKMAN

Member
Im assuming he meant ssd the way the rest was about how much textures he can load now id assume from that 100 gig cache or virtual memory. The important part is they can flush and pull data in mid frame at 120fps. It won't be huge chunks like Sony but shows the io is efficient and not much latency like suggested.

No doubt the SSD and I/O is very fast, it just threw me how he brought the RAM into it like that.
 
I dont believe so, logic has to be cleverly though out and engineered but I dont think we will see a large chunk of silicon for this = hardware cost.

Yes Sony spent more on engineering is likely, dont know how each factor that into base conole prices. Both probably spend more on marketing lol.

I also dont think the cooling will be expensive, as Cerny himself said it was impressive, and impressive in engineering money means performant and cost effective, but I have no opnions on cooling as we have not seen it.

Sony looks to have spent more money on audio if you ask my thoughts, there is a shit load of R&D there.

Right but I'm just trying to wrap my head around how they'll be able to have the hardware automate power shifting without dev input at 2 ms or what-have-you, in a solution that's overall cheaper than going with fixed clocks and a cooling system to cover all thermal output possibilities. Even if the end-costs for terms of the final silicon itself is cheap, the R&D I'd imagine would be somewhat on the pricier side, and that's something they would factor into the MSRP as it somewhat also impacts the BOM.

No doubt they are both spending more on marketing vs. total R&D. Even consoles like the N64, IIRC, put $100 in marketing for each system manufactured at launch, and that system itself was $250 in its day. Or we can look at something like Halo Infinite, that $500 million budget is probably $100 million for the actual game itself, and maybe $50 million - $75 million for the SlipSpace engine. So the rest would probably be towards marketing and long-term DLC costs but let's say the latter is just $25 million. That's almost $300 million for marketing, product tie-in deals, multimedia content etc. Take the actual game dev costs and that's almost 5:1 in favor of everything outside of the game development directly xD.

Cooling-wise, I'm expecting it's probably gonna be a bit more expensive than MS's, tbh. The Bloomberg article suggested cooling costs were factoring decently into the BOM. I'm sure the cooling setup itself is very impressive from an engineering component but it could be the same thing there as with the silicon they're using for enforcing the variable frequency, i.e a lot of up-front R&D costs but the final component costs could be relatively inexpensive, you just have to look at that R&D costs to also understand how it could impact the BOM and particularly the MSRP.

We aren't gonna learn jack squat about this stuff tomorrow, though. Hopefully a look at the system design, but that'll probably be the extent of it.
 

Thirty7ven

Sony make cringe trainers.
Imagine reading the dirt 5 technical director comments and the takeaway being once again that the PS5 I/O won’t make a difference.
 

Elog

Member
I don't think there's an easy or even standardized answer here because it comes down a lot to the engine a game is running, the GPU programming language being used (CUDA, etc.), and the programming techniques of the application in question. My understanding of things on this front aren't super-detailed, but I assume generally CUs are filled with work depending on the requirements of the workload, and (usually) that's done sequentially, i.e when the first CU has its caches occupied and it's working on data then the next CU in the block is given data to work with, once all CUs in a block are occupied then CUs in the next block are assigned with tasks by the scheduler etc.

Thank you. So a key question in this context is how much cache performance impacts CU performance, i.e. during high load, what is the % of time a CU waits for its cache to be cleared and then filled with new data to be processed. This is one of the numbers I have been looking for with no success (fully understanding that it is contextual but I would assume that there is some sort of normal within the framework of a given design).


I don't think the power load adjustment works on a CU-level, i.e selectively scaling the power load per CU. They are either all operating at one frequency or all operating at another frequency depending on the power allotted to the GPU. So the example you mention, I don't think that's actually something which can happen on the GPU side. This would also extend to the caches; they're either all operating at one frequency or all operating at another frequency, it's not a case of one CU operating at 2.23 GHz and another at 2.5 GHz and yet another at 1.9 GHz but across the board they're all operating at a net power load resulting in a frequency at or below 2.23 GHz.

Totally agree. I also assume that frequency will be 'chip based' and not 'part-of-chip based'. My question stemmed from some general examples that I have seen where CU utilisation varies widely across one GPU so that one CU is tapped out at 100% utilisation and consequently becomes the FPS bottle-neck. A few papers later my confusion has come to a new and higher level regarding how the different parts of the GPU interacts with the caches, GPU scheduling, power consumption/heat generation and overall efficiency. It is clear that the PS5 might have done something very smart here since Cerny touches on all of these components but it is close to impossible to discern what gains - if any - that has been achieved in overall utilisation as a % of theoretical max (i.e. the TFlops number). We will probably just have to wait and see.

.
 
Thank you. So a key question in this context is how much cache performance impacts CU performance, i.e. during high load, what is the % of time a CU waits for its cache to be cleared and then filled with new data to be processed. This is one of the numbers I have been looking for with no success (fully understanding that it is contextual but I would assume that there is some sort of normal within the framework of a given design).




Totally agree. I also assume that frequency will be 'chip based' and not 'part-of-chip based'. My question stemmed from some general examples that I have seen where CU utilisation varies widely across one GPU so that one CU is tapped out at 100% utilisation and consequently becomes the FPS bottle-neck. A few papers later my confusion has come to a new and higher level regarding how the different parts of the GPU interacts with the caches, GPU scheduling, power consumption/heat generation and overall efficiency. It is clear that the PS5 might have done something very smart here since Cerny touches on all of these components but it is close to impossible to discern what gains - if any - that has been achieved in overall utilisation as a % of theoretical max (i.e. the TFlops number). We will probably just have to wait and see.

.

The CUs being stream processors will work fastest when the needed data has enough predictability to keep the cache fed, e.g. all of the data is in an array that is streamed just-in-time for computation. Now, this can fall apart with either incoherent data access (the next data needed is computationally dependent, e.g. some RT workloads), other computational dependencies from other processors (other CUs or the CPU, etc.), or stalls from a saturated bus (see PS3’s Cell w/XDR I/O for a streamlined architecture that allows for very high efficiency). Data retrieval is very expensive, and can introduce massive latency. As a general rule, larger caches can lower the costs (power & time) associated with larger complex data structures. Another problem that can arise is when an algorithm is not granular enough, so it does not adequately leverage the parallelism available. This is frequently witnessed with single-threaded code on the CPU.

To achieve high efficiency, either the software needs to avoid tasks that create unpredictable fetches, dependency issues, unnecessarily over saturating the memory bus, etc., or the hardware can be enhanced to lower the costs associated with complex workloads.

Complex AI workloads are creating huge new challenges for hardware, and one attempt to address massive interdependencies involves a trillion+ transistor wafer-sized chip that consumes over 10 kW!

Some developers might have GDC presentations showing performance profiling, and the process they went through to fill GPU ‘bubbles’ with asynchronous compute workloads. I expect Sony worked with AMD to further address architectural bottlenecks related to a host of features they felt necessary for realizing their grand vision.

I do not have any hard numbers on hand for efficiency, but I seem to recall instances where 80-90% efficiency was achieved on Cell (maybe for The Last of Us?). That figure might be somewhere around 70% or more on PS4 for the best developers (GG, ND, SSM, etc.). The latest AMD tech should be even better.
 

longdi

Banned
Treating GPU memory (GDDR6) as a virtual disk? I thought the idea was a 100GB of the SSD was virtual RAM?

I think it has the same meaning. In the past, you can realistically work within the 16GB of vram, with Series X Velocity, you no longer need to see it as 'just' 16GB, but your work space now extends into the SSD capacity.
Shit is going to be fast. :messenger_bicep:
 
Last edited:
The CUs being stream processors will work fastest when the needed data has enough predictability to keep the cache fed, e.g. all of the data is in an array that is streamed just-in-time for computation. Now, this can fall apart with either incoherent data access (the next data needed is computationally dependent, e.g. some RT workloads), other computational dependencies from other processors (other CUs or the CPU, etc.), or stalls from a saturated bus (see PS3’s Cell w/XDR I/O for a streamlined architecture that allows for very high efficiency). Data retrieval is very expensive, and can introduce massive latency. As a general rule, larger caches can lower the costs (power & time) associated with larger complex data structures. Another problem that can arise is when an algorithm is not granular enough, so it does not adequately leverage the parallelism available. This is frequently witnessed with single-threaded code on the CPU.

To achieve high efficiency, either the software needs to avoid tasks that create unpredictable fetches, dependency issues, unnecessarily over saturating the memory bus, etc., or the hardware can be enhanced to lower the costs associated with complex workloads.

Complex AI workloads are creating huge new challenges for hardware, and one attempt to address massive interdependencies involves a trillion+ transistor wafer-sized chip that consumes over 10 kW!

Some developers might have GDC presentations showing performance profiling, and the process they went through to fill GPU ‘bubbles’ with asynchronous compute workloads. I expect Sony worked with AMD to further address architectural bottlenecks related to a host of features they felt necessary for realizing their grand vision.

I do not have any hard numbers on hand for efficiency, but I seem to recall instances where 80-90% efficiency was achieved on Cell (maybe for The Last of Us?). That figure might be somewhere around 70% or more on PS4 for the best developers (GG, ND, SSM, etc.). The latest AMD tech should be even better.

I remember seeing a GPU video from NXGamer that threw out some quick percentages on this and IIRC those numbers for average efficiency were probably around 35% - 40% between PS4 and XBO. But to their credit they did say those were very rough and quick-guess numbers, and just maybe typical efficiency usage. It's possible for example with the optimization coding techniques some PS studios picked up over the years that they were able to get higher efficiency figures, maybe near the 70% or so as you speculate, though these were probably titles within the last 2-3 years leading up to today (like the upcoming TLOU2 and GOT).

Dunno what the peak efficiency utilization was on XBO; FWIW that system was not necessarily designed with gaming at the forefront of the architectural design IMHO and to add on top of that such complicated the level of optimized integration with DX11, let alone DX12, on the platform. If efficiency utilization was lower on XBO I would say that's more an admonishment of the system's design facilitating multimedia at its forefront for the hardware that was eventually built, and not necessarily OS efficiency or DX11/DX12 efficiency (though the hardware design itself would impact the degree of optimization that could be done with the OS and DX11/DX12 API on the system platform).

Thank you. So a key question in this context is how much cache performance impacts CU performance, i.e. during high load, what is the % of time a CU waits for its cache to be cleared and then filled with new data to be processed. This is one of the numbers I have been looking for with no success (fully understanding that it is contextual but I would assume that there is some sort of normal within the framework of a given design).

Dunno really, but I figure RAM bandwidth factors heavily into this. That's going to affect the size of data chunks going across the bus at a time in parallel (bus size), and how many times the GPU can access data in the memory across the bus (speed amount). Those are areas where XSX has the advantage with the wider 320-bit bus (40 bytes maximum data chunk transfer size per cycle) and overall parallel bandwidth (560 GB/s on the 10 GB pool, vs. 448 GB/s on a potential 10 GB - 11.5 GB pool with PS5, assuming OS reserves 2 GB and CPU/Audio tasks are going to use some RAM for their data, too).

Overall though I think in that context it's going to depend a lot on what specific workloads call for.

Totally agree. I also assume that frequency will be 'chip based' and not 'part-of-chip based'. My question stemmed from some general examples that I have seen where CU utilisation varies widely across one GPU so that one CU is tapped out at 100% utilisation and consequently becomes the FPS bottle-neck. A few papers later my confusion has come to a new and higher level regarding how the different parts of the GPU interacts with the caches, GPU scheduling, power consumption/heat generation and overall efficiency. It is clear that the PS5 might have done something very smart here since Cerny touches on all of these components but it is close to impossible to discern what gains - if any - that has been achieved in overall utilisation as a % of theoretical max (i.e. the TFlops number). We will probably just have to wait and see.

For those examples you saw, I guess a lot depends on if they were RDNA or RDNA2 GPUs, because a good deal of small changes have probably been made going between the two. One CU getting tapped at 100% would feed into issues regarding the frontend (things like the Geometry Processor, ACE units, Graphics Command Processor etc.) that would've needed to be fixed; both MS and Sony have worked very closely with AMD on trying to sort that out, but keep in mind they both have their own isolated teams with engineers from their companies and AMD engineers on-board as well, so the solutions they came up with in this regard were likely in isolation, though building off general roadmap specs that AMD would have already came up with as blueprints to implement themselves in the PC GPU designs (which, as we know, will probably have some aspects been influenced from specific customizations Sony and MS have realized with their teams).

How Sony's own customizations play into answering some of those problems isn't fully known; the cache scrubbers for example may've been required as an architectural feature specific to Sony's solution to help flush waste in the GPU caches faster than what AMD's "default" solution might've provided though said default solution might be perfectly fine for GPUs clocked lower than Sony's. The customizations they've made with the Geometry Engine, AFAIK, it's still based off the Primitive shaders/engines but are also targeting for culling earlier on in the rendering pipeline. Again whether that's the type of customization that was specifically needed for Sony's solution due to the high GPU clock or something that might end up being more useful in a wider net of the PC GPUs even if at lower clocks (and thus being better than any AMD "default" features in that regard), that remains to be seen, as you've stated.
 

rnlval

Member
This is mumbo-jumbo. Both consoles are using NAND, which is a page and block-level technology. In other words, data is read at the page level, and written at the block level. This is just the nature of the technology. You cannot access NAND data at the byte (let alone bit) level unless you place it in a different type of memory with that privilege first such as SRAM, DRAM, MRAM or NOR Flash (the latter has very slow write speeds btw, but is the only one AFAIK with bit-level read accessibility since it's often used for XIP), at which point that isn't the NAND providing that level of granularity, but the different memory some of that data is in.

So basically when it comes to explaining the basics of how SSDs (particularly the NAND they use) works, that giant continuous paragraph gets it wrong, they are fantasizing something that isn't possible. The very closest you could get with that is if they were using something like ReRAM (which doesn't even exist in any notable capacities AFAIK and is still in very early stages), MRAM (capacities of only a few MBs and very expensive even for that), or 3D Xpoint (AFAIK quite expensive per-GB though it exists in pretty large capacities and mass availability mainly for data center markets). But those "only" offer byte-level accessibility at lowest granularity level.

I've heard about the profiles, but IIRC didn't Cerny clarify with DF that the final retail system will handle profiles autonomously? Which I would be very curious if could even be done, since doesn't the game code itself determine the amount of power usage that would be going to the CPU and GPU?

They would need some extremely good detection logic and ability to switch power load through the components almost instantly if handling things automatically on their end, at least if the devs decided on profiles they could query the hardware for adjusting power loads ahead of time for specific instances where they expect power usage to be greater than usual. That's just what I'm thinking off in my head, though.
Btw, NVMe follows PCIe protocols. If consoles' SSD follows NVMe, then it has PCIe protocols..
 

Gamer79

Predicts the worst decade for Sony starting 2022
Rabble rabble my jerkoff ssd number is bigger than yours. Take all the theory bullshit you want. I want to see the results.
 

rnlval

Member
Why talk about stuff you have no idea about with someone who uses UE4 every day and embarrass yourself? I simply don't understand.
Secondly I dont have to wait for middle/end of the gen. I get my hands on the demo Q1 2021.

If a laptop full of bottlenecks can run it at 1440p at 40 fps using the bottle-necked process of External Sata SSD > USB > CPU > System RAM > CPU > VRAM > GPU. (no DirectStorage, no Hardware Decompression, No unified Ram, No SFS)

A machine with Nvme 4.0 SSD with hardware decompression on board > Unified Ram > GPU will be able to run it at equal or better quality.

Its just that simple.
Modern GPU has built-in DXTC/BCx hardware decompression, hence the said laptop with RTX GPU doesn't have to deal with uncompressed raw data.

NVIDIA's Turing still has superior GPU real time compression/decompression hardware when XSX's RDNA 2 GPU needs higher memory bandwidth to rival RTX 2080 with 256 bit GDDR6-14000. LOL

I'm still waiting for AMD to deliver RTX 2080 with a 256-bit bus GDDR6-14000 like solution.
 

rnlval

Member
There was no LODs on the UE5 demo, just asset size, but thats that technology, we dont know what Decima and others will do with super streaming tech and use global illunation and thats it.

Just the way I see it. Ps5 games will push like that UE5 demo, especially FIRST party but also UE5 games can do it without effort by looks of it.

XSX will push 60 / 120 FPS in some cases for simpler 2d and isometric / top down stuff and AAA will push ray tracing further than global illumination as it can, and will be better in that domain by 15./18 % or however it falls :messenger_beaming:

3rd pary wont bother much lol
From https://www.unrealengine.com/en-US/blog/a-first-look-at-unreal-engine-5
Statement from EPIC,

Nanite geometry is streamed and scaled in real-time


Notice Nanite has an automatic "geometry scaling" feature.

Geometry overdraw is wasteful.
 
I remember seeing a GPU video from NXGamer that threw out some quick percentages on this and IIRC those numbers for average efficiency were probably around 35% - 40% between PS4 and XBO. But to their credit they did say those were very rough and quick-guess numbers, and just maybe typical efficiency usage. It's possible for example with the optimization coding techniques some PS studios picked up over the years that they were able to get higher efficiency figures, maybe near the 70% or so as you speculate, though these were probably titles within the last 2-3 years leading up to today (like the upcoming TLOU2 and GOT).

Dunno what the peak efficiency utilization was on XBO; FWIW that system was not necessarily designed with gaming at the forefront of the architectural design IMHO and to add on top of that such complicated the level of optimized integration with DX11, let alone DX12, on the platform. If efficiency utilization was lower on XBO I would say that's more an admonishment of the system's design facilitating multimedia at its forefront for the hardware that was eventually built, and not necessarily OS efficiency or DX11/DX12 efficiency (though the hardware design itself would impact the degree of optimization that could be done with the OS and DX11/DX12 API on the system platform).



Dunno really, but I figure RAM bandwidth factors heavily into this. That's going to affect the size of data chunks going across the bus at a time in parallel (bus size), and how many times the GPU can access data in the memory across the bus (speed amount). Those are areas where XSX has the advantage with the wider 320-bit bus (40 bytes maximum data chunk transfer size per cycle) and overall parallel bandwidth (560 GB/s on the 10 GB pool, vs. 448 GB/s on a potential 10 GB - 11.5 GB pool with PS5, assuming OS reserves 2 GB and CPU/Audio tasks are going to use some RAM for their data, too).

Overall though I think in that context it's going to depend a lot on what specific workloads call for.



For those examples you saw, I guess a lot depends on if they were RDNA or RDNA2 GPUs, because a good deal of small changes have probably been made going between the two. One CU getting tapped at 100% would feed into issues regarding the frontend (things like the Geometry Processor, ACE units, Graphics Command Processor etc.) that would've needed to be fixed; both MS and Sony have worked very closely with AMD on trying to sort that out, but keep in mind they both have their own isolated teams with engineers from their companies and AMD engineers on-board as well, so the solutions they came up with in this regard were likely in isolation, though building off general roadmap specs that AMD would have already came up with as blueprints to implement themselves in the PC GPU designs (which, as we know, will probably have some aspects been influenced from specific customizations Sony and MS have realized with their teams).

How Sony's own customizations play into answering some of those problems isn't fully known; the cache scrubbers for example may've been required as an architectural feature specific to Sony's solution to help flush waste in the GPU caches faster than what AMD's "default" solution might've provided though said default solution might be perfectly fine for GPUs clocked lower than Sony's. The customizations they've made with the Geometry Engine, AFAIK, it's still based off the Primitive shaders/engines but are also targeting for culling earlier on in the rendering pipeline. Again whether that's the type of customization that was specifically needed for Sony's solution due to the high GPU clock or something that might end up being more useful in a wider net of the PC GPUs even if at lower clocks (and thus being better than any AMD "default" features in that regard), that remains to be seen, as you've stated.

Of course, utilization is a marriage of hardware and software, so the low utilization figure you mentioned sounds very plausible, especially for single-threaded code that does not significantly invoke asynchronous compute on the GPU. Improving AC was a key Sony innovation that allowed software to improve utilization by pushing more work to idle CUs (the GPU ‘bubbles’ in the profiler tool).
 
Btw, NVMe follows PCIe protocols. If consoles' SSD follows NVMe, then it has PCIe protocols..

Right, that's true. But the NAND itself is built by design to perform read and write accesses in a certain way. So the PCIe protocol may transfer data at byte-level through packets (it was double-word with earlier versions and using 8b/10b encoding there; maybe it's different now with 4.0 tho it uses 128b/130b with scrambling), but the physical NAND itself can't be directly addressed at byte-level for either reads or writes, just pages and blocks. That's how the technology is structured by the manufacturers of the chips, it's built into the fabric of the tech at its root.

So I'm wondering how that pastebin was getting to a conclusion the system could access the data at bit-level when we know they're using TLC NAND chips and NAND's lowest granularity levels for reads are page, and for writes they're blocks. The controllers still have to adhere to that even if the systems are using NVMe which uses PCIe. And because of that I'm guessing they might've been referring to the SRAM cache in the PS5 I/O block?

That said I'm no engineer and definitely wasn't involved in designing either console, so maybe there's something there I wouldn't be aware of 🤷‍♂️ .

Of course, utilization is a marriage of hardware and software, so the low utilization figure you mentioned sounds very plausible, especially for single-threaded code that does not significantly invoke asynchronous compute on the GPU. Improving AC was a key Sony innovation that allowed software to improve utilization by pushing more work to idle CUs (the GPU ‘bubbles’ in the profiler tool).

Yeah, some devs are just going to be better at utilizing hardware than others, and 1st parties tend to always get the best use out of these systems. Though I guess going back to the past that wasn't always mainly the case; I know companies like Treasure were able to do things with the MegaDrive and Saturn that was at least toe-to-toe with some of the best of SEGA's 1st party on those systems, and they were strictly a 3rd-party dev.

Sony's work with the ACE units was a big role in allowing some great asynchronous programming on PS4, and AMD took that to heart with their PC cards. So was volatile bit (which at least a little bit, the cache scrubbers feel like a continuation of in a few ways). I also think MS's work with executeIndirect support at the hardware level will help a lot with asynchronous programming on their GPU's end; IIRC the XBO had support for it but aside from that and maybe a couple Nvidia GPUs no other GPUs had the hardware support for utilizing it. Wouldn't be surprised if AMD GPUs going forward have such hardware support in the future.
 

ToadMan

Member
That shit happens, like with the extra 4 gig RAM in PS4, it’s also a process that can have set backs or some luck. Like most things in life.

there are a few discoveries we use today that where accidental or luck when they experimented.

Sony got lucky? Then so did AMD who are producing GPUs with that clock and as a result PC users got lucky.

The only unlucky ones are Xsex gamers lol

"How much texture data can I now load? "

Answer : A little less than half as much as PS5.
 
Last edited:

sinnergy

Member
Sony got lucky? Then so did AMD who are producing GPUs with that clock and as a result PC users got lucky.

The only unlucky ones are Xsex gamers lol



Answer : A little less than half as much as PS5.
How would you know? Maybe be the PS5 gpu can’t do a half frame refresh.
 

ToadMan

Member
in a solution that's overall cheaper than going with fixed clocks and a cooling system to cover all thermal output possibilities.

Like most you’ve misunderstood what Sony is using this technology for. It’s not to save power - it is to optimise the use of power.

It’s not about saving $1 a unit on cooling - Sony’s cooling Solution is likey more expensive that Xsex.

The reason Sony are using this is to drive the clock speed that high. High clocks are only useful if one can make use of that clock tick to perform useful work - that needs power.

Assuming MS aren’t using a similar system in Xsex, they’re leaving performance on the table. Tflops is only one third of the calculation that predicts gpu performance, another third is power (the final third is “activity” the code that’s running).

Smartshift is about providing power - if MS haven’t done that then their power cap will be their limit of performance.

So far, we “think” we know they’re making 200W available. 60 of that goes to the cpu, so MS are left with around 130W for their gpu (allowing 10W for the rest of the system - that’s probably a bit light).

That’s less than half the power a 2080ti and about half a 5700xt.
 
Last edited:

ToadMan

Member
How would you know? Maybe be the PS5 gpu can’t do a half frame refresh.

Well multiplats will tell the story ...

Oh look multiplats run the same PS5 and Xsex.

How can it be the most powerful console can’t show that mighty 2tf advantage in simple multiplat games?
 
Last edited:

sinnergy

Member
Well multiplats will tell the story ...

Oh look multiplats run the same PS5 and Xsex.

How can it be the most powerful console can’t show that mighty 2tf advantage in simple multiplat games?
How would you know now there won’t be a difference? Both are not out.

maybe there will be a difference.
 

ToadMan

Member
How would you know now there won’t be a difference? Both are not out.

maybe there will be a difference.

Destiny 2 same res and frames

Bloobers’s game - observer. Rebuilt from the ground up for next gen they say. Same res and frames. And blooper is making an Xsex exclusive so they should know how to use that power.

Those are multiplats and for destiny cross gen. Exactly the kind of games Xsex is supposed to “eat for breakfast” lol.
 
Destiny 2 same res and frames

Yes, crossgen.

Bloobers’s game - observer. Rebuilt from the ground up for next gen they say. Same res and frames. And blooper is making an Xsex exclusive so they should know how to use that power.

Indie Launch game. Did they also say that the loading times are the same? And there are no elevator-scenes on XSX? lol

Let's wait until big AAA non-crossgen/launch games arrive to make a judgement, okay?
 

sinnergy

Member
Treating GPU memory (GDDR6) as a virtual disk? I thought the idea was a 100GB of the SSD was virtual RAM?
Who knows how it works ... they didn’t explain that part .

maybe it maps addresses right over from the GDDR 6 to the SSD so it sees only a 100 GB pool and serves what’s needed on screen in time to the 16 GB VRAM automatically.

and maybe it works totally different. We won’t know until we have a deep dive.
 
Last edited:

Leyasu

Member
Dunno, you tell me how long.

We'll see after today.
What is it with people on here that talk about things definitively, then try and turn the question when asked what they are basing things on? It’s like a school playground debate with certain people on here.

Anyway, I am basing my expectations on how previous gens have played out.

The first year to eighteen months the games are mostly shinier previous gen games because of dev time and late access to dev kits. Unless of course the dev environment for the ps5 was already in a mature stat complete with dev kits in late 2017 early 2018....
 

Ar¢tos

Member
Yes, crossgen.



Indie Launch game. Did they also say that the loading times are the same? And there are no elevator-scenes on XSX? lol

Let's wait until big AAA non-crossgen/launch games arrive to make a judgement, okay?
You realize this discussion will never lead anywhere? (at least for 2 years)
Crossgen games are not suitable for comparison by your standards because.... They are crossgen.
1st party games aren't suitable for comparison because they don't run on both platforms.
That limits to 3rd party multiplatform games that are next-gen only, but... THERE WILL BE NONE. Install bases are too small the first 2 years to justify development cost for nextgen only, and the few 3rd party next-gen only games will be platform exclusives because they are done on contract with either Sony or MS.
 

ToadMan

Member
Yes, crossgen.



Indie Launch game. Did they also say that the loading times are the same? And there are no elevator-scenes on XSX? lol

Let's wait until big AAA non-crossgen/launch games arrive to make a judgement, okay?

Care to list a few of those non-crossgen AAA launch games for Xsex? That’s the whole problem - there aren’t any.

Meanwhile, the cross gen multiplats are exactly the games Xsex was supposed to be better for (just take a browse through this thread) while waiting for years for MS to produce it’s anaemic 1st party line up.

If you hadn’t noticed - that indie exclusive is 50% of the exclusives xsex is going to have at launch. There are only 2 announced

If you’re going to shit on those games then you’re basically shitting on the whole console - well done, you’ve caught up with the rest of us in pointing out MS is proposing to offer a premium console with zero 1st party exclusives and what looks like no decent 3rd party exclusives either.

The Xsex marketing - “worlds Most powerful console” - is translating to same FPS and res in multiplats. How is that supposed to push Sony to do better with their stuff?
 

ToadMan

Member
Unless of course the dev environment for the ps5 was already in a mature stat complete with dev kits in late 2017 early 2018....

Supposedly PS5 was shaping up to be a 2019 console so it may well be dev kits have been around since 2018.
 

Psykodad

Banned
What is it with people on here that talk about things definitively, then try and turn the question when asked what they are basing things on? It’s like a school playground debate with certain people on here.

Anyway, I am basing my expectations on how previous gens have played out.

The first year to eighteen months the games are mostly shinier previous gen games because of dev time and late access to dev kits. Unless of course the dev environment for the ps5 was already in a mature stat complete with dev kits in late 2017 early 2018....
What answer do you want to have?
A lot of the time, long development cycles include development of the game engines, which some of Sony's studios already have. That time can already be cut, which cut save them what? 1-2 years?

If let's say HZD2 already started development 3 years ago, when the first reports about it came to surface, and supposedly it's development was shifted to PS5 2-3 years ago, it isn't far-fetched that they might have it ready next year. Possibly Q1 2021 going by recent rumors.

Sony also had little announcements in recent years and they have enough studios that have been working on the down-low.

When we get games like COD every year, that had 2-3 years of development time, what makes you say that Sony can't have PS5 titles ready by the time PS5 releases? Especially if they aim for technical showcases rather than fullblown AAA titles.

Not to mention that UE5 is designed to drastically cut development time, which doesn't make it seem unreasonable to assume that Sony 1st party has developed similar techniques with similar results.
 

Ar¢tos

Member
Sony can only wish they could have a hidden IO handler in the power brick!
But they did! And a hidden dGpu in the controller under each analog stick.
How else would Destiny 2 run at 4k@60 on ps5 too since the XSX is astronomically more powerful?
PS5 shouldn't be able to run it above 1440p with that whole 18% difference.
 

SaucyJack

Member
It seems my earlier post was deleted as the moderation team was unable to distinguish mocking of misterxmedia from console warring 🤷‍♂️.
 

Paracelsus

Member
It seems my earlier post was deleted as the moderation team was unable to distinguish mocking of misterxmedia from console warring 🤷‍♂️.

To be fair the Sony astroturfing has reached levels of terrorism, they're literally scaring people.
We're approaching "ampere is doomed, you need 4080ti or RDNA3 and Zen 4 plus 64gb of DDR6 ram and nvme 12 GB/s to run PS5 games".
After tonight, it's going to be even worse.
 
Last edited:

Shmunter

Gold Member
To be fair the Sony astroturfing has reached levels of terrorism, they're literally scaring people.
We're approaching "ampere is doomed, you need 4080ti or RDNA3 and Zen 4 plus 64gb of DDR6 ram and nvme 12 GB/s to run PS5 games".
After tonight, it's going to be even worse.
Hehe, amusing.
 

Kenpachii

Member
NO you dont understand, supersampling from very high detail to lower is about quality of pixels that results in, thats why movie quality assets look amazing even at 720p.

Its not about native resolution, that is the point to be learned from the UE5 Demo demo, 1440p upscaled looks better than native and lower quality by a long shot.

To take it to extreme, go look at a PC game playing old console games in 4K, its not about the native resolution is it.

If you want to brush the quality of assets vs resolution understanding to the side as itsjust a demo, please do, you know sony will push high quality assets tomorrow so get used to it, its along generation.

Also god war and HZD were 46 GB, add kraken compression, remove all dublicates which is allot, disks now 100/128 GB and there you have it, good luck does not come into it, Sony will push assett sreaming and leverage the SSD IMO.

Quality difference from 4k > 8k textures is absolutely abysmal.

4k vs 8k textures, honestly nobody is going to notice it.



NO you dont understand, supersampling from very high detail to lower is about quality of pixels that results in, thats why movie quality assets look amazing even at 720p.

Its not about native resolution, that is the point to be learned from the UE5 Demo demo, 1440p upscaled looks better than native and lower quality by a long shot.

Yea 128k resolution textures probably also look amazing, guess why nobody does it? for 720p display other then petabyte storage solutions movies use? there you go.

Higher quality textures are always better then lower quality textures. A better car is always better than a worse car. but if that worse car does 99% of what the better car does at a tenth of cost there you go.

And that's exactly the issue here.

To take it to extreme, go look at a PC game playing old console games in 4K, its not about the native resolution is it.

This logic is completely useless a 400p last last gen texture is always going to look like 400p shit tier quality texture, we are talking about 4k vs 8k textures or 2k vs 8k textures. a resolution that sits at far higher then 400p texture is also going to show obviously all the limitations with it, go call me when that PS5 is booting 32k resolution. sure the 8k texture would pop better then at 150 inch screens.

Consumers today have 4k screens, anything above 4k texture wise is useless no matter how you spin it really. its simple idiotic allocation of resources for absolute no reason. This is why tech demo's exist. they do exactly that, idiotic ways of pushing stuff to showcase what its capable off not to showcase what will happen.

I bet if they reduced those 8k textures to 4k nobody would have noticed it. Why didn't they do it? tech demo.

ou want to brush the quality of assets vs resolution understanding to the side as itsjust a demo, please do, you know sony will push high quality assets tomorrow so get used to it, its along generation.

They can do for some objects like character models in closed environments with less detail, but most of the objects much like today will be of lower resolutions textures because of the reason memory and storage space. Simple math will showcase u why as i explained already. They already do that currently on consoles also even uncharted etc have low res textures and god of war even lower then 1080p to not blow their budgets. This aint going to change.

Also god war and HZD were 46 GB, add kraken compression, remove all dublicates which is allot, disks now 100/128 GB and there you have it, good luck does not come into it, Sony will push assett sreaming and leverage the SSD IMO.

Duplicates will shave off some disc size for sure, kraken compression hasn't been proven yet to what it does but frankly will both migrate the abnoxious higher requirement for 8k textures like u saw in the EU5 demo demonstrated? nope not even close.

What sony first party does is whatever really, they could make there next flag ship game around PS2 hardware because that's simple where they get paid for to do. however for 3rd party developers will they bother with being able to push a few better textures at some locations or will they just cut off towards 4k textures and call it a day because more devices have to run it anyway? yea there you go. and that's exactly where file sizes also come into play.

Current games are ~90gb big with some already moving up to 150gb, and those are around 4k textures at best. want to up that even more? yea good luck with that. Also PS5 disc size is 100gb. Pretty sure they will have to install those games anyway towards the main drive and i would not be shocked if you go digital it needs extra space to store + install after it. Because they will have to compress it in order to keep the file sizes small enough. Which will also lock more space away from that SSD.

Look u can believe in the PS5 all u want. All i see is a tiny increasement in texture quality that will be unnoticable by players and a bit faster loading times because that's what the speed simple does if games even allow to utilize it. While console loading times are obnoxious currently. PC loading times even with a simple SSD hasn't been a issue for ages now. Will games get more complex? sure. Do we need faster SSD's? lol nope. The longest loading times i have in games is waiting on connections and that's about it.

The SSD in the PS5 is made for first party developers to make there life more easier on this i agree with anybody else on this front. However for 3rd party developers they will still have to ship on xbox and PC so why bother focusing on PS5 SSD performance and build a game around it? exactly they won't.

Funny enough what people should be more discussing then the textures and loading speeds and SSD performance is why that EU5 demo that practically was a single character walking through death scripted environments ran at 1440p and barely playable frame rates. Remember when people claimed that the zen 2 cpu make 60 fps possible without effort? like all those i/o / kraken / ssd sony fanboys claimed a few weeks or months ago because it was just the jaguar that hold them back? that CPU would just magically render double the framerate without GPU involvement? boy o boy they got hit out of that delusion faster than light it seems like. Why is nobody discussing the barely playable framerate and only 1440p in a next gen box that is supposed to run 4k and 60 fps minimums? Not even a GPU twice the performance would probably pull it off.

Now realize why i said earlier on GPU is all that matters? bingo. Guess why cerny overclocked that GPU to 2,2ghz and why xbox pushes a 12tflop gpu forwards? because they know.
 
Last edited:
Top Bottom