- Mini-ITX
- Amazon Kindle
- Azonnali processzoros kérdések órája
- Fekete misztikum: DeepCool Mystique 360 vízhűtés
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Autós kamerák
- Rendkívül ütőképesnek tűnik az újragondolt Apple tv
- Vezeték nélküli fülhallgatók
- TCL LCD és LED TV-k
- AMD K6-III, és minden ami RETRO - Oldschool tuning
Hirdetés
-
2024 - Alig egy nap múlva jön a Sony új State of Play előadása
gp Az előzetes tervek szerint több mint 30 perces lesz a műsor.
-
Egyre több európai használja a Telegramot, ezért megkereste az EU
it Hamarosan sokkal szigorúbb szabályozás alá esik az EU-ban a Telegram, mivel egyre több a helyi felhasználója.
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
-
PROHARDVER!
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
-
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
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.
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Ozeki Kft.
Város: Debrecen