[C++] Accelerated OpenGL onder linux (zonder Xfree)

[B-Man]

Hallo,

Ik ben bezig met het ontwerp van een OpenGL applicatie die in onder linux wil draaien, zonder Xfree geinstalleerd te hebben. Ik heb al aardig wat projecten bekeken:

DRI, libSDL, mesa, GLUT, GGI, noem maar op.

Maar door de bomen zie ik het bos even niet meer, het lijkt erop dat de ene lib de andere nodig heeft. Ik snap dat libSDL een lib is die zelf een andere renderer nodig heeft, net als GGI.

Nu vind ik echter niet duidelijk hoe ik accelerated OpenGL zonder Xfree krijg. SDL ziet er qua stijl goed uit, alleen, welke renderer plug ik hieronder? DRI ondersteunt aardig wat vga kaarten, maar de website vermeld dat DRI zelf ook op Xfree leunt. Geen optie dus (lijkt me).

Kortom: kan iemand die bekend is in de wereld van accelerated OpenGL onder linux wat duidelijkheid bieden?

Bij voorbaat dank!

-edit-
En voor ik het vergeet: ook DirectFB en DRIFB heb ik bekeken. Beiden ondersteunen bijna geen hardware, dus (nog) niet erg nuttig. Ook kwam ik OpenPTC nog tegen, maar uit de soruces kon ik afleiden dat dit onder linux ofwel op X11 of SDL steunt, kortom: enkel een extra laag.

[ Voor 15% gewijzigd door B-Man op 17-08-2003 19:01 ]

[.oisyn]

Waarom wil je eigenlijk xfree-loos werken? Nou heb ik niet echt verstand van OpenGL onder linux, maar hoe doet bijvoorbeeld de linuxversie van Quake3 het? Is dat ook onder xfree of heeft die ook een eigen systeem?

[ Voor 68% gewijzigd door .oisyn op 17-08-2003 21:51 ]

[ACM]

Ik meen dat Mesa de de-facto OpenGL implementatie voor Linux is, Nvidia levert dan zijn eigen Mesa-library mee, waardoor dat wat beter geaccelereerd kan worden. Maar echt veel weet ik er niet van.

[B-Man]

Mesa is een software renderer, zover was ik al. Een aantal vendors bieden een Mesa-variant aan die delen van mesa hardware matig accelereert. DRI, waar Xfree >= 4.0 gebruik van maakt, gebruikt dan ook de mesa implementatie.

Ik wil buiten Xfree om accelerated OpenGL, omdat Xfree erg groot (en onnodig) is voor wat ik wil. Ik ben bezig met een soort van proof-of-concept. Als ik accelerated OpenGL buiten Xfree aan de praat krijg, horen jullie hier later nog wel meer over.

Ik denk dat ik deze week maar eens de sources van DRI ga bekijken, aangezien ik net las dat DRI ook los te gebruiken moet zijn. DRI en Xfree worden altijd in een adem genoemd omdat Xfree simpelweg de enig app is die het client-deel van DRI implementeert.
Het grote voordeel van DRI is dat er een uniform driver model voor linux is, en dat er al een aantal accelerated drivers beschikbaar zijn.

Overigens las ik vandaag ook dat DirectFB een OpenGL extension heeft gekregen: http://www.directfb.org/directfbgl.xml
Probleem met DirectFB blijft echter ook weer de ondersteuning voor vga kaarten, of beter gezegd, het ontbreken ervan.

[ACM]

Sja, maar XFree is de defacto-standaard voor grafische zaken binnen Linux. Er zijn wel andere grafische omgevingen (Accelerated X oid, en nog meer), maar daar moet je veelal voor betalen of ze zijn nog erg incompleet (zoals DirectFB) en de meeste mensen nemen de overkill van X dan maar voor lief.

Verwar trouwens XFree niet met de windowmanager, als je de "twm"-windowmanager bekijkt is dat een enorm simpele manager en niet zo uitgebreid als KDE/Gnome/e.a.
Je zou dus met een lichtgewicht windowmanager al een aardige winst in de "logheid" kunnen vinden.

Er bestaat ook nog de framebuffer-terminal enzo binnen linux, waarmee ik iig ooit een image-viewer heb gezien die dus op de "terminal" afbeeldingen kon laten zien, wellicht dat daar OpenGL voor te vinden is. Maar het kan ook zijn dat DirectFB daar pas de eerste doorontwikkeling voor is.

[B-Man]

ACM: Ik heb al eens een simpele windowmanager geprogrammeerd, dus ik ben op de hoogte van een aantal internals van Xfree. Ik wil zoals al gezegd gewoon geen Xfree. Ik weet dat er buiten Xfree om ook accelerated gewerkt kan worden (zoals DirectFB en DRI) maar vroeg me af wat een goede/snelle combinatie is.

[ACM]

Ik denk trouwens dat je daar beter voor in NOS kan zijn (als er al iemand wat van weet hier), dus ik verplaats het daar even heen (uit P&W).

[Verwijderd]

Ik sluit me bij ACM aan, ik zie niet in waarom je voor een grafisch systeem geen X zou gebruiken. OpenGL heeft ook een grafisch systeem nodig. Of dacht je dat de 3D functionaliteit van die nvidia kaarten enig nut had als er geen 2D was? .

DRI is overigens een kernel implementatie van hardware acceleration en wordt geimplementeerd door... X. . Je mag je eigen client van DRI maken als je wilt, maar is het gebruiken van X dan niet veel sneller?

Ik ben er geinteresseerd in waarom X voor jou "te" groot zou zijn, ben je met embedded 3D dingetjes bezig ofzo? .

[im_ik]

Ik heb er ook eens naar zitten kijken aangezien een openGL X implanmitatie er erg lekker zou zijn

Maar waar ik op uit kwam is dat je de "modules" api van Xfree moet na bouwen'en om zo de
driver te laden..
In de readme van de nvidia lnx driver staat oa een lijstje met de files die hij instaleerd

code:

(these are all the files of the NVIDIA Accelerated Linux Driver Set,
plus their symlinks):

        /usr/X11R6/lib/modules/drivers/nvidia_drv.o

        /usr/X11R6/lib/modules/extensions/libglx.so.x.y.z
        /usr/X11R6/lib/modules/extensions/libglx.so -> libglx.so.x.y.z

        /usr/lib/libGL.so.x.y.z
        /usr/lib/libGL.so.x -> libGL.so.x.y.z
        /usr/lib/libGL.so -> libGL.so.x

        /usr/lib/libGLcore.so.x.y.z
        /usr/lib/libGLcore.so.x -> libGLcore.so.x.y.z

        /lib/modules/`uname -r`/video/NVdriver, or
        /lib/modules/`uname -r`/kernel/drivers/video/NVdriver

Verder heb ik niet gekeken aangezien dit project voor mij te lang zou gaan duuren.

[B-Man]

Kijk, wat ik erg grappig vind is het feit dat er altijd gezegd wordt dat je keuze hebt op linux Nu blijkt echter dat vrijwel iedereen zegt "Wil je graphics? Dan moet je Xfree gebruiken", where's the choice in that?

Ik ben inderdaad (o.a. voor embedded oplossingen) aan het kijken of ik geen lichter grafisch systeem kan opzetten, buiten xfree om.

Back ontopic: ik ga zometeen eens wat spelen met directfb om te kijken hoe dat werkt. Het mooie van DirectFB is dat ik mogelijk gebruik kan gaan maken van de bestaande DRI drivers van ati, nvidia, etc, aangezien deze voor OpenGL een implementatie van Mesa leveren. En laat er nu dus net een DirectFBGL module zijn uitgebracht die DirectFB en Mesa aan elkaar knoopt.
Ik wil overigens niet per se met hardware accelerated OpenGL aan de slag, maar zie dit meer als een interessante optie om in mijn achterhoofd te houden. Waarom 2D danwel 3D tekenen door de CPU laten doen, als je een dedicated GPU in je systeem hebt die het veel sneller kan?

Overigens is het naast embedded oplossingen wel interessant om eens te kijken wat de mogelijkheden zijn voor een instant-graphical boot. Zoiets als bootsplash (www.bootsplash.org), maar dat je vervolgens in de grafische modus blijft werken. Dus vanaf het moment dat de kernel geladen is naar een grafische modus schakelen.

--edit
Oh, en im_ik: om de drivers van nvidia te kunnen gebruiken (het OpenGL deel dan), hoef ik geloof ik niet eens een DRI client implementatie te maken, maar kan ik direct de OpenGL driver aanspreken. Wil ik geen OpenGL doen, dan moet ik een DRI client interface bouwen (net als XFree).

[ Voor 11% gewijzigd door B-Man op 18-08-2003 14:46 ]

[B-Man]

offtopic:
En ACM: bedankt voor het verplaatsen van m'n topic. Vragen zoals dit zijn wat lastig te plaatsen vind ik: het is een programmeervraag, maar heeft ook enkel met linux te maken (NOS).

[B-Man]

Overigens (ter verduidelijking): ik wil in eerste instantie enkel met 2D zaken aan de slag. OpenGL kan erg goed met 2D overweg, en bied een opstapje naar 3D.

[moto-moi]

Hmmm, ik kwam zonet toevallig deze link tegen, dri op de framebuffer.. Maar helaas op dit moment alleen voor Radeon chips..

[B-Man]

moto-moi schreef op 18 August 2003 @ 22:44:
Hmmm, ik kwam zonet toevallig deze link tegen, dri op de framebuffer.. Maar helaas op dit moment alleen voor Radeon chips..

Ja, kwam ik gisteren ook tegen. Leuk project, maar eens in de broncode duiken. Als zij de radeon driver al geport hebben, is dit natuurlijk interessant om eens te bekijken. Ik heb hier gelukkig genoeg testpc's met videokaarten (nvidia riva tnt, i810, radeon, sis onboard).

Ik had me in eerste instantie voorgesteld om een bestaand framework te gebruiken voor het daadwerkelijk tekenen van data, en zelf meer met een high-level lib bezig te zijn. Aangezien zo'n framework dus nog niet of nauwelijks bestaat wil ik wat meer weten over videokaarten en hun aansturing onder linux, beelzebub, (of iemand anders) heb jij een paar tips/links voor me waar ik mee kan "beginnen" om wat kennis te vergaren over dit onderwerp?

[.oisyn]

Verwijderd schreef op 18 augustus 2003 @ 11:33:
OpenGL heeft ook een grafisch systeem nodig. Of dacht je dat de 3D functionaliteit van die nvidia kaarten enig nut had als er geen 2D was? .

Wat bedoel je met een "grafisch systeem"? In principe is er niets in de trand van XFree oid nodig. Ja, je hebt iets nodig dat communiceert met de hardware, en daar heb je dus de drivers en de OpenGL implementatie voor (en dus waar B-Man naar op zoek is). Er hoeft verder geen geregel te zijn van een grafisch systeem. De applicatie kan in fullscreen draaien, en hoeft zich om niemand te bekommeren. Nergens 2D voor nodig

Een goed voorbeeld hiervan zijn de oude 3dfx kaarten, dat waren ook geen ordinaire videokaarten, maar puur hardware om 3dbeelden te genereren en op je monitor te krijgen.

[Verwijderd]

.oisyn schreef op 19 August 2003 @ 01:01:
Wat bedoel je met een "grafisch systeem"? In principe is er niets in de trand van XFree oid nodig. Ja, je hebt iets nodig dat communiceert met de hardware, en daar heb je dus de drivers en de OpenGL implementatie voor (en dus waar B-Man naar op zoek is). Er hoeft verder geen geregel te zijn van een grafisch systeem. De applicatie kan in fullscreen draaien, en hoeft zich om niemand te bekommeren. Nergens 2D voor nodig

ik bedoel een "simpel" systeem om objecten te tekenen. Ik vind 't zelf niet erg prettig om in pixels te werken, vooral niet als ik alleen maar pixels heb. Als je in DRI werkt, dan heb je dus geen vensters, geen objecten, helemaal niks. Alleen een prutteltje nietszeggende pixels bij elkaar in een ge-mmap()'ed buffertje (gok ik). Je moet er maar van houden. .

En zoals je al zegt, voor iets als fullscreen OSD applicaties is dat nog best wel te doen. Maar voor openGL lijkt een klein object systeem me toch wel gewenst.

@B-man: wat vond je van directFB? Je geeft zelf al aan toch wel iets naar een high-level lib op zoek te zijn (maar dan klein/efficient); directFB lijkt me dan een van de weinige bestaande opties (aangezien je X te log/groot vindt). Als je zelf aan de gang wilt? Mjah, in X duiken zou ik je afraden. . X is vrij groot, complex en vooral oud. X leert je verkeerde gewoontes, 't maakt niet altijd gebruik van mogelijkheden van moderne videokaarten. DirectFB is een stuk mooier (moderner) wat dat betreft. Je zou dus in de DRI/GL backend van directFB kunnen kijken. Pas wel op dat directFB een groot geintegreerd geheel is, dus je kan niet "even simpel" een module er uit halen. .

Als je geen directFB wilt, dan zul je zelf de DRI documentatie moeten lezen (linkje) voor een eigen mini-client-interface. Pas wel op dat je geen gigantische duplication of code van directFB/X doet, dan kun je net zo goed die code copieren of alsnog die gebruiken (want: wat is dan nog het verschil? ).

[ Voor 3% gewijzigd door Verwijderd op 19-08-2003 08:05 ]

[.oisyn]

Verwijderd schreef op 19 augustus 2003 @ 08:04:
En zoals je al zegt, voor iets als fullscreen OSD applicaties is dat nog best wel te doen. Maar voor openGL lijkt een klein object systeem me toch wel gewenst.

Voor OpenGL zijn die objecten niet eens nodig. Sterker nog, voor OpenGL is de pixelarray niet eens nodig. Je tekent met OpenGL functioncalls de polygonen. De videohardware doet de rest, dus idd pixels inkleuren en die tonen op het scherm. En OpenGL kan prima in fullscreen werken. Dus waar zijn die objecten waar je het over hebt dan voor nodig?

[Creepy]

.oisyn schreef op 19 August 2003 @ 14:07:
[...]


Voor OpenGL zijn die objecten niet eens nodig. Sterker nog, voor OpenGL is de pixelarray niet eens nodig. Je tekent met OpenGL functioncalls de polygonen. De videohardware doet de rest, dus idd pixels inkleuren en die tonen op het scherm. En OpenGL kan prima in fullscreen werken. Dus waar zijn die objecten waar je het over hebt dan voor nodig?

OpenGL heeft helemaal geen weet van windowing, schermen e.d aangezien dit platform afhankelijk is en OpenGL platform onafhankelijk. Als je een rendering context creeert moet dit ding toch ook openGL compatible zijn voordat je met OpenGL aan de slag kan?
de GLut Library kan een window aanmaken en zorgen dat dit window compatible is met OpenGL zodat er ook daadwerkelijk output op het scherm getekent kan worden. OpenGL zelf heeft helemaal geen weet of ie nou bezig is in een windows of fullscreen. Je zult altijd naast OpenGL iets van een windowing system (hoe simpel dan ook, alleen al een fullscreen window aanmaken is in theorie al genoeg) moeten hebben wil je output van openGL kunnen zien.

[B-Man]

--edit--
Beelzebubu, keek over je linkje naar de DRI faq heen, zit deze nu te lezen. Mogelijk beantwoord deze mijn onderstaande vragen al.
--/edit--

Voordat we verzanden in een "Wat doet OpenGL wel/niet"-discussie, ga ik weer even ontopic. Aangezien ik me nog niet bezig kan houden met high-level dingen, eerst low-level zaken maar eens aan de praat krijgen, ben ik op zoek gegaan naar wat meer info over linux device drivers, dri, framebuffer device, enz.

Ik heb gevonden:
- Een interessante lap tekst over linux device drivers. Het is een stuk simpeler dan ik verwacht had.
- Tevens ben ik de sources van i810fb aan het bekijken, om een concreet voorbeeld te hebben.

Ik het DirectFB hier nog niet aan de praat gekregen op mijn i810 testmachine. Als ik DirectFB (.16) gepatched heb met de patch van de i810fb website, en vervolgens configure run, weigert deze de i810 mee te nemen in het proces. Ik ben er nog niet uit waarom niet.

Ik heb overigens de i810fb framebuffer driver zelf al wel aan de praat. Zit nu te kijken naar een console op 1024x768x16bpp;

Na dus een aantal zaken gelezen te hebben, begin ik wat meer grip op de materie te krijgen. Qua structuur ziet het er dus als volgt uit:

Kernel level driver
^
||
Userland interface(directFB/svgalib/DRI/Direct OpenGL)
^
||
Mijn app

Waar ik echter nog niet helemaal uit ben:

• Kan een driver ook de videokaart aanspreken zonder gebruik te maken van de framebuffer? M.a.w.: is dit de enige manier om een device driver te gebruiken? Aangezien er een apart fbDRI project is, neem ik aan dat DRI/DRM de framebuffer helemaal niet gebruikt...
• Om meerdere apps tegelijk op de framebuffer te laten werken, of algemeen gezien: om meerdere apps tegelijk met de videokaart te laten werken, moet er ergens een centraal, gesynchroniseerd (gelocked) toeganspunt zijn, toch? En DRI is hier een voorbeeld van.
• Hoe verloopt bijvoorbeeld een high-level functie als DrawLine? Kan een kaart zelf enkel blitten (dus arrays van pixels op het scherm zetten)? Ik begreep eerder dat videokaarten ook geavanceerdere commando's kunnen verwerken?
  Wordt een commando als DrawLine dus vanaf de high-level lib helemaal doorgegeven aan de kernel-level driver, of wordt deze functie ergens onderweg naar de driver omgezet in een serie pixels die als transformatie op het scherm wordt uitgevoerd?

Kortom: ik ben eigenlijk opzoek naar de basics over videokaarten, videodrivers, en low-level libs. Tot dusver vind ik de docs bij de eerdergenoemde projecten ietwat gebrekkig of onduidelijk. Vandaar mijn bovenstaande vragen: ik wil graag wat meer overzicht voordat ik de "diepte" inga

[ Voor 4% gewijzigd door B-Man op 19-08-2003 16:09 ]

[Verwijderd]

B-Man schreef op 19 August 2003 @ 16:07:
--edit--
Beelzebubu, keek over je linkje naar de DRI faq heen, zit deze nu te lezen. Mogelijk beantwoord deze mijn onderstaande vragen al.
--/edit--

Grotendeels wel ja. .

• Kan een driver ook de videokaart aanspreken zonder gebruik te maken van de framebuffer? M.a.w.: is dit de enige manier om een device driver te gebruiken? Aangezien er een apart fbDRI project is, neem ik aan dat DRI/DRM de framebuffer helemaal niet gebruikt...

Ja dat kan. DRM is onafhankelijk daarvan. Uiteraard heb je dan geen object systeem, maar daar was je zelf natuurlijk ook al achter.

Als je dat object systeem toch nodig hebt, lees dan eerst even FAQ sectie 3.2.5.2. .

• Om meerdere apps tegelijk op de framebuffer te laten werken, of algemeen gezien: om meerdere apps tegelijk met de videokaart te laten werken, moet er ergens een centraal, gesynchroniseerd (gelocked) toeganspunt zijn, toch? En DRI is hier een voorbeeld van.

Ja.

• Hoe verloopt bijvoorbeeld een high-level functie als DrawLine? Kan een kaart zelf enkel blitten (dus arrays van pixels op het scherm zetten)? Ik begreep eerder dat videokaarten ook geavanceerdere commando's kunnen verwerken?
Wordt een commando als DrawLine dus vanaf de high-level lib helemaal doorgegeven aan de kernel-level driver, of wordt deze functie ergens onderweg naar de driver omgezet in een serie pixels die als transformatie op het scherm wordt uitgevoerd?

Ehm, hangt geloof ik van je toplevel systeem af. Ik heb X al vaker oud genoemd, dat is niet voor niks. Verschillende optimalisaties voor drivers ondersteunt X niet. Simpelweg omdat die nog niet bestonden toen X al bejaard was ( ), en X te groot en te traag is in haar ontwikkeling. Niet voor niks is er een discussie gaande over verandering van het X ontwikkel proces (Keith! / ). X doet afaik inderdaad de pixel-rendering in software en stuurt dat naar de driver toe. Misschien is dit sinds kort anders, maar in het verleden was dat iig zo.
DirectFB is een stuk geoptimaliseerder. Die doet al dat soort dingen in hardware met een software fallback implementatie (dit is algemeen genomen echt een perfect systeem!), dus dat zal een stuk sneller zijn. Dit is ook de methode die ik (uiteraard) zou aanraden als je je eigen client-interface breed wilt laten werken. Denk voorbij je eigen serie test-kaartjes en denk in "wat zou er theoretisch mogelijk zijn?". Niet alles hoeft natuurlijk gelijk geimplementeerd, maar denk hieraan bij het design van je programmeer-interface.

Good going!

[B-Man]

Beelzebubu: wederom bedankt voor je reactie, de puzzelstukjes beginnen op hun plaats te vallen.

Wat ik nog steeds niet helemaal vat (kan het ook niet in de FAQ van DRI terugvinden) is de interactie tussen de verschillende DRI onderdelen en het al dan niet generiek zijn van onderdelen.

Wat ik al begrepen heb is dat in de kernel de DRM zit, die het synchronisatie stuk afhandelt. Is het dan echter zo dat, nadat een userland app toegang heeft, deze daarna de DRM niet meer nodig heeft, en direct met de kernel level (kaart specifieke) driver praat?

Wat ik mis is een helder plaatje dat DRI/DRM uitlegt (heb al wel wat plaatjes gezien, maar die zijn niet echt duidelijk), en eventueel een overzicht van de interfaces. (Ala javadocs zeg maar). Ik zit hier nu door de sources te bladeren, en zie door de bomen het bos even niet meer.

Overigens heb ik je (stille?) hint al opgepikt hoor. Ja, ik voel zelf ook wel wat voor DirectFB
Al is het wel zo dat er al een hardware-vendor (Nvidia) is, die zich achter DRI heeft geschaard. Al kan ik die driver ook aanspreken vanuit DirectFBGL als ik het systeem goed begrijp... DirectFB calls worden dan afgehandeld door het OpenGL deel van de DRI driver.
Eventueel kan ik over DirectFB dan weer SDL gebruiken, alhoewel SDL zelf ook direct met OpenGL uit de voeten kan...

Kortom: wat is dan zinvol? Ik weet in ieder geval zeker dat ik geen XFree wil, anders was ik dit hele topic natuurlijk niet begonnen SDL ziet er qua structuur ook "fijn" uit, heb er al wat mee gespeeld. Het enige voordeel van SDL -> DirectFB -> OpenGL boven SDL -> OpenGL is dan dus het feit dat DirectFB calls ook transparant softwarematig kan verwerken.

[B-Man]

Oh, en heb net DirectFB ook aan de praat gekregen, zij het zonder de userland i810 implementatie (enkel de i810 framebuffer driver in de kernel, dan wordt er door DirectFB waarschijnlijk niets geaccelereerd lijkt me).

Kan ik in ieder geval wat aan het spelen/testen met DirectFB.

[deadinspace]

B-Man schreef op 19 augustus 2003 @ 17:14:
Wat ik nog steeds niet helemaal vat (kan het ook niet in de FAQ van DRI terugvinden) is de interactie tussen de verschillende DRI onderdelen en het al dan niet generiek zijn van onderdelen.

AFAIK:

DRI is simpelweg een arbitrator en abstractie voor de resources; Het zorgt ervoor dat meerdere applicaties van de hardware gebruik kunnen maken, en dat dingen als DMA instellingen, memory mapping e.d. consistent worden afgehandeld. Wat overblijft is redelijk directe toegang tot de hardware, die dus wel per chipset verschilt, dus je hebt nog een userspace deel nodig.

Het userspace deel is doorgaans libmesa, die snapt OpenGL aan de ene kant (waar de applicaties mee praten), en praat de juiste DRI commando's tegen de kernel.

DRI is hiermee volledig generiek en staat volledig los van XFree86. Mesa is in principe niet aan X of XFree86 gebonden, maar het zou kunnen dat de huidige implementatie wel gericht is op X / XFree86 als windowing environment.

DRI lijkt in dit opzicht vrij veel op de Linux framebuffer

Is het dan echter zo dat, nadat een userland app toegang heeft, deze daarna de DRM niet meer nodig heeft, en direct met de kernel level (kaart specifieke) driver praat?

Ja, de userspace app praat via de DRI kernel interface... Je hebt DRI dus altijd nodig.

Al is het wel zo dat er al een hardware-vendor (Nvidia) is, die zich achter DRI heeft geschaard.

Volgensmij heeft nVidia juist een eigen (niet compatible) implementatie, in plaats van dat ze de Linux DRI gebruiken...

Eventueel kan ik over DirectFB dan weer SDL gebruiken, alhoewel SDL zelf ook direct met OpenGL uit de voeten kan...

Waarom gebruik je dan sowieso geen SDL (met SDLGL)? Dan maakt het niet uit waar het op draait... SDL kan op X werken, afaik ook op DirectFB, maar ook op bijvoorbeeld MacOS X, Windows en BeOS.

Kortom: wat is dan zinvol? Ik weet in ieder geval zeker dat ik geen XFree wil

Ja, je noemt het groot... Maar het is met flink strippen wel binnen de 10 MB te krijgen hoor. Waarschijnlijk nog wel kleiner ook.

SDL ziet er qua structuur ook "fijn" uit, heb er al wat mee gespeeld. Het enige voordeel van SDL -> DirectFB -> OpenGL boven SDL -> OpenGL is dan dus het feit dat DirectFB calls ook transparant softwarematig kan verwerken.

Nou nee, er is geen voordeel. Ik snap niet exact wat je met dat laatste bedoelt, maar als je het over de software-fallbacks van DirectFB hebt: dat doet mesa ook.

[Verwijderd]

deadinspace schreef op 19 August 2003 @ 18:08:
DRI is simpelweg een arbitrator en abstractie voor de resources; Het zorgt ervoor dat meerdere applicaties van de hardware gebruik kunnen maken, en dat dingen als DMA instellingen, memory mapping e.d. consistent worden afgehandeld. Wat overblijft is redelijk directe toegang tot de hardware, die dus wel per chipset verschilt, dus je hebt nog een userspace deel nodig.

Nee. DRI is zelf een interface. De X driver voor de 2D draait overigens ook in kernelspace. Zowel de X driver als DRI zijn universele interfaces, dus elke kaart is "achter" die interface gelijk. Daarom heb je ook maar 1 libGL nodig met alle DRI drivers erbij. .

Maar het is alleen een dun wrappertje, voor de rest is het directe hardware access. Zonder software fallbacks, obviously. .

[Verwijderd]

B-Man schreef op 19 August 2003 @ 17:14:
Beelzebubu: wederom bedankt voor je reactie, de puzzelstukjes beginnen op hun plaats te vallen.

Nice. .

Wat ik nog steeds niet helemaal vat (kan het ook niet in de FAQ van DRI terugvinden) is de interactie tussen de verschillende DRI onderdelen en het al dan niet generiek zijn van onderdelen.

Wat ik al begrepen heb is dat in de kernel de DRM zit, die het synchronisatie stuk afhandelt. Is het dan echter zo dat, nadat een userland app toegang heeft, deze daarna de DRM niet meer nodig heeft, en direct met de kernel level (kaart specifieke) driver praat?

Dat is DRM. DRM is een interface. De drivers zijn de implementaties. Dit is best wel vaag, maar de hele kernel werkt zo. . DRM is niks behalve wat generieke functies voor ("client") drivers voor registratie van hardware, en daarbuiten is DRM alleen de interface, dus de afspraak van hoe driver en userspace met elkaar communiceren. Daar zit niks tussen. De driver implementeert dus uiteindelijk DRM.

Wat ik mis is een helder plaatje dat DRI/DRM uitlegt (heb al wel wat plaatjes gezien, maar die zijn niet echt duidelijk), en eventueel een overzicht van de interfaces. (Ala javadocs zeg maar). Ik zit hier nu door de sources te bladeren, en zie door de bomen het bos even niet meer.

Hmmm, API documentatie? Goede vraag. . Ik gok dat je op de website van die FAQ die ik je eerder gaf de meeste kans maakt om API documentatie te vinden. Als het daar niet is, dan is de header alles, vrees ik...

Overigens heb ik je (stille?) hint al opgepikt hoor. Ja, ik voel zelf ook wel wat voor DirectFB

.

Kortom: wat is dan zinvol? Ik weet in ieder geval zeker dat ik geen XFree wil, anders was ik dit hele topic natuurlijk niet begonnen SDL ziet er qua structuur ook "fijn" uit, heb er al wat mee gespeeld. Het enige voordeel van SDL -> DirectFB -> OpenGL boven SDL -> OpenGL is dan dus het feit dat DirectFB calls ook transparant softwarematig kan verwerken.

SDL is wel mooi ja, ik heb er een tijdje mee gewerkt. Dat is uiteindelijk een keuze die je zelf maakt. Wat erg makkelijk is, is om het gewoon uit te proberen. Schrijf kleine testjes, test op snelheid van rendering, binary size (stripped), ontwikkeltijd e.d., en kijk welke binnen jouw eisen en beperkingen valt. .

[B-Man]

Drie posts verder (bedankt heren), en weer een stuk wijzer. DRM biedt dus enkel de interface, die door een driver geimplementeerd wordt. Dit zou dan ook betekenen dat de driver enkel een interface naar de kaart biedt, en dat de userland app/driver daadwerkelijke functies van de kaart aanspreekt, toch?
DRM levert dus een algemene interface naar de hardware, net als de framebuffer.

Als ik zo de posts terug lees, ga ik in eerste instantie wat tests schrijven met zowel SDL als DirectFB, om wat hands-on ervaring te krijgen met deze libs.

[deadinspace]

Verwijderd schreef op 19 August 2003 @ 18:17:
Nee. DRI is zelf een interface.

Ja, klopt... DRI is de interface/architectuur, DRM is het apparaat in de kernel zelf. Ze lijken ook zoveel op elkaar

De X driver voor de 2D draait overigens ook in kernelspace.

Nou... Niet echt. XFree86 doet een iopl(), waarmee hij zijn I/O rechten verhoogt. Hierdoor mag XFree86 alle I/O poorten benaderen (met alle eventuele gevolgen van dien), maar het blijft een userspace process

Zowel de X driver als DRI zijn universele interfaces, dus elke kaart is "achter" die interface gelijk. Daarom heb je ook maar 1 libGL nodig met alle DRI drivers erbij. .

Nou nee, dat is niet waar.

Achter het X protocol is iedere videokaart gelijk ja. Je praat X, de X server regelt de rest.

Met DRI is dit niet zo; DRI is voor resource management e.d., maar je moet nog steeds weten wat de specifieke opdrachten / I/O operaties voor een specifieke kaart zijn; dit doet DRI niet voor je. libmesa bevat deze kaart-specifieke delen.

Beschrijving xlibmesa3-gl (emphasis mine):

Mesa is a 3D graphics library which presents an API intended to be compatible with OpenGL. XFree86 maintains its own version of the Mesa library (which is regularly resynchronized with the official one) to permit development of the XFree86 X server's Direct Rendering Infrastructure (DRI), which makes the 3D acceleration features of many modern video cards available to X client programmers.

Chipset-specific DRI modules, if available for your machine architecture, are provided in this package. (Unlike the modules in the xserver-xfree86 package, the DRI modules are loaded by the Mesa library, not by the X server itself.)

Ook staan op mijn systeem de volgende bestanden, welke onderdeel zijn van mesa:

/usr/X11R6/lib/modules/dri/gamma_dri.so
/usr/X11R6/lib/modules/dri/i810_dri.so
/usr/X11R6/lib/modules/dri/i830_dri.so
/usr/X11R6/lib/modules/dri/mga_dri.so
/usr/X11R6/lib/modules/dri/r128_dri.so
/usr/X11R6/lib/modules/dri/radeon_dri.so
/usr/X11R6/lib/modules/dri/sis_dri.so
/usr/X11R6/lib/modules/dri/tdfx_dri.so

De chipset-specifieke drivers dus

Zonder software fallbacks, obviously. .

Nee, die software fallbacks zitten in mesa, zoals ik zei

[B-Man]

Net de docs (en overview: met class diagram pff) van DirectFB zitten lezen, en hoe meer ik lees, hoe meer DirectFB aansluit op mijn wensen. Ik heb de DirectFBGL interface ook al bekeken, en dit maakt DirectFB helemaal een geschikte kandidaat, aangezien ik dan direct met OpenGL in DirectFB kan werken. Het is me echter v.w.b. DirectFBGL niet duidelijk of ik meerdere concurrent OpenGL apps kan draaien in een DirectFB sessie.

--edit
Deadinspace: Ik had al zo'n vermoeden m.b.t. DRI; dat de daadwerkelijke implementatie van hardware calls en het aanroepen van functionaliteit van een videokaart dus in een userland driver zit. DRM (de kernel interface dus) bied dus enkel toegang tot de kaart, en implementeert verder geen non-generieke zaken die kaart specifiek zijn. Mijn vraag is dan: waarom is er dan per kaart/fabrikant een andere kernel level driver nodig? Omdat het per kaart verschilt welke adressen gebruikt worden?

--edit2
Overigens ook erg handig (voor mij dan) dat er ook een C++ wrapper is voor DirectFB, mijn eigen project ontwikkel ik in C++ (programmeer ook in java, hier echter niet, java is hier te traag voor he );
Het geneuzel (ja, ik vind het wat onhandig) met pointers die this vervangen, en returnwaarden die gezet worden in functie-parameters vermijd ik liever. De C++ wrapper is dan ook meteen een stuk "schoner".

[ Voor 57% gewijzigd door B-Man op 20-08-2003 00:23 ]

[Bas!]

Mjah directfb is een heel mooi concept, zou ik ook voor gaan. Libsvga is voor zover ik weet ook nog een optie.
Probleem met dit soort zut is dat nvidia kaarten nooit hardware geaccellereerd gaan worden. Net als een hoop propriety features hardware ondersteund gaan worden aangezien royalties niet betaald worden.
DRM is juist niet generiek maar de kaartspecifieke interface dat het generieke dri mogelijk maakt.

[B-Man]

Bas! schreef op 20 August 2003 @ 17:07:
Mjah directfb is een heel mooi concept, zou ik ook voor gaan. Libsvga is voor zover ik weet ook nog een optie.
Probleem met dit soort zut is dat nvidia kaarten nooit hardware geaccellereerd gaan worden. Net als een hoop propriety features hardware ondersteund gaan worden aangezien royalties niet betaald worden.
DRM is juist niet generiek maar de kaartspecifieke interface dat het generieke dri mogelijk maakt.

Met behulp van DirectFBGL wordt het wel mogelijk om de OpenGL interface van de nvidia driver aan te spreken. Ik neem aan dat die via de eigen kernel module van nvidia de kaart aanspreekt, en mogelijk zit dat de framebuffer device in de weg. Binnenkort maar eens testen, heb hier een paar nvidia kaarten.