Megy-e az Intel GMA az Nvidia zárt driverével? :)

Fórumok

Kedves Olvasó!
Ne kezdj hangosan nyeríteni a röhögéstől,
a címben nem egy láma kérdés van...
de nagyon régen írtam már utoljára hasonló
vasárnapi polgárpukkasztó posztot... :)
Ugyanis megy. Részben legalábbis.

A kísérlet alanya egy Acer Aspire 5736z notebook volt,
integrált Intel GM45 VGA vezérlővel.
Hardveres 3D teljesítménye az intel driverrel a szokásos szerény érték,
3D asztalhoz és Google földgömbhöz pont elegendő,
a glxgears 1070 fps-t mutat.

Most jön a csavar.
Ha a zárt forrású Nvidia linux driver 71.86.14-ből
kiemeljük a libGL, libGLcore, és libnvidiatls libeket,
és a megfelelő átnevezések és linkek létrehozásával
rendszerbe illesztjük őket, minden működik tovább,
a glxgears is 980 fps körül mutat, tehát számottevő
teljesítményesés nem is keletkezik...a 10-15 éves
Nvidia kártyákhoz írt, több mint 6 éves driverrel.
A konzekvenciák levonásában számítok a hup közönségére.

Figyelmeztetés: aki ki szeretné próbálni, számoljon a következőkkel:
az ICH9 chipset rosszul viseli a mutatványt, bár maradandó károkat
elvileg nem okoz, néhány reset, és helyreáll.
Ideiglenesen kiakadhat a GM45 memóriavezérlése,
összekuszálódhat a framebuffer címzése,
és leállhat a Realtek gyártmányú HDA hangchip is.

A libglx, az nvidia_drv, és az nvidia kernel modul nem kell
a 71.xx csomagból, csak a kliens oldali GL.
A kétféle tls közül a 2KB-os lib a nyerő.
A későbbi Nvidia driverek (96.xx, stb) már nem alkalmasak
a fenti trükkre, szegmens hibával elszáll a glxgears.

Hozzászólások

imadom ezt a "barkacsoljunk valami marhasagot, majd adjuk el, mint vilagmegvalto tudas" dolgot.

Nem akkora marhaság, mint gondolnád, kedves NagyZ...
ugyanis -a kliens-szerver GLX felépítés okán-
a fenti "marhaság" bizonyos mértékig lehetővé teszi,
hogy összehasonlítsuk különböző gyártók/készítők
drivereinek jóságát teljesen azonos hardver körülmények között.

Egyrészt érdekes dolgok derülhetnek ki, mert eddig a a drivert
mindig mindenki a hozzá tartozó hardverrel együtt mérte,
azaz két ismeretlen tényező összegét kaptuk eredményül.
Az így kapott érték talán reálisabban méri a kliens oldali GL
sebességét.

Másrészt, az órajel húzásán kívül még egy esélyt kapunk
a 3D teljesítmény esetleges fokozására, ha valamelyik gyártóé
például egy másik hardverrel jobban teljesít.

-
"Attempting to crack SpeedLock can damage your sanity"

Nézd, szerintem kételkedni kötelező.
A linuxos 3D gyorsítás világa tele van dogmákkal,
amik LEHET hogy nem teljesen igazak.

Simán kiderülhet például, hogy az intel driver kliensoldali része
nem is olyan rossz minőségű, csak maga a hardver gyenge.
-
"Attempting to crack SpeedLock can damage your sanity"

Ez mind rendben van, de ezzel nem jutsz közelebb a probléma megoldásához
egyetlen lépéssel sem. A fenti próbák viszont bizonyíthatják,
hogy nem a szerver GLX keresztmetszete a mumus,
és nem feltétlenül a DRI az üdvözítő megoldás,
mint ahogy azt az évtizedes dogma tartja.

Sőt. Az Nvidia drivere szinte azonos teljesítményt nyújt Linuxon,
és Windowson is, nagyon kicsit az utóbbi javára.
Annyit biztosan lehet róla tudni, hogy a zárt, unified driver
minden platformra azonos kódbázis alapján készül náluk.

Tehát, a probléma okaként a többi kártyánál marad a DRI / fakeglx,
és a kernel meghajtók minősége, mint elsőszámú okok.
-
"Attempting to crack SpeedLock can damage your sanity"

Lehet, hogy többször olvastam el mint te...és nem csak a belinkelt
dri.freedesktop.org oldalt. (a szekrény alján még talán el van mentve
valamire pár demó, amit DOS alatt fordítottam Watcom fordítóval,
hardveres OpenGL gyorsításra építve)

Szerintem éppen hogy a jelen lévők 95%-ának nincs fogalma arról,
hogy mit írtam le. Az Nvidia és az összes többi gyártó linuxos
3D driverei között egyetlen alapvető felépítésbeli különbség van.
Az Nvidia régi drivere szabályos GLX protokol szerint működik,
az összes többié pedig DRI. Kb. 3% különbséget mértem most
a két megoldás között. Ha ez a 3% különbség valódi terhelés alatt
sem növekszik jelentősen a GLX rovására, akkor a DRI születésének
legfőbb oka, fundamentuma egy tévedés, amiért cserébe biztonság
terén szépen elintézték az X-szervert az eredeti állapothoz képest.

Szerk.: pontosítsunk, nem az összes többi gyártóé DRI.
A Matrox Parhelia és a P6xx-P7xx sorozat linux drivere is
tisztán GLX implementáció. A régebbi G200-G400-G550-eseké DRI.
-
"Attempting to crack SpeedLock can damage your sanity"

3% különbség: A glxgears FPS értéke kb attól is változhat, hogy milyen gyorsan mozgatod közben az egeret..............
Nem hiába szállítja a legtöbb disztro egy olyan patch-csel ami

-iacknowledgethatthistoolisnotabenchmark

kapcsolóval írja csak ki az FPS értéket. Ettől te még szorgalmasan jelentgeted itt hogy mivel hány FPS-t értél el benne. Gratulálok.

Lehet, hogy elavultnak számítanak,
de a teszthez -a rendelkezésre álló jelentős mennyiségű
hardverből- nem minden alkalmas, illetve bármin azért
nem fogok "kamikaze repülést" indítani...
(pár napja az egyik Voodoo 3 2000 PCI kártyámat
majdnem kinyírta egy PCI-bugos alaplap,
szóval sem múzeális, sem drága új kártyát
nem kockáztatok, azon túl, hogy nem biztos,
hogy alkalmasak a tesztre)
-
"Attempting to crack SpeedLock can damage your sanity"

A mérési körülményeket meg lehet valósítani úgy,
hogy a gears is értelmes értékeket, információkat eredményezzen.
(értsd: értékelhető válaszokat adjon a kérdésekre)
Ettől függetlenül a szál nem erről szól,
ha még nem esett volna le.
-
"Attempting to crack SpeedLock can damage your sanity"

Olvasd el subchee linkjét, hogy miért is nem használható laborkörülmények közt SEM a glxgears semmiféle benchmarknak.
Nem csak az a gond vele, hogy bármilyen külső körülmény befolyásolhatja az értékeket...

Persze Linuxon nehéz dolgod van, pl. a Unigine demok (amik valóban alkalmasak teljesítmény-összehasonlításra) nem hiszem, hogy szóba állnak olyan rendszerrel, amin a legfrissebb támogatott OpenGL verzió a 13 éves 1.2 vagy legjobb esetben 1.5 (opensource csodadriverek esetén).

Régi hardverre -valódi terheléses teszt gyanánt-
ott van a Quake3, a Tuxracer, vagy a TORCS, stb...
Lehet velük fps-t mérni, csak vigyázni kell,
hogy azonos beállításokkal, ugyanazt futtasd.
Futnak is, már napok óta, több vason is.
-
"Attempting to crack SpeedLock can damage your sanity"

Lehet, hogy én fogalomzavarban szenvedek, de a DRI az nem egy keretrendszer, a DRM kernelmodul kliense ami az X szervert megkerülve közvetlen hozzáférést biztosít az alkalmazásoknak a grafikus hardverhez (valamint koordinálja a hozzáférést az X szerver és más alkalmazások számára), továbbá hardveres gyorsítást biztosít a Mesa és a framebuffer console (ebben az esetben nincs szükség X szerverre) számára?

A GLX ezzel szemben egy API amin keresztül az OpenGL használhatóvá válik az X szerver kliensei számára, valamint egy interfész ami a kliensek és az X szerver (akár hálózaton keresztül is) majd az OpenGL library (legyen az az OpenGL nyílt forrású implementációja, azaz a Mesa vagy egy gyártóspecifikus libGL) között teremt kapcsolatot.

És ha jól értelmezem te adott OpenGL library-t helyettesítesz egy másikkal aminek mindehez nem sok köze van.

Oké, végre egy higgadt, tárgyilagos szemlélő is akadt,
aki láthatóan tisztában van az alapfogalmakkal.
A poszt indításakor a grafikus hardver egy Intel GM45 volt.
A saját drivere a DRI-re épül.
Ezzel szemben a kézzel "beletákolt" Nvidia 71.xx "fél driver"
(a kliensoldali libek) nem DRI-hez vannak linkelve,
mivel az Nvidia holmija a GLX protokollt használja.
Magyarul, ha a telepített pl. Intel vagy ATI kártya GL libjét
kicseréled a megadottra, akkor GLX-en keresztül fog üzemelni,
és csodák csodája, nem megy rosszabbul. (a pár százalék javulás mindössze
a libGL-ek különbségeiből fakadhat)

Az általános dogma szerint a GLX használata kisebb teljesítményt
eredményez, mint a DRI. A DRI ezért jött létre, és ezért a vélt
pluszért áldozott nem keveset a rendszer biztonságából is.
A UTAH-GLX anno ezért ment a levesbe, pedig 10 éve már
nyílt forrással gyorsítottak a korabeli első Geforce kártyákon is.
A nyílt forrású linuxos világ ezen a téren egy évtizeddel ezelőtt
a sok bába közt kiöntötte a gyereket is a fürdővízzel együtt.
-
"Attempting to crack SpeedLock can damage your sanity"

Utánnanéztem és az Nvidia továbbra sem a DRI-t használja, van egy implementációjuk, ahogy van egy GLX implementációjuk is, amit korábban is használtak.

A Nouveau, azaz a nyílt forrású Nvidia driver ellenben a DRI-t használja.

Azaz összefoglalva az Nvidia és az AMD hivatalos eszközmeghajtói nem támaszkodnak a DRI-re és van egy OpenGL library (libGL) implementációjuk, valamint támogatják a GLX-et, ami nélkülözhetetlen az OpenGL és az X szerver közötti integrációhoz.

Az OpenGL libary-nek elvileg támogatnia kell a DRI-t, az Nvidia implementációja pedig elvileg nem támogatja, mindössze GLX protokol üzenetek küldését az X szerver fele vagy direct rendering esetén az Nvidia DRI implementációja fele, ami az Intel esetén nem áll rendelkezésre.

Azaz ebben az esetben nem áll rendelkezésre a direct rendering, mindössze egyféle indirect hardware rendering az X szerveren keresztül.

Azt megértem, hogy ennek a teljesítménye közel azonos lehet a direct renderinggel, de aligha lehet annál nagyobb, így nem egészen értem mit akarsz elérni.

Lényegében a direct rendering helyett közbeiktattad az X szervert (indirect rendering), ami szoftveres és hardveres renderelést is használhat.

http://wiki.linuxquestions.org/wiki/OpenGL
http://wiki.linuxquestions.org/wiki/DRI
http://wiki.linuxquestions.org/wiki/GLX
http://dri.freedesktop.org/wiki/glxinfo

Ismerd be, fogalmad sincs mi az az indirect rendering, pedig az amit leírtam, az X szerver közbeiktatása, ami GLX protokol streamen - akár a hálózaton is - keresztül kapja az OpenGL renderelésre vonatkozó adatokat.

Az indirect rendering ezenfelül hardveresen gyorsítható (indirect hardware rendering), amihez az X szerver átadhatja a GLX protokol streamet egy DRI kliensnek vagy az X szerver maga lehet a DRI kliens.

http://dri.freedesktop.org/wiki/GLcoreExtension

Az indirect rendering nem az X szerver közbeiktatása, amennyiben nem közvetlenül a DRI-n, hanem GLX extension használatával az X szerveren keresztül zajlik a renderelés?

Mondhatnám, hogy annyi is elég, hogy igennel és nemmel válaszolsz, de mi lenne Gabucino ha a változatosság kedvéért néhány sornyi információt hozzá tudnál tenni ehhez.

Komolyan, csak néhány sor, nem is kerül több időbe mint a trollkodás és meg is mutatná, hogy nem alaptalan a korábbi hozzáállásod.

Az nemigen lehetséges, mivel az X szerverrel történő interakció szükséges, valamint az X szerver meg a DRI-hez.

Most megnéztem ezeket és igazad lehet:
http://dri.sourceforge.net/doc/dri_data_flow.html
http://dri.sourceforge.net/doc/dri_control_flow.html
http://dri.sourceforge.net/doc/images/data_flow.jpg
http://dri.sourceforge.net/doc/images/control_flow.jpg

Tessék, máris sokkal előrébb vagyunk, mondom én, hogy érdemes megosztani a szakmai tudásodat és akkor még a trollkodás is belefér.

Azaz ebben az esetben nem áll rendelkezésre a direct rendering, mindössze egyféle indirect hardware rendering az X szerveren keresztül.

Pontosan. Marad a GLX használata, mint egyetlen lehetőség a rendszer számára a fenti lib-csere után. Tehát, kiiktattam a DRI-t, de a GLX-en keresztül elérhető maradt a hardveres gyorsítás.

Azt megértem, hogy ennek a teljesítménye közel azonos lehet a direct renderinggel, de aligha lehet annál nagyobb, így nem egészen értem mit akarsz elérni.

Az általánosan elfogadott dogma szerint a GLX sokkal rosszabb hatásfokú, mint a DRI. A fenti teszt közel azonos, sőt néha még picit jobb értéket is mutatott GLX esetén. Szóval, valami már régóta nem stimmel a GLX vs. DRI téma háza táján. A többség csak ül, szapulja a linuxos 3D gyorsítást, és a legtöbb esetben jogosan teszi. Én találtam valamit, és közzétettem. Megmagyarázni csak részben tudom, ez mind csak hipotézis és néhány kísérlet eredménye. Szeretném, ha akadna néhány kíváncsi ember, aki látva a fentieket belenéz a dolgokba, esetleg sikeresen reprodukálja, belenéz a forrásokba, mert több szem többet lát...Hátha javíthatnánk a linuxos 3D gyorsítás minőségén.

-
"Attempting to crack SpeedLock can damage your sanity"

Szerintem ott lesz a kutya elásva, hogy a DRI tervezése idején
még a GLX proto 1.0-1.1-1.2-es implementációi léteztek csak linuxon,
azoknál még ismeretlen fogalom volt pl. a command dma használata
hardveresen gyorsított indirekt renderingnél.
A GLX 1.3-1.4-ben ezt már implementálták. (lehet, hogy már az 1.2-ben is,
de majd a trollok rákeresnek a gugliban...és még mielőtt belekötnek,
itt a command dma-t nem a kliensoldal éri el mint a DRI-nél,
hanem a szerver GLX gondoskodik róla)

Szóval, ugyanazt a teljesítményt biztosan elő lehet állítani,
a DRI-ben lévő ismert biztonsági problémák nélkül.
(eltekintve attól a ténytől, hogy az Nvidia 71.xx libGL-lel
GLX üzemmódra kényszerítve eddig minden tesztgépen
több jött ki a csövön pár százalékkal, mint a DRI használata esetén)

Ugyanakkor a GLX használata az X szerverrel történő interakcióban nélkülözhetetlen direct rendering vagy sem.
Világos dolog. (bár a GLX 1.3 vagy az 1.4 specifikációja mintha ezen a téren is emlegetne bypass lehetőséget, ez viszont már nekem sem egészen világos)

-
"Attempting to crack SpeedLock can damage your sanity"

Ez leginkább csak arról tanúskodik, hogy az Nvidia féle OpenGL library (libGL) adott szinten kompatibilis az Intel által használttal, szó sincs róla, hogy az Nvidia driverével menne.

Kliens-szerver a GLX. Legalábbis, papíron.
Az Nvidia 71.xx után ez már nem biztos,
a 96.43-nál már valószínűleg a libglx-en keresztül
olyan dolgokat is küld a kerneldriver felé a libGL,
ami "normális" esetben még a saját feladata lenne,
bár ez még csak tipp. (lehet, hogy túl sokat nézegettem mostanában
az egykori UTAH-GLX, és a korai DRI/DRM forráskódokat és doksikat)

A másik érdekesség az, hogy a fentiekben az intel driver
kliensoldali része kb. 10%-kal gyorsabb, mint az Nvidia 71.xx.
Namármost, az Nvidia driver azóta HÍZOTT. Nem is kicsit,
mert a kártyák fejlődtek. Ki fogom próbálni az Nvidia kártyáimat
is az Intel GL-lel, (vagy akár ATI, Matrox, stb-vel is),
mert kíváncsi vagyok a teljesítményre.
Ingyenes szoftveroldali tuning lehetősége jöhet ki ebből,
ha jól sikerül, és ha igen, kíváncsi lennék a gyártók arckifejezésére is...
-
"Attempting to crack SpeedLock can damage your sanity"

De a glxgears annyira nem benchmark, hogy tényleg mindössze csak azt indikálja a megváltozott FPS érték, hogy eltérő libGL-t használsz (és számos más körülmény is befolyásolhatja, azaz még azt sem feltétlenül).

Ha már valamivel akkor teszteld Quake-el, nem mintha sok értelme lenne.

Még az éjjel lement egy rakás teszt, különféle játékprogramokkal is.

Az eddigi eredmények azt mutatják, hogy talán a DRI nem hozza azokat
a teljesítménybeli előnyöket, amiért létrehozták...
ráadásul a DRI komoly biztonsági problémákat is felvet.
Az Nvidia nem véletlenül maradt a GLX mellett,
bár a 96.xx óta már az övék sem teljesen tisztán hagyományos
GLX implementáció, legalábbis erre utalnak bizonyos jelek.

-
"Attempting to crack SpeedLock can damage your sanity"

Tényleg, ha már az Intel driver kérdés szóba került,
az IEGD-t sikerült-e már bárkinek is a Red Hat/Fedora
pároson kívül bármilyen egyéb linuxra felkergetni?
http://edc.intel.com/Software/Downloads/IEGD/
Kíváncsi lennék az Intel hardverből a hivatalos driverrel
kihozható teljesítményre.
-
"Attempting to crack SpeedLock can damage your sanity"

Azt lehetne kerni hogy ne utogess plusz entereket a soraid vegen ? :p

Friss próba egy Intel i865G integrált VGA-val:
a fenti "műtét" mintegy 4%-ot javít rajta,
(komolyabb terhelést még nem kapott, de fog...)
viszont ami még érdekesebb: az Nvidia kliens GLX alatt
az i915_dri dolgozik. (ha kiiktatom, csak szoftveres a render)
Szóval, akkor most mi van ilyenkor?
A szerver GLX ilyenkor "fakeglx" hosztként viselkedik,
és -az X megkerülésével- mindent továbbít a DRI felé?
Vagy a DRI lenne 100% pontosan az 1.2-1.3 GLX
dokumentációkban utalásként szereplő bypass lehetőség?
-
"Attempting to crack SpeedLock can damage your sanity"

Az van, h as libGL _nem_ driver, hanem egy halom matematikai muveletet is vegzo state machine aminek van kapcsolata a hardverrel. Az a 4% abbol adodik, h az nvidia jobb munkat volt kepes vegezni az optimalizacioval, vagy architekturalisan jobban van megtervezve, mint az intel/opensource valtozata. Cserebe viszont kapsz egy sztochasztikus mukodest es ez az a vonas az ami teljesen es tokeletesen ertelmetlenne teszi az egesz "tesztet".

---
pontscho / fresh!mindworkz

Ez most akkor olyan, mintha gázolajat öntenél a benzines autóba vagy olyan, mintha a shell motorolajat kicserélnéd mol motorolajra?
Valaki autós hasonlatot, pls!

olyan, mintha a Dieseles teherautodnak elokeresnel egy kis 91-es kevereknek hitt 90-es evekbeli olmozott motorolajat, amit hivatalosan mar nem is tankolhatnal (de tokmidnegy, mert ugyis motorolajat ontottel a tankba a Diesel melle, nem a forgalomban nem levo uzemanyag-tipust), hogy aztan elmondasd, hogy amikor nyomtad a gazpedalt, 4db-lel hangosabb hangja volt a motornak, de azt nem sikerult lemerni, hogy ezzel egyutt jobban is gyorsult-e :D Ja, es mindebbol megallapitanad, hogy a 91-es keverek es a Diesel tokeletesen mukodik osszetankolva, mert el tudtad forditani a slusszkulcsot

Kellett 1-2 nap, mire működő állapotba hoztam a Viewperf 6.1.2 egykori RH-s release-ét, de érthetően valami olyan, elfogadható tesztprogramot szerettem volna, ami nem overkill, pláne nem a rendelkezésre álló -eléggé vegyes- tesztkörnyezet számára. (glxgears megy a levesbe, a Viewperf -nagyon remélem- már nem fogja csípni a szemét azoknak, akiknek kicsit erősebbre sikerült a kritikai vénája...) :)

Mivel a tesztben néhány nyugdíjas VGA és öregebb libGL is szerepel, így -első körben- a Viewset DX-06-ra esett a választásom, az első néhány viewperf.log holnapra várható.

Korrekt? :)

-
"Attempting to crack SpeedLock can damage your sanity"

Na, született néhány viewperf.log file, a DX-06-tal, i865g és RV250 hardveren.
(libGL variánsok: MESA 7.2, MESA 7.10, ATI 8.28, és Nvidia 71.86-ból)
Egy baj van csak. A teszt még mindig overkill, mert nyilvánvaló szoftveres fallback-et okoz ott is, ahol én indirekt hardveres render eredményt vártam. Lejjebb kell venni a teszt paramétereit, és át kell néznem benne az igényelt GL, GLU, GLX verziókat, na meg az EXT..., ARB..., stb, hogy "közös nevezőt" képviseljen a tesztelt cuccoknál, és ne vágja ki a biztit szoftveres renderre, mert így még értékelhetetlen. Dolgozom rajta.
-
"Attempting to crack SpeedLock can damage your sanity"

Mondjuk érdekelne, hogy egy x200m ati-n nyílt driverhez odatolva ezeket a libeket, vajon kikerülhető-e így a dri? Csak kíváncsiságból érdekel.

ha nem fut a portal2, szoljal eCoffeenak, majd megszerelni neked szerintem. sot, procit se kell cserelned meg 5 evig!

Csodák nincsenek.
Egyszerűen csak hiszek a szoftver minőségének erejében,
és nem szeretem az erőforrás-pazarlást.
Ez legtöbbször elegendő ahhoz, hogy egy-két hardver generációváltást meg lehessen spórolni.
-
"Attempting to crack SpeedLock can damage your sanity"

Technikailag a Portal 2-nek mennie kell az integrált Radeon X200 videókártyán, ami valamivel gyorsabb az Intel GMA 950-nél.

A gyakorlatban ennyire fog menni: http://www.youtube.com/watch?v=JAp8xUPiOqA

Nálam Intel GMA 4500MHD-n rendesen megy, 30-35 fps-el játszható 1440x900-as felbontáson, közepes grafikai beállítások és konzolos tweakelés mellett.

Igen, kipróbáltam és megy. DRI kiiktatásával 5-13%-kal több lett az FPS unreal-ben, elégdúrva!

Tényleg kipróbáltad?
Nekem az első gondolatot az adta ehhez az egészhez, hogy a UTAH-GLX project annak idején Linuxon Quake tesztben sok esetben megközelítette, néhány tesztben pedig el is verte a Windowst, azonos hardveren, azonos beállítások mellett. A tesztek és a munka egy részénél személyesen az "atyaúristen", John Carmack is ott volt, részt vett. (és a poén, hogy általában ő is a glxgears-re alapozta az első köröket, aztán jött pl. a Quake)

Szóval, aztán jött a DRI, és azóta jót nemigen lehet hallani a linuxos 3D gyorsításról.
A UTAH-GLX pedig eltünt a süllyesztőben, pedig 2002-ben már nyílt forrású Nvidia driverük volt az FX5900 Ultra-ig bezárólag. (a kártya hivatalosan még nem is létezett, egy évvel később jelent meg az üzletekben)

Pár mondatban ez a mozgatórugója annak a néhány "eretnek gondolatnak", amit fel mertem vetni.
-
"Attempting to crack SpeedLock can damage your sanity"

"John Carmack is ott volt, részt vett. (és a poén, hogy általában ő is a glxgears-re alapozta az első köröket, aztán jött pl. a Quake)"

Valószínűleg ő a glxgears eredményeket a megfelelő helyén kezelte, és le tudta szűrni a megfelelő következtetéseket, amik semmiképpen nem egyenlőek a nagyobb fps == nagyobb teljesítmény relációval.

--
Don't be an Ubuntard!

Az indirect rendering nem lesz nagyobb teljesítményű a direct renderingnél, leszámítva ha a szoftveres renderelés a processzor miatt hatékonyabb.

Persze lehetséges a hardveresen gyorsított indirect rendering is, egy ilyen megvalósítás volt az Utah-GLX és a jelenlegi végső soron DRI-t alkalmazó megoldások.

Azonban az Utah-GLX fejlesztői szerint az indirect rendering lassabb.

Additionally, the DRI modules only support hardware acceleration for "direct" clients, whereas Utah-GLX only has "indirect" client support. On the one hand, this means that Utah-GLX is slower.

http://utah-glx.sourceforge.net/faq.html#AEN10

Én sem csodát várok, és nem is a fizika megcsúfolását.
Tisztában vagyok mindkét módszer elvi működésével, de mi van akkor, ha a DRI-ben mondjuk évtizede kerülgetünk valami disznó nagy bottleneck-et, ami ezt a mért különbséget okozza? (tipikus szakmai "fától az erdőt" jelenségre gondolok)

-
"Attempting to crack SpeedLock can damage your sanity"

A teljes DRI azon részét kerülhetjük ki a "kényszerített GLX" üzemmel, aminek az a dolga, hogy az X-szervert kikerülve juttassa az adatokat a hardverhez.
Ettől még simán maradhat (az így már indirekt) hardver gyorsítás.
-
"Attempting to crack SpeedLock can damage your sanity"

Az S3 Virge/Trio szoftveres. Van hozzá DRI modul, DRM kód, és nagyon régi kernelmodul is. (libdrm git-ben egy hétig ásva lehet megtalálni, de leforgatnom nem sikerült, azóta már rengeteg minden változott)
A DRI része néha benne van egy-két disztróban, de nem működik, dead code az egész...
Magyarul, akik belefordítják a kiadott csomagokba, azok NEM TUDJÁK hogy mit csinálnak,
és még SOHA nem ellenőrízték le.

Szóval, a fenti kártyánál szinte biztosan az swrast_dri.so dolgozik.
Ettől függetlenül a legegyszerűbb rajzolási műveletek lehetnek gyorsítottak,
a DirectDraw-hoz hasonlóan, és dolgozhat az MMX/SSE is.
-
"Attempting to crack SpeedLock can damage your sanity"

Közben feltűnt, hogy az S3 Trio videókártyák nem is 3D gyorsítók.

Gyorsító az, csak nagyon primitív.
Tud z-buffert, meg kb. fillpoly és textúrázás alapszinten...
A Tomb Raider 1-hez (DOS-os) pl. volt anno S3-as tomb.exe patch, ami hardveresen hajszolta az S3 Trio/Virge kártyákat, kb. 400x300-ban akadás nélkül, 640x480-ban már kicsit akadozva.

-
"Attempting to crack SpeedLock can damage your sanity"

Mondjuk érdekelne, hogy egy x200m ati-n nyílt driverhez odatolva ezeket a libeket, vajon kikerülhető-e így a dri? Csak kíváncsiságból érdekel.

Kikerülhető bizonyos mértékig. A hardvert továbbra is a DRI modulok kódja fogja meghajtani, de a GL packetek útvonala módosul, és a GLX protokollon keresztül kerül a pipeline-ra, nem a DRI-nek az X-et megkerülő bypass-án keresztül. (ez még mindig nem szentírás, csak józan logikai következtetés, ami tévedés is lehet abban az esetben, ha a DRI "fakeglx" hosztként viselkedik, bár szerintem ezt még Carmack sem tudja kéregből, nemhogy én...)
-
"Attempting to crack SpeedLock can damage your sanity"

Akkor ezért lehet az is gondolom, hogy vmware-ben linux alatt sokkal rosszabb a 3d teljesítmény, mint vmware-ben windows alatt.

Linux:
glxgears:
839 frames in 5.0 seconds = 167.773 FPS
818 frames in 5.0 seconds = 163.465 FPS
840 frames in 5.0 seconds = 167.947 FPS
856 frames in 5.0 seconds = 171.013 FPS
823 frames in 5.0 seconds = 164.459 FPS

Syrnix2: Benchmark result: 5 points

Windows:
qtgears:
6134 frames in 5 seconds = 1226 FPS
7059 frames in 5 seconds = 1411 FPS
6382 frames in 5 seconds = 1276 FPS
6905 frames in 5 seconds = 1381 FPS
6692 frames in 5 seconds = 1338 FPS

Syrnix2: Benchmark result: 312 points

Linuxon a glxinfo|grep direct: direct rendering: Yes

Szóval hogy lehet kikapcsolni ezt a dri-t, hogy jobb legyen?

--
Don't be an Ubuntard!

LIBGL_ALWAYS_INDIRECT

Ezzel indirect renderinget használ, ami alapértelmezetten szoftveres renderelést jelent, de AIGLX-el (aminek a

texture_from_pixmap

OpenGL extension a követelménye) hardveres gyorsítás is adott.

LIBGL_ALWAYS_SOFTWARE

Ezzel direct renderinget használ, de szoftveres rendereléssel.

Minden esetben a DRI szoftveres rendereléssel és indirect rendering esetén kerülhető meg, ami akkor jelent teljesítménynövekedést ha a processzorod hatékonyabb a renderelés során, mint a virtualizált videókártya.

A glxgearst meg ne, komolyan, akárhányszor azzal benchmarkolsz isten megöl egy lolit kiscicát.

"akkor jelent teljesítménynövekedést ha a processzorod hatékonyabb a renderelés során, mint a virtualizált videókártya."

Elvileg van hardveres gyorsítás a virtuális gépen belül, a host videókártyájának adja át a hívásokat, tehát a szoftveres renderelés mindenképpen rontana a teljesítményen.

--
Don't be an Ubuntard!

A VMware Workstation dokumentációja szerint OpenGL esetén mindössze szoftveres renderelést támogat, Direct3D esetén pedig OpenGL wrapperrel hardveres gyorsítást.

http://www.vmware.com/pdf/ws7_manual.pdf

De vannak third party alkalmazások amivel a hardveres gyorsítás is megoldható OpenGL-el VMWare alatt.

http://sourceforge.net/projects/vmgl/

Töltsd le a linuxos Nvidia 71.86 telepítőt.
Rámold ki. ( sh ./NVIDIA-*.run -x )
A kicsomagolt mappákból szedd ki a libGL, libGLcore libeket,
és körültekintően linkeld be a rendszerbe,
majd a tls almappában lévő libnvidiatls-t is (a 2KB-ost).
tehát, mentsd el valahová a jelenlegi /usr/lib/libGL*
aztán az nvidiás libGLcore.so.71.84.14 legyen linkelve /usr/lib/libGLcore.so.1
a libGL.so.71.86.14 pedig /usr/lib/libGL.so > /usr/lib/libGL.so.1 > /usr/lib/libGL.so.1.2

Ha minden oké, akkor teszt.
(konzol legyen, hogy ha elszúrsz valamit, akkor lásd)

-
"Attempting to crack SpeedLock can damage your sanity"

Kellene egy kis segítség.
Viewperf 6.1.2-höz nem találok olyan tesztet, ami nem küldi szoftver fallback-re az egészet a régebbi libek mellett . Kellene valami nagyon primitív, de megbízható terheléses teszt.
(mivel a glxgears tényleg elfér akár a dma-n szó szerint)

Szóval, jól jönne valami olyan teszt, aminél minden régebbi libnél is teljesülhet az indirekt, de hardver gyorsított rendering.
-
"Attempting to crack SpeedLock can damage your sanity"

Alakul a tesztkörnyezet. A Viewperf 6.1.2 alapjain, a MedMCAD-01 tesztből készítettem egy csökkentett változatot. 480x480-as ablakba rendereli (és forgatja) egy CAD-ben elkészített fénymásológép drótvázát. Ez úgy néz ki, hogy közös minimum lehet az összes libGL verzió számára, nem dob ki szoftveres fallbackre, és még mindig elegendő terhet jelent a rendszernek, nem úgy mint a glxgears...
Egy érdekesség: a teszt használja a libGLU-t, és nem mindegy hogy melyiket adom neki...akár 40%-os teljesítménybeli szórást jelent az, hogy honnan van a libGLU.
Most vadászom a különböző kártyagyártók, Mesa-verziók, egykori UTAH-GLX csomagok libGLU fájljait, mert ez sem mindegy...
-
"Attempting to crack SpeedLock can damage your sanity"

Legközelebb végezhetne olyan tesztet, amiben rongyokat tesztel különféle tisztítószerekkel párosítva, hogy melyikkel milyen gyorsan és hatékonyan pucolja az ablakot, a teszt végén grafikusan összesítve. A tesztre fel tudnék ajánlani kb. 10 darab ablakot. :-)

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

UPDATE: első pár teszt, MESA 7-es GLU az eddigi favorit.
A libGL variánsok közül az ATI 8.28-as és az Nvidia 71.86.14-es fej-fej mellett produkál, 5.4-5.5 fps környékén. A MESA 7.0-7.10-es libGL-ek esetén a mért értékek 7-9fps közötti intervallumban vannak, szóval eddig a MESA DRI vezet, ATI RADEON 9000 (rv250) hardveren mérve. Mindjárt kezdem az Intel i865-öt is vallatni!
-
"Attempting to crack SpeedLock can damage your sanity"

UPDATE: közben ki kellett ugrani egy ügyfélhez "nem jön be az internet" jellegű hibára...visszaérkezve már készen várt az i865g tesztje.Az eredmények libGL verziók szerint:

MESA 7.2-es : 8.51fps
MESA 7.10-es: 8.46fps
Nvidia 71-es: 8.15
ATI 8.28-as : 7.84fps

Na, ez már érdekesebbet mutat. Az apró fps-differencia ne tévesszen meg senkit, a teszt van olyan bonyolult, hogy kellően izzad a CPU és a GPU is, a teljesítménybeli szórás 8,5%-os, szóval kilátszik a zajból....
Az Nvidia (és vele az egyetlen GLX üzemben ketyegő teszt) nem hoz többletet, de valamiért NEM MARAD LE az élmezőnytől még ilyen mértékű terhelés alatt sem. Az ATI hozza az ismert papírformát, DRI üzemben megy a teszt, és erősíti az ismert szabályt, hogy az ATI elsődlegesen hardvert tud gyártani, másodlagosan pedig szoftvert is. A mezőnyt a MESA 7.2 vezeti, utána következik a friss 7.10-es, természetesen mindkettő DRI-n keresztül.

A fenti Nvidia eredmény szerintem azt mutatja, hogy az ő libGL-ük vagy egy nagyságrenddel jobb a többiekénél, vagy ha nem, akkor a GLX proto mégsem ront annyit az eredményeken, ha tisztességesen meg van csinálva.

(folyt.köv.)

-
"Attempting to crack SpeedLock can damage your sanity"

Majd legközelebb az eredmények számtani középértékéhez képest is pontosan kiszámolom a plusz-minusz eltéréseket, és megígérem, hogy grafikonon is ábrázolni fogom...(a szó hétköznapi, pongyola értelmében fogalmaztam fentebb, gyors százalékszámítás után, és igazad van, ez így nem pontos és szabatos...ettől függetlenül maguk az eredmények még érvényesek)
-
"Attempting to crack SpeedLock can damage your sanity"

A kis különbség abból adódik, hogy a teszt még mindig hajszál híján overkill...ha lejjebb venném a paramétereket, magasabb fps értékek adódnának, arányosan ugyanennyi, de "láthatóbb" különbséggel.
Akkor viszont jönne rögtön néhány nagyon becsületes szándékú kritikus, és jogosan kifejtené, hogy glxgears-szé degradáltam a Viewperf-et.

Általában nincs ennyi el....ni való időm, de erre régóta "spórolok".
Azóta, amióta csak elégedetlen vagyok a linuxos nyílt 3D teljesítménnyel,
és ennek okán szinte minden valamirevaló gépemben Nvidia VGA van.
(kivétel persze néhány Intel, ATI, Matrox, SIS és S3)
-
"Attempting to crack SpeedLock can damage your sanity"

Van bőven újabb hardver is, de nem igazán tesz lehetővé ennyire egyszerű "piszkálást", sőt, szinte semmilyen módosítást nem lehet rajtuk eszközölni a fent leírt tárgykörben.
Nulla tudásnál valamivel többel rendelkezem, na jó, nem sokkal...néha előfordult, hogy a California és a Sam Houston számtek tanszéke a tanácsaimat kérte, de ennél feljebb és előrébb -szégyenszemre- soha nem jutottam a szakmában, leszámítva a munkámat, a vállalkozásomat, és néhány hazai és nemzetközi "hobby-projektet". Nem akarom megváltani a világot. Érdekes dolgokat találok néha, és szeretném, ha mások is elgondolkodnának rajtuk, mert több szem tényleg többet lát, feltéve ha nem zsebben hordják. Két lib máshová linkelése nem művészet, de próbáld ki, hogy ha a libGLU-t azonos verzió mellett másik vendorra cseréled, a mérhető teljesítmény máris akár +/- 40%-ot változhat. Ha ez smafu, akkor azt már le sem írom, hogy mit tesz az ATI gyári driveréből való libGL, amikor egy Geforce 220GT-vel szerelt linux rendszeren nem találja a DRI-t...
-
"Attempting to crack SpeedLock can damage your sanity"

Az a libGL csere eredménye, amit tizedesben és néha egy-két fps-ben látsz.
A publikált eredmények futása alatt végig azonos volt a libGLU, és minden más is.

Külön játszottam egy kört azonos lib-verziójú GLU variánsokkal, és nagyon csúnyán befolyásolta az eredményt. Ennek fényében furcsállom, hogy a két nagy gyártó miért nem ad dedikált GLU-t a driver csomagjaiban, és miért bízza a teljesítmény alakulását esetleges származású GLU-ra, amikor az egyáltalán nem biztos, hogy szépen illeszkedik a drivereihez.

Szerk:

Megnéztem az eddigi GLU eredményeket is.
Intel i845g és i865g VGA-n 5-től 8fps-ig változik tőle.
(Geforce 6200-on már egyáltalán nem változtatnak semmin a GLU variánsai, a teszt minden funkciója ugyanúgy gyorsított, egységesen 125fps volt mindegyik.)
-
"Attempting to crack SpeedLock can damage your sanity"

UPDATE: Intel i845g

MESA 7.10 : 7.25fps
MESA 7.2 : 6.98fps
Nvidia 71.86.14: 5.68fps
ATI 8.28 : 5.54fps

(a teszt még mindig azonos, Viewperf 6.1.2-ben a MedMCAD-01 -copier wireframe- első menete 480x480-ban)

Ahogy gyengül a grafikus hardver, mintha úgy maradna le egyre jobban a GLX-es eredmény a MESA DRI-hez képest...az ATI-ról nem is beszélve...szóval, a DRI fejlesztésének kezdetén -korabeli hardveren- látványos lehetett a különbség, a mai "erőmű" gépeken és modern VGA-kártyák esetén pedig már nem számít vajon?

-
"Attempting to crack SpeedLock can damage your sanity"

azt gondoltam ez most egy régebbi április 1. írás de nem, május1.es:)

Uraim, sajnálattal kell közölnöm, hogy a fenti ügyben mindannyian megbuktunk méréstechnikából. Én is, mert hallgattam azokra, akik a glxgears helyett izmosabb tesztet követeltek. Három napja érzem, hogy Shannon és Murphy valahol itt lapul az egyik sarokban, és nagyon jól szórakoznak. Miért? Mert a jelgenerátor és a különböző átviteli láncok paramétereinek vizsgálata helyett megmértük a mérésre használt oszcilloszkóp felső határfrekvenciáját... Nem egészen világos? Mindjárt az lesz. A fenti szálban az eredeti "kapcsolás" szerint a glxgears egy jelgenerátor, ami egyszerű jelforma mellett nagyfrekvenciás jelet állít elő. A libGL egy interfész, ami a jelet egy vonalra illeszti. A GLX protokoll vagy a DRI ez esetben egy-egy átvileti lánc. A grafikus kártya pedig az oszcilloszkóp szerepét játssza, csakhogy...amíg egy valódi szkóp felső határfrekvenciája egy adott beállítás mellett független a jel összetettségétől, tartalmától, addig a 3D VGA esetén ez változó. A mérhető fps érték függ a jel tartalmától, tehát bonyolultabb utasításokat tartalmazó jelsorozat esetén meredeken esik a mérhető felső határfrekvencia. (aki még mindig nem értené: könnyűszerrel létrehozható két, bájtra azonos hosszúságú GLX packet-sorozat, melyből az egyik esetén a VGA egységnyi idő alatt rengeteget fel tud dolgozni, a másikból pedig csak néhányat) Mivel itt nem a VGA teljesítőképességére vagyunk kíváncsiak, hanem a jelgenerátor, az interfész, és leginkább az átviteli láncok elemeire, ezért a "szkóp" felső határfrekijét a lehető legmagasabb értéken kell tartanunk, az átviteli lánc lehető legnagyobb terhelése mellett. A glxgears közel állandó terhelésen tartja a libGL-t és a GLX-et vagy a DRI-t is, mert szünet nélkül a lehető legtöbb képkockát igyekszik előállítani, és mivel a jelsorozat egyszerű, az átvitt és feldolgozott üzenet-szakaszok számát a legtöbb VGA segítségével komoly mennyiségig tudjuk mérni. (a teljesen korrekt méréshez VGA helyett egy spciális "null-driver" kellene, ami nem végrehajtja, csak számolja a beérkező utasítás-sorozatokat, és természetesen egy olyan "preparált" glxgears, ami közben számolja a kiadott utasítás-sorozatokat...így már tiszta értékekhez lehetne jutni mind GLX proto, mind pedig DRI üzem esetén)

Végül következzen a lehetséges megfejtés, vagyis az Nvidia libGL-lel kényszerített GLX üzem miért produkál a DRI-hez képest közel azonos, vagy akár magasabb glxgears fps értékeket: évek óta szériatartozék a legtöbb linuxon az AIGLX, és pontosan ez a dolga, a lehető leggyorsabbá teszi az indirekt, hardveresen gyorsított leképezést...Bonyolultabb "mérőjel", tehát összetettebb 3D feladat esetén pedig már sem AIGLX, sem DRI nem segít, mert szimplán beleütközünk a VGA hardver korlátaiba.

-
"Attempting to crack SpeedLock can damage your sanity"

Teljesen jogosan...:)
Mindenki -kevés kivétellel- csak az ismert dogmatikus tételt szajkózta, miszerint a "glxgears nem benchmark". Nem is az, ha a 3D VGA teljesítményére vagyunk kíváncsiak. Itt azonban két különböző átviteli lánc méréséről volt szó, ahol a glxgears mindössze a négyszögjel-generátor szerepét kell, hogy betöltse. Arra pedig nagyban alkalmas.
-
"Attempting to crack SpeedLock can damage your sanity"

Az első bekezdésre nem fogok vagy próbálok meg reagálni.

De az AIGLX-el kapcsolatban csak annyi, hogy az a DRI-vel használatos, azaz majdnem, mivel az Nvidia és az AMD a zárt eszközmeghajtóikban más implementációt használnak a DRI helyett, de mindegyik támogatja az AIGLX-et, ami az elnevezésének megfelelően hardveresen gyorsított indirect renderinget biztosít.

Megjegyezendő még, hogy Gabucino tévedett mikor azt állította, hogy X szerver nélkül nem lehetséges a DRI-t használni.
http://dri.freedesktop.org/wiki/DriWithoutX

Persze ezt nem fogom felróni neki (alighanem szívbajt kapna, pedig mindenki tévedhet), legalábbis nem azonnal, most még levelezni fogok egy fejlesztővel aki segíthet prezentálni, hogy Gabucino ebben a kérdésben nem csak a segítőkészséget nélkülözi, de számomra eddig nem evidens és kiábrándító módon a szakmai tudást is.

gab nem allitott semmit, hanem szarkasztikusan elmagyarazta hogy az x nelkuli dri-zes finoman szolva se erdekel senkit - nyilvan rossz dontes volt ez ott ahol az ironia es szarkazmus kozotti kulonbseget se erti senki ugye

te meg szepen megvarod mig kibannoljak es utana nyilatkozol rola hulyesegeket, "cool story bro"

Akkor lehetséges, hogy nekem nem esett le a szarkazmus?

Ez volt az eredeti bejegyzése a HUP-on:

"Várjuk a beszámolód az x szerver/glx nélküli DRI-zéről, cool story bro"

A hozzászólásomat követően a hupmeme-n ez jelent meg:

"butthurt (directfb rulez!!)"

Majd a hozzászólásodat követően erre változott:

"butthurt analfabéta (jaés directfb rulez!!)"

Ez is inkább azt indikálja, hogy tőled tudta meg hogy ő szarkasztikusan magyarázott.

Azonban ha nem akkor tényleg analfabéta, valamint kivételesen ostoba vagyok és megkövetem magam.

Ez meglehetősen bizonytalan, halmozottan, hogy a DRI azon részben tévesnek, nem pontosnak igérkező meghatározásából indultunk meg, hogy az az X szerver megkerülése (ez elismerten meglehetősen pontatlan és félrevezető megfogalmazás)

Mostmár legalább eljutottunk odáig, hogy a DRI lehetséges X szerver nélkül, aminek vannak előnyei és hátrányai is.

"az x nelkuli dri-zes finoman szolva se erdekel senkit"

Ez szubjektív, és sok szempontból irreleváns is, hogy érdekel-e bárkit is vagy sem.

Meg ott van még a Wayland, ami szintén a DRI-re támaszkodik, egyben eliminálja az X szervertől való függőséget.

:zancsi lelkesen mutogat a Wayland-re:

Az Ubuntu és a Fedora is alapértelmezetten használni tervezi, valamint az Intel is a MeeGo-n.

A Wayland is érdektelen?

:zancsi továbbra is lelkesen és hipnotikusan mutogat a Wayland-re, mondván ne a szarkazmus értelmezése képességének hiányára, hanem a Wayland-re koncentrálj: