Regiszterkezelés dinamikusan

Az RDNA 4 egyik leglényegesebb újítása a regiszterkezelést érte, amit az AMD ugyan összekötött a sugárkövetéssel, de valójában általános megoldásról van szó, még akkor is, ha az aktuális dizájnban a shader fordító opcionálisan dönt arról, hogy melyik shadert fordítja statikus, illetve melyiket új, dinamikus regiszterallokációval.

A lényeg megértéséhez érdemes egy picit elemezni, hogy a mai GPU-k hogyan működnek ebből a szempontból. Legyen szó akármilyen modernebb architektúráról, a feldolgozás alapvetően SIMT jellegű, vagyis a munkavégzést biztosító SIMD motor egy meghatározott számú konkurens wave-et futtat, amikor egy adott shadert betölt. A wave-ek számát az dönti el, hogy az adott shader program mennyi adattal dolgozik, ezeket ugyanis mind be kell tölteni a regiszterterületbe. Persze architektúraspecifikusan mindig van egy maximum megengedett wave mennyiség, de ezt most hagyjuk, ilyen esetben amúgy is optimális a hardverdizájn kihasználása.

A konkurens wave-ek arra szolgálnak, hogy átlapolható legyen a memóriaelérés késleltetése, vagyis az a cél, hogy az adott shader futtatása során, hogy mindig legyen egy olyan szabad wave, amihez már megérkezett az összes adat, így azzal dolgozni lehet. A gondot igazából a komplexebb shaderek okozzák, ugyanis ezek annyira sok adatot használhatnak, hogy kevés lehet nekik a SIMD motorhoz tartozó regiszterterület. Vegyünk egy egyszerű elméleti példát. A shader operációnként 2 kB-nyi adatot használ, ami 32-utas SIMD motorral számolva 64 kB-os regiszterterhelés. Tegyük fel, hogy 128 kB-os a regiszterterületünk, amibe így két wave-hez szükséges adatmennyiség fér bele, tehát a SIMD motoron két konkurens wave futhat. Ez így egészen rosszul hangzik, mert bármennyire is gyors a VRAM elérése, biztosan lesz olyan helyzet, amikor még mindkét wave adatra vár, és ekkor az adott SIMD motor nem csinál semmit, elvégre nem tud mivel dolgozni.

Nem biztos ugyanakkor, hogy szükség van mind a 128 kB-nyi adatra a regiszterből. Sőt, nagyon tipikus, hogy ennek csak a töredéke kell, de mivel a GPU-k regiszterallokációja statikus, ezért nem tehetünk ellene semmit, muszáj betölteni előre a potenciálisan feldolgozásra váró adatokat, még akkor is, ha annak a 90%-a nem is lett hasznosítva. Innen azért látszik, hogy ez egy eléggé pazarló módszer, de mivel a GPU-k korábban eléggé egyszerű shadereket futtattak, nem igazán volt napirenden, hogy a regiszterallokáció dinamikus legyen, mert annak azért vannak extra tranzisztorköltségei. Ergo inkább elfogadták a cégek azt, hogy ez így a működést tekintve igencsak rossz, a komplex shaderek esetében garantáltan nem lesz hatékony a hardver memóriaelérése, de tranzisztorköltségben azért nem olyan kellemetlen kompromisszum.

[+]

Az AMD az RDNA 4-ben ezen változtat, és bevezetik a dinamikus regiszterallokációt. Ez annyit tesz, hogy a hardver csak azt az adatot tölti be a regiszterbe, amire a SIMD motoron futtatott shadernek szüksége van. Ennek alapvető hatása az lehet, hogy még a komplex shader kódok esetében is elérhető az, hogy nagy mennyiségű konkurens wave fusson az új Radeon SIMD motorjain, így garantálva a memóriaelérés optimális átlapolását. Kevésbé kihangsúlyozott dolog, hogy ilyen formában az RNDA 4 a rosszul optimalizált shaderekre is eléggé immunis lehet, hiszen ezek jellemzően ott csúsznak félre, hogy irreálisan nagy regiszternyomást eredményeznek, ami aztán rontja a memóriaelérés hatékony átlapolását. Ezt valószínűleg azért nem hirdeti a cég, mert nem szeretnék azt az üzenetet közvetíteni a programozók felé, hogy mostantól hátra lehet dőlni, el lehet engedni a gyeplőt, majd a hardver megoldja. Nem, nem fogja megoldani. Kevésbé érintheti majd rosszul az RDNA 4-et egy nem optimalizált shader kód, de ettől még az optimalizálás jelentősége fontos marad, már csak a többi architektúra miatt is.

Az RDNA 4 ezen képessége egyébként nem függ a programtól, nem kell direktek támogatni. Az eszközillesztőben szállított shader fordító dönti majd el, hogy az adott shadert statikus vagy dinamikus regiszterallokációra fordítja. És első körben az AMD keverten alkalmazza majd ezt a módszert, ezen belül annyi biztos, hogy a sugárkövetéshez hasznosítják majd az újítást, mert az itt használt shaderek eléggé komoly varianciát mutatnak a regiszternyomás tekintetében. Például a bejárással járó munka eléggé kevés regisztert szokott igényelni, de a korábbi hardvereknek kötelező volt a legrosszabb forgatókönyvre készülnie. Az RNDA 4-ben lehet dolgozni a valós terhelésre, ahhoz szabva a regiszternyomást.

A cikk még nem ért véget, kérlek, lapozz!