de 590 vreet dan ook veel te veel stroom en nvidia had destijds enorme moeite om hem uit te brengen, Hij kwam dan ook veel en veel later op de markt dan zijn tegenhanger van AMD. Die van AMD destijds was 2 x 256 bits. Ook al kwam hij heel veel maanden later op de markt dan de 6990 van AMD, de 590 was qua prestaties alleen ok op spellen waar nvidia het al goed deed. Het was geen indrukwekkende kaart, met name niet door stroomverbruik.
Nu bij de 600 series heeft Nvidia die fout niet gemaakt en AMD wel en je ziet nu het omgekeerde. Namelijk dat AMD nog de kaart in de winkel moet zien te krijgen, dat we de prijs nog niet kennen en dat er al bij voorbaat getwijfeld wordt aan de prestaties.
Het is inderdaad zo dat de RAM niet de meeste stroom vreet, echter voor de spellen is de bandbreedte naar de RAM vaak de bepalende factor en de technischde meest limiterende. Zover ik weet is er maar 1 bekend spel een uitzondering hierop, die schaalt lineair met de cores.
Verder is het zo dat GPU's anders georganiseerd zijn dan CPU's. Bij cpu's heb je eerst een enorme L1 cache die echt 99.9% van de ellende opvangt, daarna is er een L2 cache en een L3 cache. Alle caches kunnen zowel data als instructies lezen en schrijven.
Dat werkt anders bij GPU's.
Er is voor een 32-64 cores maar een kleine L1 cache. In geval van AMD heb je maar een hele kleine instructiecache van rond de 8 KB en 32 KB schrijven. In geval van Nvidia mag je kiezen als programmeur , de gehele L1 is daar 64KB en die kun je op 2 manieren opspliten in instructies en data.
Feitelijk gesproken is de L1d te klein van Nvidia om over de 32KB local shared memory van AMD te zwijgen - die is bovendien ook vet trager dan de cores - dus je wilt die niet gebruiken in een streammodel.
Dus van de registers ga je boem naar de RAM toe, waar bij het streamen we de L2 natuurlijk alleen als obstakel kunnen zien, want er wordt zo ontzettend veel gestreamed dat het me een raadsel is waarom ze zulke kleine L2's gebouwd hebben.
Na de registers valt op GPU's feiteljk dus de bijl en schrijf je praktisch gesproken direct naar de RAM. Lezen van de RAM gaat wel via een hele kleine L2 buffer van 512KB maar, afhankelijk van welk model gpu we kiezen, maar het scheelt niet veel, die kleine L2 moet dus met een stuk of 6 kanalen dus al die honderden cq duizenden cores van data voorzien. L3 is er niet.
Als we het per core uitrekenen praten we over minder dan een handvol kilobytes per core aan registers + L1 cache, zeg maar gewoon 1 tot 4 kilobyte aan registerfile en dan is het BOEM de DDR5 RAM waarvandaan je dient te streamen.
Nu de bandbreedte. Zeg we nemen een 2048 streamcore AMD gpu van rond de 900Mhz.
in theorie kan elke core in single precision floating point dus van zijn lokale registers 2 floats afhalen en dan een instructie daarop uitvoeren.
dus de bandbreedte van de cores is uitgedrukt in bandbreedte gigabytes per seconde:
2048 cores * 0.9Ghz * 2 floats * 4 bytes per float = 14745 gigabytes per seconde.
De memory controller, wat haalt hij. Zo rond de 150GB/s meet ik hier in gpgpu bij AMD.
We snappen dat met een paar kilobyte registers per core, een L1d die je feitelijk niet gebruiken kunt bij AMD (is overigens 2 cycles latency, dus ook vet trager dan de registers) en een overkill aan bandbreedte wat de cores kunnen afleveren, dan is de memory controller dus de zwakste schakel.
Dus dat is een enorme klap van 14+ TB/s die DANG neerkomt op de memory controllers die met moeite iets meer dan 150GB/s trekken.
Let wel ik heb alleen de memory READs gerekend. Over de writes heb ik 't niet eens... ..terwijl die RAM bandbreedte de volledige bandbreedte is...
RAM is dus enorm belangrijk op een GPU.
Een GPU is voor de meeste spellen zo goed als zijn bandbreedte naar de RAM.
Stilstaan bij hoe goed of slecht een RAM ontwerp is, dat is dus geen luxe.
[Reactie gewijzigd door hardwareaddict op 25 juli 2024 01:43]