Support NeoGAF

[Ascend]

What's with the clickbait headlines...? Are websites sad that their traffic dropped now that the whole human malware thing is blowing over..?

 

[RaySoft]

I get your point and I agree, but his comment there was probably directed to people comparing Intel CPU's againt AMD ones. Different functions and optimizations. Rarely is one maker best in ALL circumstances.
On the XSX and PS5 though, they both use Zen2 cores. We don't know 100% yet if either MS or Sony has tweaked any transistors yet, but probably not.
So if both CPUs are the same block, you could compare speeds. The point is though that with both having SMT on (all cores have two threads) the XSX (and Lockhart) has 100MHz advantage on paper over the PS5's CPU
But as I said elsewhere, those 100MHz is nothing in the grand scheme of things. People just reads papers and levitate towards the higher number without understanding it.
I'm quite certain that more than that 100MHz are already eaten up by the fact that the CPU on MS's consoles has more "housekeeping" duties than the PS5's CPU. So there... enjoy those paper 100MHz

 

[Elog]

3.5 Ghz vs 3.6 Ghz
10.2 tflops vs 4 tflops
5.5 GBps vs 2.4 GBps

And this is the article they run with....

And two of the big tasks that a CPU does on a console are I/O and decompression which on the PS5 has dedicated silicon (i.e. it opens up a significant amount of capacity for the CPU to do other things). The article is ridiculous.

 

[Shmunter]

Okay, that isn't really explaining his thought process in that tweet though. As for audio, both systems have dedicated audio processors. PS5's Tempest may be a bit more powerful but it's nothing offloading some work to a single CU via asynchronous programming can't match on the Series systems (and that's assuming there isn't more to their audio setup which has yet to be mentioned).

Tempest still requires devs to make sure they watch the bandwidth, or it can utilize up to 20% of the memory bandwidth (~ 90 GB/s) in some instances. And beyond that there's still the matter of bus contention as when Tempest is addressing the bus other components have to wait their turn. Like with the SSD I/O differences between the systems this is something of a benefit to the Series systems because if some bit of CPU (I/O) or CPU/GPU (audio) are handling the communication, then game logic that is CPU or GPU-bound can still access the bus simultaneously instead of needing to wait.

They're all trade-offs at the end of the day.



Read the response above. Both systems have dedicated hardware for both audio and I/O. One just has a bit moreso in that respect (PS5).

Again though, each approach as their benefits and trade-offs, as I also indicate in the above reply.

Totally not true at all. Xbox Series Also has the ability to offload cpu dependent tasks to the I/O ,custom sound chip and ray tracing. Where are you guys getting your information from?

Tempest being able to chew through 20gbs of memory bandwidth is an indicator of the sizeable computing power of the chip. XsX has no equivalent of such a chip.

XsX I/o has hardware decompression, but all other aspects of getting data in and out of ram is via the cpu on XsX, whereas on PS5 the entire I/o pipeline is handled by bespoke hardware.

There’s really not much more to it, all info is official.

 

[Dave_at_Home]

I've heard plenty of rumors saying the PS5 CPU has a single CCX, but it's also possible for Series X to have the same I suppose. It does seem, overall, that the PS5 has more things offloaded from the CPU due to its I/O capabilities, but even if it's exactly the same as Series X in terms of what the CPU does and doesn't do; than it really doesn't matter cause a 100 MHz difference means absolutely nothing.

 

[tsumake]

Does it make sense to release different hardware SKUs of console at the same time? What is the rationale?

 

[thicc_girls_are_teh_best]

Tempest being able to chew through 20gbs of memory bandwidth is an indicator of the sizeable computing power of the chip. XsX has no equivalent of such a chip.

XsX I/o has hardware decompression, but all other aspects of getting data in and out of ram is via the cpu on XsX, whereas on PS5 the entire I/o pipeline is handled by bespoke hardware.

There’s really not much more to it, all info is official.

It's not 20 GB/s, it's 20%. Which is about 90 GB/s (89.6 GB/s exactly). That bandwidth figure is basically because Tempest is a repurposed CU designed to act like an SPE. It's nice to have, but there's no negative to not having something like that in a console design, either. And as already stated, there are big tradeoffs in terms of bus contention with that setup.

PS5 has a bigger issue with bus contention compared to the Series systems because the dedicated processor in the I/O block and Tempest still have to share the bus with the CPU and GPU, that's what hUMA architecture is about. The Series systems still deal with bus contention too but not to as big a level primarily because some of the taskwork is still handled through parts of the CPU and GPU allowing game code bound to those chips to run in parallel simultaneously.

Yes, the Series systems use 1/10th of a CPU core (the same core the OS resides on) for handling transfer operations of data between storage and RAM. Again, though, that comes with a side benefit: game logic that's CPU-bound still gets to access the bus simultaneously during that type of operation. You can't do that on PS5 because they place entire operation of that nature to the dedicated processor in the I/O block. Each approach obviously has its advantages but I don't think some people realize the compromises of PS5's setup when they should be somewhat easy to realize.

It's the same thing with the cache coherency engines; the dedicated processor in the I/O block requires them so that operations can work and sync properly between it and the CPU. It's a requirement more than a pure efficiency benefit, but it brings efficiency benefits to Sony's design regardless as a result of being there. If the cache coherency engines weren't there the I/O block's functionality would be completely gimped, but that's because of Sony's implementation. Lack of cache coherency engines with MS's solution doesn't mean theirs is gimped or even compromised in such a way, as the root of their design never actually required them.

A good deal of aspects between both systems are as much apples-to-oranges as they are apples-to-apples.

I've heard plenty of rumors saying the PS5 CPU has a single CCX, but it's also possible for Series X to have the same I suppose. It does seem, overall, that the PS5 has more things offloaded from the CPU due to its I/O capabilities, but even if it's exactly the same as Series X in terms of what the CPU does and doesn't do; than it really doesn't matter cause a 100 MHz difference means absolutely nothing.

It's a 166 MHz difference with SMT On, and that's also assuming PS5's CPU is at peak frequency. In Cerny's 2% (optimal scenario) frequency drop case, that would bring the CPU down to 3.43 GHz. With SMT Off, there's a 366 MHz difference between PS5 and the Series systems (and again that's with PS5's CPU assumed at peak frequency).

The GPUs need to have their instructions sent through by the CPUs, so the faster the CPU in that aspect, the better. That's a reason the current-gen systems struggled with 60 FPS; the CPUs couldn't keep up. So even if that MHz difference is smaller than the MHz difference in the GPUs, it still matters.

Otherwise if the MHz difference in the CPUs "means absolutely nothing", that might as well render the GPU MHz difference to "absolutely nothing" since the GPUs need the CPU to send them their instructions (traditionally).

 

[Shmunter]

It's not 20 GB/s, it's 20%. Which is about 90 GB/s (89.6 GB/s exactly). That bandwidth figure is basically because Tempest is a repurposed CU designed to act like an SPE. It's nice to have, but there's no negative to not having something like that in a console design, either. And as already stated, there are big tradeoffs in terms of bus contention with that setup.

PS5 has a bigger issue with bus contention compared to the Series systems because the dedicated processor in the I/O block and Tempest still have to share the bus with the CPU and GPU, that's what hUMA architecture is about. The Series systems still deal with bus contention too but not to as big a level primarily because some of the taskwork is still handled through parts of the CPU and GPU allowing game code bound to those chips to run in parallel simultaneously.

Yes, the Series systems use 1/10th of a CPU core (the same core the OS resides on) for handling transfer operations of data between storage and RAM. Again, though, that comes with a side benefit: game logic that's CPU-bound still gets to access the bus simultaneously during that type of operation. You can't do that on PS5 because they place entire operation of that nature to the dedicated processor in the I/O block. Each approach obviously has its advantages but I don't think some people realize the compromises of PS5's setup when they should be somewhat easy to realize.

It's the same thing with the cache coherency engines; the dedicated processor in the I/O block requires them so that operations can work and sync properly between it and the CPU. It's a requirement more than a pure efficiency benefit, but it brings efficiency benefits to Sony's design regardless as a result of being there. If the cache coherency engines weren't there the I/O block's functionality would be completely gimped, but that's because of Sony's implementation. Lack of cache coherency engines with MS's solution doesn't mean theirs is gimped or even compromised in such a way, as the root of their design never actually required them.

A good deal of aspects between both systems are as much apples-to-oranges as they are apples-to-apples.



It's a 166 MHz difference with SMT On, and that's also assuming PS5's CPU is at peak frequency. In Cerny's 2% (optimal scenario) frequency drop case, that would bring the CPU down to 3.43 GHz. With SMT Off, there's a 366 MHz difference between PS5 and the Series systems (and again that's with PS5's CPU assumed at peak frequency).

The GPUs need to have their instructions sent through by the CPUs, so the faster the CPU in that aspect, the better. That's a reason the current-gen systems struggled with 60 FPS; the CPUs couldn't keep up. So even if that MHz difference is smaller than the MHz difference in the GPUs, it still matters.

Otherwise if the MHz difference in the CPUs "means absolutely nothing", that might as well render the GPU MHz difference to "absolutely nothing" since the GPUs need the CPU to send them their instructions (traditionally).

Your sourcing wrong info on tempest ability to process data. Officially it’s capable of processing in excess of 20gbs.

Irrespective, the higher the max potential allocation, the higher the compute which I’m sure you’ll agree means more processing ability. It also means more parallel processing potential ironing out stalls and unused cycles by other processors.

The tiny cpu usage on XsX as far as I/o I’m calling marketing double speak. If software is so hugely inefficient today that such high optimisation is available, the entire industry has been asleep at the wheel - possible but highly unlikely. Under full load I’m calling 2 full zen 2 cores for I/o on XsX.

Cache scrubber are well understood to provide harmony and efficiency for purpose or refreshing ram from the ssd memory subsystem without unnecessarily blowing away parts of cache. Preserving the cache in harmony with the ssd allows cache to do its thing, no need to read parts of ram wasting time and bandwidth when it’s not necessary. Absolutely a huge benefit in a system where streaming assets is a focus. Think that’s confirming what you’ve said.

 

[Dave_at_Home]

It's not 20 GB/s, it's 20%. Which is about 90 GB/s (89.6 GB/s exactly). That bandwidth figure is basically because Tempest is a repurposed CU designed to act like an SPE. It's nice to have, but there's no negative to not having something like that in a console design, either. And as already stated, there are big tradeoffs in terms of bus contention with that setup.

PS5 has a bigger issue with bus contention compared to the Series systems because the dedicated processor in the I/O block and Tempest still have to share the bus with the CPU and GPU, that's what hUMA architecture is about. The Series systems still deal with bus contention too but not to as big a level primarily because some of the taskwork is still handled through parts of the CPU and GPU allowing game code bound to those chips to run in parallel simultaneously.

Yes, the Series systems use 1/10th of a CPU core (the same core the OS resides on) for handling transfer operations of data between storage and RAM. Again, though, that comes with a side benefit: game logic that's CPU-bound still gets to access the bus simultaneously during that type of operation. You can't do that on PS5 because they place entire operation of that nature to the dedicated processor in the I/O block. Each approach obviously has its advantages but I don't think some people realize the compromises of PS5's setup when they should be somewhat easy to realize.

It's the same thing with the cache coherency engines; the dedicated processor in the I/O block requires them so that operations can work and sync properly between it and the CPU. It's a requirement more than a pure efficiency benefit, but it brings efficiency benefits to Sony's design regardless as a result of being there. If the cache coherency engines weren't there the I/O block's functionality would be completely gimped, but that's because of Sony's implementation. Lack of cache coherency engines with MS's solution doesn't mean theirs is gimped or even compromised in such a way, as the root of their design never actually required them.

A good deal of aspects between both systems are as much apples-to-oranges as they are apples-to-apples.



It's a 166 MHz difference with SMT On, and that's also assuming PS5's CPU is at peak frequency. In Cerny's 2% (optimal scenario) frequency drop case, that would bring the CPU down to 3.43 GHz. With SMT Off, there's a 366 MHz difference between PS5 and the Series systems (and again that's with PS5's CPU assumed at peak frequency).

The GPUs need to have their instructions sent through by the CPUs, so the faster the CPU in that aspect, the better. That's a reason the current-gen systems struggled with 60 FPS; the CPUs couldn't keep up. So even if that MHz difference is smaller than the MHz difference in the GPUs, it still matters.

Otherwise if the MHz difference in the CPUs "means absolutely nothing", that might as well render the GPU MHz difference to "absolutely nothing" since the GPUs need the CPU to send them their instructions (traditionally).

Someone needs to explain why any next-gen multi-platform game would utilize Series X CPU with SMT off? If you're only talking about current-gen games, than I suppose that matter, but otherwise...

I feel like people have absolutely run wild with Marks comments on the worst case scenario for PS5 games. Almost as if that will be a constant and we'll see nothing but examples time and time again. On the CPU side of things, these two machines are as close as they could be, and the second someone points this out, they go "well if the PS5 CPU needs to downclock, THIS will be the difference!" I just can't help but roll my eyes. Also, I thought the PS5 CPU was 3.5 and Series X was 3.6 (both with SMT of course), no?

 

[Dave_at_Home]

Your sourcing wrong info on tempest ability to process data. Officially it’s capable of processing in excess of 20gbs.

Irrespective, the higher the max potential allocation, the higher the compute which I’m sure you’ll agree means more processing ability. It also means more parallel processing potential ironing out stalls and unused cycles by other processors.

The tiny cpu usage on XsX as far as I/o I’m calling marketing double speak. If software is so hugely inefficient today that such high optimisation is available, the entire industry has been asleep at the wheel - possible but highly unlikely. Under full load I’m calling 2 full zen 2 cores for I/o on XsX.

Cache scrubber are well understood to provide harmony and efficiency for purpose or refreshing ram from the ssd memory subsystem without unnecessarily blowing away parts of cache. Preserving the cache in harmony with the ssd allows cache to do its thing, no need to read parts of ram wasting time and bandwidth when it’s not necessary. Absolutely a huge benefit in a system where streaming assets is a focus. Think that’s confirming what you’ve said.

Cache scrubbers are still something I'm not exactly understanding. I've read things about them increasing CU occupancy, so does this aid in the GPU being about to "punch above its weight" sort of speak?

 

[truth411]

I love the implication that SX doesn’t have a hardware based Audio solution as well. Keep spreading that FUD I guess

I never said it didn't. The point is the CPUs are virtually identical. But from what I've seen the audio work is completely offloaded from the cpu in the PS5. You guys creating narratives in your own minds.

 

[thicc_girls_are_teh_best]

Your sourcing wrong info on tempest ability to process data. Officially it’s capable of processing in excess of 20gbs.

Irrespective, the higher the max potential allocation, the higher the compute which I’m sure you’ll agree means more processing ability. It also means more parallel processing potential ironing out stalls and unused cycles by other processors.

The tiny cpu usage on XsX as far as I/o I’m calling marketing double speak. If software is so hugely inefficient today that such high optimisation is available, the entire industry has been asleep at the wheel - possible but highly unlikely. Under full load I’m calling 2 full zen 2 cores for I/o on XsX.

Cache scrubber are well understood to provide harmony and efficiency for purpose or refreshing ram from the ssd memory subsystem without unnecessarily blowing away parts of cache. Preserving the cache in harmony with the ssd allows cache to do its thing, no need to read parts of ram wasting time and bandwidth when it’s not necessary. Absolutely a huge benefit in a system where streaming assets is a focus. Think that’s confirming what you’ve said.

Regarding Tempest and its memory bandwidth, I went back to the Eurogamer article and they do indeed say 20 GB/s so you were right there and I stand corrected. To idea of overall compute...well yeah to some extent it would mean more processing ability. But the effectiveness of that processing capability in parallel depends on a ton of factors.

You have to keep in mind that Tempest is explicitly designed to mimic a PS3 SPE. That's a very different architecture makeup compared to what the next-gen systems are using which is similar in all other aspects. You also have to keep in mind that it's specifically tailored for audio programming work so while it can probably be used in some unorthodox methods creatively (the SEGA Saturn saw its audio processor used for some graphics data in Shining Force III for example)..that really comes down to if a developer A) has a good enough handling on the chip, B) sees a need to bother using it in such a way and C)can leverage the chip in that type of way within the scope of their design.

FWIW, there's a lot of reasons PS3 was seen as difficult to work with and one of them was the way the SPEs were set up. Sony's basically asking developers to re-familiarize themselves with a part of the PS3 architecture, specifically set up that way for audio taskwork and maybe having some flexibility for non-audio tasks. Now one of the reasons PS3 was difficult for devs to leverage was because the idea of utilizing SPEs conceptually was very foreign back then. Today they have much more familiarity with multi-core processors and the such, but it's still going to be an unusual setup and language for them to utilize in ways that are not easily accessible.

Also in terms of that processing power being available in parallel...well yes, it's there in parallel if we're just talking using data on the caches. But from RAM? Again there's bus contention so CPU, GPU etc. have to cede bus access to Tempest Engine when it wants to refresh the caches with new data from the RAM pool.

You're only considering the 1/10th a single CPU core for I/O on the Series systems as marketing doublespeak because you've forgotten that MS does actually have custom hardware for decompression in their systems, too. Some people are taking that to literally mean "only" decompression but that dedicated hardware very likely also has some other I/O related components to it as well. Not as much and/or the same as Sony's, but it's there. There's enough in terms of patents and outright information available (such as the explicit reference to ARM coprocessors in the Series system APUs from an Indian AMD engineer's LinkedIn many months back; most likely that's referring to a customized coprocessor on the GPU similar to some of the Nvidia GPUs with FPGA cores onboard to perform independent instruction tasks, and fits in with expansion of executeIndirect hardware features already present on Xbox One) to suggest and support this.

Yes...those are cache scrubbers. But I'm actually talking about the cache coherency engines, not the cache scrubbers (which are in the GPU). I had to edit my comment because at first I mistakenly mentioned the scrubbers.

Someone needs to explain why any next-gen multi-platform game would utilize Series X CPU with SMT off? If you're only talking about current-gen games, than I suppose that matter, but otherwise...

I feel like people have absolutely run wild with Marks comments on the worst case scenario for PS5 games. Almost as if that will be a constant and we'll see nothing but examples time and time again. On the CPU side of things, these two machines are as close as they could be, and the second someone points this out, they go "well if the PS5 CPU needs to downclock, THIS will be the difference!" I just can't help but roll my eyes. Also, I thought the PS5 CPU was 3.5 and Series X was 3.6 (both with SMT of course), no?

SMT Off will have its benefits. If it didn't, it wouldn't be offered. Not every next-gen game is going to need 16 threads, but could benefit from faster CPU clocks. Some games may also benefit from SMT Off if it means feeding the GPU with instructions faster (though with the Series systems I think MS have added an ARM coprocessor block to the GPU extending off executeIndirect in large part to fulfill this purpose, so a game on a Series device using SMT Off would probably be doing it for increasing rate/speed of CPU-bound game logic).

In terms of that 2% frequency drop, the truth is we don't know how often it will be (or if there will be instances where the drop is larger), but it's safe to say it'll happen enough to consider it as a slightly recurring scenario, particularly as the generation wears on. Just think about it; why even touch on that in a presentation to developers if there wasn't some consideration of it possibly being a somewhat persistent occurrence?

Now what specific programming environments (aside from AVX 256 instructions, which are rare) will bring that about, we don't know. But the fact variable frequency as an approach needed to be taken at all, and that frequency fluctuation is a byproduct of that approach...that signals at least something IMO.

No, with SMT On it's 3.5 GHz PS5 and 3.66 GHz Series X/Series S. Should be in one of MS's blog posts. Granted, MS likes to round down their numbers a lot, they've done the same with the GPU whereas Sony rounds up (actual GPU TF numbers are 10.275 PS5 and 12.147 Series X).

 

[itsjustJEFF]

AND: it is as fast as the XSeX! Why buy the expensive one when the cheap one is just as good?^^

It's easier to reach climax when the numbers is bigger.... LOL

Those with 4K TV's want to be able to take advantage of it. But honestly, I think most "normal" people don't have a 4k TV or monitor. Most gamers probably only game on a 1080p or 1440p TV/Monitor. Targeting 4K has been dumb since the PS3/360 days. I have 4K monitor at home for work purposes. It helps for me to have a much crap on the screen as possible.

 

[Arun1910]

100MHz SUCH DIFFERENCE

 

[anothertech]

Hahaha was very entertained.

And yes Warren is a shill.

 

[anothertech]

Tempest being able to chew through 20gbs of memory bandwidth is an indicator of the sizeable computing power of the chip. XsX has no equivalent of such a chip.

XsX I/o has hardware decompression, but all other aspects of getting data in and out of ram is via the cpu on XsX, whereas on PS5 the entire I/o pipeline is handled by bespoke hardware.

There’s really not much more to it, all info is official.

In November:

Xbox has fastest cpu!!!

DF article: ...and PS5 cpu processing several times the load of the Xbox version due to Tempest...

 

[Shmunter]

Cache scrubbers are still something I'm not exactly understanding. I've read things about them increasing CU occupancy, so does this aid in the GPU being about to "punch above its weight" sort of speak?

On chip cache is the fastest form of storage. The scrubbers tech allow only relevant parts of the cache to be marked invalid instead of the entire cache being blown away when ram is altered.

If the entire cache is deleted each time ram is refreshed then a trip to ram to refresh the cache is needed. If this happens over and over then GPU performance suffers. So conversely leaving as much cache intact as possible means less trips to ram, less GPU stalling waiting for data, higher GPU utilisation.

Last gen and traditional approaches do not have this special tech to deal with cache with such precision and simply invalidate the whole cache when underlying ram is altered.

This tech is especially important to Sony seemingly because they are relying on the potential of ram being refreshed very often when it comes to new gen techniques and the ssd. They needed a solution to allow their vision to come forth without compromising GPU cache performance.

Not sure how or even If XsX has something similar. Someone else can chime in.

 

[Snake29]

100mhz...yes such a generational leap!

 

[chilichote]

Not sure how or even If XsX has something similar. Someone else can chime in.

If that were the case, we would certainly know it. I think i.a. that's what Cerny meant when he said that PS5-Tech may also be used in AMD GPUs due to the collaboration

 

[Bo_Hazem]

Imagine saying that and not knowing that the PS5 CPU is 100% free of decompression (at least) while XSX and XSX has to give half a core of its main CPU (6.25% on XSX) which accounts to nearly double the difference between the two CPU's 2.8% (3.5 vs 3.6GHz) which also takes bandwidth penalty as well.

Some people need to read more, knowledge is a good thing to have.

 

[thicc_girls_are_teh_best]

If that were the case, we would certainly know it. I think i.a. that's what Cerny meant when he said that PS5-Tech may also be used in AMD GPUs due to the collaboration

In truth we don't know if it does or doesn't yet, that's what their August Hot Chips presentation will elucidate on if it's present. As a technological concept, cache scrubbers are nothing new, there have been architecture designs with them for years by now, probably even decades.

But in terms of mainstream game consoles yes, they are an unprecedented feature to have. Whether the Series system have them or not...if they do it'd be likely implemented differently. If they don't, though...then they just don't. At this point there's a lot more evidence pointing to custom ARM coprocessor for GPU instruction duties (to extend executeIndirect performance) on the Series systems than cache scrubbers.

So effectively, they may not enjoy the benefits of cache scrubbers, but the benefits of an ARM coprocessor logic unit for independent GPU calculations comes with its own particular benefits.

Imagine saying that and not knowing that the PS5 CPU is 100% free of decompression (at least) while XSX and XSX has to give half a core of its main CPU (6.25% on XSX) which accounts to nearly double the difference between the two CPU's 2.8% (3.5 vs 3.6GHz) which also takes bandwidth penalty as well.

Some people need to read more, knowledge is a good thing to have.

It's 1/10th of the OS core on the Series systems for I/O stack management, other than that they still have dedicated hardware decompression similar to Sony minus cache coherency engines (which are required for Sony because of dedicated processor in I/O block to maintain system performance stability with that setup). Dunno how you're factoring the clock frequency hit on that, though. It's not like the Series systems suddenly run at lower clock speeds because some of the OS core are handling I/O throughput traffic.

As I was saying before, too, that does still come with a side benefit. It means CPU-bound game logic can selectively access the memory bus during those operations, as long as the game isn't trying to access data that's being actively overwritten, obviously. I don't expect a game to be able to access the bus at the same bandwidth saturation level during this type of operation vs. if no I/O operations from storage to RAM (or vice-versa) were happening. But they'd still have a good amount to work with and every little bit helps.

Shows some of the apples-to-oranges differences in Sony and MS's approaches here, so in those instances is very difficult (almost impossible) to say one approach is just fundamentally "better" than the other.

 

[Bo_Hazem]

It's 1/10th of the OS core on the Series systems for I/O stack management, other than that they still have dedicated hardware decompression similar to Sony minus cache coherency engines (which are required for Sony because of dedicated processor in I/O block to maintain system performance stability with that setup). Dunno how you're factoring the clock frequency hit on that, though. It's not like the Series systems suddenly run at lower clock speeds because some of the OS core are handling I/O throughput traffic.

As I was saying before, too, that does still come with a side benefit. It means CPU-bound game logic can selectively access the memory bus during those operations, as long as the game isn't trying to access data that's being actively overwritten, obviously. I don't expect a game to be able to access the bus at the same bandwidth saturation level during this type of operation vs. if no I/O operations from storage to RAM (or vice-versa) were happening. But they'd still have a good amount to work with and every little bit helps.

Shows some of the apples-to-oranges differences in Sony and MS's approaches here, so in those instances is very difficult (almost impossible) to say one approach is just fundamentally "better" than the other.

PS5 I/O is 11-12x ZEN2 cores equivalent, XSX I/O is 5x ZEN2 cores equivalent according to both official details.

 

[thicc_girls_are_teh_best]

PS5 I/O is 11-12x ZEN2 cores equivalent, XSX I/O is 5x ZEN2 cores equivalent according to both official details.

I've heard 9 Zen2 core figures given by MS in terms of overall I/O performance, and 13 Zen2 cores equivalent I/O performance from Sony.

 

[Dave_at_Home]

In truth we don't know if it does or doesn't yet, that's what their August Hot Chips presentation will elucidate on if it's present. As a technological concept, cache scrubbers are nothing new, there have been architecture designs with them for years by now, probably even decades.

But in terms of mainstream game consoles yes, they are an unprecedented feature to have. Whether the Series system have them or not...if they do it'd be likely implemented differently. If they don't, though...then they just don't. At this point there's a lot more evidence pointing to custom ARM coprocessor for GPU instruction duties (to extend executeIndirect performance) on the Series systems than cache scrubbers.

So effectively, they may not enjoy the benefits of cache scrubbers, but the benefits of an ARM coprocessor logic unit for independent GPU calculations comes with its own particular benefits.



It's 1/10th of the OS core on the Series systems for I/O stack management, other than that they still have dedicated hardware decompression similar to Sony minus cache coherency engines (which are required for Sony because of dedicated processor in I/O block to maintain system performance stability with that setup). Dunno how you're factoring the clock frequency hit on that, though. It's not like the Series systems suddenly run at lower clock speeds because some of the OS core are handling I/O throughput traffic.

As I was saying before, too, that does still come with a side benefit. It means CPU-bound game logic can selectively access the memory bus during those operations, as long as the game isn't trying to access data that's being actively overwritten, obviously. I don't expect a game to be able to access the bus at the same bandwidth saturation level during this type of operation vs. if no I/O operations from storage to RAM (or vice-versa) were happening. But they'd still have a good amount to work with and every little bit helps.

Shows some of the apples-to-oranges differences in Sony and MS's approaches here, so in those instances is very difficult (almost impossible) to say one approach is just fundamentally "better" than the other.

I've said this before, but I think, ultimately, there's things in the PS5 Sony hasn't talked about yet as it relates to VR. Probably stuff in the coherency engine, maybe elsewhere. Sony's approach is a bit more bespoke because of that, while Microsoft is more traditional. Different paths due to different roadmaps and philosophy, but overall ending up at the same conclusion.

 

[thicc_girls_are_teh_best]

I've said this before, but I think, ultimately, there's things in the PS5 Sony hasn't talked about yet as it relates to VR. Probably stuff in the coherency engine, maybe elsewhere. Sony's approach is a bit more bespoke because of that, while Microsoft is more traditional. Different paths due to different roadmaps and philosophy, but overall ending up at the same conclusion.

MS's design also supports VR. There are patents (you can search the XSX thread on Beyond3D for posts; Ronaldo8 provides a lot of them) indicating features of their design for targeted VR performance.

I think people are misusing "bespoke" and "traditional" here; offloading some tasks from CPU complex to a separate processor might be bespoke to some degree, but some people seem to be using that in substitute for"exotic". It's not exotic. Outside of separate chips for this task or that, the underlying technology and architectures are completely standardized, or "traditional" in another way to word it.

Both systems have bespoke hardware. Perhaps the most exotic feature between them is PS5's Tempest Engine. But exotic doesn't necessarily mean better, because technology has standardized these days to a point where a lot of complex operations that literally required custom/exotic hardware in the past can be done through conventional means today. So in many ways there's no inherent benefit to having exotic hardware in today's systems.

I don't know if this could be considered "exotic" or bespoke in any way, but something novel with PS5's I/O solution is how it takes inspiration from DPUs, or Data Processing Units. They're used a lot in data centers and server systems and have been for years, so nothing new, but conceptually Sony's approach takes a lot of inspiration from them. So does MS's, which would make sense considering they are directly involved in those data center and server markets via Azure network. Sony and MS have simply taken some different means of executing those inspirations in their respective console designs.

 

[Dave_at_Home]

MS's design also supports VR. There are patents (you can search the XSX thread on Beyond3D for posts; Ronaldo8 provides a lot of them) indicating features of their design for targeted VR performance.

I think people are misusing "bespoke" and "traditional" here; offloading some tasks from CPU complex to a separate processor might be bespoke to some degree, but some people seem to be using that in substitute for"exotic". It's not exotic. Outside of separate chips for this task or that, the underlying technology and architectures are completely standardized, or "traditional" in another way to word it.

Both systems have bespoke hardware. Perhaps the most exotic feature between them is PS5's Tempest Engine. But exotic doesn't necessarily mean better, because technology has standardized these days to a point where a lot of complex operations that literally required custom/exotic hardware in the past can be done through conventional means today. So in many ways there's no inherent benefit to having exotic hardware in today's systems.

I don't know if this could be considered "exotic" or bespoke in any way, but something novel with PS5's I/O solution is how it takes inspiration from DPUs, or Data Processing Units. They're used a lot in data centers and server systems and have been for years, so nothing new, but conceptually Sony's approach takes a lot of inspiration from them. So does MS's, which would make sense considering they are directly involved in those data center and server markets via Azure network. Sony and MS have simply taken some different means of executing those inspirations in their respective console designs.

I don't really find anything exotic about these consoles, but I'll stick by bespoke from some of the things you've mentioned. It's obvious Series X will have no issue with VR itself, it's certainly powerful enough, but I have to directly quote Phil himself. This is from a Forbes article.

"Xbox lead Phil Spencer has, once again, ruled out VR support for the upcoming Xbox Series X.

Speaking to the Gamertag Radio podcast’s 1000th episode, Spencer outlined Microsoft and Xbox in particular’s stance on VR, saying there are no plans for any sort of virtual reality supporting the next generation of Xbox consoles.

“We’re not going to do that. I understand certain people would want that, [but] we have to focus our efforts on the things we’re doing right now. And the most precious resource that we have is the team and their ability and I just have to focus on the things we’re doing right now.”

He expanded upon his comment about resources later in the video, suggesting Xbox would be unable to provide the same full VR experience as Sony on PlayStation VR, or Valve and Oculus on PC,

“VR is not as simple as plugging your headset; you have to redo the dash, like there’s a bunch of work that goes into it. And the teams at Valve, the teams at Sony, the teams at Oculus that are doing that work, they know the completeness and what it means to support the platform.”

It could be possible down the road that Xbox finds a way to support VR, but for now it's all Sony.

 

[thicc_girls_are_teh_best]

I don't really find anything exotic about these consoles, but I'll stick by bespoke from some of the things you've mentioned. It's obvious Series X will have no issue with VR itself, it's certainly powerful enough, but I have to directly quote Phil himself. This is from a Forbes article.

"Xbox lead Phil Spencer has, once again, ruled out VR support for the upcoming Xbox Series X.

Speaking to the Gamertag Radio podcast’s 1000th episode, Spencer outlined Microsoft and Xbox in particular’s stance on VR, saying there are no plans for any sort of virtual reality supporting the next generation of Xbox consoles.

“We’re not going to do that. I understand certain people would want that, [but] we have to focus our efforts on the things we’re doing right now. And the most precious resource that we have is the team and their ability and I just have to focus on the things we’re doing right now.”

He expanded upon his comment about resources later in the video, suggesting Xbox would be unable to provide the same full VR experience as Sony on PlayStation VR, or Valve and Oculus on PC,

“VR is not as simple as plugging your headset; you have to redo the dash, like there’s a bunch of work that goes into it. And the teams at Valve, the teams at Sony, the teams at Oculus that are doing that work, they know the completeness and what it means to support the platform.”

It could be possible down the road that Xbox finds a way to support VR, but for now it's all Sony.

That quote, I take it, was always in reference to immediate plans from MS's own internal hardware division. Ben Stillwell, who worked on the xCloud team, is now a part of their VR/AR department, so they are at least actively doing R&D there. If they have a headset device planned in the near future, they'll reveal it somewhere down the line.

We know Sony have PSVR2 planned but there's actually no mention it will be available at launch. Could be months off, could be a year off. Who knows currently. I'd suspect PSVR1 is BC with PS5 though, as a no-brainer. But back to MS, I don't think anything Spencer said suggests they can't provide VR on the level of Sony or Valve or Oculus. The tech is already there in the system design, including support for foveated rendering-like techniques.

It's just that MS themselves may not be making a VR headset. But they could always partner with Valve or Oculus to design one for the Series systems, and of course, support their headsets regardless. I think one of those two are much more likely the route they'll take.

 

[DeepEnigma]

Quite amusing seeing people carry water for this Lockhart trash. Power enthusiasts and all that Jazz.

 

[CobraAB]

And yet, Sony will yet again best Microsoft this next generation.

Why?

The pudding.

Sony’s pudding is in general is the better tasting.

Always has.

 

[Dave_at_Home]

That quote, I take it, was always in reference to immediate plans from MS's own internal hardware division. Ben Stillwell, who worked on the xCloud team, is now a part of their VR/AR department, so they are at least actively doing R&D there. If they have a headset device planned in the near future, they'll reveal it somewhere down the line.

We know Sony have PSVR2 planned but there's actually no mention it will be available at launch. Could be months off, could be a year off. Who knows currently. I'd suspect PSVR1 is BC with PS5 though, as a no-brainer. But back to MS, I don't think anything Spencer said suggests they can't provide VR on the level of Sony or Valve or Oculus. The tech is already there in the system design, including support for foveated rendering-like techniques.

It's just that MS themselves may not be making a VR headset. But they could always partner with Valve or Oculus to design one for the Series systems, and of course, support their headsets regardless. I think one of those two are much more likely the route they'll take.

If Sony's next VR adventure takes off, I see no reason for Microsoft to not support the latest Valve or Oculus design. They may have a more wait and see approach here. Someone on the console side of things needs to take the plunge, so I guess Sony it is. Hopefully their next headset is awesome and actually have killer games for it. VR has the potential to bring back games that, for whatever reason, just don't resonate with gamers like they once did on previous generation of consoles. Games like, Ace Combat, Ridge Racer, Twisted Metal, etc. Could you imagine those games in VR? I feel as if VR could be the new arcade experience.

 

[Bo_Hazem]

I've heard 9 Zen2 core figures given by MS in terms of overall I/O performance, and 13 Zen2 cores equivalent I/O performance from Sony.

The CPU time saved by these decompression units sounds astounding: the equivalent of about 9 Zen 2 CPU cores for the PS5, and about 5 for the Xbox Series X. Keep in mind these are peak numbers that assume the SSD bandwidth is being fully utilized—real games won't be able to keep these SSDs 100% busy, so they wouldn't need quite so much CPU power for decompression.

Storage Matters: Why Xbox and Playstation SSDs Usher In A New Era of Gaming

www.anandtech.com

Xbox still needs half a core of the CPU for decompressing. Not counting the sound chip on XSX nor Sony's Tempest 3D Audio GPU-based, cache-less CU's. Coherency, DMA etc inside the i/o accumulate to around ~12-13x ZEN2 cores, such extra i/o perks aren't described by xbox.

Anyway, we've done this like a thousand times already, nothing new here.

 

[thicc_girls_are_teh_best]

The CPU time saved by these decompression units sounds astounding: the equivalent of about 9 Zen 2 CPU cores for the PS5, and about 5 for the Xbox Series X. Keep in mind these are peak numbers that assume the SSD bandwidth is being fully utilized—real games won't be able to keep these SSDs 100% busy, so they wouldn't need quite so much CPU power for decompression.

Storage Matters: Why Xbox and Playstation SSDs Usher In A New Era of Gaming

www.anandtech.com

Xbox still needs half a core of the CPU for decompressing. Not counting the sound chip on XSX nor Sony's Tempest 3D Audio GPU-based, cache-less CU's. Coherency, DMA etc inside the i/o accumulate to around ~12-13x ZEN2 cores, such extra i/o perks aren't described by xbox.

Anyway, we've done this like a thousand times already, nothing new here.

Series systems don't need the cache coherency engines since they aren't having a dedicated processor DMA over the memory bus to RAM. So you can't really hold that against a design implementation that doesn't actually require said feature to function.

Do you have a source on the half a core for decompression? I'd figure that is the same core for the OS, makes the most logistical sense. Assuming that's accurate, anyway.

If Sony's next VR adventure takes off, I see no reason for Microsoft to not support the latest Valve or Oculus design. They may have a more wait and see approach here. Someone on the console side of things needs to take the plunge, so I guess Sony it is. Hopefully their next headset is awesome and actually have killer games for it. VR has the potential to bring back games that, for whatever reason, just don't resonate with gamers like they once did on previous generation of consoles. Games like, Ace Combat, Ridge Racer, Twisted Metal, etc. Could you imagine those games in VR? I feel as if VR could be the new arcade experience.

Yeah, Sony's approach to VR is to be respected, certainly. VR is already present in arcades/FECs where technically it's even more immersive since floorspace is not a concern at most of those places unlike in many homes. There's some neat games in that space which use VR but probably not at the level of a Half-Life Alyx or Astro Jet for example. Maybe some day, fingers crossed.

Hopefully MS does have plans for VR in the next-gen (or VR/AR in particular) because that's only value benefit to a platform ecosystem. No reason to not eventually support it. Would not be surprised if Nintendo also has something coming in the near future with a focus on VR. Perhaps a Virtual Boy that's actually successful?

 

[Bo_Hazem]

Do you have a source on the half a core for decompression? I'd figure that is the same core for the OS, makes the most logistical sense. Assuming that's accurate, anyway.

Actually described as a small fraction of a single core, how much exactly? Not sure, but it's assisting the i/o, unlike PS5:

DirectStorage – DirectStorage is an all new I/O system designed specifically for gaming to unleash the full performance of the SSD and hardware decompression. It is one of the components that comprise the Xbox Velocity Architecture. Modern games perform asset streaming in the background to continuously load the next parts of the world while you play, and DirectStorage can reduce the CPU overhead for these I/O operations from multiple cores to taking just a small fraction of a single core; thereby freeing considerable CPU power for the game to spend on areas like better physics or more NPCs in a scene. This newest member of the DirectX family is being introduced with Xbox Series X and we plan to bring it to Windows as well.

Defining the Next Generation: An Xbox Series X|S Technology Glossary - Xbox Wire

[Editor’s Note: Updated on 10/21 at 11AM to ensure it is now reflective of the capabilities across both of our next-gen Xbox consoles following the unveil of Xbox Series S.] As we enter a new generation of console gaming with Xbox Series X and Xbox Series S, we’ve made a number of technology...

news.xbox.com

 

[thicc_girls_are_teh_best]

Bo_Hazem Yah that's what I'm referring to; they say small fraction there, but in another source they specifically state 1/10th of a core. And I would assume this is referring to the OS core because it would be ridiculous to go from 7 cores for game devs on last-gen systems to 6 cores for next-gen.

 

[VAVA Mk2]

OP I thought the CPU in Lockhart is same as XSX?

 

[Shmunter]

Series systems don't need the cache coherency engines since they aren't having a dedicated processor DMA over the memory bus to RAM. So you can't really hold that against a design implementation that doesn't actually require said feature to function.

Do you have a source on the half a core for decompression? I'd figure that is the same core for the OS, makes the most logistical sense. Assuming that's accurate, anyway.



Yeah, Sony's approach to VR is to be respected, certainly. VR is already present in arcades/FECs where technically it's even more immersive since floorspace is not a concern at most of those places unlike in many homes. There's some neat games in that space which use VR but probably not at the level of a Half-Life Alyx or Astro Jet for example. Maybe some day, fingers crossed.

Hopefully MS does have plans for VR in the next-gen (or VR/AR in particular) because that's only value benefit to a platform ecosystem. No reason to not eventually support it. Would not be surprised if Nintendo also has something coming in the near future with a focus on VR. Perhaps a Virtual Boy that's actually successful?

Not quite sure how you conclude GPU cache coherency not being a benefit on a software I/o implementation? How the data gets into ram is divorced from how the GPU acts on that data.

if indeed XsX has no solution to managing GPU cache during asset streaming, the cache misses will be significant and GPU efficiency effected.

See how it plays out.

 

[Xplainin]

Regarding Tempest and its memory bandwidth, I went back to the Eurogamer article and they do indeed say 20 GB/s so you were right there and I stand corrected. To idea of overall compute...well yeah to some extent it would mean more processing ability. But the effectiveness of that processing capability in parallel depends on a ton of factors.

You have to keep in mind that Tempest is explicitly designed to mimic a PS3 SPE. That's a very different architecture makeup compared to what the next-gen systems are using which is similar in all other aspects. You also have to keep in mind that it's specifically tailored for audio programming work so while it can probably be used in some unorthodox methods creatively (the SEGA Saturn saw its audio processor used for some graphics data in Shining Force III for example)..that really comes down to if a developer A) has a good enough handling on the chip, B) sees a need to bother using it in such a way and C)can leverage the chip in that type of way within the scope of their design.

FWIW, there's a lot of reasons PS3 was seen as difficult to work with and one of them was the way the SPEs were set up. Sony's basically asking developers to re-familiarize themselves with a part of the PS3 architecture, specifically set up that way for audio taskwork and maybe having some flexibility for non-audio tasks. Now one of the reasons PS3 was difficult for devs to leverage was because the idea of utilizing SPEs conceptually was very foreign back then. Today they have much more familiarity with multi-core processors and the such, but it's still going to be an unusual setup and language for them to utilize in ways that are not easily accessible.

Also in terms of that processing power being available in parallel...well yes, it's there in parallel if we're just talking using data on the caches. But from RAM? Again there's bus contention so CPU, GPU etc. have to cede bus access to Tempest Engine when it wants to refresh the caches with new data from the RAM pool.

You're only considering the 1/10th a single CPU core for I/O on the Series systems as marketing doublespeak because you've forgotten that MS does actually have custom hardware for decompression in their systems, too. Some people are taking that to literally mean "only" decompression but that dedicated hardware very likely also has some other I/O related components to it as well. Not as much and/or the same as Sony's, but it's there. There's enough in terms of patents and outright information available (such as the explicit reference to ARM coprocessors in the Series system APUs from an Indian AMD engineer's LinkedIn many months back; most likely that's referring to a customized coprocessor on the GPU similar to some of the Nvidia GPUs with FPGA cores onboard to perform independent instruction tasks, and fits in with expansion of executeIndirect hardware features already present on Xbox One) to suggest and support this.

Yes...those are cache scrubbers. But I'm actually talking about the cache coherency engines, not the cache scrubbers (which are in the GPU). I had to edit my comment because at first I mistakenly mentioned the scrubbers.



SMT Off will have its benefits. If it didn't, it wouldn't be offered. Not every next-gen game is going to need 16 threads, but could benefit from faster CPU clocks. Some games may also benefit from SMT Off if it means feeding the GPU with instructions faster (though with the Series systems I think MS have added an ARM coprocessor block to the GPU extending off executeIndirect in large part to fulfill this purpose, so a game on a Series device using SMT Off would probably be doing it for increasing rate/speed of CPU-bound game logic).

In terms of that 2% frequency drop, the truth is we don't know how often it will be (or if there will be instances where the drop is larger), but it's safe to say it'll happen enough to consider it as a slightly recurring scenario, particularly as the generation wears on. Just think about it; why even touch on that in a presentation to developers if there wasn't some consideration of it possibly being a somewhat persistent occurrence?

Now what specific programming environments (aside from AVX 256 instructions, which are rare) will bring that about, we don't know. But the fact variable frequency as an approach needed to be taken at all, and that frequency fluctuation is a byproduct of that approach...that signals at least something IMO.

No, with SMT On it's 3.5 GHz PS5 and 3.66 GHz Series X/Series S. Should be in one of MS's blog posts. Granted, MS likes to round down their numbers a lot, they've done the same with the GPU whereas Sony rounds up (actual GPU TF numbers are 10.275 PS5 and 12.147 Series X).

Pretty sure Cerny said 20% in his talk.

 

[thicc_girls_are_teh_best]

Not quite sure how you conclude GPU cache coherency not being a benefit on a software I/o implementation? How the data gets into ram is divorced from how the GPU acts on that data.

if indeed XsX has no solution to managing GPU cache during asset streaming, the cache misses will be significant and GPU efficiency effected.

See how it plays out.

You don't need cache coherency engines to enforce cache coherency. I doubt MS would overlook ways to ensure cache misses are kept to a minimum, they certainly have more than enough resources and talent to ensure that.

So, we can wait and see how it plays out, certainly, but it's also a bit foolish to believe a company as large as them with the funds and resources at their disposal, would design a next-gen platform and not ensure there is coherency between data going from storage to RAM and from RAM to the GPU caches.

Just as an example, they have already mentioned ECC-enforced GDDR6 memory, and there are mentions of ARM cores specifically in an APU listing from an AMD team member's LinkedIn profile (this was many months ago). I've been speculating those ARM cores are likely for implementing further features and support of executeIndirect through hardware. They can also serve as some method of coherency, theoretically.

There's other ways of enforcing coherency of processor components in a system design too such as CCIX, but that overlays on top of PCIe 3.0/4.0 and I don't think that's being used in any consoles.

Pretty sure Cerny said 20% in his talk.

Nah, I checked a few articles (VentureBeat, Eurogamer etc.) and they quote it as 20 GB/s. 20% would be insane for something with the processing capability of Tempest, since that would be pushing 90 GB/s if true (and pretty much cripple the system bandwidth for other processor components).

 

[Shmunter]

You don't need cache coherency engines to enforce cache coherency. I doubt MS would overlook ways to ensure cache misses are kept to a minimum, they certainly have more than enough resources and talent to ensure that.

So, we can wait and see how it plays out, certainly, but it's also a bit foolish to believe a company as large as them with the funds and resources at their disposal, would design a next-gen platform and not ensure there is coherency between data going from storage to RAM and from RAM to the GPU caches.

Just as an example, they have already mentioned ECC-enforced GDDR6 memory, and there are mentions of ARM cores specifically in an APU listing from an AMD team member's LinkedIn profile (this was many months ago). I've been speculating those ARM cores are likely for implementing further features and support of executeIndirect through hardware. They can also serve as some method of coherency, theoretically.

There's other ways of enforcing coherency of processor components in a system design too such as CCIX, but that overlays on top of PCIe 3.0/4.0 and I don't think that's being used in any consoles.



Nah, I checked a few articles (VentureBeat, Eurogamer etc.) and they quote it as 20 GB/s. 20% would be insane for something with the processing capability of Tempest, since that would be pushing 90 GB/s if true (and pretty much cripple the system bandwidth for other processor components).

I agree it would be quite the oversight by MS.

Unless they are relying on ssd just being a fast loading hdd as opposed to a core part of the memory subsystem focusing on asset streaming. Their recent pr statements where they don’t see hdd based systems being a technological anchor going forward may be telling. Let’s hope not, that’s no way to push technology baselines forward.

 

[JustP_Gaming]

lol, this has nothing to do with MS's marketing team.

It's from Tom Warren; he's a try-hard who I think REALLY wants a job at Microsoft.

Would literally be a major FCC violation if he was actually a paid shill; he's just a boot licker who slobs MS's knob so much he has friends on the inside so he gets info.

Wow all because he said the CPU is faster?Lol

 

[thicc_girls_are_teh_best]

I agree it would be quite the oversight by MS.

Unless they are relying on ssd just being a fast loading hdd as opposed to a core part of the memory subsystem focusing on asset streaming. Their recent pr statements where they don’t see hdd based systems being a technological anchor going forward may be telling. Let’s hope not, that’s no way to push technology baselines forward.

But it is a core part of their memory subsystem, that's the thing xD. I agree, they need to tighten up their marketing and get things synergized again. There are too many contradictory statements coming from people on the team with some answers not really addressing discussions currently being had. That's frustrating.

However any amount of deeper reading and analysis shows they have put a metric fuc-ton into XvA, and one theme that is consistent along their hardware design is dramatically cutting down on latency, whereas Sony seems more focused on maximizing bandwidth. There's a lot pointing to their focus with XvA also being in this same vein, so it'll be interesting to see how this applies in actual games (there's tastes of it in what the DiRT 5 developer has mentioned, for example).

 

[Genx3]

The XSX and Lockhart needs more than those 100MHz for file I/O and sound handling, so in reallity it's probably the PS5 that has the stronger CPU in the end.

Well.. 100MHz is in reality nothing for starters. PS5 has more specialized hardware for file I/o compared to XSX. And XSX's 3D audio (and regular) implementation is also not on the same level as Tempest, meaning that the CPU must put in work.
Can't find the sources now, so you don't have to believe me

Not sure where you guys get your info from but;
XSX has a separate IO decompression block and separate 3D audio block.
Xbox hardware already had 3D audio since the launch of the XB1. There's a reason Dolby Atmos is available on Xbox One.

Most AAA games are going to be lower than 4K and use checkerboard.

It just makes more sense.

Doubt it.
XB1X already hit 4K most of the time and when it didn't hit 4K it was just a hair less than 4K.
No reason to blur the image quality with Checkerboarding artifacts. Either use ML to get the same image quality as 4K or just use real 4K.

The PS5 and XSX are way more powerful than the XB1X. Don't let the numbers fool you.

I expect real 4K most of the time unless its 1440P 60fps mode in a 4K 30 game.

 

[Jon Neu]

Doubt it.
XB1X already hit 4K most of the time and when it didn't hit 4K it was just a hair less than 4K.
No reason to blur the image quality with Checkerboarding artifacts. Either use ML to get the same image quality as 4K or just use real 4K.

The PS5 and XSX are way more powerful than the XB1X. Don't let the numbers fool you.

I expect real 4K most of the time unless its 1440P 60fps mode in a 4K 30 game.

The One X was a mid gen refresh, it was designed just to play the same Xbox One games but with more resolution.

The XsX it’s a totally different console with new games to be made. And at the end, from a design point, makes more sense to sacrifice native resolution in order to have better looking games.