Grafikai újítások?
Az már az előző oldal alapján is látszik, hogy az AMD nagyon belenyúlt a rendszerbe, de ezzel még nincs vége, olyan dolgokat is hozott a cég, amelyekre az utóbbi időben egyre kevesebb példa volt. Ha visszagondolunk, akkor az előző egy-két generáció főleg az általános számításokról, illetve a sugárkövetésről szólt, hagyományos grafikai fejlesztés alig-alig érte a rendszereket, leszámítva azt, amit az új API-k megköveteltek. Ugyanakkor még mindig grafikus vezérlőkről van szó, tehát benne van a nevükben, hogy olyan dologra fókuszálnak, amelyek kapcsán egyre kevesebb innovációt kapunk. Persze lehet mondani, hogy a hagyományos eljárásokat tekintve már nincs hova fejlődni, de erre az RDNA 3 most nagyon rá szeretne cáfolni.
AMD Navi 31 [+]
A strukturális felépítést tekintve sok dolog ismerős lehet, elvégre a fő alapegység továbbra is a shader motor, amelyből hat darab van a Navi 31-es GPU chipleten belül. Ezek két-két compute blokkra vannak osztva, és egy-egy compute blokkban van egy 256 kB-os L1 gyorsítótár és négy darab CUP, viszont a két ROP blokk, a raszterizáló és a Prim egység megosztva érhető el két compute blokk között. Az általános parancskezelés is látszólag változatlan, hiszen továbbra is négy ACE dolgozik a hardverben, amelyek egy HWS (Hardware Scheduler) fennhatósága alá tartoznak. Ezzel a rendszer összességében 32 compute parancslistát kezel egy grafikai parancslista mellett. Megmaradt a finomszemcsés preempció és a QoS (Quality of Service) támogatása is, amelyek közül előbbi felel azért, hogy a kritikus fontosságú feladatok előnyt élvezzenek, míg utóbbi a többfelhasználós környezet hatékony kezelését teszi lehetővé, ráadásul továbbra is virtualizálható a teljes lapkára, mindezt teljesen automatikus hardveres ütemezés mellett. Természetesen továbbra is a rendszer része első generációs RDNA-ban bevezetett priority tunneling, illetve a globális adatmegosztás, vagy más néven Global Data Share (GDS), de utóbbinak 64 kB-ról 4 KB-ra csökkent a kapacitása.
Itt megjegyeznénk, hogy ha valaki utánaszámol az AMD által megadott specifikációnak, akkor feltűnhet, hogy a hivatalosan megadott úgynevezett stream processzorok száma feleannyi, mint amennyit az architektúra felépítése alapján kalkulálni lehet. A vörös oldal a teljes értékű Navi 31-et alkalmazó Radeon RX 7900 XTX-re 6144 darab feldolgozót ad meg, holott a lapkában hat shader motor van, mindegyikben nyolc CUP-vel, és egy CUP-ben négy 64 utas SIMD motor található. Ez így bizony 12 288 darab feldolgozó. A helyzet az, hogy értelmezés kérdése, hogy melyik számot használjuk. Ha a rendszer 64 lane-ből álló wavefrontokat futtat, akkor a 12 288 a helyes. Amennyiben 32 lane-ből álló wavefrontok futnak, akkor úgy tekinthető helyesnek a 6144 feldolgozó, hogy számításba vesszük a dual-issue képességet, és ezt egyébként az elméleti számítási teljesítmény meghatározásánál már figyelembe is veszi az AMD.
Ezek alapján adódhat a kérdés, hogy mi az újdonság, hiszen eddig nincsenek nagyon látványos változások az RDNA 2-höz képest. Nos, az extrák a motorháztető alatt vannak. Egyrészt a grafikai parancsmotor kapott egy új egységet, ami az MDIA, azaz a Multi-Draw-Indirect Accelerator nevet viseli. Ennek célja a processzor tehermentesítése bizonyos szituációkban, ami azért lehet hasznos, mert a DirectX 12 ugyan jót tett a CPU-k hatékonyabb kihasználásának, de egyre több játékon belül drasztikusan emelkedik a kiadott rajzolási parancsok száma. Ezen pedig újabb csoda az API-k oldalán nem fog segíteni, jobb processzorok kellenek, de ezek se jönnek túl gyorsan. Van azonban egy nagyon sűrűn használt DirectX 12 funkció, ami az ExecuteIndirect nevet viseli, és ezáltal egyetlen API paranccsal több rajzolást is meg lehet oldani, továbbá lehetővé teszi az API hívások CPU és GPU által történő vezérlését, valamint a rajzolási parancsok közötti bekötés módosítását. Ezt majdnem minden DirectX 12-es cím használja, de még így is előfordulhat processzorlimit. A Multi-Draw-Indirect Accelerator egy olyan speciális gyorsító a grafikai parancsprocesszoron belül, amely bizonyos ExecuteIndirecttel kapcsolatos munkákat átvesz a processzortól, ezáltal tehermentesítve azt, vagyis csökkentve a processzorlimit korlátozó hatását. Az AMD mérései szerint az új rendszer – az előző generációhoz viszonyítva – másodpercenként 2,3-szor több rajzolási parancsot képes végrehajtani.
[+]
A nyers számok tekintetében fontos figyelembe venni, hogy a Navi 31 esetében 50%-kal nőtt a háromszögek feldolgozásának, illetve a raszterizálásnak teljesítménye a Navi 21-hez viszonyítva, de ez pusztán abból ered, hogy négy helyett hat shader motor van a lapkán belül, tehát ez az előrelépés mondhatni logikus és elvárt. A Prim egységek azonban megújultak, és a korábbi verzióhoz képest már órajelenként nem csak kettő, hanem négy háromszöget is megvizsgálnak NGG módban, így a nem látható háromszögek hardveres kivágása önmagában is kétszeresére gyorsult.
Ezeknél sokkal érdekesebb azonban a ROO, azaz a Random Order Opaque képesség. Itt arról van szó, hogy az AMD lecserélte a viszonylag nagy átrendezési puffert úgynevezett eredménytáblára, aminek két előnye van. Egyrészt viszonylag sok tranzisztort lehet vele megspórolni, másrészt a pixel shaderek eredményének exportját bizonyos feltételek teljesülése esetén sorrendtől függetlenül is engedi, vagyis hamarabb szabadulhatnak fel a lekötött erőforrások a hardveren belül.
Végül szintén új fejlesztés a Pixel Wait Sync, ami finomszemcsés függőségmenedzsmentet vezet be, így egy adott pixel shader feladatra vonatkozó olvasási művelet addig nem következhet be, amíg a függő írási folyamat le nem zárul. Ettől viszont még az egyes folyamatok futtatása megkezdődhet, és ezek szimplán felfüggeszthetők, amíg a folytatásukhoz meg nem érkezik a szükséges eredmény.
A cikk még nem ért véget, kérlek, lapozz!
