Az idei év tavaszán hatalmasat szólt az a hír, amely alapján már kész ténynek tekinthető az Apple és az Imagination szakítása. Ugyanakkor reális magyarázat nem igazán van a döntésre, hiszen az Imagination eddig is igen sok dolgot megengedett a legnagyobb partnerének, gondolva itt arra, hogy az Apple mérnökei mennyire belenyúlnak az alapdizájnba. Emiatt is rendkívül váratlan volt az Imagination bejelentése, hiszen látszatra semmi indoka nem volt a szakításra az Apple-nek, de a mélyebbre kutatva van ráció a döntésükben.
Az utóbbi időben az Apple egészen elzárta a platformjait. Bár a vállalat a GPU-k szabványos elérését lehetővé tevő OpenGL, OpenGL ES és OpenCL API-kat nem szedte ki a macOS és iOS operációs rendszerekből, de a fókuszt egyértelműen a Metal kapja, ennek is a második generációs verziója. Ezzel a váltással az Apple grafikus és compute API-t is fejleszt, vagyis az ezzel járó összes nyűg a nyakukba szakadt. Márpedig nem egyszerű olyan specifikációkkal előállni, amelyekre megfelelő implementációkat lehet írni az összes Apple által kiadott hardveren, ami abból is látszik, hogy még csak a Metal 2-nél tartunk, de a macOS és iOS rendszerek közötti fragmentáció már házon belül is látszódik, ugyanis bizonyos funkciókat csak a legmodernebb grafikus architektúrák támogatnak. Ez például azért problémás, mert az Apple a hardvertervezés hiányában nehezen tud igazodni a szoftveres csoport fejlesztéseihez, így végeredményben az adott hardverre vonatkozó implementáció képességeit mindig az határozza meg, hogy az adott partnerük milyen hardveres alappal állt elő. Egy bizonyos pontig ezzel lehet játszani, de az egyes képességek utasításarchitektúrára, hardveres szálak szinkronizálására, illetve memóriamodellre vonatkozó módosítást is igényelhetnek, amit rendkívül nehézkes egy licencelt grafikus dizájnnál kivitelezni.
A szakítás valós okait minden bizonnyal sose fogjuk megtudni, az Apple valószínűleg annyit mondana, hogy nem voltak elégedettek az Imaginationnel, ami látva a termékek képességeit nem lenne valami hihető indok. A logikus magyarázat sokkal inkább az lehet, hogy a vállalat egyszerűsíteni akarja a saját munkáját. Ezt úgy lehetne a legkönnyebben megtenni, ha a grafikus és compute API fejlesztése mellett saját kézbe vennék az ultramobil GPU tervezését is, és egy beszállítóra csökkentenék a Mac platform esetében is a partnerek számát. Itt nyilván sokan az AMD-re gondolhatnak, de utóbbi döntés igazából nem zárná ki az Intelt, hiszen a Kaby Lake-G platform ennek a célnak is megfelel, elvégre az Intel processzora mellett egy AMD Radeon tanyázik.
A lehetséges opciók csökkentésével az előnyök nyilvánvalóak. Egyrészt a hardveres csapat a szoftveres részleggel közösen dolgozhatna, így a Metal fejlesztése folyamatosan szinkronban lenne az éppen aktuális ultramobil GPU architektúrával. Furcsa ezt kimondani, de ilyenre a piacon senki sem lenne képes, elvégre a vezető szabványokat szolgáltató Microsoft és Khronos Group nem tervez saját hardvert. Ez alól persze a konzol kivétel, de egészen speciális területről van szó, ahol maga a hardver sem igazán fejlődik a termékcsalád életciklusa alatt. Egyedül az AMD Mantle-höz hasonlítható ez a koncepció, hiszen ezt az API-t tényleg csak a GCN-es Radeonokra tervezték, és látszik is rajta, hogy mennyire letisztult. Többek között az erőforrás-menedzsment tekintetében nincsenek különböző pufferek, textúrák, textúratömbök, illetve UAV-k (ha a DirectX-hez hasonlítunk), egyszerűen a memóriában alapvetően lehet memóriazóna és leképezőzóna. Ezt a két erőforrást különbözteti meg a specifikáció, ami gyakorlatilag drámaian leegyszerűsíti az egész rendszer működését. A Metal sem túl bonyolult még, ugyanakkor idővel minden API az lesz, ahogy igazodni kell az újabbnál-újabb architektúrákhoz a megfelelő specifikáció kialakítása tekintetében.
A hardverpartnerek minimalizálása azt szolgálná, hogy a Metal specifikációja maradjon olyan letisztult, amilyen most, vagy ha ez nem is tartható, akkor se legyen olyan, amilyen például a Vulkan, illetve a DirectX 12, ahol rengeteg pufferformátum van megkülönböztetve néha a visszafelé kompatibilitás, néha pedig a hardvergyártók eltérő dizájnjai miatt. Ez ugyan se a Vulkan, se a DirectX 12 hatékonyságát nem rontja számottevően, viszont pont az egyszerűsége miatt a legtöbb fejlesztő leginkább a Metal API-t szereti. Ráadásul a letisztultság olyannyira valós előny, hogy az AMD máig szállít publikus Mantle implementációt a PC-kre. Bár olyan program már nem lesz kiadva, ami ezt az API-t használja, de a prototípus kódok szempontjából a fejlesztők előszeretettel kísérleteznek rajta. Az Apple tehát jól látja a problémákat, és jól látja a lehetséges megoldásokat is. Ráadásul az AMD-vel ellentétben uralják a platformjukat, tehát a Metal előnyét nem csak prototípus kódokra fordíthatják.
Nagyjából két éves távval számolva nagyon valószínű, hogy az Apple az ultramobil megoldásainál átáll a saját fejlesztésű grafikus vezérlőjére, míg a Mac esetében a választható opciók közül döntenek egy gyártó mellett, és a GPU szempontjából mást már nem is engednek be. Ez talán nem fogja azonnal éreztetni a hatását, de úgy öt éves távlatban már komoly előnyt fog jelenteni az Apple-nek. Gondoljunk csak arra, hogy a Microsoft és a Khronos Group milyen lassan dolgozik, ha az API fejlesztéséről van szó. Egyszerűen mindegyik gyártónak van beleszólása a specifikáció alakulásába, és sokszor ezek a cégek nem ugyanazt akarják, ami nyilván vitákhoz fog vezetni, vagyis a Microsoft és a Khronos Group számára olyan igazságos megoldásokat kell választani, ami minden partner számára megfelelő. Itt jó példa, hogy a véglegesítés előtt álló shader modell 6.0-ból teljesen kikerült az egyik legfontosabb újításnak beharangozott global ordered append függvénycsoport, mert nem sikerült az érintetteknek megegyezni egymással. Az Apple számára például az ehhez hasonló a problémák fel sem merülnének, egyszerűen minden ponton uralnák a platformjukat.
Az ultramobil GPU fejlesztése szempontjából egyébként az Apple azért is állhat saját lábra, mert ezeknél a hardvereknél a tranzisztorok száma eléggé limitált, vagyis okosan kell őket felhasználni. Emiatt például az Imagination vagy más partner sem építene be olyan hardveres képességeket, amelyeket csak az Apple kérne. Ezek esetlegesen ronthatnák az architektúra hatékonyságát azokon a piacokon, ahol igazából hasznuk nem lenne. A Mac gépek esetében kevésbé kritikus tényező a tranzisztorok okos felhasználása. Természetesen itt is számít, de a macOS-t futtató gépek jellemző méretkategóriájában sokkal nagyobb mozgásterük van a mérnököknek, mint mondjuk egy iPhone-nál. Emiatt itt nem célszerű saját hardvert tervezni, egyszerűen csak ki kell választani az ideális partnert az elérhető hardverek tudását, illetve a várható termékeket figyelembe véve. Itt nem kizárható, hogy a Kaby Lake-G kódnéven emlegetett dizájn is az Apple közvetlen kérésére készül. Bőven elképzelhető, hogy az Intelnek már jelezték az almások, hogy az AMD-t választották a GPU-t beszállító partnerüknek, de meghagyták a lehetőséget arra, hogy valamilyen módon a reagálhassanak a döntésükre.
A nyilvánvaló előnyök mellett buktatókkal is számolni kell. Többek között az Imagination már jelezte, hogy nem hagyják annyiban a váratlan szakítást, és perelni fogják a készülő dizájn vitás részeit. Ugyanakkor megtudtuk, hogy az Apple számos Imagination szabadalmat megvásárolt örökös licenc mellett, vagyis úgy néz ki, hogy felkészültek erre az eshetőségre. Nem szabad arról sem megfeledkezni, hogy Kaby Lake-G egyszeri fejlesztés is lehet. Bőven elképzelhető, hogy az AMD legközelebb azt mondja, hogy nem ad többé GPU-t az Intelnek, és akkor az Apple a nagy egyszerűsítési koncepcióval ott találja magát, hogy csak egy irányba mehetnek a rendelés tekintetében. Emiatt tényleg hosszabb távon gondolkodva akár az is realitás, hogy az Apple a saját ultramobil dizájnját nagy teljesítményre is felskálázza, és akkor már a Mac gépek tekintetében sem lesz szükségük partnerre. Sőt, egyszer a vállalat már levezényelt egy komolyabb architekturális váltást a Macek piacán, az sem kizárt tehát, hogy újra erre készülnek, amivel az x86/AMD64-hez való kötődést is kiváltják az ARM-mal.
