original in en Phillip Ross
en to nl Guus Snijders
Ongeveer een jaar geleden kondigde een bedrijf, genaamd 3Dfx Interactive, hun nieuwe 3D chipset aan die de manier zou veranderen waarop mensen over 3D op PCs dachten. Voor de release van 3Dfx's chipset was er geen redelijk geprijst alternatief voor high-end 3D graphics op thuissystemen. High-end graphics konden alleen gevonden worden op dure werkstations zoals SGIs en Suns met dure, gespecialiseerde hardware. PC videokaart fabrikanten zoals Number Nine, Diamond Multimedia en Matrox hadden betaalbare videokaarten op de markt, waarvan bekend was dat ze 3D mogelijkheden hadden, maar die mogelijkheden waren beperkt, vergeleken met de dure hardware zoals die in SGIs en andere werkstations.
Met het verschijnen van 3Dfx's chipset, onder de naam Voodoo 3Dfx, werden high-end 3D graphics betaalbaar voor de gemiddelde computer gebruiker. De prestaties van deze chipset vormen ongetwijfeld een benchmark in het voortdurende streven om High-end 3D graphics naar de thuis desktop te brengen. Voorheen waren de 3D mogelijkheden van andere video chipsets beperkt tot z-buffering en gourad shading (sommige minder primitieve boden beperkte texture mapping), maar deze mogelijkheden waren alleen beschikbaar in een bepaalde resolutie of kleurdiepte. Helaas was er erg veel CPU kracht nodig om sommige van deze mogelijkheden te gebruiken in een applicatie.
Hier is een voorbeeld van hoe een van de videokaarten beperkt kan zijn in zijn mogelijkheden. Het kan bijvoorbeeld claimen z-buffering te ondersteunen, maar alleen code in de video drivers hebben om z-coördinaten van pixels in video geheugen op te slaan, zodat die niet anders gebruikt kan worden. Deze z-buffering is dan alleen beschikbaar in lage resoluties en bij lage kleurdiepte, omdat hogere modi meer geheugen gebruiken. Bij hogere modi zou er onvoldoende vrij geheugen zijn om de opslag van z-coördinaten toe te staan. Zelfs met de opslag van deze z-coördinaten in het video geheugen, zou de applicatie nog steeds de CPU nodig hebben om de z-coördinaten van nieuwe pixels te vergelijken met de z-buffer in het video geheugen. Daar deze vergelijkingen significante CPU kracht kosten, elimineert de z-buffering van de video adapter niet echt de bottlenek van de klassieke z-buffering. Als dit teveel informatie is, maak je geen zorgen... het is werkelijk een technische uitleg die niet nodig is om het verschil te zien tussen video kaarten die beweren 3D te ondersteunen en de 3Dfx chipset.
Helaas heeft ook de Voodoo 3Dfx chipset zijn beperkingen. De belangrijkste beperking van deze chipset is dat hij alleen in staat is full-screen te renderen en de cipset kan niet effectief gebruikt worden als enige adapter in een computer. Video adapters die de 3Dfx chipset gebruiken, hebben een andere, werkende stand-alone videokaart erbij nodig. De videokaart met de 3Dfx chipset werkt naast de stand-alone adapter. De manier waarop het werkt is dat het besturingssysteem de normale stand-alone videokaart normaal gebruikt, maar als een applicatie de 3Dfx chipset voor renderen wil gebruiken, benaderd deze de 3Dfx drivers om de 3Dfx te initialiseren. De 3Dfx komt er dan bij en begint te renderen aan de hand van de Glide functies die worden aangeroepen door de applicatie.
In een normale configuratie zonder 3Dfx adapter, zit de stand-alone adapter in zijn eigen bus aansluiting op het moederbord en heeft een uitgang die wordt aangesloten op de monitor. De uitvoer van de videokaart wordt dan weergegeven op de monitor. 3Dfx videokaarten zoals de Monster3D en Pure3D gebruiken een "pass-through" (doorgeefluik) systeem dat zowel de stand-alone videokaart als de 3Dfx kaart toestaat dezelfde monitor te gebruiken. Een dergelijke configuratie bestaat uit beide videokaarten in sloten op het moederbord. De uitgang van de stand-alone kaart wordt aangesloten op de ingang van de 3Dfx kaart via een pass-through kabel die meestal wordt meegeleverd met de 3Dfx kaart. De monitor wordt dan aangesloten op de uitgang van de 3Dfx kaart. Tijdens normaal gebruik produceert de stand-alone kaart zijn video signaal, welke wordt doorgegeven aan de ingang van de 3Dfx kaart, en de 3Dfx geeft het video signaal door aan de monitor. Als een applicatie de 3Dfx driver verteld de 3Dfx te initialiseren, sluit de 3Dfx adapter de pass-through uit en het signaal van de stand-alone videokaart bereikt niet langer de monitor. In plaats daarvan begint de 3Dfx adapter met het versturen van zijn eigen video signaal aan de monitor. Alle rendering van de 3Dfx adapter gaat naar de monitor totdat de applicatie een afsluit commando stuurt naar de driver om de 3Dfx te deïnitialiseren en wordt het videosignaal van de stand-alone adapter weer naar de monitor gestuurt.
Helaas is met de pass-through configuratie het normale beeld van de video adapter niet zichtbaar en dit kan problemen veroorzaken voor applicaties die een venster systeem gebruiken, zoals het X Window system, als die proberen een ander venster te renderen. Er wordt een andere methode ondersteund door de 3Dfx adapters die beter geschikt is voor applicaties als deze, maar het vereist een extra monitor. Als je over twee monitoren beschikt, kun je de ene aansluiten op de uitgang van de stand-alone videokaart en de andere monitor kan aangesloten worden op de uitgang van de 3Dfx kaart. Op deze manier, zal een monitor altijd het video signaal weergeven van je stand-alone adapter. De andere monitor zal niets weergeven totdat de 3Dfx adapter wordt geïnitialiseerd. Dan, als de 3Dfx begint, kun je een monitor gebruiken voor je normale venster systeem en de andere monitor zal de fullscreen uitvoer van de 3Dfx geven.
Er is een nieuwere chipset gemaakt door 3Dfx, genaamd de 3Dfx RUSH chipset, welke in staat is om in een venster te renderen. Videokaarten met de chipset bevatten ook een 2D chipset, welke naast de Rush chipset is gebouwd, en deze delen een framebuffer. Daar er op het moment nog een ondersteuning voor LInux is, zal deze hier verder niet besproken worden, maar de ontwikkeling is in volle gang.
Een andere beperking van de 3Dfx chipset is dat het geen hogere resoluties aankan zoals de stand-alone videokaarten van vandaag de dag. Terwijl de stand-alone kaarten resoluties van 1280x1024, 1600x1200 en hoger ondersteunen, gaan de 3Dfx videokaarten vaak niet hoger dan 640x480. Dit is echter niet zo'n zware beperken als men zou denken. Met de gevanceerde anti-aliasing en texture filtering mogelijkheden van de 3Dfx, kunnen veel objecten in een 640x480 resolutie worden geperst, terwijl er nauwelijks verlies optreedt. In feite is het vaak moeilijk om de resolutie die een 3Dfx applicatie gebruikt te achterhalen door alleen naar het scherm te kijken!
De meer algemene 3Dfx kaarten zoals de Monster3D kunnen slechts 640x480 bereiken. Ik geloof dat sommige tot 800x600 kunnen worden overtuigt, maar ik heb me laten vertellen dat andere dingen daaronder lijden, zoals kleurdiepte en alpha buffering, omdat het geheugen dat anders hiervoor gebruikt zou worden, dan gebruikt wordt voor de hogere resoluties. Zwaardere 3Dfx adapters zoals de modellen van Quantum 3D ondersteunen 800x600 zonder diepte of alpha buffering uit te schakelen.
3Dfx Interactive is de fabrikant van deze 3D chipset, echter ze produceren geen videokaarten met deze chipset. Andere bedrijven zoals Diamon Multimedia, Orchid Technology en Canopus Corporation maken videokaarten die gebruik maken van de chipset. Diamond maakt de Monster 3D, Orchid maakt de Righteous3D en Canopus de Pure3D. Een bedrijf met de naam Quantum 3D komt voort uit 3Dfx, en biedt videokaarten die gebruik kunnen maken van de gevanceerde configuraties van de Voodoo (multiple PixelFX en TexelFX units, meer framebuffer of texture ram, enz). Deze modellen zijn bekend als de Obsidian 3D modellen. Zie de 3Dfx Interactive website (www.3dfx.com) voor een complete lijst videofabrikanten die videokaarten produceren met de 3Dfx chipset.
De Voodoo chipset kun je zien als een geavanceerd, flexibel grafisch render-enginge, opgebouwd uit verschillende Voodoo subsystemen. Deze subsystemen kunnen voorkomen in vele combinaties, maar de eenvoudigste configuratie zou er een zijn met slechts een Voodoo subsysteem. Ieder subsysteem is opgebouwd uit meerdere render processoren, bekend als PixelFX en TexelFX units. De PixelFX is het onderdeel dat zorgt voor pixel operaties zoals diepte buffering en goraud shading. De TexelFX unit is verantwoordelijk voor texture operaties zoals texture filtering en projectie. Deze units kunnen samenwerken om effecten als belichte textures te produceren. Ieder van deze units heeft ook zijn eigen video geheugen welke ze gebruiken voor hun eigen gespecialiseerde operaties. De PixelFX gebruikt zijn geheugen om pixels voor de framebuffer op te slaan en de TexelFX gebruikt zijn geheugen om textures op te slaan.
Iedere Voodoo subsysteem configuratie bevat een PixelFX unit, maar er kunnen ook subsystemen zijn met een, twee of drie gescheiden TexelFX units om de snelheid van de texture mapping te verhogen. Verder kan een Voodoo engine worden geconfigureerd met meerdere subsystemen en kan scanline interleaving worden gebruikt om de render snelheid van de engine te verdubbellen. Deze geavanceerde configuraties zijn zelfs in staat om een hogere performance te leveren dan high-end SGI werkstations, dit is bewezen met testen. Natuurlijk zijn deze geavanceerde configuraties een stukje duurder dan de eenvoudige configuratie zoals gebruikt in populaire Voodoo videokaarten en zijn overkill voor de meeste gebruikers.
3Dfx Interactive zal de register-level programmeringsdocumentatie van hun chipset niet vrijgeven, om te voorkomen dat hun hardware makkelijk te reverse engineeren (namaken) is. In plaats daarvan distribueren ze een SDK, genaamd Glide, welke functioneerd als een software "micro-laag" bovenop de hardware. Glide is een set functies georganizeerd in een software library welke de specifieke registers verbergt, en een redelijk eenvoudige API levert voor het programmeren van de 3Dfx chipset met een kleine overhead. De libraries zijn geport naar de platformen (inclusief Linux) welke 3Dfx kiest te ondersteunen, samen met erg gedetailleerde documentatie voor de API. Ontwikkelaars kunnen de API gebruiken om hun eigen 3D applicaties te laten werken met de 3Dfx. Glide is een erg laag-niveau graphische bibliotheek, in tegenstelling tot OpenGL of Direct3D. Het lecert geen hoog-niveau 3D graphics mogelijkheden zoals scherm lijsten of transformatie functies. Het levert alleen een kleine abstractie van de registers van de 3Dfx, en levert alleen softwarefuncties die direct zijn geïmplementeerd in hardware op de 3Dfx. Ik heb de persoon gesproken die Glide naar Linux heeft geport en hij zegt dat de library erg eenvoudige is. In principe zegt hij dat je de correcte parameters aan de Glide functies meegeeft, en de functies duwen de parameters in de registers van de kaart en vertellen de 3Dfx te renderen.
Dit wil niet zeggen dat OpenGL of Direct3D ontwikkelaars geen 3Dfx applicaties kunnen ontwikkelen. OpenGL en Direct3D drivers zijn geschreven om Glide te gebuirken, zodat ontwikkelaars de OpenGL of Direct3D API kunnen gebruiken, de driver vertaald de hoog-niveau functie aanroepen en operaties in Glide specifieke operaties die op hun beurt de 3Dfx aansturen. Dit is een erg snelle en efficiënte methode voor ontwikkeling.
Er is een Glide driver geschreven die interfaced met Mesa (de vrije OpenGL implementatie die beschikbaar is voor veel besturingssystemen) en is beschikbaar voor Linux en Windows 95. Linux is free, de compilers voor Linux zijn free, Mesa is free en de Glide SDK van 3Dfx is ook vrij beschikbaar, dus in principe is deze combinatie een erg kosten-effectieve, OpenGL ontwikkel systeem, met goede performance! Helaas is er geen Glide SDK voor Linux onder Alpha of Sparc CPU's, dus dit gaat alleen op voor het Intel 386 platform.
Op het moment van schrijven was de nieuwste versie van Mesa de versie 2.5 en zijn er beta versies van 2.6 in test. De Mesa driver is gevanceerd en kan overweg met het versnellen van punt, lijn en polygoon rendering met flat shading en gourad shading, en texture mapping, diepte buffering, fogging en blending. Hoewel ik noemde dat de 3Dfx chipset niet in staat is om anders dan full-screen te renderen, is dit wel mogelijk via een kleine hack in de Mesa driver. Deze hack neemt de data van de framebuffer van de 3Dfx en stuurt het via de PCI bus en in het video ram van de stand-alone videokaart. Al is dit niet zo snel als het funscreen renderen van de 3Dfx, het is nog steeds veel sneller dan de software rendering van alleen Mesa.
Mesa is beschikbaar voor download vanaf de Mesa ftp site, op ftp://iris.ssec.wisc.edu/pub/Mesa. Mesa wordt verspreid als twee verschillende pakketten. Een bevat de belangrijkste library en include bestanden en begint met de naam MesLib terwijl het andere bestand een pakket is met demo bestanden. Het pakket met de demobestanden begint met MesaDemos. Om te installeren, untar de pakketten en ga naar de directory die is aangemaakt tijdens het untarren. Vanaf dat punt heb je verschillende mogelijkheden om Mesa te bouwen. Vanaf versie 2.5 van Mesa, zijn er een paar transformatie routines die waren herschreven in Intel 386 assembly. Helaas waren ze nogal buggy, maar zijn gerepareerd in de Mesa 2.6 beta versies. Om Mesa te bouwen met 3Dfx ondersteuning, maar zonder de de assembly routines, kun je gebruik maken van "make linux-glide" (zonder de quotes ("") natuurlijk). Om Mesa met 3Dfx te bouwen en de assembly routines mee te nemen, gebruik "make linux-386 -glide" (ook hier zonder quotes). Vanaf Mesa 2.6 zijn er compiler optimalisaties in de makefile opgenomen die de compiler in staat stellen om code te produceren die Mesa optimaliseert voor gebruik met de beroemde GlQuake en QuakeII spellen! Als je de GlQuake optimalisatie wil gebruiken, type je "make linux-386-quake-glide" om Mesa te bouwen.
Als Mesa klaar is met bouwen, zijn er een aantal manieren waarop je kunt installeren. Een alternatief zou kunnen zijn om de betanden in de include en de lib directory te plaatsen in /usr/include en /usr/lib of /usr/local/include en /usr/local/lib. Of je kunt ze in een willekeurige directory plaatsen, zolang Linux's dynamische linker ze maar kan vinden. De directories waar de linker in kijkt kunnen worden geconfigureerd in het bestand /etc/ld.so.conf. Omdat Mesa zo snel is ontwikkeld, en omdat ik betas graag test zodra ze beschikbaar zijn, gebruik ik gescheiden directories voor iedere versie van Mesa die ik gebruik. Welke versie ik ook wil gebruiken, ik pas gewoon mijn ld.so.conf bestand aan zodat deze de directory met de versie die ik wil gebruiken bevat. Op het moment heb ik /usr/local/Mesa-2.5 met versie 2.5 van de library (/usr/local/Mesa-2.5/lib) en include (/usr/local/Mesa- 2.6/include) bestanden. En voor de 2.6 betas gebruik ik /usr/local/Mesa- 2.6b1 of /usr/local/Mesa-2.6b2. Hoe de lezer het precies aanpakt is echter helemaal aan de lezer, maar er is een HEEL belangrijke stap die je niet zou moeten vergeten. Iedere keer als je nieuwe libraries installeert of de directories in /etc/ld.so.conf moet je de ldconfig tool opnieuw draaien. Deze kijkt in de library directories en zet de correcte symlinks op en nog een paar andere dingen. Als je wilt zien welke libraries momenteel bekekend zijn bij de linker, kun je de -p optie gebruiken met ldconfig. Als ik wil weten welke versie van Mesa een applicatie gebruikt, type ik
ldconfig -p | grep MesaAls je Mesa hebt geïnstalleerd, ben je klaar om te beginnen. Om een Mesa applicatie te starten die 3Dfx gebruikt, moet je deze starten als root. Ook dient de Xserver die je gebruikt opgezet zijn om 16 bits kleurdiepte per pixel te gebruiken. Als je de demos hebt gedownload en uitgepakt, zouden deze tegelijk met Mesa moeten zijn gecompileerd en kun je ze testen. Als je Mesa gebruikt, zijn er drie verschillende manieren waarop je een Mesa applicatie kunt gebruiken. De eerste is door alles te doen met software rendering welke de 3Dfx in het geheel niet gebruikt. Dit is de default. Om de applicatie zover te krijgen 3Dfx gebruiken, dien je een omgevingsvariabele te zetten. Om de applicatie met 3Dfx in fullscreen mode te draaien, gebruik je
MESA_GLX_FX=fullscreenen het programma zal de 3Dfx gebruiken. Een Mesa programma gebruiken in X kan echter nogal tricky zijn. Als je een Mesa programma gebruikt, weet X niet dat de 3Dfx zelfs maar bestaat. Wat er gebeurt is dat er een venster wordt geïnitialiseerd en geopend, en de 3Dfx wordt geïnitialiseerd en het renderen kan beginnen. Als de muis cursor buiten het venster naar de Xserver gaat, zal het Mesa programma niet langer in staat zijn invoer van toetsenbord of muis te aacepteren. Daarom, als je niet dan een monitor gebruikt, wordt het geadviseerd dat je interactieve venster plaatsing (interactive window placement) gebruikt, als je window manager dat ondersteund. Anders, als je het Mesa programma start, zal de 3Dfx starten en je zult je Xserver desktop niet langer zien om in staat te zijn de muiscursor terug te plaatsen in het venster. Het is mogelijk om een Mesa programma zo te schrijven dat wrappen van de cursor mogelijk wordt, zodat de cursor het venster niet kan verlaten. Zodra het de rand van het venster raakt, zal het terug worden geplaatst in het midden van het venster (dit staat bekend als mouse wrap).
Om de applicatie de 3Dfx in een venster te laten renderen, dien je een paar andere omgevingsvariabelen te zetten. Je zet
SST_VGA_PASS=1Dan zet je MESAGLX_FX=window. Nadat deze waarden zijn gezet en programma draait, zou je betere performance moeten krijgen tijdens het renderen dan met alleen software rendering.