Új optimalizálási irányt próbál ki az ID software

A multiprocesszorok gyorsítótárainak hatékonyabb kihasználása a cél.

Az ID software az új Doom alatt dolgozó id tech 6 videojáték-motorral újra elmondhatja magáról, hogy az élmezőnybe tartozik az alkalmazott technológia szempontjából. Ráadásul a Doom későbbi frissítésében hozzáadott Vulkan módot máig etalonnak tartják a játékosok, és jó hír, hogy az érkező Wolfenstein 2: The New Colossus című alkotás már modernizált Vulkan leképezővel érkezik. Ez ráadásul elsőként próbál ki olyan optimalizálási irányt, amelyet korábban senki sem alkalmazott PC-n, holott például konzolon igen elterjedtnek számít. De ne rohanjunk ennyire előre, a problémát ugyanis érdemes megérteni azelőtt, mielőtt az újítás szóba kerül.

Hirdetés

Talán nem írunk újdonságot akkor, ha azt állítjuk, hogy a mai GPU-k amolyan SIMT rendszerek, vagyis alapvetően a kihasználtságlimit az, ami befolyásolja a teljesítményüket. Egy bizonyos architektúra ugyanis meghatározott számú maximummal rendelkezik az úgynevezett wave-ek futtatása szempontjából. Általánosan azt lehet mondani, hogy minél több wave futhat egy multiprocesszoron, annál kedvezőbb a memóriaelérések átlapolása, és így a hardver számára mindig van min dolgozni, amellett persze, hogy a wave-ek folyamatosan igénylik az adatot. A koncepció eléggé egyszerű. Ha egy wave számára nem áll rendelkezésre a számításhoz szükséges információ, akkor azt a hardver elmenti, és betölt egy olyan wave-et, amely már tudja folytatni a munkát az adatok birtokában. Ezért is érdemes a sok konkurens wave futtatására törekedni, hiszen minél több van ezekből, annál valószínűbb, hogy lehet futtatni valamit, így elkerülhetők az üresjáratok.

Az egész ugyanakkor csak egy elmélet, a gyakorlat bizony lényegesen nehezebb. Egyrészt a mai hardverek igen egyszerű kezelik az erőforrások allokációját. Tulajdonképpen mielőtt betöltenének egy új wave-et az ütemezőnek meg kell bizonyosodni arról, hogy minden szükséges erőforrás rendelkezésre áll, amelyre potenciálisan szükség lehet. Az egész rendszer tehát az erőforrások statikus allokációjára épít, ami nem kedvező, ugyanis az erőforrások használata már dinamikus. Emiatt jóval kedvezőbb lenne az allokáció szempontjából is a dinamikus modell, de ehhez komoly hardveres módosítás kellene, ami még a jövő zenéje.

Bár az egész konstrukció az esetek többségében életképes, problémát jelent az, hogy nem mindig az a legjobb, ha a multiprocesszor a lehető legtöbb wave-et futtatja. Ennek az oka, hogy a teljesítményt az első szintű gyorsítótárak is erősen befolyásolhatják, ugyanakkor ez rendkívül függ az adott programkódtól. Ráadásul nem csak a hardver, hanem a shader fordító is meghatározza, hogy egy shader maximum hány wave-en futhat egy adott feldolgozóegységen. Még ha a fejlesztők speciális kódokkal igazodnának is minden architektúra, összes eltérő chipdizájnjához, akkor is jöhet később egy olyan meghajtó, amelyben a shader fordító tartalmaz olyan módosításokat, ami már befolyásolja a programfuttatást. Egyedül konzolon érdemes ezt az optimalizálási lehetőséget megfontolni, mivel ott szállítani lehet bináris formában is a shadereket, illetve a hardver sem változik meg.

Nem teljesen reménytelen azonban a helyzet PC-n sem, ugyanis az ID software és az AMD kialakított egy áthidaló megoldást a problémára, amit a Wolfenstein 2: The New Colossus használni is fog. Ez egy olyan Vulkan kiterjesztés, amivel a programozók kapnak egy alapszintű kontrollt afelett, hogy a hardverek és a shader fordító miképp működjön. Ez azért reális alternatíva, mert az adott fejlesztő ismeri a saját kódját, tehát tudja, hogy az aktuális architektúrákat figyelembe véve milyen korlátokba fut bele. Tulajdonképpen eddig is látni lehetett, hogy például a futtatott vertex shader érzékeny-e az adatlokalitásra, ideális-e a wave-L1 gyorsítótár arány, vagy esetleg megfelelők-e a hardver adottságaihoz az adott futószalag-fokozaton futtatott grafikai és compute feladatok. Ha azonban ezek nem voltak jók, akkor úgy sem lehetett rajta változtatni. Az új kiterjesztést azonban lehetővé teszi ezt, továbbá még arra is képes lesz a fejlesztő, hogy multiprocesszorokon belüli a feldolgozást adott munkacsoportokra limitálja, ezzel biztosítva a skalár és az utasítás gyorsítótárak korábbinál hatékonyabb kihasználását.

Az elgondolás egyébként távolról sem jelent teljes megoldás a problémákra, tehát a jövőben egyértelműen olyan hardverek kellenek, amelyek az erőforrás-allokációt jóval dinamikusabban kezelik a maiaknál. Tűzoltásra azonban ez is megfelel, hiszen ad egy elfogadható mértékű kontrollt a fejlesztők kezébe, amivel hatékonyabb működés sajtolható ki a hardverből és a meghajtóból. Bár a rendszer egyelőre csak az AMD hardverein működik, ha beválik valószínűleg az Intel és az NVIDIA is készít egy-egy hasonló lehetőséget biztosító kiterjesztést, hiszen fenti probléma általánosan jellemző a SIMT hardverekre, persze eltérő mértékben, de az nem árthat, ha a fejlesztő megsúgja az adott implementációnak, hogy miképp működhet hatékonyabban. Erre sokszor az eszközillesztő nem tud magától rájönni, a gyártók rendszerprogramozói pedig nem fognak minden egyes alkalmazásra hatékonyan reagálni, elvégre egy-egy alkalmazásfrissítéssel elveszhet a befektetett munka.

Azóta történt

Előzmények