Ik snap werkelijk niet waarom iedereen 4096SP's maar blijft herhalen.
Ik heb het al eerder gezegd dat 64CU een GCN waarde is omdat 64 een getal is dat kan als je verdeeld tussen vier pipelines. Het was voor GCN vrij zinloos om voorbij de 64CU of eigenlijk voorbij de 48CU's te gaan.
Binnen GCN was er botweg te veel vraag en te weinig aanbod van geheugenbrandbreedte voor de zeer diverse rekentaken die een game vereist. Als je extra CU's toevoegde, dan schaalde deze vaak niet goed mee. Het probleem daar was dat naarmate er meer CU's waren, deze allemaal toegang nodig hadden tot een relatief kleinere hoeveelheid cache en VRAM. Het resultaat was constante opstoppingen en problemen met utilisatie. Daarom wonnen GCN's nog wel eens fors met meer geheugenbrandbreedte. HBM en HBM2 zijn juist zo zwaar doorgedrukt door AMD omdat ze zich dit maar al te goed besefte en er op de korte termijn niks beters zou verschijnen.
Dit probleem van een grens aan het parallel maken van berekeningen heeft te maken met Wikipedia: Amdahl's law en eigenlijk meer met Wikipedia: Gustafson's law. Je kan niet alle berekeningen perfect parallel maken, maar wel veel. De truc is om zoveel mogelijk berekeningen uit te voeren, met zo weinig mogelijk fysieke hardware. Je probeert altijd om de utilisatie van hardware zo hoog mogelijk te maken. Een van de beste manieren om dit te doen, is meer geheugenbrandbreedte. Helaas ontwikkeld geheugen zich al decennia, beduidend trager dan de fysieke rekeneenheden. AMD ging HBM2 echt niet zomaar zo doordrukken. Ze hadden het nodig.
Daar had GCN een probleem, naast de inefficiënte scheduling CU zelf.
Nu zijn we alleen bij RDNA waar ze juist deze twee dingen zo overduidelijk hebben aangepakt. Ik denk echt niet dat RDNA nog steeds een vier pipeline limiet heeft. Die limiet zou er wel eens kunnen zijn geweest omdat GCN zulke geheugenbrandbreedte beperkingen had. Voorbij de vier pipelines zit er waarschijnlijk nauwelijks schaling in. Daarnaast zou het toevoegen van extra pipelines op zich, ook nog eens voor grotere problemen kunnen hebben gezorgd.
RDNA, tenminste Navi 10 maar ik denk elke RDNA, heeft een harde ontwerpregel. Twee CU's binnen een pipeline zijn gezamenlijk verbonden als een duale CU en deze delen een cache structuur. Navi 10 is dan 10CU's diep per pipeline. Ik betwijfel of scheduling heel veel meer kan. Nee, ik denk dat je voorbij die 10CU's per pipeline, beter extra pipelines kan toevoegen voor betere parallele prestaties.
Hierom denk ik dus dat de volgende logische stap, 50% groter is dan Navi 10. Dat is 60CU/s/3840SP's met een 384bit bus. Dan zit je op 384 x 14Gbit : 8 = 672GB/s. Daarboven zou nog een extreem 80CU, 400nm2+ monster kunnen plaatsen met een 4096 bit bus en 16GB HBM2. Dan zit je op 1024GB/s. Schaalt RDNA nog steeds redelijk op dit niveau, tweemaal zo groot als Navi 10, dan zal zo'n chip, de RTX2080Ti afmaken.
Never argue with an idiot. He will drag you down to his own level and beat you with experience.