-
IT café
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!
Új hozzászólás Aktív témák
-
#41628
Petykemano
veterán
lezso6
#41627
Petykemano
veterán
válasz
lezso6
#41627
üzenetére
Ez alapján tökre illik rá, hogy a gpu nem késleltetésérzékeny. Csak közben de.
De had értsem meg én is, hogy ha van egy wave64, ami a max 16 széles feldolgozótömbön 4 órajelciklus alatt tud lefutni csak és a 4x16-os CU-n 4 wavefrontnak kellene folyamatosan futnia a maximális kihasználtsághoz.
Akkor miért kell 64 hosszú (?) Wavefrontot futtatni? Ez minek a hülye ötlete volt?
Vagy miért kell 16-os tömbökre bontani a CU-kat, miért nem 64, amit szükség esetén Lehetne bontani 2/4 felé?Találgatunk, aztán majd úgyis kiderül..
-
Abu85
HÁZIGAZDA
válasz
lezso6
#41627
üzenetére
Ez nem pont így működik. A multiprocesszornak van egy minimum száma a SIMD-eken párhuzamosan futtatható wave-ekre. A GCN-ben 10, a Polarisban 8, a Navi-ban 20. De igazából, ha eléred a 7-et, akkor bőven van elég wave átlapolni a késleltetést.
A GCN-ben egy Wave64 az négy ciklus alatt fut egy SIMD16-on. Az RDNA-ban egy Wave64 két ciklus alatt fut egy SIMD32-ön, de a variálható wavefrontméret miatt a fordító úgy is fordíthatja a kódot, hogy egy Wave32 fusson egy ciklus alatt a SIMD32-n. Egyszerre mindig csak egyel eteted mindet, a különbség az, hogy bizonyos kódoknál kedvezőbb a throughputra helyezni a hangsúlyt, míg más kódoknál a latency-re való optimalizálás hatékonyabb. Ezt amíg a korábbi GPU-kban direkten optimalizálva kellett megoldani a shader kódon belül, addig a Navi esetében már a hardver kapott olyan képességeket, hogy a fordítón keresztül felismeri a kódok jellegét, és annak megfelelően NOC vagy NTC módban futtatja.Ez is kihasználtságlimites. A másik opció a függőséglimit, de az SIMT dizájn miatt nem alakulhat ki. A kihasználtságlimit továbbra is létező jelenség marad, mert azért egyre sűrűbbek azok az übershaderek, mik lezabálják a regisztereket, de inkább az LDS-t. Például a DICE a BF5 esetében azért optimalizál az L1 reuse-ra, mert a regiszterek esetében a "hit" ablak, hát eléggé kicsi, és ez nem lesz másképp a Navi esetében sem, tehát ebből a szempontból azért még nem akkora változás, viszont az L0-L1 cache-dizájn nagyon hatékony, nem csak méretesek a gyorsítótárak, de a késleltetésük is alacsonyabb lett a korábbi dizájnokhoz képest. Ez például jelentős előnyt a DICE számára. Ettől persze a kihasználtságlimit elméletben megmarad, csak messze nem olyan erősen, ahogy a mostani hardvereken úgy általában. Itt a statikus erőforrás-allokáció problémáira még mindig optimalizálni kell, de ez gyakorlatilag minden GPU-n így van.
Variálható wavefrontméretet csak az Intel kínált (azt is igazából rosszul, mert amíg mondjuk a geometry shadekhez tényleg jól igazodott a hardver - rohadt gyors itt, szó se róla, addig a compute shadereknél már nem volt optimális a működés, mivel ez a bonyolult hardverdizájn elfogyasztotta a tranzisztorokat, és nem volt lehetőség gyors LDS-t kiépíteni ... és itt szopikázik az Intel főleg a DX12/Vulkan játékoknál, hiszen a nagyon lassan elérhető L3 cache az LDS). Az AMD és az NV korábbi architektúrái nem tudtak igazodni a kód jellegéhez. Ezért mondták folyamatosan az AMD és az NV emberei, hogy mi a jó módszer a dizájnjaiknak. Figyeld meg, hogy az AMD majd a jövőben nem fogja annyira kihangsúlyozni, hogy vigyázni kell ám az erőforrás-allokációra, mert kell a wave-szám, hogy működjön a multiprocesszor. Egyszerűen a hardver lett toleráns azokkal a kódokkal szemben, amelyek a korábbi tipikus GPU dizájnokon amúgy problémát jelentettek, például a divergens kódok, de most maga a működés tud a kódhoz igazodni.
(#41631) Petykemano: A wave/warp méretek kialakításánál az történik, hogy a hardver képes legyen annyi wave-et futtatni, hogy azok biztonsággal áthidalják a memóriaelérés késleltetését. Mondjuk a GCN-en egy wave64 futtatása elindul. Kiderül, hogy kell az adat hozzá, azért elmegy a Bélabá (ő a GPU adathordára) a memóriába, de amíg Bélabá hozza az adatot a szatyrában, addig kő (ez ilyen paraszthardver) valamit futtatni a GPU-n. Ezért elindul egy másik wave64, de annak is kell adat (természetesen sok a Bélabá), és így tovább. Egy idő után ugye megjönnek az adatok, és ha van mondjuk 7 wave, akkor tuti, hogy lesz egy olyan wave, ami addig dolgozik, amíg Bélabáék hozzák a cuccost a többi wave-nek.
Na most a kérdésedre az a válasz, hogy persze a GCN is működtethető lenne úgy, hogy mondjuk wave16-ok futnak, meg a Turing is működtethető lenne úgy, hogy wave16 fut. Nem ezzel az elméleti lehetőséggel van a probléma, hanem azzal, hogy Bélabáék nem elég gyorsak ilyen kis wave-méretre, tehát a variálható wave-mérettel többet vesztesz, mint nyersz, mert nem hoz Bélabá annyi adatot hozzájuk, hogy elfedjék a memória késleltetését. Erre tehát tervezni kell a hardvert, nem működik ez csak úgy magától. Ezért nincs variálható wave-méret a korábbi GPU-kban.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új grafikus processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva. Architektúra, esélylatolgatás, érdekességek, spekulációk, stb.
