Hirdetés

Hirdetés

Új hozzászólás Aktív témák

  • Abu85

    HÁZIGAZDA

    válasz lezso6 #41624 üzenetére

    Ez még mindig túlegyszerűsített. Tehát a GCN-nél egy SIMD16 10 wave-et képes futtatni és egy wave lefuttatásához négy ciklus kell. De nem azért kell ennyi, mert 3 ciklusig pihizik, hanem azért, mert egy wave 64 lane széles, tehát egy wave-ből egy ciklusban csak 16 lane-t futtat. Most itt megjegyezném, hogy a Polaris esetében már 8 wave-re lett csökkentve az IB mérete, de ez igazából nem túl lényeges, 6 wave fölött elég jól le lehet fedni a memóriaelérést. Ha most minden klappol a GCN-ben, akkor a peak érték VALU szintjén 1 lane/clock.
    És a munkakiosztás is számít, a GCN úgy működik, hogy megvan az adott erőforrásigénye a feladatnak, és arra futtat x wave-et. Tegyük fel, hogy ötöt. Ilyenkor az új wave-ek adagolása úgy történik, hogy mindegyik SIMD16 kap egy új wave-et, és ezek közül maximum egy lehet vertex shader wave, mert azok tipikusan eszik a regisztert és a cache-t. A compute egy picit bonyolultabb, mert ott az LDS is bejön a képbe, mint limit. De ugye asznkron compute-ban tudod mixelni a grafikai és a compute munkákat, csak legyen elég erőforrásod, hogy legalább 4 wave fusson per SIMD16. De persze van egyébként kiterjesztés is, ami a wave_limit, mert sokszor a cache-hit többet ér, mint a memóriaelérés átfedése. Nagyjából hasonlóan működik az összes többi modern GPU, az arányoknál van különbség, de ugyanúgy lehet egy kódnál fontosabb a cache-hit, mint a throughput, ugyanúgy limit lesz az LDS és a regiszter mindenhol, leginkább az LDS, stb. Ez az, amit értettek azon, hogy a mai architektúrákat könnyű megtanulni, de nehéz olyan kódot írni, ami igazán jól kihasználja a multiprocesszorok képességeit. Ha sok wave fut az is lehet baj, ha kevés, az is, aztán milyen feladatokat érdemes egymás mellett futtatni, hogy legyen elég regiszter+LDS ahhoz, hogy elég wave futhasson, stb.

    A Navi ezeken annyit változtatott, hogy a multiprocesszor olyan robusztus, hogy lényegében egy "just works" típusú rendszer lett. Tele van cache-sel, képes a saját működését a munkafolyamathoz igazítani, az ütemezés a cache tartalmához igazodik. Ha a késleltetésből származik elő, akkor úgy működik, ha a throughputból, akkor úgy. Tehát lényegében írsz egy kódot, és minden olyan optimalizálás, amit ma azért csinálsz, hogy igazodj a hardverek limitjeihez, a munkacsoportok mérete ne hasson rosszul a vektorregiszter lokalitására, ne legyenek rossz hatékonysággal használva az I-cache-ek (ez explicit API-val kiemelten fontos), a wave-ek tényleg megfelelően legyenek kiosztva, azok a Navinál igazából már nem kritikusak. Lehet ezekre optimalizálni, de arányaiban nagyon gyorsan megvan az az optimális kihasználtság, amiért a GCN-en, illetve a Turingon sokat küzdesz, ráadásul sokszor eltérő optimalizálási stratégiával.

    Érdemes megnézni, hogy a Navi mennyire teker olyan kódokban, amit tipikusan Turingra írtak. Például a BF5 egyes shaderei, ahol kifejezetten arra optimalizál a motor, hogy az L1 gyorsítótár aktívan használva legyen, mivel a vektorregiszterek újrahasznosítási lehetősége tipikusan rövid. A Navinak ez pont csemege, mert négyszer nagyobb L1 gyorsítótára van, mint a többi hardvernek, illetve még van egy extra alacsony késleltetésű L0 gyorsítótár is a két SIMD-re. Mindegy, hogy a shadert Turingra optimalizálták, hardverből le van kezelve az a probléma, amire a DICE optimalizált.

    Ennek egyébként akkor lesz nagy hátránya, ha elkényelmesedik a piac, mert oké, hogy a Navira gyorsan megvan a sebesség (konzolon fut, a PC-s meg majd vesz gyorsabbat mentalitás), de például a GCN, a Turing, és lényegében az összes régebbi GPU nagyon is igényli ezeket az optimalizálásokat. És nyilván ezek azért még maradnak egy darabig, nem is kevés ideig. Tehát nem szabad átesni itt a ló túloldalára.

    [ 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