Do we have something more concrete? A developer source?
Michael (NX Gamer) has been working as a software & hardware engineer for a long time and is well versed.
-
Ever wanted an RSS feed of all your favorite gaming news sites? Go check out our new Gaming Headlines feed! Read more about it here.
NX Gamer: PS5 Full Spec Analysis | A new generation is Born
- Thread starter Equanimity
- Start date
Michael (NX Gamer) has been working as a software & hardware engineer for a long time and is well versed.
Yeah, I think so too.
On a side note, I think for standby, or for the 'optional' low power standby mode Jim Ryan talked about last year, the OS may work more or less entirely against the SSD and it's SRAM. One of the SSD patents talked about that, for a reduced power standby mode. You don't have to keep feeding power to the DRAM in that case while in standby.
But if the full OS running in background isn't more than 3/4GB wouldn't that be enough? At least today consoles reserve that amount of ram for os. And maybe not the full OS needs to be loaded, just a small part would be stored in ram( basic console function and security, 500MB or 1GB), freeing most of it for gaming, but not essential parts of OS like trophy notification or UI when you press PS button doesn't really matter if it needs one second to load.
Just speculation, no tech guy at all
What's the background of the Digital Foundry team in comparison? I assumed they were the same.
So what kind of things will the SSD let devs do, gameplay wise? Faster swinging for Spidey for sure and a lack of tunnels and walking scenes, but what else? Will a Flash game finally be possible?
Faster background streaming of assets which was a problem for alot of games and caused performance issues
I sometimes ask that myself. They are journos so get some info not available as average user for sure, but they started counting pixels and vegetation density early in the ps360 era and went popular, but not sure they have more technical knowledge that people that already post in forums like this.
Last edited:
It's like no one watched the video, or maybe no one was paying attention to what Mark Cerny was saying.
Probably way after people realize that storage does not compute.
Interesting take from NX gamer, but where is he getting this info that games will get 15.5gb of vram, and the OS will be cached to the SSD? I didn't get that take away from Cerny's speech. He would have gloated about it if they could do that. It sounds like more of a pipe dream.
Also, his takeaway that the SSD speed will somehow make up for raw GPU power is something else. Under no circumstances will a faster SSD let the system render more things on screen. What it can do though, is allow the system to stream in assets faster.
Also, his takeaway that the SSD speed will somehow make up for raw GPU power is something else. Under no circumstances will a faster SSD let the system render more things on screen. What it can do though, is allow the system to stream in assets faster.
Yes, exactly this. The point i am making is the OS remains resident with the Kernal thread, system calls, base UI and notifications etc but all the heavy static data can be offloaded to a SSD Cache. This could take a 3GB OS (as in PS4/X1) into a 1-1.5GB OS instead resident in ram, the core I/O design and latency system means this and many other options are reality now. I will be very interested to see the OS details as to how thye have designed it and are going to use, i suspect something fancy here.
Not sure what you are saying here, but do you mean that Developers need to Choose the speed/frequency of the CPU/GPU for their game at runtime or dynamically?
Just for clarity I am almost 100% sure that is not accurate or what you are alluding to.
So, I never said that (game will get 15.5GB), I stated an example (best case/theory) what I am alluding to here is that with the speed and construction of the system this, and other options, are possible to enable the core kernal, tasks, UI to remain resident and static data to cache. So rather than 3GB of OS, it only used 1-1.5GB of OS when the game is running and then swaps back when home is pressed.
Also, please do not put words in my mouth, I never said that a fast SS replace the GPU. I said that the SSD and I/O contrsuction alongside the other benefits means that when a game is dense with objects, streaming information in the stutters, cache misses, hangs etc etc will be reduced. It will likley always be at a slightly lower resolution (as I cleary state in the video) on the PS5 but to think that all slow down, stutters and hangs are all GPU bound is niave at best or intentially distracting the narrative at worst.
Last edited:
Can anyone more knowledgeable expand on the memory differences between the two? As far as I'm aware, PS5's SSD allows it to use north of 15 GB of the system memory while saving a snapshot of the OS onto the SSD while the XSX only has around 13GB of system memory for games. Now I imagine this obviously won't impact image quality, where the XBX should be comfortably ahead, but this combined with blazing fast asset streaming should allow 1st Party games to do some pretty amazing things on the PS5.
as an enterprise engineer working in enterprise tech, seeing people that cannot differentiate their bits from bytes and their float from integer and focusing on the teraflops number as the be-all-end-all benchmark measurement of a system performance is laughable and nostalgic...reminds me of the playground bickering i had in the 90s during the 'bit wars'..............Good times.
Storage might not compute but it was by far one of the biggest bottlenecks of this generation alongside the jaguar cpu's. I think it's time that people stop downplaying it and start accepting that this crazy leap in speed will amount to more than just a single second difference in load times when compared to the XsX.
Actually, resolution is not the only thing that impacts image quality. Stuff like higher quality assets and especially having more of them (also for distant objects) should drastically increase the perceived image quality. The SSD should help with streaming in those assets.
Devs will choose whether they want full Power to gpu or full Power to CPU where one or the other underclocks below the listed spec. So a game to game Basis. I imagine most cross gen games will choose to prefer higher clocked gpu Mode as they will be gpu bound even if the Zen cores are underclocked. Zen just runs around the Jag that most cross gen games are not going to worry about CPU time, especially 30 fps games.
That is how it works.
There has to be a middle ground because on the other side people are uptalking the SSD (while the competitor actually also has an SSD) like crazy. Add to that, bandwidth is only one metric when it comes to storage, the other one is latency which is the main benefit an SSD has to HDD in general, not necessarily the bandwidth, even Cerny said as much. So please stop this black and white thinking. One has a compute advantage and memory bandwidth advantage, the other has a storage bandwidth advantage.
You mean the can prioritise the frequency to GPU or CPU IF it becomes constrained beyond the ceiling level of the capped rates. This is exactly what happens now, to have a dual mode option for develoers to choose from (ala Switch) is not new but I will be interested in seeing this option and just what the delta's are. Thanks for sharing this which I assume came from a Dev source then?
Basically you target and say I want full GPU and the CPU underclocks so the Power Budget keeps the GPU clock high. The Power that would have been CPU Reserved goes over to the GPU to keep it's clock more stable, and since the CPU is now lower clocked, the more intense utilisation or instructions will not tip the Power Balance - well, that is for a game that is also not Absolutely thrashing both.
indeed this Info comes from people who work on the Thing.
Basically, if the Gpu is at 10.2 TF, the cpu is not at 3.5 GHz.
Cerny said all this on stage basically, just not in the most direct way. The only reason to mention smart shift is if this happens, just like it does on smart shift.
One side is uptalking the SSD, the other is downplaying the 100% difference in SSD speed while uptalking a 15% difference in compute power.
Alot of people should just take a step back and stop posting for a while I think.
But the advantage is different in each area. Compute advantage is around 15/16% , that without considering potential advantages of higher clocks that may slightly offset that % in certain scenarios.
Bandwidth advantage is there, but since there are less TF maybe it's not needed so much since GPU is slightly less capable, and besides that not all memory is faster, just 62% of it, the rest is slower.
On the other side, ssd advantage is much bigger in percentage, it is not 15/20% faster, it is much more than that. If that matters time will tell, but while seems obvious that XSX is more powerful, around 15/20% at most, but if the ssd bet turns into tangible results, then the advantage there would be sensible.
We also miss the most important, price, that will put everything into context here. If same price, i think XSX on paper seems the better deal (at least until Sony proves his approach makes sense).
If one is cheaper than the other, well, that responds for itself.
They won't and they should not, just that this is not a black and white discussion, no matter what the percentages say, especially when they are not even comparing the same thing.
That is exactly what Cerny alluded to. From what I understood though, the drops in say frequency when CPU is maxed shouldn't be substantial. He talked about 2-3% drop in frequency for 10% drop in power to the GPU didn't he? Remains to be seen how that holds up.
We are going to be asking devs about System Reserved amount for ram and what exactly the CPU or gpu clocks are in each Mode.
I do not think it will have a decidedly different RAM Reservation for the OS. SSDs do not have random access latency like RAM, we use RAM for a reason.
Can you make a guess about theoretical underlocks if devs prioritize CPU or GPU?
I agree with the latter part of your post. Not sure I agree with the first part though. There's alot of people making strongly opinionated yet uninformed posts because they want their box of preference to be on top. I think there would be a better discussion to be had and could discuss the advantages of both systems in a more constructive manner without those that downplay everything of the box they aren't interested in.
Having said that I know fully well that those people aren't going anywhere nor will they stop posting.
So that's exactly why this SSD could be used as a kind of RAM memory just for some functionalities, yes, but in the end, you could. And that's the point. Until now, this was something literally impossible: Jumping over the step of loading some kind of data on the RAM memory and doing it directly from an SSD. What this means in terms of performance still remains to be seen, of course. But it might be something. If we pass by the forums and pretend to be minimally experts in hardware matters (which generally we are not, even those who try their hardest to pretend it) whe should, at least, consider this is something and not ignore it as if it was bullshit. THAT would be ignorant, in fact.
Yes, so you allocate a power/frequency budget target, that is as expected and is standard, the fluctuation levels of hardware are constant anyway. I will be interested to see the ratio they are working with as you are making it sound they chose to "effectively" down-clock the CPU below 3.5GHz, let's say 3GHz for example so that at this level the GPU is always at full capacity, this kind of locked state is quite odd as it will leave resource potential of the table, much like Dynamic resolutuon scaling makes best use of the constant fluctuating needs a GPU has, leaving these to self regulate makes the most sense. For Sony to lock this down at runtime for the devs, as you are saying, is a very odd choice indeed even if this will rarely cause an issue it wastes performance OR means the Thermals are still an issue.
There really is some interesting tech inside the consoles and just yesterday I asked DF people if they could shed some light on the differences between the lossless compression asics and the respective algorithms these asics implement, Kraken vs BCPack and Zlib but it seems no one wants to have that discussion as it seems to be too technical and unpopular. It seems more interesting to go the "simple math path" and trying to construct edge cases where one console could outperform the other, all done by actual arm chair devs.
Since 2.23 is the cap for the GPU and 3.5 is the cap for the CPU, with Cerny having said that it only takes a drop of a few % in clock speeds to drop the power draw by 10%... I can't imagine that either the GPU or CPU would clock down by very significant numbers right?
I'm very interested in knowing what the bottom is for either the CPU or GPU for the other to run at full speed.
Except when that storage is made to be used as a literal performance booster.
Storage does not compute, for instance, on PCs, when it is not designed to help increase the general performance of a system. On PCs it is used just as, that, storage, and therefore, the only thing that storage can do for you is reducing loading times.
This is not the case. Maybe you will end up understanding it. That doesnt seem feasible, though.
for games that will require full power from both gpu/cpu i guess they would drop the 2% or more to be around 10tf and keep the cpu as close to the 3.5ghz.
It is also very interesting approach, because early PS5 units will not be able to keep 3.5 ghz CPU and 2.23 ghz GPU, but later revisions will probably have more stable chips and improved cooling. Can we witness another Xbox One/Xbox One S situation?
Yeah I personally would love to see stuff like that being discussed by those with actual experience on the matter. Even if that means I might not completely understand whatever is being discussed. It's always fun to learn. It's hardly any fun to see people battle about numbers they probably don't even understand.
Maybe some basic function can be offloaded and called back when user requests it. For eg I'm preeeetty sure when you suspend/resume multiple games on SX, their entire memory state is offloaded to SSD wholesale, and loaded back when you switch to them. The SSD tech in SX is no slouch either.
false, the chip quality doesnt have an effect (but it will on production for sony)
So you think theres a possibility that when all is said and done, we will have 500BG +- for game installations/Gallery ?
It's going to be very interesting to see what devs choose to go for and it will most likely depend heavily on the type of game they are making.
Making a game that is both CPU and GPU intensive? - - > CPU at 3.4 and GPU at 2.15
GPU intensive game? - - - > CPU at 3.3 and GPU at 2.23
CPU intensive game? - - - > CPU at 3.5 and GPU at 2.10
I imagine it will be something like this. Ofcourse I pulled the numbers from my ass so it's going to be interesting to see what the actual numbers are.
Probably around 700GB, but this time storage should be used better, there shouldnt be storage that you cant install on this time because there is no "copying" process.
That's why storage was a major point for MS in planning their new console while not forgetting the actual compute units. They made their velocity engine, made an asic for Zlib and BCPack realtime lossless compression, used an SSD that guarantees sustained bandwidth rates and developed directstorage.
On the other hand, it also helps on PC to help computing units but it does never compute in any case, at least not contributing to the actual load of a PC or console, while its controller can save up CPU cycles. Microsoft explained how their custom lossless compression ASIC saves CPU cores.
I don't want to jump into the arguments but I'm a software engineer by trade with more than 10 years experience working in the automotive industry. I only switched to doing DF stuff when we left for Europe as it was a chance to do something I was more passionate about. Definitely NOT a journalist by training at all but we have one of the best ensuring that THAT side of things gets done right.
I will say, what Alex is alluding to in this thread is based on discussions with multiple people doing actual work on this box so keep that in mind...
Good lord, dude, you can't ask yesterday and expect content immediately. Even if we were to jump right on it, it takes a lot of time to create that video! I think that's a technical topic that should occur when we have real data from software that can illustrate the differences.
New thread worthy imo, because there is a lot of misconception that it doesn't work like that at all.
Sorry, I didn't get an answer back so thought it was lost or ignored. I am not demanding anything, I even asked elenarie but of course that person is under NDA so that was expected. A simple "we might look at it" would have been sufficient but hearing nothing indicates a "nope, won't do".
That's not news though, Cerny said it right away. He also said that "in that worst case scenario" a 10% reduction in power on one of them would only drop a few points in the clock, so they expect that to be almost unnoticeiable.
I didn't see it here, though, to be honest. The sheer volume of replies and questions people have been throwing towards us makes it tough to respond to anything. Only this morning is it quieting down! It's all good, though.
I think it doesnt work like that. They are monitoring transistors occuped in cpu and gpu continously while running max clock in both. If they reach an occupancy point (for example all the cus and registers busy) is when the smartshift enters in the game reducing cap clock from cpu or gpu.
For example: a real time scene from Uncharted takes 95% of transistors in both cpu and gpu. They have a profile and know that with that occpancy they are over the 220 watts cap of the cooling solution, so they start downclocking. And that scene will hit that point in all PS5s out there.