Next Generation Hardware Speculation with a Technical Spin [post E3 2019, pre GDC 2020] [XBSX, PS5]

Status
Not open for further replies.
Or, it can be an unannounced product unrelated to either system.
Obviously, its just that chances of high performance gaming chip already in QS status that is still unannounced are relatively low. We know AMD discloses semi custom work in their quarterly reports, that is if they have new semi custom partner, they announce it (without specifying name obviously). They haven't done so since announcing Subor, therefore we can say this custom chip likely points into another direction.

For now, we only had Sony/MS gaming console and Chinese Vega based console as G products.That company has gone under now and for them to have such high spec system just ready to be announced and released seems far fetched. Especially when we add other info such as Ariel PCI ID matching Gonzalo, Gonzalo having clear Sony's codename connotations, 16GB of highest spec GDDR6 RAM etc.
 
Obviously, its just that chances of high performance gaming chip already in QS status that is still unannounced are relatively low. We know AMD discloses semi custom work in their quarterly reports, that is if they have new semi custom partner, they announce it (without specifying name obviously). They haven't done so since announcing Subor, therefore we can say this custom chip likely points into another direction.

For now, we only had Sony/MS gaming console and Chinese Vega based console as G products.That company has gone under now and for them to have such high spec system just ready to be announced and released seems far fetched. Especially when we add other info such as Ariel PCI ID matching Gonzalo, Gonzalo having clear Sony's codename connotations, 16GB of highest spec GDDR6 RAM etc.

The thing about absolutes being based on assumptions or even prior understandings (i.e., designs) that these absolutes end-up being dead wrong. I don't even have to mention all those tech-sites/bloggers/YouTubers whom have been wrong about being absolutely sure on something Navi related. The whole Navi architecture being power-hungry or simply a mild improvement over the prior architecture comes to mind (because of a doctored PCB). One thing about console gaming designs over the decades (especially rumored hardware), absolutes shouldn't never be based on assumptions or one source for information. Or unreliable/unverified benchmarks. Authentic documentation dumps, then maybe...
 
And thats great thing about APISAK and Komachi, they dig these products before anyone else and in this case give their opionion on what it actually is. There is no absolutes here, at least not from them.

Personally have no opinion on YT tech vloggers regarding this as info we got can be looked at open minded straight from the source.
 
I think @chris1515 has a screenshot of the now deleted Flute benchmark. You can make your own specs from that.

Found it:
AMD-Flute-semicustom-APU-Zen-2-konzole-UserBenchmark-2.png

How do you infer memory bus width and RAM type from the above?

But they didnt. APISAK found code and posted it. Komachi decoded it and for 1600 said it might be 1.6GHZ because he doesnt know what it could be, as its not the same for G products as is for others.

I think he thought its PS5 for several reasons. PCI ID matches Ariel, which was rumored to be PS5 codename. After that, we found out it is gaming APU with Navi GPU Zen2 CPU and 16GB of GDDR6 on 256bit bus. It cannot be Scarlett duo to bus, but could be PS5, because if we are honest its hard to see it being anything else.

Especially since codename matches Sony products in quite a few ways.

As far as I can tell, this is a bit of a case of circular Chinese whispers. The "Ariel<-->PS5" connection derives from the the same very source. Komachi himself is the one who introduced this. There were no prior rumours mentioning Ariel as a codename relating to the PS5 that Komachi's Gonzalo tweet was confirming. So if the suggestion of Gonzalo being PS5 is predicated on "Gonzalo = Ariel", then there is basically zero indication that "Ariel" has anything to do with the PS5 aside from the original Komachi Gonzalo tweet.
 
Are there any FACTS known about exactly what process any of the next-gen consoles will be using?
We know that they will be fabbed @ tsmc.
We, well I am assuming it will either be in a 7nm or 7+nm process.
Either way the use of the new 7+nm process would probably allow for 10-15% greater GPU performance.

So my current guess would be like zen2 @ 3.2 + RDNA Gen 2 Arch with 36 CU @ 5700 speeds + 10-15% or maybe 40CU's @ 5700 speeds
If the console is on normal 7nm, i feel like 36CU @ 5700 speed is the Max we will get given the power envelope..
 
Are there any FACTS known about exactly what process any of the next-gen consoles will be using?
We know that they will be fabbed @ tsmc.
We, well I am assuming it will either be in a 7nm or 7+nm process.
Either way the use of the new 7+nm process would probably allow for 10-15% greater GPU performance.

So my current guess would be like zen2 @ 3.2 + RDNA Gen 2 Arch with 36 CU @ 5700 speeds + 10-15% or maybe 40CU's @ 5700 speeds
If the console is on normal 7nm, i feel like 36CU @ 5700 speed is the Max we will get given the power envelope..

No facts about that. While it's most likely to be fabbed at TSMC, it's also possible for them to be fabbed at Samsung.

Basically everything outside of what Sony and MS have directly stated is pure speculation.

Regards,
SB
 
How do you infer memory bus width and RAM type from the above?



As far as I can tell, this is a bit of a case of circular Chinese whispers. The "Ariel<-->PS5" connection derives from the the same very source. Komachi himself is the one who introduced this. There were no prior rumours mentioning Ariel as a codename relating to the PS5 that Komachi's Gonzalo tweet was confirming. So if the suggestion of Gonzalo being PS5 is predicated on "Gonzalo = Ariel", then there is basically zero indication that "Ariel" has anything to do with the PS5 aside from the original Komachi Gonzalo tweet.
You have to analyse how userbenchmark label and test the memory and then make assumptions from that with Flute tests. It's tea leaves science because in the end we can only assume the behavior of the tests.
 
You have to analyse how userbenchmark label and test the memory and then make assumptions from that with Flute tests. It's tea leaves science because in the end we can only assume the behavior of the tests.

An explanation of how the bus width and RAM type was arrived at would still be appreciated.

The original post in question stated "we know the RAM type and bus width of the AMD Flute", which now sounds increasingly unlikely that we can say with any confidence we know anything besides the numbers on the leaked benchmark... whatever they mean.
 
An explanation of how the bus width and RAM type was arrived at would still be appreciated.

The original post in question stated "we know the RAM type and bus width of the AMD Flute", which now sounds increasingly unlikely that we can say with any confidence we know anything besides the numbers on the leaked benchmark... whatever they mean.
OK, my own subjective analysis:

- 154ns latency gives us GDDR(x) ram
- 16GB and "0," and "1024" MB * 16 give us 16 chips of 1GB GDDR(x)

Now salt is needed: Single score, sc write: 33.1 (GB/s) could indicate those are 18gbps chips (72GB/s) in a clamshell setup and so GDDR6. That's based of others benchs of DDR4, the single score always seem to indicate the max bandwidth of one ram component, here one chip.

As it's a real bandwidth test, It's often 8% from the max theoretical bandwidth on the DDR4 tests. Here 33.1 is 8.8% from 36 (half of 72). So those could be 18gbps GDDR6, not even downclocked. But that final part is my own interpretation about those numbers. And I am more confident about that part mostly because of the OQA PCB leak which is still the best leak out there (ignoring Gonzalo / Flute obviously).

What is odd in this leak is 16GB only. But that could be caused if the benchmark failed to recognize the clamshell setup of GDDR6. I mean, it already failed to recognized GDDR6.
 
- 154ns latency gives us GDDR(x) ram
It does?

Micron's datasheets for GDDR5 claim a CAS latency between 7 and 24 cycles. Even if it was using the most relaxed setting, at GDDR5's command rate clocks we should have a measured latency below that of DDR4. GDDR6 should be even lower given the even higher command rate.

What if these are actually blocks of 16bit LPDDR4X or even LPDDR5? I don't know how that memory type behaves in measured latency.


EDIT:
Lo and behold, on Anandtech's just released Ice Lake performance article, they're measuring almost 120ns on the system's LPDDR4X @ 3733MT/s:

Ian Cutress said:
The DRAM latencies of course are apples and oranges in this case as Intel’s new LPPDR4X memory controller in the new ICL part doesn’t have a counter-part we can compare to, but as expected the memory latency is notably worse than a desktop part so no big surprises there.
 
Last edited by a moderator:
Wasn't there a latency difference because of the way gpu memory controller work? Which was unrelated to the memory type?

I am not seeing any dramatic timings differences either in the standards or datasheets, so I'm also wondering why there's been a long standing claim that gddrx is higher latency...
 
Wasn't there a latency difference because of the way gpu memory controller work? Which was unrelated to the memory type?

I am not seeing any dramatic timings differences either in the standards or datasheets, so I'm also wondering why there's been a long standing claim that gddrx is higher latency...

This so coming from controller..
 
This is the userbenchmark test of the Subor chinese console with 8GB of GDDR5:

https://www.userbenchmark.com/UserRun/13631632

tested latency: 139ns (flute, 154ns)

That's not a spec, it's a single benchmark result from a rather obscure system that never really got any deep analysis.

Regardless, that test claims the GDDR5 memory was working at 2GHz DDR or 4GT/s, so at half the chips' default 8GT/s which probably means the bench ran in some sort of power saving mode (or rather non-gaming mode) for the RAM.
At equal CAS settings and half the clocks the system would get considerably higher latency.
In fact, at twice the clock speeds and assuming linear scaling due to same CAS settings that system would get around 70ns of latency, which is about what the Ryzen 2000 systems are getting in that benchmark.



I'm also wondering why there's been a long standing claim that gddrx is higher latency...
I think it's because people used to think CAS cycles == latency.
And when the first GDDR5 chips came up with CAS 15 in the datasheet people measured it against DDR3 chips with CAS 9 and assumed it was worse.
 
Last edited by a moderator:
Wasn't there a latency difference because of the way gpu memory controller work? Which was unrelated to the memory type?

I am not seeing any dramatic timings differences either in the standards or datasheets, so I'm also wondering why there's been a long standing claim that gddrx is higher latency...

It shouldn't be. The actual memory modules (type) aren't the cause of latency. It's the actual memory controller design between them that causes this. GDDR memory controllers are much wider (wider memory bus) and GDDR chips are grouped into more channels than DDR. While this design offers more bandwidth and clock-speeds for graphic data workloads, the controller's I/O and management chip design can cause certain latencies to occur, which doesn't necessarily affect the GPU rendering process from rendering things in timely manner.

So, a secondary memory controller (that's more CPU specific) between the CPU and GDDR can be implemented into the APU design or even the CPU itself. IIRC, the PS4/Pro single memory controller is equipped with some additional logic on managing/provisioning the speeds/bandwidth between the processing components (CPU/GPU) and their specific needs when accessing GDDR.
 
That's not a spec, it's a single benchmark result from a rather obscure system that never really got any deep analysis.

Regardless, that test claims the GDDR5 memory was working at 2GHz DDR or 4GT/s, so at half the chips' default 8GT/s which probably means the bench ran in some sort of power saving mode (or rather non-gaming mode) for the RAM.
At equal CAS settings and half the clocks the system would get considerably higher latency.
In fact, at twice the clock speeds and assuming linear scaling due to same CAS settings that system would get around 70ns of latency, which is about what the Ryzen 2000 systems are getting in that benchmark.




I think it's because people used to think CAS cycles == latency.
And when the first GDDR5 chips came up with CAS 15 in the datasheet people measured it against DDR3 chips with CAS 9 and assumed it was worse.
Specs are nice to have but of limited value. Only tests really count. This is a test. Flute is another. I am sure there are plenty others tests that would indicate the same thing.
 
Specs are nice to have but of limited value. Only tests really count. This is a test. Flute is another. I am sure there are plenty others tests that would indicate the same thing.
Yes but that is measuring more than just the memory type. It includes the entire memory path.

Looking at the specs between two memory standards is comparing command sets and electrical timings. Those are exact clocking. If you include the memory controller logic, the cache logic, arbitration logic between cpu/gpu, etc... you can no longer separate which part of the 154ns is the actual memory type involved.
 
Status
Not open for further replies.
Back
Top