Mit kínál a Metal API?

Az előző oldalból érezhető, hogy itt nem csak a processzorlimit problémájáról van szó, hanem sokkal inkább arról, hogy a fejlesztők megkapják a hardver felett az irányítást. Az alacsony szintű hardverelérést biztosító API-k tulajdonképpen arra szolgálnak, hogy a hardver képes legyen futtatni a shader programokat, míg a többi olyan dolog, amit eddig a driver végzett el, ugyan megmarad, de mostantól az alkalmazás felel értük. A fejlesztők számára ez a modell rendkívül ismerős, hiszen az Xbox 360 és a PlayStation 3 konzolokra így fejlesztettek a 2007-es esztendő után, illetve így fejlesztenek ma az Xbox One és PlayStation 4 konzolokra is. Lényegében a programozó elől eltűnik az a feketedoboz, ami akadályozza teljes profilozást. Ez azt eredményezi, hogy ha a programkódban hiba van, akkor azt mindenféle gyártói segítség nélkül, maximum egy héten belül ki lehet javítani.

Az Apple Metal, az AMD Mantle és a Microsoft DirectX 12 – a számos érdekes újítás mellett – főleg azt a célt szolgálja, hogy az adott játékhoz mindössze három hónap alatt, egyetlen programozó képes legyen egy teljesen optimalizált leképzőt írni. Ezzel az adott stúdió nagyságrendekkel kevesebb pénzt költhet a leképzőre, vagy esetleg az eddig befektetett pénzt új generációs grafikai eljárások kidolgozására is fel lehet használni, illetve a megfelelő leképző elkészítéséhez szükséges idő is drasztikusan redukálható.

A Metal API-ra rátérve, a rendszer alapja pont ugyanaz, mint a másik két korábban bemutatott megoldásnak. A parancspuffereket teljes mértékben az alkalmazás ellenőrzi és tölti be a parancslistába. A programozó teljes kontrollt kap azzal kapcsolatban, hogy milyen munkát mikor futtat a grafikus vezérlőn. A többszálú feldolgozás érdekében a parancspuffereket egymással párhuzamosan is fel lehet építeni. A leképzés előkészítésére befogott processzormagok száma csak a programozó döntésétől függ, így a skálázódás megfelelően felépített motor mellett igen sok szálra biztosítható. Az Apple éppen ezért mondja, hogy akár tízszer több rajzolási parancs is kiadható az OpenGL ES-hez viszonyítva. Ez leginkább elméleti adat, de az alacsony szintű hardverelérést biztosító API-k működését ismerve teljesen reális kijelentés, azonban a gyakorlatban nem valószínű, hogy látunk rá példát. Persze elképzelhető, hogy az almás cég meggyőzi a Firaxist, hogy az érkező új Civilization játékot érdemes lenne portolniuk iOS-re, és ebben az esetben az Apple A7 SoC csupán a Metal API működése miatt gyorsabban futtatná a programot, mint például a Macbookok vagy az iMacek.

[+]

Az előbbi modellre épülő koncepciót egyébként a fejlesztők független parancspufferes API-ként emlegetik, de ilyen a Metal, a Mantle és a DirectX 12 is. Hatalmas előny ennél a rendszernél, hogy a kernel driver számára nincs feladat, noha a DirectX 12 esetében ugyan létezik kernel driver által futtatott szál, de gyakorlatilag csak elhanyagolható mértékű munkát végez, így mérhetetlenül kevés erőforrást is igényel. Ez fontos, ugyanis az eddig használt API-khoz készült meghajtók megpróbálják kihasználni a többmagos processzorokat, így a leképzés előkészítéséhez szükséges szerver szálakat párhuzamosan futtatják, de ez nagyon gyengén kontrollálható. Többek között ez a rendszer már önmagában is igen komoly fejtörést okoz a fejlesztőknek, mivel az elérhető processzormagokat konkrétan az alkalmazástól veszik el. Mivel ez a program oldaláról kontrollálhatatlan, a legtöbb fejlesztő egyszerűen csak azt teszi, hogy az elérhető processzormagok felét vagy harmadát szimplán odaadják a grafikus drivernek. Ez természetesen az erőforrás nagymértékű pazarlása, de a gyakorlatban sajnos nincs jobban működő megoldás. Szerencsére az alacsony szintű elérést biztosító API-kkal az alkalmazás kontrollálja a leképzés előkészítését, így a fejlesztő nagyságrendekkel hatékonyabban is beoszthatja az elérhető processzormagokat. Ebből az is érezhető, hogy – a közhiedelemmel ellentétben – nem a fejlesztők hozzáértése, hanem pont az aktuális grafikus API-k alacsony hatásfokú működése akadályozza a sokmagos processzorok kihasználását.

Az állapotváltások problémájára a Metal API az állapotobjektumokkal reagál, ami gyakorlatilag az a modell, amit a Microsoft alkalmaz a DirectX 12-nél. Ennek értelmében előre el kell készíteni a szükséges objektumokat, majd azokat nem is kell módosítani. Ezek között a váltás nagyon gyors, és shaderek újrafordításával sem kell számolni, mivel a szükséges programok is előre le vannak fordítva. Itt nagyon fontos kiemelni, hogy a programozó tudja, hogy az alkalmazás mit fog tenni, így képes felkészülni minden eshetőségre, miközben a drivernek nincsenek meg azok az adatok, amelyekkel előre láthatók lehetnének a futtatás során szükséges shaderek. A Mantle itt egy picit másképp működik, bár a cél ugyanaz, de az AMD monolitikus futószalagot vezetett be, ami nem csak az állapotváltások gyorsítására, hanem azok minimalizálására is törekszik.

A Metal lényegesen különbözik a DirectX 12 és a Mantle API-tól abban, hogy az Apple teljes mértékben TBDR-re tervezte, ami érthető döntés figyelembe véve azt a tényt, hogy az Apple A7 IGP-jéhez ez az ideális, de a speciális működés igen nehézzé teszi az API támogatását a többi grafikus architektúra alól, mivel ezek TBR vagy IMR felépítéshez igazodnak. Funkcionálisan megoldható a kompatibilitás, de hatékonyság tekintetében lehetnek gondok. Ez persze vélhetőleg nem érdekli az Apple-t, illetve az is eldöntöttnek tűnik, hogy a cég a következő pár évben is az Imagination új grafikus IP-it fogja használni.

A Metal új shader nyelvet is bevezet, mely a MSL (Metal Shading Language) névre hallgat. Itt az Apple nagyrészt azt célozta meg, hogy az elterjedtebb nyelvekről, mint például a DirectX 12 és a Mantle által is használt HLSL-ről egyszerű legyen az effektek portolása. Több fejlesztő egyébként problémának érzi, hogy a Metal nem támogat indirect draw, vagy ismertebb néven indirect dispatch funkciót, ami limitálja a compute futószalag használhatóságát. Valószínűleg ezzel egészítik majd ki először az API-t.

Kiemelendő, hogy az Apple Metal API pár területen azért másképp működik, mint a DirectX 12 és a Mantle. Többek között nem teszi elérhetővé a videomemória explicit vezérlését a fejlesztőknek, ugyanakkor így sem a hagyományos, grafikus meghajtók által vezérelt megoldásról van szó, hanem maga az API felel érte, vagyis bizonyos mértékig a hardverelérés alacsony szintűnek tekinthető, de nem annyira, mint a többi új API esetében. Ezzel a modellel az Apple a hardver kihasználhatóságát ugyan némileg korlátozza, de a vállalat valószínűleg jobban félt attól, hogy a megírt, Metal API-t használó alkalmazások az újabb hardvereken túl lassan futnának, ha a fejlesztők teljes kontrollt kapnának a videomemória felett. Ennek megfelelően az Apple inkább az API folyamatos frissítésével oldja meg az új hardverek vezérlését, ami így is előnyt jelent a korábbi modellekhez képest, miközben a jellemzően konzolokban alkalmazott koncepció hátrányaival nem kell majd megközdeni. Szintén megjegyzendő, hogy a Metal API bekötési rendszere nem tekinthető úgynevezett bindless modellnek, tehát ebből a szempontból is különbözik az Apple megoldása a DirectX 12 és a Mantle API-tól. UGyanakkor magát a bekötési modellt így is átdolgozta a vállalat, hogy a korábbi opciókhoz képest hatványozottan kevesebb processzoridőt igényeljen.

A memória kezelése szempontjából a Metal kihasználja, hogy az Apple A7 egy SoC, azaz rendszerchip. Bár a rendszermemóriát a CPU és az IGP nem osztja meg, de egymás memóriaterületeit elérhetik, és program által felügyelt körülmények között meglehetősen rugalmas az írásra vonatkozó szabály. Lényegében a processzor memóriájában, azaz gyakorlatilag a rendszermemóriában tárolhatók lehetnek a pufferek, amiből az IGP szimplán olvashat. Az írásra vonatkozóan az alkalmazásnak kell felügyelnie azt, hogy a processzormagok és az IGP ne írja egyszerre ugyanazt az erőforrást, illetve ha az egyik részegység bármilyen adatot is módosít a memóriában, akkor azt az írás időtartamáig nem érheti el egy másik részegység. Ez később kiegészülhet a teljesen koherens memóriakezeléssel, amint lesz egy olyan Apple SoC, amely képes támogatni az egységes virtuális memóriát, illetve a platformszintű atomi utasításokat.

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