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

(*) Ali Salehi, a rendering engineer at Crytek contrasts the next Gen consoles in interview (Up: Tweets/Article removed)

Interview removed days ago and people moved on. I don't get why then ppl come over and post stuff like this just happened to do what, rewrite the narrative and make this remembered as 'fake news'? It doesn't retract from the possibility that whatever was written and shared is still true. It has been chawed to the annals of internet history, no need to feel like spinning it. Shu also corroborates this with unnamed developers and I trust that guy completely so I don't get the hate for this guy since what he said was already known mostly, he just added an introspective. It didn't had numbers or hard data and what he said generally lined up with what has been known specification wise and what it actually means.
 

psorcerer

Banned
can actually service two requests at once, given the right controller

Yep. It doesn't change anything.
RDNA 64bit controller can serve 4 requests at a time. Still you cannot access lower and upper parts of the same chip in the same request.

With multiple channels (between 5 and 20 for XSX depending on controller logic) there are independent requests.

That's why it's 560 or 336GB/sec and not 112.
Each memory controller has max bandwidth of 2x56GB/sec.
And each can serve a fixed amount of requests to a specific address.
Addresses are interleaved with at least 128B stride. But interleave full circle is different for 10 and 6 chip config. Therefore it will never happen that there is a request to the 2 "smaller" controllers when 3 "bigger" ones serve 6way interleaved request.
Only when 10way requests are served.
It's not rocket science.
 
Do you really know how a memory controller works?

Probably better than you, if we're honest. Though my understanding is by no means complete.

The full bus do any request at time... to have two or more simultaneous access at the same time you need 2 or more memory controllers and busses.

No, for fucks sake, you don't need the full bus! NOOOOOOOO! That's the entire point of multi channel memory buses of the last 30 years! You don't need two buses to read data from two separately channelled areas of memory.

For fucks sake man, what are you doing? Where did you learn your shit?!?

So if the CPU is doing a request in the slow memory part the GPU needs to wait until that request ends.... same for the GPU of it is doing a request on the fast part the CPU needs to wait it time.

No, that would be fucking stupid. If memory channels weren't facing contention for access, and the scheduler had a shot at access there's no fucking reason to wait.
 

ethomaz

Banned
Now to be fair, it seems as though MS may have an ace up their sleeve with BCPack? There’s an article that covers a series of tweets between Richard Geldreich and James Stanard (Graphics Optimization R&D and Engine Architect at Microsoft)


Another interesting Geldreich tweet:



Of course I chose Geldreich’s tweets because, as far as I’m aware, he’s certainly the only one I’ve come across who has spoken at great detail about BCPack. It’ll be fascinating to understand the differences between the two as time move forward and more is revealed.

BCPack indeed can compress better than Kraken in textures... Kraken is a more generic so it is good in any type of data while BCPack is specific for textures so it does compress better textures.

But that is already accounted in the SSDs speeds figures:

Xbox: 2.4GB/s base, ~4.8GB/s compressed (BCPack 50% compression)
PS5: 5.5GB/s base, 8-9GB/s compressed (Kraken 30-40%)
 
Yep. It doesn't change anything.
RDNA 64bit controller can serve 4 requests at a time. Still you cannot access lower and upper parts of the same chip in the same request.

No-one, least of all me, ever said you could.

That's why it's 560 or 336GB/sec and not 112.
Each memory controller has max bandwidth of 2x56GB/sec.
And each can serve a fixed amount of requests to a specific address.
Addresses are interleaved with at least 128B stride. But interleave full circle is different for 10 and 6 chip config. Therefore it will never happen that there is a request to the 2 "smaller" controllers when 3 "bigger" ones serve 6way interleaved request.
Only when 10way requests are served.
It's not rocket science.

Ooof.

So .... are you prepared to reiterate again that any access to the "slow" 6GB blocks any access to the "fast" 10 GB for the duration of that access?

Time to own your comments, son!
 

ethomaz

Banned
Probably better than you, if we're honest. Though my understanding is by no means complete.



No, for fucks sake, you don't need the full bus! NOOOOOOOO! That's the entire point of multi channel memory buses of the last 30 years! You don't need two buses to read data from two separately channelled areas of memory.

For fucks sake man, what are you doing? Where did you learn your shit?!?



No, that would be fucking stupid. If memory channels weren't facing contention for access, and the scheduler had a shot at access there's no fucking reason to wait.
That is how memory controller works.
In the same request you can do read or write to any or all channels.

But if you need to do another request you need to wait.

CPU and GPU can’t use the same bus at the same time.
 
That is how memory controller works.
In the same request you can do read or write to any or all channels.

But if you need to do another request you need to wait.

CPU and GPU can’t use the same bus at the same time.

Might I ask ... why do you think a system has multiple channels across it's memory bus, and an overall control system that tries to schedule accesses across those channels, in the most efficient manner possible?

And yeah, I'm a cunt and a drunkard but I actually do know more about this than you. Thanks for helping a fuckwit like me know that for sure....
 
Nothing changed.

Well, you're a smart guy, and often quite funny in a dry way.

But it's good to know the limits of your understanding.

Pride comes before a fall for all of us!

Don't worry, I'll rub this in during future months in a polite way (I'm sure you still have lots of valuable insights to offer!).
 

psorcerer

Banned
Well, you're a smart guy, and often quite funny in a dry way.

But it's good to know the limits of your understanding.

Pride comes before a fall for all of us!

Don't worry, I'll rub this in during future months in a polite way (I'm sure you still have lots of valuable insights to offer!).

I've already analysed how it will work. Just too lazy to find that post.
I hope MSFT won't lock GPU in 10GB though that would waste much more perf than all the 560/336 pools.
 

ethomaz

Banned
Might I ask ... why do you think a system has multiple channels across it's memory bus, and an overall control system that tries to schedule accesses across those channels, in the most efficient manner possible?

And yeah, I'm a cunt and a drunkard but I actually do know more about this than you. Thanks for helping a fuckwit like me know that for sure....
Independent memory channel was created to cover a big issue in “Ganged” memory controller where you couldn’t access two different rows at same time...

For example you have two 32 bits channels... and the data in your memory where A and D are in the Channel 1 and B and E are in the Channel 2.

Row 1 > A B
Row 2 > D E

In “Ganged” you need to fetch twice to read A and E because the data is in different rows.

So they created Independent memory controllers that is how modern memory access is done. That way you the Channel 1 can access A and Channel 2 access E at same time.

But that is still a one data fetch.

You can’t say Channel 1 fetch this data for CPU and Channel 2 fetch this data for GPU.

You do one single data fetch that can access all data independent due the different channels.
 
Last edited:

B_Boss

Member
Your use of parentheses offends me deeply.

I kid.

Just so you know, just use the "@" symbol and the beginning of the user's name and it should pop up.

B_Boss B_Boss

Ah, apologies about that 🤣. You don’t kid fully I’d wager, probably grammar/punctuation OCD, I understand. Thanks a ton for that.
 
For the record, nothing stops games from putting CPU related data accesses in the fast RAM along with other aspects of the game. As Microsoft said, every other part of the console, including audio, cpu etc, sees similar performance on either block of memory. Only the GPU sees different performance if it uses the slow portion.

So depending on just how good Sampler Feedback Streaming truly is, and even without it, there's no reason the CPU and GPU can't both tap the 560GB/s portion of memory. For lower priority accesses that don't require as much speed, that's what the remaining slower 3.5GB can be used for, but the CPU will be using the GPU optimal memory for sure.

For example, do people know where the standard memory actually is? It's in the 6 2GB chips after the first 1GB, in the second 1GB portion of memory addresses. I can see data, if it's needed in GPU memory, quickly being shifted from standard memory over to GPU optimal memory fairly quickly. Memory on either side can be accessed in any order for the most part. Because the main thing to keep in mind is that even the slower side of memory will be significantly faster than the SSD ever will, so I can see devs from time to time, if they have to, banking data there.

The beauty of being on the gaming side is I don't have to worry about the intricacies lol. I'll let the game developers worry about all that.
 

rnlval

Member
I'm trying to explain why a complete shutdown of the "fast" 10GB for any access to the "slow" 6GB would be illogical and an unrealistic (IMO) idea. I have a problem with that idea, I don't thing MS would engineer a system that did that.

Let me flip the tables, and ask you a question:

Lets say 1 memory controller is accessing data from the "slow" 6GB. Lets also say the other 4 memory controllers have accesses they are able to fulfil in the "fast" 10GB.

Do you think they'll sit there, doing nothing, or do you think they'll fulfil those requests?
The clues are given by MS e.g. OS reserve is allocated in the six 2GB chips with 336 GB/s bandwidth with an assumption for low memory hit rates.

It depends on memory controllers arbitration if it prioritizes memory request towards 560 GB/s address range and would the GDDR6 memory controller enable full-duplex for dual 16bit channels?
It depends on memory controllers' arbitration on how it load balances the memory array.

Textures have many data reads, sample feedback has textures being generated (write) for the next frame recycle(read) and frame buffers have many read-write operations.

For throughput, data striping across multiple memory chips would be imployed.

For XSX, all frame buffers should be in 10GB with 560 GB/s address range to maximize rendering performance.

With one second time interval and equal memory access rates for 3.5 GB and 10 GB memory address range, the effective bandwidth is 448 GB/s.

86% of one second time interval for 10GB would yield 481.60 GB/s (math, 0.85 x 560)
14% of one second time interval for 3.5GB would yield 47.04‬ GB/s (math, 0.14 x 336)
Total effective memory bandwidth is 528.64‬ GB/s

Let CPU consume 48 GB/s BW
For XSX GPU's BW would be 480‬ GB/s

For PS5 GPU'sBW would be 400 GB/s

XSX has 20% memory advantage over PS5.

Note why XSX's Gears 5 benchmark has RTX 2080 like results instead of RTX 2080 Super+.
 

rnlval

Member
BCPack indeed can compress better than Kraken in textures... Kraken is a more generic so it is good in any type of data while BCPack is specific for textures so it does compress better textures.

But that is already accounted in the SSDs speeds figures:

Xbox: 2.4GB/s base, ~4.8GB/s compressed (BCPack 50% compression)
PS5: 5.5GB/s base, 8-9GB/s compressed (Kraken 30-40%)

dquyAcc.jpg


4.8 GB/s ZLIB decompression path for non-texture data type
"More than 6 GB/s" is BCpack decompression path for texture data type
 

ethomaz

Banned
dquyAcc.jpg


4.8 GB/s ZLIB decompression path for non-texture data type
"More than 6 GB/s" is BCpack decompression path for texture data type
That is incorrect.

4.8GB/s is already BCPack average on Xbox... Zlib is nowhere close to 50%.
Over 6GB/s is the best case of BCPack just like 22GB/s is the best case for Kraken.

4.8GB/s is 50% BCPack compression.

 
Last edited:
The clues are given by MS e.g. OS reserve is allocated in the six 2GB chips with 336 GB/s bandwidth with an assumption for low memory hit rates.

It depends on memory controllers arbitration if it prioritizes memory request towards 560 GB/s address range and would the GDDR6 memory controller enable full-duplex for dual 16bit channels?
It depends on memory controllers' arbitration on how it load balances the memory array.

Textures have many data reads, sample feedback has textures being generated (write) for the next frame recycle(read) and frame buffers have many read-write operations.

For throughput, data striping across multiple memory chips would be imployed.

For XSX, all frame buffers should be in 10GB with 560 GB/s address range to maximize rendering performance.

With one second time interval and equal memory access rates for 3.5 GB and 10 GB memory address range, the effective bandwidth is 448 GB/s.

86% of one second time interval for 10GB would yield 481.60 GB/s (math, 0.85 x 560)
14% of one second time interval for 3.5GB would yield 47.04‬ GB/s (math, 0.14 x 336)
Total effective memory bandwidth is 528.64‬ GB/s

Let CPU consume 48 GB/s BW
For XSX GPU's BW would be 480‬ GB/s

For PS5 GPU'sBW would be 400 GB/s

XSX has 20% memory advantage over PS5.

Note why XSX's Gears 5 benchmark has RTX 2080 like results instead of RTX 2080 Super+.

Nice analysis. I expect they'll get a pretty cool boost in performance once additional GPU features are supported. But this also means that RTX 2080 and RTX 2080 Super will get performance boosts also since they both fully support VRS, Sampler Feedback, Texture Space Shading, Amplification Shaders, as well Mesh Shaders.

Man, it's going to be cool as hell seeing what developers do with these two consoles, how creative they get.
 

rnlval

Member
Nice analysis. I expect they'll get a pretty cool boost in performance once additional GPU features are supported. But this also means that RTX 2080 and RTX 2080 Super will get performance boosts also since they both fully support VRS, Sampler Feedback, Texture Space Shading, Amplification Shaders, as well Mesh Shaders.

Man, it's going to be cool as hell seeing what developers do with these two consoles, how creative they get.
My RTX 2080 Ti is wasting a large chunk of silicon and it mostly acting like a faster GTX 1080 Ti for most current games. I'm still planning to buy RTX 3080 Ti
 

rnlval

Member
That is incorrect.

4.8GB/s is already BCPack average on Xbox... Zlib is nowhere close to 50%.
Over 6GB/s is the best case of BCPack just like 22GB/s is the best case for Kraken.

4.8GB/s is 50% BCPack compression.


That's incorrect.


Note the 50%+ for BCpack.
 
Last edited:
My RTX 2080 Ti is wasting a large chunk of silicon and it mostly acting like a faster GTX 1080 Ti for most current games. I'm still planning to buy RTX 3080 Ti

Us gamers are so greedy lol. That 2080 Ti will be like a beast reborn when more games start taking advantage of the DX 12 Ultimate feature set, which Turing already had full support for since launch.
 

Shmunter

Member
I don't understand the question.
To service a request from a 2GB chip you occupy the whole bus of that chip. That's what "servicing a request" means.
You cannot do more than that chip was designed to service at any given time.
Therefore when all the "bigger" chips are servicing a request you cannot squeeze in any others.
And you cannot even use the remaining 4Gb efficiently. Because of striding into bigger chips.
You need to do a diagram. Needs to include straws.
 

Shmunter

Member
BCPack indeed can compress better than Kraken in textures... Kraken is a more generic so it is good in any type of data while BCPack is specific for textures so it does compress better textures.

But that is already accounted in the SSDs speeds figures:

Xbox: 2.4GB/s base, ~4.8GB/s compressed (BCPack 50% compression)
PS5: 5.5GB/s base, 8-9GB/s compressed (Kraken 30-40%)
These BCPack info seems incomplete. Is the suggestion it is 50% consistently? Unrealistic.

The Kraken figure actually provides a range. BCPack may reach 50% , but realistically could less and on average lower than Kraken. No idea, just speculation since info is seemingly misleading indicating an agenda?
 
These BCPack info seems incomplete. Is the suggestion it is 50% consistently? Unrealistic.

The Kraken figure actually provides a range. BCPack may reach 50% , but realistically could less and on average lower than Kraken. No idea, just speculation since info is seemingly misleading indicating an agenda?

Well the guy on twitter that spoke about it appears to be a compression specialist, so he would seem to know a great deal about the stuff. He even has a company focused around it.
 

rnlval

Member
I'm trying to explain why a complete shutdown of the "fast" 10GB for any access to the "slow" 6GB would be illogical and an unrealistic (IMO) idea. I have a problem with that idea, I don't thing MS would engineer a system that did that.

Let me flip the tables, and ask you a question:

Lets say 1 memory controller is accessing data from the "slow" 6GB. Lets also say the other 4 memory controllers have accesses they are able to fulfil in the "fast" 10GB.

Do you think they'll sit there, doing nothing, or do you think they'll fulfil those requests?
I revised my XSX memory diagram and it's based on RDNA's block diagram.

h0aDcaR.png


The APU is a multitasking processor and each 64bit memory controller will continue to process memory requests based on the memory address target.

The six 2GB GDDR6 chips were inspired by RX-5600 XT's 192 bit 336 GB/s layout.

To fit into the dual shader engine layout, I plan to revise the diagram to split the last 64bit memory controller into two 32bit memory controllers.
 
Last edited:

ZywyPL

Banned
BCPack indeed can compress better than Kraken in textures... Kraken is a more generic so it is good in any type of data while BCPack is specific for textures so it does compress better textures.

But that is already accounted in the SSDs speeds figures:

Xbox: 2.4GB/s base, ~4.8GB/s compressed (BCPack 50% compression)
PS5: 5.5GB/s base, 8-9GB/s compressed (Kraken 30-40%)

Does it? We don't know how effective both compression methods are, that's where the BCPack might shine, because let's say we have 4 vs 8 GB/s bandwidth, BUT the compressed take 2 vs 4GB, that would completely even the odds. Now what if BCPack is much more efficient than that? Let's say 1-1,5GB vs 4?

What's more, in some old interview regarding DirectML, the developer said that the AI upscaling is so efficient that there's actually no need to store high-resolution textures anymore, because it's impossible to tell the difference between the high-res ones and upscaled low-res ones. And bare in mind XBX has addition 2TF to spare vs PS5, and those extra CUs can go exactly for such additional AI computations instead of graphics per se.

So all in all, it's possible that XBX simply might not need such immense bandwidth. But as always, time will tell, without a single 3rd party AAA game we can only speculate.
 
D

Deleted member 775630

Unconfirmed Member
So I’m correct and I posted that tweet lol

4.8GB/s is average BCPack 50% compression and that is why MS shared it on official specs.
He didn't say average 50% compression. He said AT LEAST +50%. Also it's a back of the envelope calculation this could easily be 40% as well as 60%
 

Panajev2001a

GAF's Pleasant Genius
DirectML, the developer said that the AI upscaling is so efficient that there's actually no need to store high-resolution textures anymore

You take this at face value but Sony’s remarks about PS5 (considering they are not a HW group only, but have plenty of teams very highly skilled at maxing our what their game consoles can do and the lead architect is a game developer and designer) are taken with such caution? Does not compute. PS5 could drop resolution a few percent here and there and achieve the same magic with textures decompression if it is all in software and still get the upper hand there if it were that easy.
 
D

Deleted member 775630

Unconfirmed Member
There could be scenarios where Kraken can actually max out the 22 GB/s decompression rate... so?
So nothing... I'm just saying he quoted him wrong which results in the spread of wrong information and confusion.
 

Kenpachii

Member
Which one exactly?

Made a post about it somewhere i think that explained my points, its somewhere buried in this thread.

The guy had some good points but sadly a lot of it made no sense to the point either the interviewer translation is shit, or the dev is pulling a witcher 3 PS4 moment.
 

pawel86ck

Banned
Interview removed days ago and people moved on. I don't get why then ppl come over and post stuff like this just happened to do what, rewrite the narrative and make this remembered as 'fake news'? It doesn't retract from the possibility that whatever was written and shared is still true. It has been chawed to the annals of internet history, no need to feel like spinning it. Shu also corroborates this with unnamed developers and I trust that guy completely so I don't get the hate for this guy since what he said was already known mostly, he just added an introspective. It didn't had numbers or hard data and what he said generally lined up with what has been known specification wise and what it actually means.
I would like to know how old this interview was. According to Ali Salehi MS didnt updated DX12 in a long time and we know for a fact it's not true, because there is DX12 ultimate now.
 

Akuji

Member
decompression solutions is software both can and will be modified over the generation. something better is avaiable? lets use this. just like cerny said in the presentation many already use kraken, its not like its a thing that the ps5 brings along.
The important side is, as always, hardware. Which Chip has more performance so that it does not become a bottleneck?
The figure they give is that the xbox solution can output UP TO 6gb/s after decompresisng the incoming data. But with more clever software usage u can probably get higher results as well. Within their current software solution 6gb/s seems like its the max. maybe they get to 7-8gb/s theoretical max
decompression. But then it likely would need more then 2.4gb/s raw data output of the xbox ssd to have enough data to actually decompress that much.

same goes for PS5, the important data is 2.4 gb/s and 5.5gb/s that neither one of them are bottlenecked by the chip they built the chip stronger then necassary. that goes for both. i can see the xbox chip running into some small bottlenecks with less then 3x the output of the raw input of the ssd.
It will be extremly minor tough ... PS5 with the 20gb/s chip is nearly 4 times the input of the ssd so there wont be any bottleneck at all. atleast thats my guess.

will it matter overall? nah probably not. Decompression will work on both to the same extend.

What matters is the raw speed of the ssd not the decompression chips if they both are accuratly designed for their SSD, which to me it seems to be the case.

2.4gb/s vs 5.5gb/s is the only number that matters.

Which game will profit from it? Heavy simulation games probably the most, chaning those values in all the databases, giving and checking if people go to do their jobs, what their jobs are etc etc could give open world games a much more realsitic feeling.
Maybe the PS5 get some real GPU cycles saved because the system needs to render less of the 360° view, maybe the xbox can go with 300° of sight needs to be rendered while the ps5 is ok with 240° which would mean a 20% performance gain. Not overall graphics mind you, just that tiny bit of what makes a game run on the console. So probably around 5% overall?

These consoles are going to be very close in performance and cost probably the same.
 

ethomaz

Banned
I would like to know how old this interview was. According to Ali Salehi MS didnt updated DX12 in a long time and we know for a fact it's not true, because there is DX12 ultimate now.
What you consider update?

“DX12 Ultimate isn’t a giant leap over standard DX12, the graphics API first released back in 2014 that this “ultimate” version is building off. But it does bring together a number of software advances — most prominently Ray Tracing 1.1 (which now no longer requires the GPU ping the CPU) — that will make optimizing games for the upcoming Xbox Series X and the latest Nvidia and AMD graphics cards much easier. At the same time, the API is also keeping support for older PC and Xbox hardware intact.”

It basically a update to add DRX 1.1... the Direct3D API is the same.
 
Last edited:

cormack12

Gold Member
Won't Sony be compressing less raw data though if Cerny is to be believed about the deduplication gains? A higher rate of deduplication means smaller raw data payload to compress for streaming right? I'm assuming it's inline as there would be no benefit to decompress then dedupe?

 

Tamy

Banned
“But it does bring together a number of software advances — most prominently Ray Tracing 1.1 (which now no longer requires the GPU ping the CPU) — that will make optimizing games for the upcoming Xbox Series X and the latest Nvidia and AMD graphics cards much easier. .”

So a game can be optimized using DX12 Ultimate and run on a variety of Xbox devices and both AMD and Nvidia cards.

This is also great, or not?

Doesn't sound like DX is a nightmare to work with? It sounds to me that it makes it much easier for multiplatform devs, which is a good thing.
 

ethomaz

Banned
This is also great, or not?

Doesn't sound like DX is a nightmare to work with? It sounds to me that it makes it much easier for multiplatform devs, which is a good thing.
It is still a abstraction layer that didn’t have all options available to all platforms.

A specific platform API is easier for optimizations and performance.

That is his point... most game devs doesn’t like DirectX12 at all because it add a lot of complexity over DirectX11..: that is why the adoption is so slow even after 5 years.

That opinion piece is still pretty recent: https://www.gamasutra.com/blogs/BradWardell/20191007/351772/Living_with_Vulkan_and_DirectX_12.php

MS renamed DX12 to DX12U to try with DXR 1.1 make devs finally jump on the ship... if you want to use Ray-tracing you need to use DX12U now because you can’t do that with DX11 unless you code to metal.
 
Last edited:

pawel86ck

Banned
What you consider update?

“DX12 Ultimate isn’t a giant leap over standard DX12, the graphics API first released back in 2014 that this “ultimate” version is building off. But it does bring together a number of software advances — most prominently Ray Tracing 1.1 (which now no longer requires the GPU ping the CPU) — that will make optimizing games for the upcoming Xbox Series X and the latest Nvidia and AMD graphics cards much easier. At the same time, the API is also keeping support for older PC and Xbox hardware intact.”

It basically a update to add DRX 1.1... the Direct3D API is the same.
Yes, that's what I consider an update, and your quote even mention XSX games will be even more optimized because of it.
 

ethomaz

Banned
Yes, that's what I consider an update, and your quote even mention XSX games will be even more optimized because of it.
That part talks about Ray-tracing (DXR 1.1) before DX12U the ray-tracing support with DXR 1.0 was specifically to nVidia cards.
Now it support AMD cards (that includes Xbox Series X) so you can use the same code across nVidia and AMD for Ray-tracing making it easy like it says in the quote.

Dirext3D and everything else continues the same... there is no update in the API since 2014 except the add of DXR (ray-tracing support).
 
Last edited:

geordiemp

Member
No-one, least of all me, ever said you could.



Ooof.

So .... are you prepared to reiterate again that any access to the "slow" 6GB blocks any access to the "fast" 10 GB for the duration of that access?

Time to own your comments, son!

1. So MS said in their specs are, in their words

10GB at 560GB/s, 6GB at 336GB/s

2. If the slower access did not stop or interupt the other memory...the spec would read something like

10GB at 560GB/s
OR 10GB at 224GB/s AND 6GB at 336GB/s simultaneously

Or an easier way to think of this, is if access to all the RAM is more independent, there is no need for MS to mention in their spec 336 GB/s max
 
Last edited:

ZywyPL

Banned
You take this at face value but Sony’s remarks about PS5 (considering they are not a HW group only, but have plenty of teams very highly skilled at maxing our what their game consoles can do and the lead architect is a game developer and designer) are taken with such caution? Does not compute. PS5 could drop resolution a few percent here and there and achieve the same magic with textures decompression if it is all in software and still get the upper hand there if it were that easy.

Fo course Sony can come up with their own, custom compressing solution, I won't be surprise at all if they will somewhere down the line, but until Cerny/Sony mention something else than ZLIB and Kraken, that's were we're at, I cannot comment on something that doesn't exist.
 
Last edited:

martino

Member
there is no update in the API since 2014 except the add of DXR (ray-tracing support).

come on seriously ...


some examples with explicit titles you will have hard time to twist but each post od the blogf is more a less about updating/ improving / adding in the api...
 
Last edited:

pawel86ck

Banned
Dirext3D and everything else continues the same... there is no update in the API since 2014 except the add of DXR (ray-tracing support).
That's still an update man and because many games on XSX will run with RT it's probably a significant one.


May I ask why are you trying so hard to defend Ali Salehi? It's your friend or you are just liking playstation brand too much?
 

ethomaz

Banned
come on seriously ...


some examples with explicit titles you will have hard time to twist but each post od the blogf is more a less about updating/ improving / adding in the api...
That's still an update man and because many games on XSX will run with RT it's probably a significant one.


May I ask why are you trying so hard to defend Ali Salehi? It's your friend or you are just liking playstation brand too much?
Again.

DX12U is a logo or label... what that means? That means that any hardware that supports DX12U label needs to support 4 features: ray-trading hardware acceleration, support to Mesh Shaders, Variate Rate Shading and Sampler Feedback.

These are the 4 features that Are required to label DX12U in your hardware.

The API is the same.... it didn’t change... you have the same DX12 released in the past for better or worst.

The guy in the interview made a comparison that MS still uses the DX12 on Xbox Series X instead to made a API specific created/updated to the Xbox Series X hardware and that is true.

DX12 is a generic API made to work across several platforms and that come at a cost... it is not made specifically to use one single platform potential... unlike the PS5’s API where Sony build it specifically to use the hardware of PS5.
The biggest advantage of DX12 API is that it makes development across several platforms easier because you can use a common API.

You guys keep trying to make the CryTek dude wrong when he doesn’t say nothing wrong at all.

BTW quote part you guys are trying to pick up lol

“For the Xbox, they have to put DirectX and Windows on the console, which is many years old, but for each new console that Sony builds, it also rebuilds the software and APIs in any way it wants.”
 
Last edited:

martino

Member
Again.

DX12U is a logo or label... what that means? That means that any hardware that supports DX12U label needs to support 4 features: ray-trading hardware acceleration, support to Mesh Shaders, Variate Rate Shading and Sampler Feedback.

These are the 4 features that Are required to label DX12U in your hardware.

The API is the same.... it didn’t change... you have the same DX12 released in the past for better or worst.

The guy in the interview made a comparison that MS still uses the DX12 on Xbox Series X instead to made a API specific created/updated to the Xbox Series X hardware and that is true.

DX12 is a generic API made to work across several platforms and that come at a cost... it is not made specifically to use one single platform potential... unlike the PS5’s API where Sony build it specifically to use the hardware of PS5.
The biggest advantage of DX12 API is that it makes development across several platforms easier because you can use a common API.

You guys keep trying to make the CryTek dude wrong when he doesn’t say nothing wrong at all.

nice narrative but the fact is RDNA2 features are built to work the more efficient possible with dx12.
So why would dx change when he is the target ?
What is lover level than what dx12 do ? (your link) and are you implying xsx will not have lower access in his case only ? (where are the proof)

the narrative everything is custom on sony and nothing is on ms only show bias to me.
 
Last edited:

ethomaz

Banned
nice narrative but the fact is RDNA2 features are built to work the more efficient possible with dx12.
So why would dx change when he is the target ?
What is lover level than what dx12 do ? (your link) and are you implying xsx will not have lower access in his case only ? (where are the proof)
No narrative just facts.

The API itself is the proof lol
The same code works across several hardware... PC, Xbox One, Xbox One X, Zbox Series X.
That is abstraction... a API made to work with several platforms and not specifics to one.

BTW that is why MS labeled it Untimate.
 
Last edited:
Top Bottom