It cannot be Scarlett duo to bus, but could be PS5, because if we are honest its hard to see it being anything else.
Or, it can be an unannounced product unrelated to either system.
It cannot be Scarlett duo to bus, but could be PS5, because if we are honest its hard to see it being anything else.
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.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.
I think @chris1515 has a screenshot of the now deleted Flute benchmark. You can make your own specs from that.
Found it:
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.
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..
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.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.
OK, my own subjective analysis: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.
It does?- 154ns latency gives us GDDR(x) ram
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.
It's worse than LPDDR4X: it's GDDR(x)
This is the userbenchmark test of the Subor chinese console with 8GB of GDDR5:We've been through this before...
Why is GDDRx worse in latency than DDR4, let alone LPDDR4X?
What spec in modern GDDRx makes it have higher measured latency than modern DDR4?
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 is the userbenchmark test of the Subor chinese console with 8GB of GDDR5:
https://www.userbenchmark.com/UserRun/13631632
tested latency: 139ns (flute, 154ns)
I think it's because people used to think CAS cycles == latency.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...
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.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.
Yes but that is measuring more than just the memory type. It includes the entire memory path.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.