Mi a helyzet az API-val?
A hardverek általánosabb megközelítése mellett komoly tényező még a szoftver, illetve jobban mondva az API (Application Programming Interface), vagyis alkalmazásprogramozási felület. A grafikus számításokkal dolgozó programokat szinte kivétel nélkül API-ra írják, ennek segítségével az adott alkalmazás úgy használhatja a különböző rendszerek szolgáltatásait, hogy annak belső működését nem szükséges ismerni. A hardver és az API között a grafikus driver teremt kapcsolatot, mely nevének megfelelően meghajtja a hardvert. Elméletben elmondható, hogy ha egy hardver és a hozzá tartozó driver támogat egy bizonyos API-t, és arra készül egy alkalmazás, akkor a program minden további nélkül futni fog a hardveren. A valóság azonban ennél sokkal bonyolultabb; bármennyire is az egységesség az API célja, a jó sebességhez direkt optimalizálásokra is szükség van.
A legfontosabb megérteni, hogy ahogy a különböző hardvereknek van egyfajta logikai futószalagja, úgy az API is rendelkezik ezzel. Jellemző, hogy a hardvert az elsődlegesen megcélzott API elvi működéséhez igazítják, de ma már a grafikus vezérlők nem csak egy-két API-t támogatnak, hanem lassan egy tucatot vagy többet, így könnyen kitalálható, hogy nagyon nehéz minden igénynek tökéletesen megfelelni. Ezen a ponton a hardvergyártók és az API fejlesztéséért felelős cégek, illetve csoportok együttműködnek, hogy a lehető legjobb működést biztosítsák, de szinte lehetetlen minden szituációt gyorsan lereagálni.
Az elterjedt grafikus API-k szempontjából az OpenGL, a mobil piacra szánt OpenGL ES, valamint a Windows operációs rendszereken uralkodónak számító DirectX említhető meg. Sajnos mindegyik API-ról elmondható, hogy az alapvető logikai futószalag szintjén az azonnali leképzést részesítik előnyben, ennek megfelelően az IMR elvnek kedveznek. A TBR – a korábban leírtak ismeretében – az azonnali leképzés elvét csípőből elveti, ugyanis a mozaikok leképzése addig nem kezdődhet el, amíg a háromszögek nincsenek betöltve, kötegelve és sorba rendezve.
Az OpenGL és az OpenGL ES nem kínál általános megoldást a fenti problémára, így nagyon nehéz megállapítani, hogy mikor van az összes háromszög betöltve a mozaikba. Erre a gyártók specifikus kiterjesztéseket kínálnak, amit jellemzően kihasználnak a programok (legalábbis amelyek Androidra és iOS-re készülnek). A DirectX API már kínál egy általános lehetőséget arra, amivel a fejlesztő meghatározhatja, hogy az összes háromszög be van-e töltve, de ezt gyakorlatilag senki sem használja, mivel a PC-s piacon elterjedt, IMR-elvű rendszereknél ennek semmi haszna nincs.
Egy másik jelentős problémája a TBR és TBDR elvű rendszereknek, hogy limitált a mozaikokban kötegelhető háromszögek száma. Ezt ugye az API semmilyen formában nem korlátozza, és így tesznek az IMR-elven működő hardverek is, vagyis a fejlesztők nagyon bőkezűen bánhatnak ezzel, bár nem feltétlenül ajánlott, mivel a teljesítményre negatív hatással van részletesebb geometria. Visszatérve az ultramobil megoldásokhoz, a mozaikokban a limitáció mértéke a háromszöglista méretétől függ, így minden hardver más paramétert használ. Ezzel a fejlesztőknek kalkulálniuk kell az alkalmazáshoz készített tartalomnál, de akkor sincs baj, ha esetleg szükség lenne a hardveres limitáció túllépésére. Ilyenkor két fázisban kell a feldolgozást elvégezni. Be kell vetni egy mélységpuffert, amibe le kell menteni a kötegelhető háromszögek egy részéről az információt, majd a második fázisban a maradék háromszöggel kell folytatni a munkát a lementett mélységpuffer adatainak felhasználásával. Sajnos ez a megoldás nagyon lassú egy ultramobil GPU-nál, de működőképes. Ugyanakkor a legtöbb fejlesztő igyekszik úgy alakítani a tartalom minőségét, hogy ne ütközzenek a hardverek ebbe a korlátba. Elsősorban ez az oka annak, hogy a mobil piacra szánt játékok alacsony geometriai részletességgel dolgoznak.
A fentiekből már látható, hogy nem egyszerű úgy megírni egy programot, hogy az minden hardveren optimálisan működjön, ugyanakkor ma még viszonylag kedvező a piac eloszlása, mivel az ultramobil és a PC-s GPU-k – eltérő alkalmazásaik révén – jellemzően nem egy ligában játszanak. A Windows RT és főleg a Windows 8 megjelenése azonban alapvető váltás. A Microsoft a mobil piac megcélzásával hirtelen szembetalálta magát azzal, hogy ki kell szolgálnia minden rendszert, lehetőleg közös alapokkal. A DirectX 11.1-es API-t már ennek megfelelően tervezték, így a gyártók megkapták a lehetőséget, hogy egyéni kiterjesztésekkel segítsék a fejlesztők munkáját, illetve általánosan kihasználható újítás, hogy a program a futtatás elején lekérdezheti, hogy a hardver milyen elven dolgozik. Ezt a D3D11_FEATURE_DATA_ARCHITECTURE_INFO struktúra használatával lehet megtenni. Amennyiben egy alkalmazást a fejlesztő kellő körültekintéssel ír meg – az eltérő elven működő hardvereket figyelembe véve –, akkor a DirectX 11.1-es API-val lehetőség van arra, hogy a program minden hardveren megfelelő hatékonysággal fusson.
A cikk még nem ért véget, kérlek, lapozz!
