A szabvány mindenkinek az érdeke
A grafikus API-khoz fejlesztett gyártóspecifikus kiterjesztések mindig is részei voltak a PC-nek. Ezen a Microsoft és a Khronos Group sem akart változtatni a DirectX 12 és a Vulkan API kidolgozásánál, hiszen eddig sem okoztak bajt, és nem sok esély volt arra, hogy ez a jövőben megváltozik. Ennek a gondolkodásnak az volt az alapja, hogy a PC-t az iparág, ezen belül is elsődlegesen a játékokat fejlesztő cégek különálló platformnak tekintik, így értékelik a PC képességeit, majd aszerint próbálnak reagálni a problémákra.
Ha jobban belegondolunk, más lehetőségük sosem volt, és a DirectX 12, illetve a Vulkan fejlesztésénél sem vették számításba az érintettek, hogy lehetne ezt másképp csinálni. Ennek a legfőbb oka talán az, hogy a PC-t tisztességes távolságban tartsák a konzoloktól, ami tulajdonképpen egy hasonló, de helyenként mégis elkülönülő fejlesztési irányt kínál ennek a szegmensnek. Hogy ez jó-e vagy sem, azt nehéz eldönteni, de tény, hogy a PC-s piacon rengeteg különböző hardver van, ráadásul relatíve gyorsan érkeznek új megoldások, tehát talán nem akkora baj, hogy bizonyos közös elvi alapok mellett néhol a PC a maga útját járja, és nem másolja a más hardveres fejlődési modellt alkalmazó konzolpiacot.
Nagyjából idén márciusban az AMD bejelentette, hogy márpedig szerintük nem csak lehetne a PC-s fejlesztéseket másképp csinálni, hanem meg is építik azt az alapot, ami erre lehetőséget ad. A vállalat már a GPUOpen hivatalos bejelentésénél is kritikus problémának nevezte, hogy a konzolra és a PC-re vonatkozó fejlesztések nagyon elkülönülnek, amit akkor többféleképpen is lehetett értelmezni. Például úgy, hogy a GPUOpen keretében a MIT licenc mellett elérhető nyílt forráskód megnyitja az utat a PC-re fejlesztett effektek konzolra portolása előtt. Ezt még el is lehet fogadni, hiszen az összes érintettnek csak pozitív hozadéka lehet belőle.
Az AMD azonban egész másképp értette azt, hogy a konzolra és a PC-re vonatkozó fejlesztéseket közös mederbe kell terelni, és ez rávilágít a GPUOpen egy kevésbé kellemes jellegére is. Nevezetesen a GPUOpen nem csak arról szól, hogy a fejlesztéshez használt kódok nyílt forrásúak legyenek, hanem arról is, hogy a GPU megnyíljon a fejlesztő előtt. Utóbbi furcsa megfogalmazásnak tűnhet, de valójában szinte mindegyik grafikus vezérlő rendelkezik egy rakás olyan képességgel, amelyet a szabványos API-kon keresztül a fejlesztők egyszerűen nem érhetnek el. Ennek az oka a fragmentáció kézben tartása, ugyanis nem lenne egyszerűbb az a helyzet, ha a hardverek összes képessége szabadon kihasználható lenne, és akkor létezne gyártónként egy-egy shader nyelvekre vonatkozó specifikáció, azaz effektíve annyiféle shader kódot kellene írni, szállítani és karbantartani, ahány gyártót céloz az adott program fejlesztője. Mivel nem sokan szeretnének egy ilyen világba dolgozni, így az egyes újításokat a GAB (DirectX), illetve az ARB (OpenGL, Vulkan) csoport ugyan kielemzi és felveszi a lehetőségek listájára a szabványosítás szempontjából, de csak akkor számolnak velük, ha az összes gyártó garantálni tudja, hogy készítenek rá támogatást. Amint ez az örömteli pillanat elérkezik az adott csoporton belül, úgy a funkcióból szabvány lesz.
Az AMD gondja ezzel ugyanaz, ami másnak. A GAB és az ARB nagyon lassan halad a szabványosítással, mert nem egy, nem kettő, de még csak nem is három, hanem legalább egy tucat szereplő visszajelzései alapján döntenek ezekben a kérdésekben, és általában az ennyire demokratikus rendszerek velejárója, hogy a hatékonyságuk rendkívül alacsony, függetlenül attól, hogy minden esetben megfontolt és racionális döntések születnek.
A cikk még nem ért véget, kérlek, lapozz!
