Yup. Navi 10, Navi 14 en nu ook de XSX chip hebben die verhouding van vier ROPS per RBE. Navi 12 idem, maar dat is eigenlijk een Navi 10 met HBM2.

Hoe waarschijnlijk zou een verdubbeling van de ROPs dan zijn naar 128 in Navi 21? Het zou een primeurtje zijn voor AMD, volgens mij zijn ze nog nooit voorbij de 64 gekomen.
Ik denk zeer waarschijnlijk omdat ik niet zie hoe AMD anders met iets fors snellers moet komen. RDNA is net zoals GCN vrij top down georganiseerd. Er is een centrale hardware scheduler die de baas is in de videokaart. Die stuurt een aantal shader engines aan met elk twee shader shader array's en een set backend units.
Dit dus:
AMD heeft voor de shaders in RDNA ook gekozen voor dubbele units voor CU, array en engine. Ik denk dat dit ingebakken is en niet zal veranderen. De logische conclusie is dat ze voor Navi 21, nog twee engines toevoegen. Dan krijg je 80CU's, acht shader array's met elk zestien ROPS voor een totaal van 128 en vier shader engines.
Als ze het niet doen, dan krijg je vier shader array's die niet meer 10CU's diep zijn, maar 20CU's diep. Backend hetzelfde houden is dan gewoon vragen om "Vega 2.0". Backend verdubbelen is waarschijnlijk nog steeds niet optimaal omdat je alsnog maar vier shader array's hebt die je alles moet laten doen. Dat is niet erg flexibel en gaat waarschijnlijk ten koste van occupancy, dus het percentage van de CU's die daadwerkelijk iets doen tijdens een clock cycle. Dat was een van de vele problemen van Vega, naast natuurlijk de backend zelf, de lage clockspeeds, het verbruik en de inefficiënte CU's.
Navi 22 gaat denk ik ook een interessante worden. Omdat je met paren van shader array's in engines zit, denk ik dat zes shadar array's er niet inzitten. Ik denk dat Navi 22 dan ook twee engines en vier array's heeft en iets dieper gaat zijn qua CU's.
XSX is dat in ieder geval. Daar zijn het er al 12 of 14CU's per array i.p.v. 10CU's.
Dat heeft zo zijn voor en nadelen. Voordelen zullen zijn dat het de chip iets simpeler en kleiner maakt. Het grote nadeel is dat de backend waarschijnlijk relatief zwakker is dan Navi 10 of Navi 21. Occupancy zou hier ook iets minder kunnen zijn omdat je wederom zulke diepe array's hebt zoals bepaalde GCN's ook hadden. Dat maakt het gewoon wat lastiger om alle CU's van afdoende werk te voorzien.
Het verschil met GCN is dat je nu veel betere CU's hebt die ook niet meer alleen shaders doen, maar ook RT. RDNA2 haar RT lijkt in staat te zijn tot een vrij serieus maximaal aantal rays, maar waarschijnlijk gaat die maximale output wel ten koste van wat shader taken. Dat is immers ook zo voor Turing en Ampere. Het is hybrid RT waar de shader ALU's in de feedback loop zitten, maar de RT zelf word gedaan door aparte rekeneenheden. Het nadeel met RDNA2 is dat er binnen de TMU van een CU gekozen moet worden tussen textures of RT. Vanuit de scheduler zal er dus rekening gehouden moeten worden dat sommige CU's hun TMU in RT mode staat en geen textures kan mappen. Die kan je dan beter inzetten voor logic en ernaast RT draaien. Laatste is dat ik ook niet uit wil sluiten dat AMD toch iets van denoising gaat implementeren voor hun RT. Dat zal met de shaders moeten gebeuren en die kunnen dan geen floating points of logic doen.
En dit is ook het verhaal van PS5 vs. XSX waar inmiddels de
console wars in volle gang zijn. Sony koos voor een relatief kleine 36CU RDNA chip met een serieus hoge clockspeed van 2,23GHz. De backend van de GPU draait ook gewoon op de clockspeed en die zal zeer snel zijn. Sony probeert de relatief geringe frontend maximaal te benutten met die SSD. Het nadeel is dat Sony waarschijnlijk wat minder extra capaciteit heeft voor RT. Die heeft Microsoft juist wel, maar hun chip heeft waarschijnlijk minder occupancy en beduidend lagere clockspeeds die de backend ook geen plezier doen. Ik denk dat ze op shader niveau aardig vergelijkbaar zullen zijn, maar Microsoft iets betere RT zal hebben en Sony meer kan met spectaculair grote spelwerelden vanwege de SSD.
Maar die twee hebben denk ik ook relevante voor ons. We weten dat de XSX eigenlijk een 56CU chip is met 4CU's uitgeschakeld. Sony heeft alleen 36CU's gezegd. Ik vermoed eigenlijk dat het er daar 40CU's zijn, maar ook 4CU's uitgeschakeld. Wat stopt AMD precies om die toch al ontwikkelde configuraties naar PC te brengen als Navi 22 en Navi 23?
Hoe meer ik er namelijk over nadenk, hoe waarschijnlijker ik het eigenlijk acht dat Navi 23 op 36 of 40CU's uit gaat komen met een 256bit bus met 448GB/s. Dezelfde configuratie als de RX5700 series, iets sneller, efficiënter en veel goedkoper met RT.
Dan Navi 22 met 56 of misschien 60CU's met 512GB/s. Ik denk dat 64CU's eigenlijk alweer te veel is en je daar tegen dezelfde problemen begint aan te lopen als Vega. Voor Navi 22 denk ik dat AMD misschien juist de snot uit het ding wil clocken vanuit de fabriek om die backend maar te versnellen. Zelfs dan nog denk ik dat deze het minst "gebalanceerd" zal zijn van de drie. Dus iets minder qua shaders en iets beter qua RT en logic omdat je die extra CU's hebt.
Ik zou eigenlijk niet verbaast zijn als Navi 22 qua shader prestaties een tikje tegenvalt vergeleken met Navi 21 en Navi 23 en qua RT een tikje beter is dan Navi 21 of Navi 23. En ik zou daar vrede mee hebben. Immers koop ik waarschijnlijk een Navi 22 voor Witchertracing.
Edit: bedacht me ook net dat dit allang gelekt is.
Zag ook net dat iemand al de moeite heeft genomen om het uit te tekenen.
Komt ook bij dat het qua L2 cache configuratie dus kennelijk geen 384bit bus kan zijn. Ja, dan is HBM2E dus ook veel waarschijnlijker.
[
Voor 5% gewijzigd door
DaniëlWW2 op 11-09-2020 15:56
]
Never argue with an idiot. He will drag you down to his own level and beat you with experience.