Hirdetés

2024. május 3., péntek

Gyorskeresés

Útvonal

Fórumok  »  Videokártyák  »  AMD GPU-k jövője - amit tudni vélünk (kiemelt téma)

Téma összefoglaló

Téma összefoglaló

  • Utoljára frissítve: 2017-08-30 10:47:05

LOGOUT.hu

A legtöbb kérdésre (igen, talán arra is amit éppen feltenni készülsz) már jó eséllyel megtalálható a válasz valahol a topikban. Mielőtt írnál, lapozz vagy tekerj kicsit visszább, és/vagy használd bátran a keresőt a kérdésed kulcsszavaival!

Összefoglaló kinyitása ▼

Hozzászólások

(#4982) Abu85 válasza gbors (#4970) üzenetére


Abu85
HÁZIGAZDA

Az NVIDIA messze van attól a modularitástól, amilyen a GCN. Pont ez az oka annak, hogy a Fermi csak a GF104/114-es GPU szintjén jó. Fölötte túl nagy, bár igaz, hogy más a célja is, de alatta egyszerűen a rendszer nem jól skálázódik. Túl nagy lesz a kisebb lapka. A GF106-Brats elég jó összehasonlítás. A feldolgozók valóban modulárisak, de a fő probléma a komplex vezérlés, ami eddig nem volt megoldva sehol. A GCN-ben az ACE motor látja el ennek a feladatát. Ez teljesen moduláris, sőt akár ki is hagyható a rendszerből, bár nyilván ez a hatékonyság rovására megy. A Kepler még nem lesz ilyen az NV-nél, de a Maxwell esetében már dolgozni kell egy hasonló rendszeren, mert csak így lehet normálisan skálázni.
A Bulldozer modul a hozzátartozó L2-vel 30,4 mm^2, míg a Sandy Bridge mag 29,5 mm^2 a hozzátartozó L3 szeletével. Abszolút nem nagy különbség. Egy szálon a Sandy Bridge mag a jobb, míg erős throughput terhelésen a Bulldozer modul. Ez nyilván tervezési eltérés. A különbség itt az L3-nál van. Az Intel azt a felépítést erőlteti, ami a korábban törölt Larrabee-kben volt. Az AMD nem akarta felvállalni ennek a kockázatát, mert kétszer nem működött, így kérdés, hogy harmadjára jó lesz-e. Inkább maradtak az L3 esetében a MOESI-nél. Arra az integrációra amire az AMD készül jobb döntés is, mert a GCN is rendelkezik normális belső cacheszervezéssel, és a Bulldozer is. Innentől kezdve az L3 egy kommunikációs elem lenne, vagyis 1-2 MB elég is. Az Intel az integrációt az L3-ra építi fel, és a Larrabee magok beépítésével is élni fog az x86 memóriaarchitektúrájának alapszabálya, vagyis egy mag L3-ba kiírt eredményét egy másik mag a következő ciklusban olvashatja. Erről megoszlanak a vélemények, hogy ez mennyire jó. A két elkaszált Larrabee mutatja, hogy vannak buktatók. Az Intelnek még egy dobása van a MIC fejlesztéssel és dönteni kell a Skylake integrálásáról. Nyilván a kérdés jelentős, mert ha a MIC bukik az még nem tragédia, de a Skylake esetében már biztosra kell menni. Ha továbbra sem működik a Larrabee, akkor szerintem nem fogják integrálni.
Az NV CPU-magja az eddigi ARM-magokhoz képest viszonylag nagy lesz. Az ARMv8-at még sok utasítással kiegészítik, hogy illeszkedjen az igényeikhez. Persze valószínű, hogy nem lesz akkora, mint a mai x86-os csúcsmagok. Ezt majd extra magokkal próbálják ellensúlyozni. A heterogén érában ennek nincs nagy jelentősége. Ha egy mag nem hozza azt, amit a másik cég egy magja, vagy modulja, akkor dobsz be még egyet, és a probléma letudva. Az NV-nek még az SM-ben kell dolgoznia. A CUDA magokban az FP skalárt vektorfeldolgozóra kell cserélni. Ez is a hatékonyságot növeli.

A Fusionbe nem kell 32 CU. Elég 8 például, ehhez kell egy vagy két ACE, de inkább egy. Egy 1 MB-os L3 és két CPU-modul. Az Intel sem fog a Skylake-be 50 Larrabee magot építeni. Itt azon van a hangsúly, hogy az általános számításoknál a GPU egyszerűen sokkal hatékonyabb lehet a párhuzamos feldolgozás mellett. Egyetlen GCN CU például annyi flops/ciklust tud, mint egy Interlagos processzor. Persze nyilván az órajel nem egyezik, így a valóságban négyszer több GCN CU kell, de még így is nagyságrendekkel hatékonyabb az egész. Ugyanez igaz az Intelnél és az NV-nél is, csak más arányokkal, a GPU-s feldolgozás a throughput terhelés mellett elképesztően hatékony.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Útvonal

Fórumok  »  Videokártyák  »  AMD GPU-k jövője - amit tudni vélünk (kiemelt téma)
Copyright © 2000-2024 PROHARDVER Informatikai Kft.