Alacsony szintű hozzáférést PC-re is!
Az előző oldalon leírtak kapcsán felmerülhet a kérdés, hogy PC-n miért nincs ilyen libGCM stílusú API, ami alacsony szintű hozzáférést biztosítana a hardverhez. Nos, erre röviden annyit lehet válaszolni, hogy mindegyik cég grafikus processzora más utasításarchitektúrát használ, így pedig az alacsony szintű kompatibilitás biztosítása igen nehéz feladat. Maga a téma viszont érdekes annyira, hogy jobban belemélyedjünk a dolgokba. Megjegyzendő ugyanis, hogy a történelem során számtalanszor felmerült már az igény egy univerzális utasításarchitektúrára a grafikus vezérlők esetében is, vagyis a PC-s API-k többletterhelését mindenki nagyon komoly problémának tekinti. Valójában az is, de eddig minden koncepció, ami ezek kiváltására tört, a süllyesztőben végezte.
Az egyik grandiózus projekt a PC-s API-k megkerülésére a Larrabee volt, amivel az Intel egy olyan grafikus processzort szeretett volna kidolgozni, mely ugyanazt az utasításarchitektúrát használja, amit a PC-s központi processzorok. Ezzel a cég azt is jelezte, hogy egyetértenek az univerzális utasításarchitektúrára vonatkozó koncepcióval, és a lehető leghamarabb a tettek mezejére léptek. A cél lényegében az volt, hogy az x86 ne csak a központi processzorok, hanem a grafikus processzorok piacán is kiemelt hatalmat kapjon. Ennek érdekében a vállalat éveken keresztül pumpálta a projektbe a dollármilliárdokat, fittyet hányva azokra az iparági figyelmeztetésekre, melyek megpróbálták elmagyarázni a cégnek, hogy elméletben kiváló koncepciójuk a gyakorlatban nem fog működni.
A Larrabee végül a süllyesztőben végezte, de a projekt MIC néven él tovább. Viszont a számtalan áttervezés és vezércsere mellett még ma sem látjuk, hogy a gyakorlatban mennyire gyorsan képes futtatni egy aktuális játékot, és az Intel a nagyszabású, univerzális utasításarchitektúrát bevezető terveiről egyelőre lemondott. A Larrabee problémája egyébként az iparági szakértők véleménye szerint az volt, hogy az x86-ot alapvetően nem úgy tervezték, hogy megfelelően skálázódjon egy adatpárhuzamos végrehajtásra tervezett hardverben. Ez logikus is, hiszen amikor az utasításarchitektúra alapjait letették, akkor még fel sem merült, hogy valaha is lesznek többmagos processzorok. Márpedig a grafikus vezérlők esetében az adatpárhuzamosságot konkrétan beletervezik az adott utasításarchitektúrába, és a GPU-kon pont ezért skálázódik a teljesítmény igen jó hatásfokkal.
Az Intel elképzelése egyébként úgy még működőképes lehet, hogy ha a feldolgozáshoz szükséges adatok mindig ott vannak a processzormag mellé társított gyorsítótárban. Ilyenkor a skálázódás megfelelő szintet érhet el, viszont így a lapka igen nagy része csak gyorsítótárból állna, miközben a futtatott munkafolyamatok alapvetően tolerálják a késleltetést, vagyis az egész koncepció átcsap egy masszív tranzisztorpazarlásba. Ezt úgy érdemes felfogni, hogy amíg az Intel a tranzisztorok milliárdjait csak azért építi be, hogy a nagyobb gyorsítótárakkal segítsék a skálázódást, addig a más elvű rendszerrel dolgozó konkurenciának ezzel nem kell foglalkoznia, így az extra tranzisztorokat extra teljesítményre költhetik. Ezek után könnyen belátható, hogy a Larrabee eredeti elképzeléséből miért nem lett semmi.
A központi, azaz lényegében a késleltetésre optimalizált processzormagokhoz tervezett utasításarchitektúrák tehát kiestek a képletből, de még mindig ott volt a lehetőség, hogy a grafikus processzorok fejlesztésével foglalkozó cégek megegyezzenek egy adatpárhuzamos végrehajtásra tervezett univerzális utasításarchitektúráról. Ez a koncepció elvi síkon ezt jelentené, hogy a fejlesztő az adott programot konkrétan lefordítja a mindenki által használt utasításarchitektúrára, és a hardver azt képes lenne direkten futtatni. Ez az elv működik a központi processzoroknál, hiszen az x86/AMD64-re lefordított programok futnak az AMD, az Intel és a VIA megfelelő processzorain, és ugyanez igaz a jóval népesebb ARM-os rétegre is az ARM-ra fordított alkalmazások mellett. A többletterhelést ezzel teljesen ki lehetne ütni, hiszen eltűnne az API-ra az igény, de gondot jelent, hogy a gyakorlatban ez az elképzelés sem megvalósítható.
Bár az előbbi bekezdés mindenképp jól hangzik elvi síkon, de ahogy korábban már említettük, a grafikus processzorok alapvető tervezési koncepciója, hogy skálázható legyen a rendszer. Nagyon érdekes megnézni az iparágat ebből a szempontból, hiszen majdnem egy tucat cég foglalkozik ma GPU-k tervezésével, viszont közülük csak az AMD és az NVIDIA tesz le nagymértékben skálázható architektúrákat az asztalra. Bár ez az adat jelentéktelennek tűnhet, de valójában nagyon is fontos tényezőről van szó, ugyanis egy grafikus számításokra tervezett rendszer teljesítményének skálázhatóságát nagymértékben befolyásolja az adott utasításarchitektúra. Olyannyira, hogy még az AMD és az NVIDIA is le szokta cserélni ezt nagyjából 4-6 éves ciklusokban, és ugyanezt megteszi a többi cég is, csak valamivel tágabb időintervallumok mellett.
Az univerzális utasításarchitektúra ötlete tehát teljesen megbukott, mivel a teljesítmény skálázódása mindenki számára sokkal fontosabb a kompatibilitásnál, így pedig a hardverekhez való alacsony szintű hozzáférés megvalósítása is nehéz ügy, hiszen nincs egy közös pont, amit reálisan meg lehetne ragadni.
Van még fény az alagút végén
A HSAIL, mint lehetséges irány
A fentebb leírt adatok lehangoló jövőképet festenek, de a PC-s grafikus API-k által okozott többletterhelés annyira komoly probléma, hogy a cégek még ma sem adták fel a küzdelmet egy jobb jövő érdekében. Bár a fizikai szinten implementált utasításarchitektúra nem lehet közös, de létezik egy mentőöv, ami kihasználható. Mivel maguk a gyártók is viszonylag sűrűn cserélik az utasításarchitektúrát, mindenképp biztosítani kell egy olyan kompatibilitási rést, amivel az új hardverek is képesek futtatni a régieken kitesztelt programokat. A grafikus API-k mellett ugyanis ma már az általános számításra kihegyezett platformok is jelentős piacot szereztek, így meg kell oldani, hogy egy OpenCL-ben írt program bármilyen OpenCL-t támogató hardveren fusson. Erre az érintett cégek az úgynevezett virtuális utasításarchitektúrákat alkalmazzák. Ezeknek hála a fizikai szinten implementált utasításarchitektúra megváltozhat, miközben a kompatibilitás virtuális szinten biztosított.
Az AMD, az ARM, a Qualcomm, az Imagination Technologies, a Vivante és a DMP összefogott annak érdekében, hogy ha már a közös utasításarchitektúra használata elvi szinten nem lehetséges, akkor legalább a virtuális utasításarchitektúra szempontjából legyen egyezés. Ez már egy reálisan vállalható elképzelés, hiszen a skálázhatóság érdekében mindenki úgy tervezheti az adott rendszert, ahogy akarja, és eközben kellően alacsony szinten lesz egy olyan közös pont, amire a fejlesztők építhetnek. Ez a közös pont jelenleg a HSAIL, melyhez tervezhető egy olyan grafikus API, amivel konzolokhoz hasonló feldolgozási elv érhető el, ezzel búcsút intve a komoly problémának tekinthető többletterhelésnek. Gondot jelenthet viszont, hogy ezt az elképzelést az Intel, illetve az NVIDIA nem támogatja, és amíg ebből a szempontból nincs teljes megegyezés, addig a PC görgeti maga előtt az aktuális grafikus API-k extrém mértékű többletterhelését, ami komoly előnyt ad az új generációs konzoloknak.
A cikk még nem ért véget, kérlek, lapozz!
