Ott hagytuk abba, hogy ha módot találnánk egy első hallásra nyilvánvaló képtelenség tesztelésére, mármint hogy az egyik gyártó illesztőprogramjával (driver) hajtsuk meg a másik hardverét, akkor szinte biztosan érdekes következtetésekre jutnánk a driverek minőségét illetően. A linuxos openGL, ha szűkmarkúan is, de lehetővé teszi a fenti képtelenséget. A kliensoldali libGL.so dokumentáltan alkalmas heterogén hardverkörnyezet működtetésére is, tehát lehet a gépünkben két különböző 3D-gyorsító VGA-kártya, és - bizonyos feltételek és kompromisszumok teljesülése mellett - mindkettő meghajtható ugyanazon libGL.so-n keresztül. Ezek szerint nem lehetetlen az sem, hogy egy másik eszköz kliensoldali meghajtóját alkalmazzuk egyfejes kiépítésnél is, a legrosszabb, ami történhet, hogy nem működik majd a gyorsítás, esetleg lefagy az X-szerver vagy a gép (normál használathoz a zárt driverek licence tiltja az ilyesmit, de kis csapatunk úgy gondolta, hogy egy egyszeri, a fejlődés irányának esetleges helyreállításáért elvégzett tudományos kísérlet minden bizonnyal távol áll a rosszindulatú felhasználástól).
A kísérlet
Adott egy integrált, Intel i845-ös masina, amit normál esetben az i810 nyílt driver hajt, teljesítménye pedig több mint visszafogott. Mivel a 71.86.xx Nvidia driver volt az utolsó, ami még nem ellenőrizte a telepített fájlok verzióit és konzisztens voltát, mi több, nagyjából a kor eszközeihez is passzolt, ezért erre esett a választás. A beépített parancssori kapcsoló segítségével kicsomagoltuk a telepítőt, átnéztük a dokumentációkat és a fájlok azon funkcióit, melyek visszafejtés nélkül, ismereteink és következtetéseink alapján is nyilvánvalóak. Szükségünk lesz a libGL-re, a libGLCore-ra és - próbálgatásos alapon - a két mellékelt Nvidia TLS közül a rendszerünkön működőképes egyikre, ezeket az eredeti fájlok mentése után egy kis átnevezéssel, linkeléssel könnyen rendszerbe lehet illeszteni (az első két fájl a kliensoldali GL, GLX funkciók és a gyorsított 3D alapfunkciók hordozója, a TLS pedig még véletlenül sem az X-en keresztüli, titkosított hálózati kommunikációt segítő Transport Layer Security, hanem a Thread Local Storage rövidítése, ami lehetővé teszi, hogy a leképezésben részt vevő programok, folyamatok közvetlenül a memórián keresztül kommunikálhassanak egymással és cserélhessenek adatot).
Ha mindezzel megvagyunk, indítsunk egy szimpla glxgears tesztet (a mérést az átalakítás előtt is el kell végezni). Egy kis kitérő: a szakma ezt hallva jogosan verheti az asztalt, hogy: „A glxgears nem benchmark!” Csakhogy nem a 3D VGA teljesítményére vagyunk kíváncsiak - aminek mérésére egyébként a glxgears tényleg csak rendkívül érintőlegesen alkalmas -, hanem az átviteli lánc helyességét vizsgáljuk. A tradicionális GLX és a DRI közötti egyik legnagyobb különbség a kommunikációs láncban van, ezért nekünk olyan mérőeszköz kell, ami rengeteg apró ismétlődő jellel képes terhelni az átviteli lánc elemeit olyan módon, hogy az a megjelenítő eszközzel különösebb erőlködés nélkül számlálható legyen, és erre egy apró, szinte triviális openGL teszt tökéletesen alkalmas, és az eredmény is magáért beszél. Az i845 és a hasonló korú eszközök mérésénél a fenti GLX összeállítás 0-30% közötti pluszteljesítményt tud felmutatni... ja, hogy a nulla nem eredmény? Dehogynem! Az egy évtizede békésen regnáló aktuális mantra szerint a GLX pont hogy szignifikánsan gyengébb átviteli teljesítményt kellene, hogy mutasson, tehát még a nulla (az egyezés) is óriási eredmény, mert ledönt egy hatalmas tévedést, és végre elkezd rendet rakni a fejekben egy egész dekádon átívelő tévelygés után.
Azok az esetek pedig, melyeknél javulás következett be, egyértelműen eldöntik a versenyt. A fenti teszteket természetesen terhelés alatt, korabeli játékprogramokkal és a ViewPerf 6.2 professzionális (leginkább CAD) méréshez használt tesztjeinek megfelelő léptékre csökkentett változataival is elvégeztük, az eredmények szintén eltörlik az eddigi szabályokat. A tesztek kiterjesztése ATI Radeon kártyákra szintén hasonló eredményeket hoz, sőt, a szoftveres leképezés is megizmosodik tőle (i915 esetén tapasztaltunk ellenkező eredményt, ahol a kernel driver és a drm nem tett lehetővé az adott rendszer keretei között normális működést, illetve néhány lapkészletnél a memóriavezérlő hajlamos megbolondulni a fentiektől, de ezt egy reset megoldja... maradandó kárt tenni egyetlen hardverben sem sikerült, ennek ellenére olvasóinknak azt tanácsoljuk, hogy ehhez hasonló kísérleteket csak a célra konkrétan feláldozható gépekkel végezzenek, azokért semmilyen felelősséget nem vállalunk).
Következtetések
A GLX protokoll semmivel sem rosszabb, sőt sok esetben jobb, mint a DRI-ben implementált megoldás, szóval nem véletlen, hogy az Nvidia a mai napig ragaszkodik hozzá.
Az egy évtizeddel ezelőtti mérések vagy tévedésen alapulnak, vagy az időközben „divatba jött” XCB és az AIGLX alkalmazása, gyorsító hatása helyre tette a dolgokat, és időközben a command dma használata is gyökeret vert a Linuxon, ami a Utah-GLX idején még csak terv, illetve szórványos megoldás volt.
A GLX protokoll leírása egyértelműen ír a GLX DIRECT megoldásról, amikor is a kliens és a szerver is egy gépen foglal helyet, így az információ hálózati be-, és kikódolás - tehát veszteség - nélkül utazik az általunk futtatott pl. játékprogramtól az X-szerveren keresztül a VGA-kártyáig. A TLS egy rakás nehézkes és nagy tömegű információ továbbításával kapcsolatos problémánkat megkönnyíti és felgyorsítja, tehát vétek lenne nem tudomást venni róla (a MESA forrásában benne van a lehetőség, a bináris csomagok nagy részénél mégis kétséges az opció megléte).
A sikeres tesztekben a hagyományos XAA gyorsítási architektúra és memóriavezérlés működött, ahol EXA vagy UXA és GEM került a képbe, ott mindig esett az fps. Erről hosszú viták zajlanak a szakmai fórumokon, nekem személy szerint az a véleményem, hogy ha valami kevesebb fps-t produkál, arról egy kicsit nehéz elmagyarázni, hogy nekünk az jobb. Rendben van, hogy például a kompozit effekteknél jobban teljesít, de észre kellene végre venni, hogy a Compiz-mániába azóta már a Microsoft is csúnyán belebukott a Vista kapcsán, szóval mindenki vonja le belőle azt a konzekvenciát, amit gondol, illetve olvasson utána, hogy az újításokat kik és miért erőltetik, favorizálják. Akár néhány oldalnyi „guglizás” után minden világos lesz. Van értelme az ilyen irányú fejlődésnek, de ez nem a Linux-felhasználók, és főleg nem a játékosok érdekét szolgálja.
Végeredmény
Mindezek fényében már csak az volt hátra, hogy sikeresen átfordítsunk a MESA kódbázis alapjain egy olyan új kliensoldali drivert, egy libGL.so-t, ami lehetőleg mindenben kamatoztatni próbálja az Nvidiánál látottakat, a Utah-GLX örökségében olvasottakat, és mindazt a fejlődést és lehetőséget, amiket az elmúlt időkben maga a MESA és az X-szerver kínál számunkra. Hosszú fordítási munka kezdődött, ahol sok-sok kudarc, kódpiszkálás és tanulás eredményeként előállt egy kezdeti, működőképes libGL.so fájl, ami a fentiek nagy részét már tisztességgel megvalósítja.
Az eredmények önmagukért beszélnek, a különböző fillrate tesztekben a fenti i845 - jó minőségű képet adva - elérte az Intel által kiadott elméleti hardver-specifikáció felső határértékét (sőt néha ennél többet is, persze utóbbi esetben már a memória sávszélességének limitje felett is teljesített, ami természetesen rossz hatással volt a képminőségre, villódzás és tearing formájában). Az öreg i845-ön simán játszható lett például a World of Padman legújabb verziója. Mivel ez a libGL még közel sem minden szempontból volt megfelelő, elkezdődött egy még inkább optimalizált driver fordítása, azonban ez - első lépésben - még csak szoftveres leképező (MESA XLIB) verzióban sikerült. E driver második próbája - ami a keresztségben a softlibGL2 nevet kapta - már értékelhető eredményeket hozott. Teljesítménye egy P3 gépen viszonylag kis javulást mutat a szokásos DRI SWRAST PROVIDER-hez képest, de egy egymagos P4 vagy Athlon masinán már az új szoftveres leképezővel egész komoly játékokat, demókat lehet futtatni, még modernebb vason pedig akár 400 százalék feletti teljesítmény is kijön a csövön a MESA DRI által nyújtott szoftveres leképezéshez képest.
A tesztek és a kísérletek természetesen nem fejeződtek be itt, további kísérletek zajlanak a meglévő kísérleti driverek további javítására, egyéb hardvereszközök kiterjesztésére és pl. a népszerű böngészők WebGL teljesítménye, illetve az Adobe Flash 2D és 3D teljesítményének - Linux rendszeren - a fentiek segítségével történő javítása érdekében. Bedobtunk egy kavicsot az állóvízbe, és az bizony hullámokat vetett. Ha e cikkek okán semmi más nem történik, csak további fejlesztők kapcsolódnak be a munkába, és néhányan kísérletekbe kezdenek, elkezdenek szabadon gondolkodni, és esetleg még jobb, előremutatóbb ötletekkel állnak elő, már tettünk egy óriási lépést a jó minőségű és nyílt forrású linuxos 3D driverek irányában.
Eredmények
A cikkben felsorolt kísérleti driverek helyet kaptak a nyomtatott PC World magazin mellékletén, azokat - saját felelősségére - bárki kipróbálhatja. A teszt többféle Linux disztribúción is jól működhet, mi a Little Susie feat. KDE3-at és az openSUSE-t alkalmaztuk, a kezdeti problémák elkerülése végett mindkettőből a bevált 32 bites kiadást. Kicsomagolás és tesztelés: Csomagoljuk ki a driver fájlt, ami két mappát tartalmaz, egyikben a hardveresen gyorsított, a másikban a szoftveres leképezést megvalósító libGL.so található. Nyissunk egy konzo ablakot, lépjünk be a választott mappába, és ott adjuk ki az [LD_PRELOAD=./libGL.so glxgears] parancsot. (A glxgears helyett bármilyen játék vagy 3D-teszt megadható, a fenti eljárással a rendszer a választott libGL-t fogja az adott program futtatásához használni. A teszt bármilyen gyártó (Intel, ATI/AMD, Matrox, S3, SIS) VGA-kártyáinál érdekes eredményeket adhat. Nvidia VGA esetén a hardveresen gyorsított teszt-verziót nincs értelme lefuttatni, az újabb bináris meghajtók mellett pedig nem is igazán lehetséges.)
INTEL i845G integrált VGA mérés (Hardveresen gyorsított teszt)
INTEL i845G, MESA DRI i915
2465 frames in 5.0 seconds = 492.880 FPS
2446 frames in 5.0 seconds = 489.043 FPS
2448 frames in 5.0 seconds = 489.553 FPS
GLX teszt, kísérleti libGL.so.1.2
2627 frames in 5.0 seconds = 525.152 FPS
2580 frames in 5.0 seconds = 514.227 FPS
2580 frames in 5.0 seconds = 515.054 FPS
Az összes Intel mérési eredmény letöltéséhez kattints ide.
ATI Radeon 7500 mérés (Hardveresen gyorsított teszt)
RADEON, MESA DRI
7163 frames in 5.0 s = 1432.430 FPS
7188 frames in 5.0 s = 1437.599 FPS
7190 frames in 5.0 s = 1437.955 FPS
GLX teszt, a kísérleti libGL.so.1.2
9781 frames in 5.0 s = 1953.173 FPS
9720 frames in 5.0 s = 1943.880 FPS
9740 frames in 5.0 s = 1946.987 FPS
Az összes RADEON mérési eredmény letöltéséhez kattints ide.
