HollyGamer said:
But the scenarios is different on polaris and Fiji, and modern gaming with directX 12 (or even directX 11) and use advance Vulkan and Opengl and Cl say the other way around . So Polaris toe to toe with Fiji at least it super close.
|
Not that relevant for consoles as developers are more likely to leverage the low-level API's instead to extract more performance.
And Polaris isn't toe to toe with Fiji. I provided evidence for this.
HollyGamer said:
It's possible that's why Sony wait for another year (2020) release date , yes cost will be major problem with that , but for a console that will last for 6 to 7 or even 8 years it's not that difficult. Also Adored TV have made some calculation on Chip silicon size/price possibility with the size of 250 mm2 PS4 Pro polaris and the possibilities of using the same size chip on PS5 , his calculation is on the spot
https://www.youtube.com/watch?v=qgvVXGWJSiE&t=2223s
|
A random youtube video, evidence does not make.
250mm2 includes the entire chip by the way. That includes the CPU, memory controller, caches, fixed function logic and so on... If you think you are going to fit 73 CU's into that... Well. Not sure what to tell you.
HollyGamer said: Don't bring vega 64 or or even vega VII , Navi even tho it's still has the same GCN it might have modification due to the small die.
|
Are you suggesting that Navi will need less transistors per CU than Vega 7? Do you have evidence for this?
HollyGamer said: Hell Many people doubt Sony able to pull 4,2 on PS4 pro even you are doubt Microsoft able to pull 6 teraflop on 500 USD price console. |
Source please.
HollyGamer said: Vega 56 is not a beast compared to high end GPu, but compared to Polaris or even Hawai is big , and on top of that the benchmark shows it's an igpu (an igpu as powerful as vega 56) is amazing. |
The complete performance isn't amazing, whichever way you cut the cake. It's mid-range.
Bofferbrauer2 said:
Are you guys really comparing Polaris to Fiji??? That's like comparing a 1060 to a 980Ti, of course the older one would win that duel.
|
We are. Because the argument is where Navi falls in AMD's product stack and how it compares to other parts.
Bofferbrauer2 said:
Btw, It think Polaris is Tonga's successor, not Hawaii's. Otherwise it would have been named 490 instead of 480. The fast that Polaris has less CU than Hawaii should also give that away, and both are effectively at the same performance.
|
Actually both.
Because Polaris had an x90 part. Aka. RX 590.
Intrinsic said:
Vega 64 ad Vega 7 are really bad references to make when talking about next gen consoles. And that is primarily becase they both use HBM RAM. The memory ontrollers for those takeup around 30% of the die space available in those chips!
|
Wide GDDR6 buses can also take up a fair amount of die space as well, granted not likely as much as HBM, but certainly a step up over 256-bit GDDR5 controllers.
Intrinsic said:
If you really want to analyze die space usage ou have to do a lot better than that. Take the XB1Xfor instance, it has 12GB of GDDR5 RAM.. its memory controllers fit into a chip thats about 350mm2 along with a CPu and 40CU GPU. Going from 12GB of GDDR5 to 24GB of GDDR6 (just an example) will take the same amount of space with regards to on chip memory controllers. Its been calculated that the Ryzen CPU will take about the sameamount of space on a die that jaguar takes right now. That leaves a gd dalaount of space for the GPU.
|
Ryzen 3 is about 80mm2 for an 8-core complex at 7nm.
Jaguar is 24.8mm2 for an 8-core complex at 28nm.
That doesn't include things like I/O.
At the end of the day, CPU cores themselves tend to be relatively small anyway, it's everything tacked on to hide bandwidth and latency (I.E. Caches) that drives die sizes of CPU's up.
Straffaren666 said:
I wouldn't rule out 72 CUs (73 CUs seems strange). That's twice the amount of the Pro which is built on 16nm. TSMC claims their 7nm yields about a 60% power reduction and 3x transistor density improvement compared to their 16nm process.
|
AMD will be required to sacrifice some of the "density" in order to reduce leakage and noise so they can dial up clock rates.
Straffaren666 said:
Vega 7 is not a good example as it wasn't designed for 7nm from the ground up, which Navi is.
|
Navi is Graphics Core Next based... Graphics Core Next isn't really designed for any particular node, it started life out at 28nm remember, got shrunk to 14nm and then 7nm... All the while iterative updates were introduced into the core design to extract more performance.
Navi isn't a new design built from the ground up. That's the ultimate crux of the issue, it's just more Graphics Core Next, nothing special.
At the end of the day, regardless of GPU, AMD's designs are inefficient, old and outdated... And sadly that is going to reflect on the capabilities of the next-gen consoles.
Intrinsic said:
Ok.... at 28nm the PS4 had a die size of 348mm2. This shrunk to 321mm2 in the 16nm PS4pro. Yet they were able to double the amount of CUs in the Pro compared to the base PS4.
|
You are better off comparing the Playstation 4 Slim against the Pro, they are built at the same node.
The Pro doubles the Slims CU count, but die size increased by around 32mm2.
Intrinsic said:
I have said this multiple times already....... until we actualy see working Navi basd hardware, no one (myself included) can say with any certainity what is or isn't possible all based on assumptions made from an older microarch.....
|
We can already get an idea of allot of the design principles of Navi on the already established general design principles of Graphics Core Next that date back to the launch Xbox One and Playstation 4.
Straffaren666 said:
It's true that AMD hasn't released a GCN based GPU with more than 4 SEs or 64 CUs and there probably is a technical reason for that. However, scaling up the amount of SEs/CUs seems like a smaller change than for instance adding the FP16 ISA/foveated rendering or unifying the CB/DB caches with the L2 cache, which has been done between various iterations of the GCN architecture. I believe the 64 CU limit is located in some part of the GPU front-end and the main reason for not crossing that limit so far has probably been more due to the die size and power consumtion prohibiting it anyway, than technical hurdles to redesign the GPU front-end.
|
Graphics Core Next already has a multitude of bottlenecks inherent in it's design, it's why it's a compute monster, but falters in gaming.
Blowing out functional units will simply compound those inherent issues.
In saying that, Graphics Core Next is also highly modular, AMD can pick and choose what parts of the chip to update and leave the rest identical, which reduces R&D and time to market.
But the main reason for why Graphics Core Next won't scale beyond 64 CU's is simple.
Load balancing. - Which also occurs on the front end as well... And because the Geometry and Raster Engines are tightly integrated in a multi shader-engine outlay design like Graphics Core Next... The screenspace is split between the 4 engines and their respective clusters evenly.
Imagine you are splitting your display into 4x parts, the load balancing needs to be dynamic, so those parts shift so that the load is equal across all 4x shader engines.
What happens if we add more Shader Engines? It reduces the utilization across all the CU's. - There is only so much Screenspace that you can dynamically allocate with usable work to keep the entire chip busy. - One of Graphics Core Next's largest issues is effective utilization... Which was a much larger issue with the prior Terascale designs, hence why AMD introduced VLIW4 to increase utilization.