2017. november 22., szerda

Útvonal

Tesztek » Videokártya rovat

A grafikus meghajtók optimalizálásának lényege

Ma már szinte minden új programhoz új eszközillesztő kell. Megvizsgáljuk, hogy miért, és hogy lesz-e változás a jövőben.

Az absztrakció kérdése

A PC-s játékosok, ezen belül is főleg az iparág eseményeit követő felhasználók körében nem kell bemutatni az úgynevezett grafikus meghajtókat vagy eszközillesztőket, viszont sokan nem tudják, hogy miről van szó, így röviden leírjuk, hogy ezek lényegében olyan szoftverek, amelyek vezérlik az adott grafikus vezérlőt, illetve lehetővé teszik az elterjedtebb API-kra írt programok futtatását a hardveren. A különböző eszközillesztők szerves részei a PC-s termékeknek, sőt igazából más területeknek is, csak az adott szegmenstől függ a frissítés gyakorisága. Amit viszont a PC-t felhasználó réteg leszűrhet, hogy semmihez nem jön olyan sűrűn frissítés, mint a grafikus vezérlőkhöz. Legyen szó béta vagy WHQL jelölésű meghajtóról, egy évben legalább fél tucat új verzió jelenik meg szinte mindegyikhez, és a programok, elsődlegesen a játékok esetében, rendszeresen felhívják a felhasználók figyelmét, hogy frissítsék a grafikus eszközillesztőt. Felmerülhet a kérdés, hogy miért van ez, miért ilyen fontos a legújabb szoftververziók használata, illetve egyáltalán lehet-e arról szó, hogy ez a működési modell a jövőben megváltozik. Jelen cikkünkben e kérdésekre keressük a választ.

Többször lehet hallani egy-egy új játék kapcsán, hogy majd megérkezik hozzá a megfelelő grafikus meghajtó, amivel jobban fog futni. Ez az elterjedt grafikus API-kban, mint például a DirectX vagy az OpenGL teljesen helytálló felvetés, és nagyrészt ezek az eszközillesztők biztosítják, hogy az adott játék jól fusson az adott grafikus vezérlőn. Itt nem csak a sebességről van szó, hanem a megjelenítés hibamentességéről is. Ezeket a gyártók úgynevezett alkalmazásspecifikus profilokkal érik el. Minden grafikus eszközillesztő tartalmaz egy igen nagynak mondható adatbázist, amely leírja, hogy mely alkalmazásokhoz mely beépített rutinokat kell használni. Az azonosítás jellemzően az alkalmazás futtatható állományának nevéből történik meg, ezért sem szokták ajánlani ennek a fájlnak az átnevezését. Amennyiben a meghajtó nem tartalmaz profilt az adott programra, úgy az általános rutinokon keresztül történik a vezérlés.

A profilok a grafikus meghajtókban tartalmazzák az alkalmazás kompatibilitási jellemzőit az egyes eszközillesztőben található funkciókra, mint például a kényszeríthető élsimítás vagy anizotrópikus szűrés. Ha esetleg valamelyik opció grafikai hibákat generál, akkor a profilba bekerül egy tiltás a nem kompatibilis technikára, így a felhasználó azt már hiába állítgatja. Szintén a profilok felelnek a több grafikus vezérlővel rendelkező rendszerek optimális működéséért, vagy ha ez nem oldható meg, akkor a támogatás kényszerű kikapcsolásáért. Az eszközillesztőknek jellemzően e részeit láthatja a felhasználó, és például az AMD, illetve az NVIDIA bizonyos funkciókra enged némi felülbírálási lehetőséget is, ha a felhasználó úgy gondolja, hogy a szoftver valamiért rosszul dönt, vagy esetleg elfogadja a grafikai hiba melletti működést az esetleges járulékos előnyök mellett. Ezt hivatalosan egyik említett cég sem ajánlja, de a lehetőség adott.

A profilok viszont ennél sokkal többről szólnak. Az aktuálisan elérhető DirectX és OpenGL API-kban közös, hogy elvágják a fejlesztőt a hardvertől. A programozóknak a lehetőségei abban ki is merülnek, hogy az API működésére koncentrálnak, és a parancsok tényleges feldolgozása az API alatt dolgozó grafikus eszközillesztők feladata. Ezt egyfajta absztrakciónak nevezzük, mivel létezik egy olyan közös alap (maguk az API-k), amelyekre meg lehet írni az alkalmazást, és azt képesek futtatni a közös alapot támogató hardverek a grafikus eszközillesztőkön keresztül. Az absztrakció mértékét maga az API határozza meg. Ez nem kiválasztható, mivel már az adott API specifikációja behatárolja a programozó számára lényegesnek és lényegtelennek tartott funkciók elérhetőségét. Itt kerül előtérbe az absztrakció szintje. Elméleti megközelítéssel élve két opciót különböztetünk meg: a magas és az alacsony szintű absztrakciót. A magas szintű mód előnye, hogy rendkívül jó lesz a kód teljesítményének portolhatósága, de ez az általános sebesség rovására mehet. Az alacsony szintű mód ennek az ellentéte, vagyis a sebesség a hardver kiemelt hozzáférhetősége következtében igen magas lehet, de a kód teljesítményének portolhatósága már kedvezőtlen, tehát minden hardverre külön kell optimalizálni.


Az aktuális megoldások absztrakciós szintjei [+]

A gyakorlatban ez az egész nem olyan egyszerű, mint ahogy hangzik. Bár a DirectX és OpenGL API-k esetében leginkább a magas szintű absztrakciót szokás emlegetni, de az elmúlt évben több fejlesztő is kiemelte, hogy az aktuális DirectX inkább egyfajta középszintet képvisel. Más megfogalmazással élve rendkívül jól körülírja az a programozói nézet a helyzetet, miszerint a DirectX 11 absztrakciójának szintje túl magasan van ahhoz, hogy gyors legyen, de túl alacsonyan ahhoz, hogy egyszerűen lehessen rá programozni. Nagyon hasonló helyzetben van az OpenGL is, csak erre az API-ra nem írnak túl bonyolult játékokat a fejlesztők. Ez az elsődleges oka annak, hogy folyamatosan frissíteni kell a grafikus meghajtókat, mivel maga az absztrakciós szint van a programfejlesztések szempontjából igen rossz helyen, ugyanakkor ezzel a működési modellel kell együtt élni, és a legjobb teljesítményt, illetve stabilitást kihozni belőle.

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

H​i​rde​tés​

Előzmények

Hi​r​d​e​té​s​

Copyright © 2000-2017 PROHARDVER Informatikai Kft.