Richard Huddy egy rendkívül érdekes kijelentést tett az elmúlt héten a bit-tech számára adott interjúban. Az AMD fejlesztői kapcsolataiért felelős szakembere szerint a PC-s játékok grafikai színvonalát elsősorban az API limitálja. Elmondása alapján a helyzet nagyon vicces, mivel az aktuális konzolgenerációnál (Xbox 360 és PlayStation 3) már tízszer erősebb PC-s hardverek léteznek, a játékok azonban mégsem néznek ki sokkal jobban PC-n.
Az interjú alapján Richard Huddy leszögezte, hogy egy exkluzív cím a konzoloknál nagymértékben épít az adott hardver képességeire, és ezek a programok elképesztően néznek ki. Az elsődleges előny a konzolnál a rajzolási parancsok száma, ami akár a húszezret is elérheti, és a rendszer másodpercenként 30-60 képkockát ki is rajzol a képernyőre. PC-n sajnos az API-n keresztül zajlik a rajzolás, így ez a szám 2000-3000 lehet, ha nem akarnak a fejlesztők teljesítményproblémákba ütközni. Talán a DirectX 10 és 11 esetében bevezetett újításokkal el lehet jutni 5000 parancs alkalmazásáig, de ez még mindig messze a konzolokkal elérhető szint alatt van.
Az előbbiekhez hozzáfűzve emlékezhetünk, hogy a DirectX 10 legnagyobb újítása volt az erőforrás érvényesítésének reformja, amivel a rajzolási parancsok közötti késleltetés csökkent minimálisra. Ennek megfelelően az adott program a futtatás megkezdésekor behatárolta a hardver képességeit, és nem kellett ellenőrizni a hardveres támogatást a parancsok kiadása előtt. A DirectX 11 ezt a feldolgozást a többszálú munkavégzéssel egészítette ki, de egyelőre a rendszer nem teljesen úgy működik, ahogy az elvárható lenne. A fejlesztők visszajelzései szerint nem kevés esetben negatív hatást fejt ki a teljesítményre a több programszálon történő renderelés. Elméleti síkon ezen lehet javítani a driver fejlesztésével, de nem éppen könnyű kezelni a helyzetet.
Richard Huddy
Richard Huddy elmélete szerint egyszerűen érdemes elgondolkodni az API elhagyásán, és a hardverek natív programozását kell előnyben részesíteni. A feltevés nagyon jól hangzik, és kétségtelen, hogy technikailag ez lenne a legjobb megoldás, de üzleti szempontok alapján komoly kétségek merülhetnek fel. Az elsődleges probléma a kompatibilitás biztosítása, ami alapvetően az API feladata. Amennyiben egy adott programot egy fix architektúrára ír a fejlesztő, akkor az alkalmazás csak az adott hardvereken fog tökéletesen futni. Ez a megállapítás az utódokra is vonatkozik. Jó példa erre a Radeon HD 6900 esetében történt változás, amely termékekben az AMD a VLIW5-ös shader processzorokat VLIW4-re cserélte. Egy VLIW5-re optimalizált program sebessége nem lesz túl jó az új megvalósításon, vagyis át kell dolgozni az optimalizálást, ami nem kis idő. Itt érkeztünk el ahhoz a tényezőhöz, ami a legnagyobb probléma. A fejlesztőknek pont idejük nincs, és itt nem egy hardver optimalizációjára kell gondolni, hanem rossz esetben legalább három-négyre. Üzleti szempontok alapján ez jelenleg nem fér bele, még akkor sem, ha számottevő előnyt jelentene.
Az AMD által felvázolt elmélet elsősorban a kompatibilitásban bukik el. Tény, hogy az előnyök számottevőek lennének, de az üzleti érdekek nem ezt diktálják. Az IBM PC elsősorban arra épül, hogy a platformra megírt programok a gyártóktól függetlenül futnak a termékeken, ellentétben a konzollal, ahol egy fix célhardvert vásárol a felhasználó az adott játékokhoz. Mindkét elgondolásnak van előnye és hátránya, és ezekkel együtt kell élni. Ami viszont változást hozhat az a platformosodás. Jelenleg a hardverkínálat és a konfigurációk mixelésének lehetősége gyakorlatilag határtalan. A rendszerszintű integrációval ez a helyzet jelentősen egyszerűsödik, vagyis a fejlesztőknek idővel kevesebb potenciális architektúrával kell számolni. Ezen a ponton Richard Huddy javaslata értékelhető lehet. Az adott programot meg lehet írni a kívánt API-kra, és azokon kívül egy vagy több specifikus rendert is lehet készíteni natívan az elérhető hardverek képességeihez igazítva. Ilyen elven a kompatibilitás az API-kon keresztül megmaradna amellett, hogy a natív renderelő kihasználhatná az adott technika képességeit. Valószínű, hogy a legtöbb fejlesztő nem fog élni ezzel a lehetőséggel, de a grafikát egyre jobban korlátozza majd a grafikus API, vagyis az igazi innovációhoz idővel elengedhetetlen lesz az adott architektúrákhoz illő specifikus futószalag kialakítása. Megfontolandó lehetőség még a játékok számítási felhőben történű futtatása, amivel a nagyobb gyártók már kísérleteznek, de egyelőre kevés olyan hely van a Földön, ahol a követelményeknek megfelelő a hálózat minősége.
