The Linux &c3Dfx; HOWTO <author>Bernd Kreimeier (<htmlurl url="mailto:bk@gamers.org" name="bk@gamers.org">) <date>v1.03, 12 Luglio 1997 <abstract> Questo documento descrive il supporto del chip acceleratore grafico &c3Dfx; per Linux. Elenca l'hardware supportato, descrive come configurare i driver e risponde alle domande più frequenti. Lo scopo è quello di portare i nuovi utenti al successo il più velocemente possibile e di ridurre così il traffico nei newsgroup e nelle mailing list Usenet. Documentazione tradotta da Piero Boato (<htmlurl url="mailto:pboato@dsi.unive.it" name="pboato@dsi.unive.it">). </abstract> <toc>  <sect>Introduzione Questo è il Linux &c3Dfx; HOWTO. Vuole essere una rapida guida su tutto quello che c'è da sapere per installare e configurare il supporto per &c3Dfx; sotto Linux. Qui si trovano le risposte alle domande più frequenti sia riguardo lo specifico supporto per &c3Dfx; sia riguardo la grafica 3D sotto Linux in generale. Inoltre ci sono alcuni riferimenti ad altre fonti di informazione su svariati argomenti collegati alla grafica 3D generata a computer da acceleratori hardware. Queste informazioni sono valide solo per Linux installato su piattaforme Intel. Alcune informazioni possono essere applicabili anche su altre architetture, ma non ho esperienza o informazioni dirette. Sono da applicare solamente su schede basate sulla tecnologia &c3Dfx;, ogni altro acceleratore grafico non rientra nel contesto di questa documentazione. <sect1>Riconoscimenti La maggior parte delle informazioni contenute in questa documentazione sono state fornite dalle persone coinvolte nella trasposizione della Glide per Linux e nel suo processo di beta test. Daryll Strauss ha fatto la trasposizione, Paul J. Metzger ha modificato il driver &VooMesa; (scritto da David Bucciarelli) per Linux, Brian Paul lo ha integrato con la sua famosa libreria &Mesa;. Riguardo alla Mesa accelerata per &VooDoo; un ringrazziamento particolare va a Henri Fousse e Charlie Wallace. La gente alla &c3Dfx;, in particolar modo Gary Sanders e Gary McTaggart, ha fornito molto materiale, come ha fatto Ross Q. Smith della Quantum3D. Grazie al pacchetto &SGMLT; (conosciuto anche come Linuxdoc-SGML), questo HOWTO è disponibile in diversi formati, tutti generati dallo stesso file sorgente. Per informazioni sull'&SGMLT; vedi la sua homepage all'indirizzo <htmlurl url="http://web.inter.NL.net/users/C.deGroot/sgmltools/" name="web.inter.NL.net/users/C.deGroot/sgmltools/">. &c3Dfx;, il logo &c3Dfx; Interactive, &VooDoo;, e &VooRush; sono marchi registrati dalla &c3Dfx; Interactive, Inc. &Glide;, &TexUs;, Pixelfx e Texelfx sono marchi registrati dalla 3Dfx Interactive, Inc. &OGL; è un marchio registrato dalla Silicon Graphics. Obsidian è un marchio registrato dalla Quantum3D. Gli altri nomi di prodotti sono marchi registrati dai rispettivi proprietari e con ciò sono da considerarsi propriamente riconosciuti. <sect1>Storia delle Revisioni <descrip> <tag>Versione 1.03</tag>Prima versione resa pubblica. </descrip> <sect1>Nuove Versioni di Questa Documentazione Puoi trovare la versione più aggiornata di questa documentazione presso <htmlurl url="http://www.gamers.org/dEngine/xf3D/" name="www.gamers.org/dEngine/xf3D/">. Le nuove versioni di questa documentazione verranno postate nel newsgroup <htmlurl url="news:comp.os.linux.answers" name="comp.os.linux.answers">. Inoltre saranno depositate in vari siti per l'ftp anonimo che archiviano questo tipo di informazioni come <htmlurl url="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/" name ="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/">. Le versioni ipertestuali di questo e di altri Linux HOWTO sono disponibili su molti siti World-Wide-Web, compreso <htmlurl url="http://sunsite.unc.edu/mdw/mdw.html" name="sunsite.unc.edu/mdw/mdw.html">. La maggior parte delle distribuzioni di Linux su CD-ROM includono gli HOWTO, spesso nella directory <tt>/usr/doc/</tt>, inoltre presso alcuni rivenditori si può acquistarne una copia stampata. Se si fa una traduzione di questo documento in un'altra lingua, me lo si faccia sapere che accennerò qui alla sua esistenza. <sect1>Commenti e Correzioni Confido in te, lettore, per far sì che questo HOWTO sia utile. Se si hanno suggerimenti, correzioni o commenti, per piacere me li si spedisca (<htmlurl url="mailto:bk@gamers.org" name="bk@gamers.org">), e io cercherò di inserirli nella prossima revisione. Per piacere si aggiunga <tt>HOWTO 3Dfx</tt> al soggetto della lettera, così procmail lo scaricherà nell'apposita cartella. Prima di mandare bug report o domande, per favore si legga per intero questo HOWTO e si inviino informazioni dettagliate sul problema. Se si publica questa documentazione in un qualche CD-ROM o in altro supporto fisico, sarà apprezzata una copia in omaggio. Mi si scriva per il mio indirizzo postale. Inoltre si consideri la possibilità di una donazione al Linux Documentation Project come contributo al mantenimento della documentazione gratuita per Linux. Per maggiori informazioni si contatti il coordinatore dei Linux HOWTO, Greg Hankins (<htmlurl url="mailto:gregh@sunsite.unc.edu" name="gregh@sunsite.unc.edu">). <sect1>Politica di Distribuzione Copyright (C) 1997 Bernd Kreimeier. Questo HOWTO è una documentazione gratuita; si può ridistribuirlo e/o modificarlo secondo le specifiche della GNU General Public License publicata dalla Free Software Foundation; presenti nella versione 2 della License, o (a scelta) in qualche versione seguente. Questa documentazione viene distribuita nella speranza che possa essere utile, ma <bf>senza alcuna garanzia</bf>; senza anche l'implicita garanzia di <bf>commerciabilità</bf> o di <bf>adeguatezza ad uno scopo particolare</bf>. Si veda la GNU General Public License per maggiori particolari. Si può ottenere una copia della GNU General Public License scrivendo alla Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.  <sect>Tecnologia degli Acceleratori Grafici <sect1>Principi Questa sezione descrive molto velocemente la tecnologia degli acceleratori grafici per computer, in modo da aiutare a capire i concetti usati in seguito. Se se ne vuole sapere di più si può consultare un libro su &OGL;. Fondamentalmente, la grafica 3D su computer richiede spesso un gran numero di calcoli per ogni singolo pixel dello schermo. Questo è vero soprattutto per quelle applicazioni che devono rappresentare un mondo poligonale nei vari frame di un'animazione interattiva. Anche a basse risoluzioni come 320x200, ciò richiede una capacità di calcolo superiore a quella che può essere fornita anche dal PC più potente. Per superare questo collo di bottiglia, alcune società hanno progettato, costruito e venduto processori dedicati alle operazioni necessarie per la grafica 3D. Purtroppo praticamente nessuno dei produttori di schede ha finora offerto alcun supporto per Linux. Fortunatamente, il produttore dei chipset &VooDoo; e &VooRush;, &c3Dfx;, ha deciso di supportare l'uso delle schede basate sul &VooDoo; con Linux. Ciò che si prefigge questa documentazione è di descrivere il supporto attualmente disponibile. <sect1>Configurazioni Hardware (Add-on) Gli acceleratori grafici si trovano in formati diversi: o come schede PCI capaci di passare attraverso il segnale video di una scheda VGA (possibilmente un acceleratore 2D o video), o come schede PCI che generano grafica sia VGA sia 3D (rimpiazzando totalmente il vecchio controller VGA). Le schede &c3Dfx; basate sul &VooDoo; appartengono alla prima categoria. Entreremo nel merito in seguito. Se non ci sono conflitti hardware, qualsiasi scheda acceleratrice può essere presente sotto Linux senza interferire, ma per accedere all'acceleratore, si deve disporre di un driver. <sect1>Limiti di Prestazioni <sect2>Limiti di fill rate La grafica accelerata dall'hardware è limitata nelle prestazioni per diversi motivi. Un tipico collo di bottiglia è il fill rate: il numero totale di pixel che l'hardware può generare in condizioni ottimali in un determinato tempo - ad es. circa 40 Mpixel/secondo. Data una risoluzione di 640x480 e nessuna sovrascrittura, l'hardware non può generare più di 130 frame/secondo. Il numero di sovrascritture dipende dall'attuale profondità della scena (quanti poligoni interseca un raggio passante per un pixel) e dall'efficienza dell'algoritmo di determinazione delle superfici visibili usato dall'applicazione. Disegnare ogni pixel due volte significa 65 frame/secondo, una sovrascrittura pari a 2 (disegnare ogni pixel tre volte) ti porta a circa 43 frame/secondo. <sect2>Perdita di refresh Inoltre, probabilmente si utilizzeranno due buffer, invertendo il buffer in primo piano con quello nascosto non appena il frame è completato. Qui entra in gioco la velocità di refresh del monitor: si può invertire i buffer soltanto durante il periodo di refresh. Se la propria applicazione salta un periodo di refresh a 60Hz ad ogni frame, il frame rate effettivo scenderà a 30Hz (un frame ogni due refresh). Perdere due periodi di refresh porterà a 20Hz. <sect2>Limiti di primitive Se la propria scena non è molto dettagliata (solo pochi poligoni, ma molto grandi, con molte sovrascritture), l'applicazione sarà probabilmente limitata dal fill rate - è possibile fornire altre primitive (linee, triangoli, poligoni) all'hardware, ma la generazione dei pixel non può essere in alcun modo accelerata. Invece, se la propria applicazione rappresenta un infinità di piccoli triangoli o poligoni, probabilmente ci si ritroverà limitati dalla generazione delle primitive. Dato una banda passante del PCI di 33MHz per 32bit, o 132 MB/sec, e un pacchetto di dati per triangolo di 3 vertici (9 coordinate, ognuna a 16bit, più 3 colori, ognuno a 24bit), e un frame rate di 20Hz, si potranno trasferire circa 240K triangoli/frame - senza contare i dati delle texture, gli accessi al disco e le altre operazioni. <sect1>Caratteristiche dell'Accelerazione Hardware Le operazioni di rendering solitamente supportate dagli acceleratori hardware che si rispettino sono: <itemize> <item>Texture mapping con correzione prospettica <item>Alpha-blending, Nebbia <item>Anti-aliasing <item>Filtering bi-lineare delle texture <item>Livello di dettaglio (LOD) MIP mapping <item>Correzione a livello sub-pixel <item>Ombreggiatura Gouraud basata sui poligoni e modulazione delle texture <item>Double buffering <item>Buffering di profondità, stencil buffer </itemize> Solitamente, l'hardware permette un aumento della risoluzione dello schermo (dato che il rendering esclusivamente software è limitato a 320x200 pixel per i frame rate interattivi), il filtraggio avanzato, la traslucenza reale del canale alpha, e l'uso di frame buffer a colori reali a 16bpp o 24bpp. <sect1>Cenni sull'Architettura &VooDoo; Solitamente, il maggior collo di bottiglia si riscontra nell'accesso alla memoria delle texture e ai buffer di profondità e dei fotogrammi. Per ogni pixel nello schermo, ci sono almeno uno (mappatura in vicinanza), quattro (bi-lineare) o otto (tri-lineare) accessi in lettura alla memoria delle texture, più una lettura/scrittura al buffer di profondità e una lettura/scrittura al buffer dei fotogrammi. L'architettura &VooDoo; separa la memoria delle texture da quella dei buffer dei fotogrammi e di profondità suddividendo il rendering in due stadi separati, con due unità distinte (il pixelfx e il texelfx), ognuna con il proprio collegamento alla memoria corrispondente. Questo permette un fill rate superiore alla media, a discapito della gestione della memoria (p.es. la memoria dedicata ai frame non utilizzata non può essere usata per il caching delle texture). Inoltre, un &VooDoo; può usare due TMU (unità di gestione delle texture o texelfx), ed infine, due &VooDoo; possone essere collegati per accedere allo stesso RAMDAC con un meccanismo chiamato Scan-Line Interleaving (SLI). In parole povere SLI significa che ogni pixelfx disegna una riga di schermo ogni due, il che riduce l'impatto della banda passante sulla memoria destinata ai frame di ogni pixelfx.  <sect>Installazione Configurare Linux per supportare gli acceleratori &c3Dfx; richiede i seguenti passi: <enum> <item>Installare la scheda. <item>Installare la distribuzione &Glide;. <item>Compilare, linkare e/o lanciare le applicazioni. </enum> Le sezioni seguenti trattano ognuno di questi passi in dettaglio. <sect1>Installare la Scheda Per installare l'hardware si seguano le istruzioni del produttore o o lo si lasci fare al rivenditore. Non dovrebbe essere necessario modificare le impostazioni degli IRQ o del canale DMA, dato che il Plug&Pray (tm) o quelle predefinite dalla fabbrica dovrebbero funzionare. Le schede add-on qui descritte sono dispositivi mappati in memoria e non usano IRQ. L'unico tipo di conflitto da evitare è la sovrapposizione di memoria con altri dispositivi. Dato che &c3Dfx; non sviluppa o vende nessuna scheda direttamente, è inutile contattarla per qualche problema. <sect2>Risoluzione dei problemi di installazione hardware Per verificare l'installazione e la mappatura della memoria, si esegua <tt>cat /proc/pci</tt>. L'output dovrebbe contenere qualcosa come <code> Bus 0, device 12, function 0: VGA compatible controller: S3 Inc. Vision 968 (rev 0). Medium devsel. IRQ 11. Non-prefetchable 32 bit memory at 0xf4000000. Bus 0, device 9, function 0: Multimedia video controller: Unknown vendor Unknown device (rev 2). Vendor id=121a. Device id=1. Fast devsel. Fast back-to-back capable. Prefetchable 32 bit memory at 0xfb000000. </code> per una Diamond Monster 3D affiancata ad una Diamond Stealth-64. Inoltre un <tt>cat /proc/cpuinfo /proc/meminfo</tt> può essere utile per scovare un conflitto e/o mandare un bug report. Con i kernel attuali, probabilmente si avrà un avviso in fase di boot simile a questo <code> Jun 12 12:31:52 hal kernel: Warning : Unknown PCI device (121a:1). Please read include/linux/pci.h </code> che può essere tranquillamente ignorato. Se si ha una scheda non molto comune o si incappati in una nuova revisione, si dovrebbe prendersi l'onere di seguire le avvertenze in <tt>/usr/include/linux/pci.h</tt> e mandare tutte le informazioni necessarie a <htmlurl url="mailto:linux-pcisupport@cao-vlsi.ibp.fr" name="linux-pcisupport@cao-vlsi.ibp.fr">. Se si incontra un qualche problema con la scheda, si dovrebe provare a verificare se il supporto DOS e/o Win95 o NT funziona. Probabilmante non si riceverà alcuna risposta utile da un fabbricante di schede per un bug report o una richiesta riguardanti Linux. Anzi, avendo avuto a che fare con il sistema di supporto e-mail di Diamond, non mi aspetto nessuna risposta utile anche per gli altri sistemi operativi. <sect2>Configurare il kernel Non c'è bisogno di alcuna configurazione del kernel, fin tanto che il supporto PCI è abilitato. Si può consultare il <htmlurl url="http://sunsite.unc.edu/mdw/HOWTO/Kernel-HOWTO.html" name="Linux Kernel HOWTO"> per i dettagli sulla compilazione del kernel. <sect2>Configurare i device I driver correnti non hanno (ancora) bisogno di device speciali. Si differenziano così dallo sviluppo degli altri driver (p.es. i driver sonori, che usano <tt>/dev/dsp</tt> e <tt>/dev/audio</tt>). Il driver usa il device <tt>/dev/mem</tt> che dovrebbe sempre essere disponibile. Di conseguenza, si deve usare <tt>setuid</tt> o i diritti di root per accedere alla scheda acceleratrice. <sect1>Disposizione dei Monitor Le schede add-on sono utilizzabili in due modi. Si può sia far passare il segnale video dalla propria scheda VGA attraverso la scheda accelerata e poi allo schermo, sia usare due schermi contemporaneamente. Si faccia riferimento al manuale fornito dal costruttore della scheda per i dettagli. Entrambe le configurazioni sono state provate con la scheda Monster 3D. <sect2>Soluzione a schermo singolo Questa configurazione permette di controllare l'operatività di base della scheda acceleratrice - se il segnale video non viene trasmesso al monitor è possibile che ci sia un guaso hardware. Si ricorda che il segnale video può deteriorarsi sensibilmente se passa attraverso la scheda video. Fino ad un certo punto questo è inevitabile. Comunque, in alcune recensioni si sono lamentati della scarsa efficenza dei cavi forniti a.es. con la Monster 3D e a giudicare da quello che ho testato, non ci sono stati cambiamenti. Ci sono altre pecche nella configurazione ad un solo schermo. Passare dalla modalità VGA a quella accelerata farà cambiare la risoluzione e la frequenza di aggiornamento, anche se si usa una risoluzione di 640x480 p.es. con X11. Inoltre, se si sta usanto X11, la propria applicazione è responsabile della gestione di tutti gli eventi della tastiera e del mouse, quindi si potrebbe rimanere bloccato a causa di un cambio di contesto o esposizione sullo schermo dell'X11 (che è completamente invisibile quando viene usata la modalità accelerata). Si potrebbe usare la modalità SVGA in console invece dell'X11. Se si usa la configurazione ad un solo monitor e si cambia spesso modo, ci si ricordi che il proprio monitor potrebbe non gradire questo tipo di utilizzo. <sect2>Soluzione a due schermi La scheda acceleratrice non ha bisogno del segnale d'ingresso VGA. Invece di far passare l'output video attraverso la scheda acceleratrice, si può attaccare un secondo monitor alla sua uscita e usarli entrambi contemporaneamente. Questa soluzione è più costosa, ma dà risultati migliori, dato che lo schermo principale funzionerà sempre in alta risoluzione senza la perdita di qualità del segnale che la soluzione passante comporta. Inoltre si può usare X11 e l'accelerazione a schermo intero in parallelo, facilitando lo sviluppo e il debugging. Il problema è che la scheda accelerata non produce alcun segnale video quando non viene utilizzata. Di conseguenza, ogni volta che l'accelerazione grafica termina, può attivarsi lo screensave/powersave hardware del monitor, se esiste. Anche in questo caso, il proprio hardware potrebbe non gradire di essere trattato in questo modo. Si dovrebbe usare <code> setenv SST_DUALSCREEN 1 </code> per forzare un output video continuo in questa configurazione. <sect1>Installare la Distribuzione &Glide; Il driver e la libreria &Glide; sono forniti come un unico archivio compresso. Si usino <tt>tar</tt> e <tt>gzip</tt> per scompattarlo e si seguano le istruzioni nel README e nell'INSTALL che accompagnano la distribuzione. Si legga ed esegua lo script di installazione. L'installazione copia tutto in /usr/local/glide/include,lib,bin e imposta l'ld.conf a cercare là. Dove installare la distribuzione e impostare l'ld.conf sono due azioni indipendenti. Se non si esegue l'impostazione dell'ld.conf allora si avrà bisogno dell'LD_LIBRARY_PATH. Se si vogliono compilare le proprie applicazioni grafiche, sarà necessario installare gli header file in una locazione accessibile in fase di compilazione. Se non si vuole usare l'installazione vista sopra (cioè si decide per un'altra locazione), ci si assicuri che ogni applicazione possa accedere alle librerie condivise in esecuzione o si otterrà un risultato del tipo <tt>can't load library 'libglide.sò</tt>. <sect2>Usare il programma detect Nella distribuzione c'è il programma <tt>bin/detect</tt> (il sorgente non è disponibile). Si deve lanciarlo come root, ed si otterrà qualcosa di simile <code> slot vendorId devId baseAddr0 command description ---- -------- ------ ---------- ------- ----------- 00 0x8086 0x122d 0x00000000 0x0006 Intel:430FX (Triton) 07 0x8086 0x122e 0x00000000 0x0007 Intel:ISA bridge 09 0x121a 0x0001 0xfb000008 0x0002 3Dfx:video multimedia adapter 10 0x1000 0x0001 0x0000e401 0x0007 ???:SCSI bus controller 11 0x9004 0x8178 0x0000e001 0x0017 Adaptec:SCSI bus controller 12 0x5333 0x88f0 0xf4000000 0x0083 S3:VGA-compatible display co </code> come risultato. Se non si possiedono i diritti di root, il programma se ne verrà fuori con <code> Permission denied: Failed to change I/O privilege. Are you root? </code> L'output potrà tornare utile per un bug report. <sect2>Usare i programmi di test All'interno della distribuzione &Glide; si può trovare una directory con i programmi di test. Si noti che questi programmi sono sotto il copyright della &c3Dfx; e sono legalmente usabili solo se hai comprato una scheda con chipset &c3Dfx;. Si veda il file LICENSE nella distribuzione o il loro sito web <htmlurl url="http://www.3dfx.com/" name="www.3dfx.com"> per i dettagli. Si raccomanda di compilare e linkare i programmi di test anche se nella distribuzione ci sono i binari. Nota che alcuni programmi richiedono che altri file della distribuzione, come <tt>alpha.3df</tt>, siano disponibili nella stessa cartella. Tutti i programmi di test usano una risoluzione di 640x480. Alcuni richiedono la pressione di più tasti come input, altri chiederanno solamente <tt>Press A Key To Begin Test</tt>. Si faccia attenzione alla perdita del contesto di input se si sta eseguendo in contemporanea X11 sullo stesso schermo. Si consulti il README.test per una lista del programmi, e per altri dettagli.  <sect>Risposte Alle Domande Più Frequenti Le sezioni seguenti rispondono ad alcune delle domande che sono state poste nei newsgroup e mailing list Usenet. Le FAQ sono state suddivise per comodità in più parti, vale a dire <itemize> <item>FAQ: Requisiti? <item>FAQ: &VooDoo;? &c3Dfx;? <item>FAQ: &Glide;? <item>FAQ: &Glide; e SVGA? <item>FAQ: &Glide; e XFree86? <item>FAQ: &Glide; vs. OpenGL/Mesa? <item>FAQ: Quake? <item>FAQ: Risoluzione dei problemi? </itemize> Ogni sezione elenca alcune domande e risposte, a cui si possono ricondurre la maggior parte dei problemi.  <sect>FAQ: Requisiti? <sect1>Quali sono i requisiti di sistema? Un PC Linux con PCI 2.1 o seguente, un monitor con risoluzione 640x480 o maggiore e una scheda acceleratrice 3D basata sul &c3Dfx; &VooDoo;. Funziona su P5 o P6, con o senza MMX. <sect1>Funziona con Linux-Alpha? Attualmente non ci sono distribuzioni Linux &Glide; per le piattaforme diverse dalla i586. Dato che i sorgenti della &Glide; non sono pubblicamente disponibili, si devono aspettare i binari. Quantum3D ha annunciato il supporto per DEC Alpha per la seconda metà del 97. Per piacere si contatti Daryll Strauss se si è interessati al supporto di questo progetto. <sect1>Quali chipset sono supportati? Attualmente sotto Linux è supportata la più recente revisione dei chipset &c3Dfx; &VooDoo;. I chipset &VooRush; non sono tuttora supportati. <sect1>Quali schede sono supportate? Questa sezione elenca le schede che attualmente si sanno funzionare sotto Linux. Non ci sono schede ufficialmente supportate, dato che &c3Dfx; non vende alcuna scheda. Queste informazioni sono basate sull'ultimo kernel di Linux disponibile al momento di scrivere, ed elencano le schede che sono state testate, più le schede che dovrebbero funzionare, ma che non sono state provate. È importante sottolineare che il supporto Linux per una data scheda non richiede solamente un driver per la componente acceleratrice 3D. Se una scheda integra anche la parte VGA, allora sarà necessario anche il supporto per Linux SVGA e per XFree86. Attualmente, è preferibile la soluzione con scheda add-on, dato che ti permette di scegliere una scheda grafica normale ben supportata da Linux. Ci sono altri aspetti discussi in seguito. Sono state testate le seguenti configurazioni: <itemize> <item>Diamond Monster 3D con Diamond Stealth 64 3240XL <item>Orchid Righteous 3D con una scheda grafica basata sul S3-968 <item>Quantum3D Obsidian 50-4220 </itemize> Queste sono le configurazioni esistenti delle schede Obsidian, la maggior parte delle quali non sono ancora state testate, ma comunque dovrebbero funzionare. <descrip> <tag/Obsidian 50-2200/ 1 pixelfx con 2MB di frame buffer memory, 1 texelfx con 2MB di texture memory <tag/Obsidian 50-2400/ 1 pixelfx con 2MB di frame buffer memory, 1 texelfx con 4MB di texture memory <tag/Obsidian 50-4400/ 1 pixelfx con 4MB di frame buffer memory, 1 texelfx con 4MB di texture memory <tag/Obsidian 50-2220/ 1 pixelfx con 2MB di frame buffer memory, 2 texelfx con 2MB di texture memory ciascuno, per un totale di 4MB di texture memory <tag/Obsidian 50-4220/ 1 pixelfx con 4MB di frame buffer memory, 2 texelfx con 2MB di texture memory ciascuno, per un totale di 4MB di texture memory. Questa configurazione era l'originale "Obsidian Pro" che era stata usata per il 3DS Plug-in Project (ora fatto con la Datapath Realistorm). Datapath era solito chiamarla "Pro VR". <tag/Obsidian 50-4440/ 1 pixelfx con 4MB di frame buffer memory, 2 texelfx con 4MB di texture memory ciascuno, per un totale di 8MB di texture memory. Questa configurazione è il nuovo obiettivo per il 3DS Plug-in Project (ora fatto con la Datapath Realistorm). <tag/Obsidian 50-2440/ 1 pixelfx con 2MB di frame buffer memory, 2 texelfx con 4MB di texture memory ciascuno, per un totale di 8MB di texture memory. <tag/Obsidian 100-2440/ aka 2440-SLI, aka XS-100, o semplicemente "SLI". Due schede PCI, ognuna con 1 pixelfx con 2MB di frame buffer memory e 2 texelfx con 4MB di texture memory ciascuno, per un totale di 8MB di texture memory per scheda. Le texture devono essere memorizzate su entrambe le schede, così ciò non equivale a 16MB di texture memory. L'uscita video scan line interleaved permette di raddoppiare il fill rate. </descrip> Il pacchetto commerciale con software aggiuntivo per Autodesk 3DS MAX chiamato Obsidian 3DS, originariamente usava 50-4220 ed ora è distribuito assieme ad una scheda 50-4440. Le seguenti schede non sono ancora state testate: <itemize> <item>Deltron RealVision Flash 3D </itemize> Con l'attuale Glide &GlVer;, le seguenti schede basate sul &VooRush; non dovrebbero funzionare con Linux: <itemize> <item>Hercules Stingray 128/3D <item>Intergraph Intense 3D Rush </itemize> Dato che il chipset &VooRush; supporta operazioni in finestra, viene usato su schede VGA accelerate, che richiedono un supporto per XFree86 o Linux SVGA non ancora disponibile. Le schede non basate sui chipset &c3Dfx; (e.g. prodotte da S3, Matrox, 3Dlabs, Videologic) non funzionano con i driver &c3Dfx; e esulano dagli scopi di questa documentazione. <sect1>È supportata la Hercules Stingray 128/3D? In questa scheda, l'acceleratore 2D è montato su una scheda PCI e il chipset &VooRush; su una scheda figlia. Attualmente questa scheda non è supportata nè dalla Linux &Glide;, né dai server accelerati XFree86. Tuttavia il server SVGA XFree86 funziona secondo quanto riportato nella mailing list di Mesa. Supporta gli 8, i 16 e i 32 bpp. <code> # device section settings Chipset "AT24" Videoram 4032 # videomodes tested by Oliver Schaertel # 25.18 28.32 for 640 x 480 (70hz) # 61.60 for 1024 x 786 (60hz) # 120 for 1280 x 1024 (66hz) </code> Attualmente non c'è supporto per il &VooRush;. Varrebbe la pena tentare, ma siccome il produttore non ha fornito alcuna scheda di prova, ci si deve arrangiare. Per quanto riguarda il componente VGA collegato al &VooRush;, è un acceleratore della Alliance Semiconductor's ProMotion-AT3D multimedia. Il supporto XFree86 per l'AT3D/AT24 non sarà accelerato prima della XFree86 4.0, che è lungi a venire. <sect1>È supportata la Intergraph Intense 3D Rush? Sebbene questa scheda sia integrata in un'unica scheda, è sostanzialmente la stessa combinazione di chipset (AT3D, &VooRush;), così vale lo stesso discorso fatto in precedenza per la Hercules Stingray. Da quanto ha detto David E. Anderson della Intergraph, per il momento non hanno intenzione di fornire alcun supporto per Linux.  <sect>FAQ: &VooDoo;? &c3Dfx;? <sect1>Chi è &c3Dfx;? &c3Dfx è un industria di San Jose produttrice di acceleratori grafici 3D per giochi arcade, console, e schede per PC. Il loro sito ufficiale è <htmlurl url="http://www.3dfx.com/" name="www.3dfx.com">. &c3Dfx; non vende direttamente alcuna scheda, ma hanno una società associata, la Quantum3D. Si veda la loro home page al sito <htmlurl url="http://www.quantum3d.com/" name="www.quantum3d.com"> per maggiori informazioni. <sect1>Che cos'e il &VooDoo;? Il &VooDoo; è un chipset prodotto dalla &c3Dfx;. Viene usato nelle schede acceleratrici per PC. Si veda la sezione dell'HOWTO sull'hardware supportato. C'è un nuovo chipset, il &VooRush;, che attualmente non è supportato sotto Linux.  <sect1>Dove posso trovare altre informazioni sul &VooDoo;? C'è una FAQ della &c3Dfx;, che dovrebbe essere disponibile al loro <htmlurl url="http://www.3dfx.com/voodoo/faq.html" name="sito web">. Si possono trovare informazioni commerciali nei seguenti siti: <itemize> <item><htmlurl url="http://www.3dfx.com/voodoo/sale/" name="www.3dfx.com"> <item><htmlurl url="http://www.quantum3d.com/" name="www.quantum3d.com"> <item><htmlurl url="http://www.orchid.com/" name="www.orchid.com"> <item><htmlurl url="http://www.diamondmm.com/" name="www.diamondmm.com"> <item><htmlurl url="http://www.deltrontech.com/f3dinfo.htm" name="www.deltrontech.com"> </itemize> <sect>FAQ: &Glide;? &TexUs;? <sect1>Che cos'è &Glide;? &Glide; è un API proprietaria più i driver per accedere all'accelerazione grafica 3D hardware basata sui chipset prodotti dalla &c3Dfx;. &Glide; è stato progettato ed implementato per DOS, Windows e Macintosh, ed è stato convertito per Linux da Daryll Strauss. <sect1>Che cos'è &TexUs;? Nella distribuzione è <tt>libtexus.so</tt>, che è l'Interactive Texture Utility Software di &c3Dfx;. è una libreria di eleborazione delle immagine ed alcune utility per preparare le immagini per essere usate con la libreria Interactive &Glide; di &c3Dfx;. Tra le caratteristiche di &TexUs; ci sono la conversione dei formati dei file, la creazione di MIPmap e il supporto per l'Interactive Narrow Channel Compression delle texture di &c3Dfx;. L'utility <tt>texus</tt> di &TexUs; legge le immagini in alcuni dei formati più diffusi (TGA, PPM, RGT), genera MIPmap e scrive le immagini come file di texture &c3Dfx; Interactive (vedi a.es. alpha.3df, incluso nella distribuzione) o come file immagine per essere controllati. Per i dettagli sui parametri di <tt>texus</tt> e sulle API, si veda la documentazione di &TexUs;. <sect1>&Glide; è freeware? No. &Glide; non è nè GPL nè soggetta a qualche altra licenza pubblica. Si veda il file LICENSE nella distribuzione per i dettagli. &Glide; viene fornita solo in formato binaro e non si dovrebbe usare o distribuire alcun file se non quelli rilasciati pubblicamente, se non si ha firmato un NDA. La distribuzione &Glide; inclusi i sorgenti dei programmi di test sono sotto il copyright della &c3Dfx;. Lo stesso discorso va fatto per tutti i sorgenti presenti nella distribuzione &Glide;. Secondo le parole della &c3Dfx;: Questi non sono di pubblico dominio, ma possono essere distribuiti liberamente solo ai posessori di prodotti &c3Dfx;. Niente scheda, niente codice! <sect1>È disponibile il sorgente della &Glide;? No. Il sorgente della &Glide; è reso disponibile solo in base ad uno speciale accordo e un NDA con &c3Dfx;. <sect1>La Linux &Glide; è supportata? Attualmente la Linux &Glide; non è supportata. Essenzialmente, viene fornita sotto le stesse restrizioni della DLL GLQuake. Comunque, &c3Dfx; vuole fornire il maggior supporto possibilie, e sta iniziando a muoversi in questa direzione. Per il prossimo periodo, si dovrà far riferimento al newsgroup &c3Dfx; (vedere sotto). Inoltre, la pagina web della Quantum3D riporta che il supporto Linux (per la Obsidian) è previsto sia per l'architettura Intel sia per quella AXP nella seconda metà del 97. <sect1>Dove posso postare le domande su &Glide;? Ci sono alcuni newsgroups attualmente disponibili sul server NNTP <htmlurl url="news://news.3dfx.com/" name="news.3dfx.com"> gestiti dalla 3Dfx. Questi gruppi USENET sono dedicati alla &c3Dfx; e a &Glide; in generale e principalmente forniscono assistenza per DOS, Win95 e NT. L'attuale elenco è: <code> 3dfx.d3d.drivers 3dfx.events 3dfx.game.titles 3dfx.games.glquake 3dfx.glide 3dfx.glide.linux 3dfx.oem.products.diamond.monster3d 3dfx.oem.products.hercules.stingray128-3d 3dfx.oem.products.orchid.righteous3d 3dfx.oem.products.quantum3d.obsidian 3dfx.oem.products.realvision.flash3d 3dfx.products 3dfx.test </code> Per piacere si usi <htmlurl url="news://news.3dfx.com/3dfx.glide.linux" name="news.3dfx.com/3dfx.glide.linux"> per tutte le domande relative alla Linux &Glide;. Una mailing list dedicata alla Linux &Glide; è in preparazione (probabilmente sarà disponibile ad agosto inoltrato). Si spedisca una lettera a <htmlurl url="mailto:majordomo@gamers.org" name="majordomo@gamers.org">, senza alcun soggetto, e con <tt>info linux-3dfx</tt> come corpo del messaggio per avere informazioni sulle direttive di posting, l'archivio di hypermail e su come iscriversi alla lista o averne, quando disponibile, il compendio. <sect1>Dove spedire i bug report? Attualmente si deve fare riferimento al newsgroup (vedere sopra), che è <htmlurl url="news://news.3dfx.com/3dfx.glide.linux" name="news.3dfx.com/3dfx.glide.linux">. Non c'è nessun supporto e-mail ufficiale attivato. Per le domande non specificatamente riguardanti la Linux Glide, ci si assicuri di usare un altro newsgroup. <sect1>Chi la sta mantenendo? &c3Dfx; nominerà presto un mantenitore ufficiale. Attualmente, il mantenitore non ufficiale della conversione per Linux della &Glide; è Daryll Strauss. Per favore si postino i bug report nel newsgroup (v. sopra). Se si crede di aver trovato un bug non riportato precedentemente, per piacere si scriva a Daryll all'indirizzo <htmlurl url="mailto:daryll@harlot.rb.ca.us" name="daryll@harlot.rb.ca.us">. <sect1>Come posso contribuire alla Linux &Glide;? Si possono inviare dettagliati bug report. Un'altra possibilità è fornire programmi d'esempio da includere nella distribuzione. Un altro grande contributo potrebbe essere aggiungere del codice ai sorgenti del driver &VooMesa; basato sulla &Glide;. Si vedano la sezione sul &VooMesa; in seguito. <sect1>Devo usare la &Glide;? Sì. Dato che per il momento non ci sono altri driver &VooDoo; disponibili per Linux. <sect1>Dovrei programmare usando l'API della Glide? Dipende dall'applicazione che si ha intenzione di sviluppare. La &Glide; è un API proprietaria che è in parte simile alla &OGL; o alla &Mesa;, in parte contiene funzioni disponibili come estensioni di qualche implementazione di &OGL; e in parte contiene funzioni non riscontrabili da nessuna altra parte se non nella &Glide;. Se si vuole usare l'API &OGL;, si deve usare &Mesa; (vedere sotto). &Mesa;, o meglio il driver &VooMesa;, propone una API che si rifà all'API OpenGL, molto ben documentata e largamente usata. Comunque, il driver &VooMesa; è in versione alpha primitiva, quindi se lo si usa si devono accettarne le scarse prestazioni e il mancato supporto di alcune funzioni. In breve, la scelta è personale - se si cercano le massime prestazioni e si accettano i problemi di portabilità ad hardware non-&c3Dfx;, La &Glide; non è una cattiva scelta. Se si tiene al mantenimento, l'&OGL; potrebbe essere la scelta miglior a lungo termine. <sect1>Qual'è la versione attuale? La versione della Linux &Glide; che sarà resa pubblica è la &GlVer;, dato che è la prossima release della &Glide; per DOS/Windows. Nota che questo HOWTO è stato scritto basandosi sulla Linux &Glide; 2.3.1, dato che la &Glide; 2.4 non è ancora stata rilasciata e che la conversione per Linux della &Glide; 2.4 non è ancora stata terminata. Visto che l'API non cambierà e visto che non ci sono variazioni pianificate per la distribuzione Linux &Glide;, questa documentazione ricoprirà ancora la maggior parte dei problemi. <sect1>La Linux &Glide; è identica alla DOS/Windows &Glide;? La versione della Linux &Glide; che verrà resa pubblica sarà la &GlVer;, seguendo la release della DOS/Windows &Glide; &GlVer;. L'API e l'implementazione si suppongono essere identiche. La &Glide; 2.2 è stata portata in Linux nell'Aprile 1997. La conversione della &Glide; 2.3.1 è stata fatta nel Giugno 1997. Entrambe prive di una ottimizzazione chiave per l'impostazione dei triangoli, che sarà inclusa nella release &GlVer; della Linux &Glide;. Le conversioni precedenti non sono state rese disponibili pubblicamente e sono state usate solo per il beta test. <sect1>Dove trovo informazioni sulla &Glide;? Ci sono esaurienti informazioni disponibili da &c3Dfx;. Si può scaricarle dalla loro home page a <htmlurl url="http://www.3dfx.com/software/download_glide.html" name="www.3dfx.com/software/download_glide.html">. Sono gratuite, presumendo che tu abbia comprato una scheda basata sull'hardware &c3Dfx;. Per favore si leggano il regolamento di licenza. Come inizio, si può cercare qualcosa dei seguenti testi: <itemize> <item>Glide Release Notes <item>Glide Programming Guide <item>Glide Reference Manual <item>Glide Porting Guide <item>TexUs Texture Utility Software <item>ATB Release Notes <item>Installing and Using the Obsidian </itemize> Sono disponibili come documenti Microsoft Word, e fanno parte della distribuzione Glide per Windows, cioè del file d'archivio autoscompattante. Per scaricarli separatamente dovrebbe essere disponibile la copia postscript a <htmlurl url="http://www.3dfx.com/software/download_glide.html" name="www.3dfx.com">. Nota che il numero della release non è sempre sintonizzato con quello della &Glide;. <sect1>Dove trovare alcuni demo per &Glide;? Si possono trovare i sorgenti di demo per &Glide; all'interno della distribuzione (i programmi di test) e alla home page della &c3Dfx;. Il problema con quest'ultimi è che alcuni richiedono ATB. Per portare questi demo sotto Linux, dev'essere completamente riscritto la gestione degli eventi. Inotre, possono essere utili alcuni dei sorgenti delle demo per &OGL; che accompagnano Mesa e GLUT. Anche se l'API della &Glide; è diverso dall'API &OGL;, entrambi mirano alla stessa hardware rendering pipeline. <sect>FAQ: &Glide; e SVGA? Non si dovrebbero avere problemi a lanciare le applicazioni basate sulla &Glide; utilizzando la modalità VGA sia a schermo singolo sia a schermo doppio. Potrebbe essere una buona idea utilizzare una risoluzione di 640x480 anche in modalita SVGA, se si sta utilizzando una configurazione a schermo singolo. <sect>FAQ: &Glide; e XFree86? <sect1>Funziona con XFree86? Sostanzialmente, l'hardware &VooDoo; non si interessa di X. L'X server inoltre non noterà che il segnale video generato dall'hardware VGA non giunge al monitor nella configurazione a schermo singolo. Se la propria applicazione non è stata scritta facendo attenzione all'X, il passaggio della &Glide; alla modalità a schermo intero può causare dei problemi (vedi la sezione Risoluzione dei Problemi). Se non interessa il sovraccarico di lavoro che comporta scrivere un'applicazione sotto X11, si potrebbe usare la console in modalità SVGA. Riassumendo: sì, funziona sotto XFree86, ma no, non è cooperante se non si scrivono le applicazioni accortamente. <sect1>Funziona solo a schermo intero? Vedi sopra. L'hardware &VooDoo; non è conscio di un ambiente a finestre, e nemmeno lo è la Linux &Glide;. <sect1>Cosa mi dici sulla GLX per XFree86? Ci sono un paio di problemi. L'hardware &VooDoo; attualmente supportato e l'attuale revisione della Linux &Glide; funzionano solamente a schermo intero, e non sono predisposte per condividere un framebuffer (buffer video, memoria video) con un ambiente a finestre. Così GLX o qualsiasi altra integrazione con l'X11 non è ancora possibile. Il &VooRush; potrebbe essere capace di cooperare con XFree86 (dato che la parte SVGA della scheda funziona con il server SVGA di XFree86), ma non è ancora supportato dalla Linux &Glide;, così come non è ancora supportato dai server S3 o dagli altri server XFree86. Inoltre GLX è legato a &OGL; o, nel caso di Linux, a &Mesa;. Il gruppo di XFree86 attualmente sta lavorando per integrare Mesa con i loro X server. GLX è in fase beta, XFree86 3.3 ha qualche "aggancio" per GLX. Si veda la pagina su GLX di Steve Parker a <htmlurl url="http://www.cs.utah.edu/~sparker/xfree86-3d/" name="www.cs.utah.edu/~sparker/xfree86-3d/"> per le informazioni più recenti. Attualmente &Mesa; usa ancora la sua emulazione GLX con Linux. <sect>FAQ: &Glide; versus &OGL;/&Mesa;? <sect1>Glide è OpenGL? No, &Glide; è un API proprietaria di &c3Dfx; con alcune caratteristiche specifiche per il &VooDoo; e il &VooRush;. Una OpenGL per &c3Dfx; è in preparazione (vedi sotto). Alcune caratteristiche della Glide potrebbero richiedere le EXTensioni a OpenGL, alcune delle quali si trovano già in altre implementazioni (a.es. le texture paletizzate). La cosa più simile all'&OGL; accelerato dall'hardware per Linux che si può attualmente trovare è &Mesa; di Brian Paul assieme al driver &VooMesa; di David Bucciarelli (vedi sotto). <sect1>Mesa funziona con &c3Dfx;? Dalla release 2.3 Beta3, Mesa funziona con la Linux &Glide; 2.2, similmente a Mesa con &Glide; per DOS/Windows. Ci sono patch Mesa 2.3b3 per la Linux &Glide; 2.3.1. Le seguenti versioni di Mesa funzioneranno con la Linux &Glide; &GlVer;; fin tanto che l'API non cambierà, dovrebbero essere sufficienti le patch Mesa 2.3b3. La distribuzione &Glide; non fa parte della distribuzione Mesa. Potrebbe essere necessario scaricare l'archivio della libreria Mesa da <htmlurl url="ftp://iris.ssec.wisc.edu/" name="l sito FTP iris.ssec.wisc.edu">. <sect1>Dove ottengo altre informazioni su OpenGL? Si usi la porta di accesso alle info su &OGL; di Mark Kilgard a <htmlurl url="http://reality.sgi.com/mjk_asd/opengl-links.html" name="reality.sgi.com/mjk_asd/opengl-links.html">, e si proceda da là. <sect1>Dove ottengo informazioni su &Mesa;? La home page di &Mesa; è <htmlurl url="http://www.ssec.wisc.edu/~brianp/Mesa.html" name="www.ssec.wisc.edu/~brianp/Mesa.html">. C'è un archivio della mailing list di Mesa a <htmlurl url="http://www.iqm.unicamp.br/mesa/" name="www.iqm.unicamp.br/mesa/">. Questa lista non è dedicata a &c3Dfx; e &Glide;, ma se si è interessati ad usare l'hardware &c3Dfx; per accelerare &Mesa;, è un buon punto di partenza. <sect1>Dove ottengo informazioni su &VooMesa;? Per le ultime informazioni sul driver &VooMesa; mantenuto da David Bucciarelli (<htmlurl url="mailto:tech.hmw@plus.it" name="tech.hmw@plus.it">) si veda la home page a <htmlurl url="http://www-hmw.caribel.pisa.it/fxmesa/index.shtml" name="www-hmw.caribel.pisa.it/fxmesa/">. <sect1>C'è una &OGL; commerciale per Linux e &c3Dfx;? &c3Dfx; ha pubblicamente annunciato un'implementazione di OpenGL per Windows per quest'anno (seconda metà del '97). Non si sa quando questa sarà disponibile anche per Linux. Di OpenGL realizzate da terze parti, sono a conoscenza di tre prodotti: <itemize> <item>MetroLink MetroOpenGL <item>XInside OpenGL <item>Evans & Sutherland OpenGL </itemize> L'ultima viene distribuita da Portable Graphics, ed è una trasposizione pura e semplice della &OGL; reference software implementation, con un kit di linkaggio per una vecchia revisione degli X server di XFree86. Portable Graphics non ha mai promesso un supporto hardware. Per quel che ne so, questo prodotto non è più disponibile. Gli altri due hanno promesso il supporto per gli acceleratori hardware, ma entrambi sono legati ad una trasposizione proprietaria degli X server ed entrambi non supportano alcuna accelerazione 3D, per quel che ne so. <sect1>Cosa mi dici di GLUT? La distribuzione GLUT di Mark Kilgard è un posto molto valido per ottenere applicazioni d'esempio e molti utili programmi. La si trova a <htmlurl url="http://reality.sgi.com/mjk_asd/glut3/glut3.html" name="reality.sgi.com/mjk_asd/glut3/">, e si può prendererla comunque. La release attuale è GLUT 3.4. Comunque, visto che GLUT gestisce il double buffer, finestre, eventi ed altre operazioni intimamente legati all'hardware e al sistema operativo, una Voodoo-GLUT richiede alcune modifiche specifiche. C'è una alpha release disponibile come parte della più recente distribuzione &Mesa; (David Bucciarelli, Henri Fousse). <sect>FAQ: Ma Quake? <sect1>Cosa mi dici della Quake GL? La DLL rilasciata da &c3Dfx; è disponibile solo per Windows. Supporta un sottoinsieme di OpenGL specifico per Quake (Vedi <htmlurl url="http://www.cs.unc.edu/~martin/3dfx.html" name="http://www.cs.unc.edu/~martin/3dfx.html"> per un elenco non ufficiale dei code path supportati. No, questa DLL non è stata portata sotto Linux. No, non c'è alcuna versione di Quake basata sulla Glide, neanche per Windows. Non ho alcuna notizia su una glQuake per Linux. <sect>FAQ: Risoluzione dei problemi <sect1>Questo hardware è stato testato? Si vedano i requisiti hardware scritti prima, c'è un elenco di hardware che è stato provato e che funziona. <sect1>Failed to change I/O privilege? Si deve essere root, o rendere <tt>setuid</tt> la propria applicazione per lanciare un'applicazione basata su &Glide;. A causa del DMA, il driver accede a <tt>/dev/mem</tt>, che non è accessibile in scrittura da alcuno se non da root, per validi motivi. Vedi il README della distribuzione &Glide; per Linux. <sect1>Funziona senza i privilegi di root? Ci sono casi particolari in cui, ovviamente, l'uso di setuid diventa un problema. Attualmente ci sono soluzioni in preparazione, che richiedono cambiamenti all'interno della libreria stessa. <sect1>Le immagini sono distorte (schermo singolo)? Se si sta usando la configurazione analogica passante, il normale schermo SVGA o X11 può apparire considerevolmente male. Si può provare ad utilizzare un miglior cavo di connessione di quello fornito con la scheda acceleratrice (quelli venduti con la Diamond Monster 3D sono solitamente peggiori di quelli distribuiti assieme alla Orchid Righteous 3D), ma fino ad un certo punto è inevitabile che ci sia una perdita di segnale a causa del percorso di trasmissione aggiuntivo. Se l'immagine a pieno schermo 640x480 creata dalla scheda acceleratrice risulta distorta, ciò può indicare un problema hardware reale. Si deve contattare il costruttore della scheda, non &c3Dfx; per i dettagli, dato che la qualità del segnale video non ha niente a che fare con l'acceleratore - il costruttore della scheda sceglie il RAMDAC, i driver d'uscita e gli altri componenti responsabili. <sect1>L'ultimo frame è ancora lì (schermo singolo o doppio)? Si è terminata la propria applicazione con Ctrl-C o non è terminata correttamente. La scheda acceleratrice fornirà all'infinito l'attuale contenuto del framebuffer come segnale video finché non le verrà detto altrimenti. <sect1>Si attiva il powersave (schermo doppio)? Quando l'applicazione termina nella configurazione a due schermi, la scheda acceleratrice non fornisce più alcun segnale video. Perciò il powersave si attiva ogni volta. Per evitarlo, si usi <code> setenv SST_DUALSCREEN 1 </code> <sect1>La mia macchina sembra stallare (X11, schermo singolo)? Se stai utilizzando X quando lanci una applicazione &Glide;, probabilmente si è mosso il mouse fuori dalla finestra e gli input della tastiera non raggiungono più l'applicazione. Se l'applicazione è progettata per funzionare concorrentemente con X11, si potrebbe o ingrandire la finestra a pieno schermo o usare le funzioni <tt>XGrabPointer</tt> e <tt>XGrabServer</tt> per reindirizzare tutti gli input all'applicazione mentre l'X server non può accedere al monitor. Si noti che il catturare tutti gli input con <tt>XGrabPointer</tt> e <tt>XGrabServer</tt> non qualifica l'applicazione come well-behaved (ovvero che si comporta bene con X), e che il tuo programma può bloccare l'intero sistema. Se si ha questo problema senza utilizzare X, ci si assicuri che non ci siano conflitti hardware (vedi sotto). <sect1>La mia macchina stalla (schermo singolo o doppio)? Se il sistema non risponde ad alcun input (si stanno usando due monitor e ci si accorge della perdita di fuoco (focus), si potrebbe essere in presenza di un conflitto hardware più o meno subdolo. Si veda la sezione Risoluzione dei problemi all'installazione per i dettagli. Se non c'è alcun ovvio conflitto di indirizzi, ci possono essere ancora altri problemi (v. sotto). Se si sta scrivendo del proprio codice, la ragione più comune di stallo è che non si è fatto lo snap dei vertici. Vedi la sezione sullo snapping nella documentazione della &Glide;. <sect1>La mia macchina stalla (uso una scheda VGA S3)? È possibile che ci sia un problema di sovrapposizione di regioni di memoria tipico delle S3. Ci sono alcune informazioni ed una patch al problema nominato S3 nel sito web della &c3Dfx;, ma queste si applicano solo a Windows. Da come l'ho capito, la causa del problema è che certe schede S3 (le più vecchie revisioni della Diamond Stealth S3 968) riservano piu spazio di memoria di quello che effettivamente usano, così la &VooDoo; deve essere mappata in una differente locazione. Comunque, questo non è stato riportato come un probblema sotto Linux, e può essere specifico di Windows. <sect1>Nessun conflitto di indirizzi, ma stalla comunque? Se si sta usando una scheda madre con un supporto PCI non-standard o incompleto, si può provare a mischiare un po' le schede. Sto usando un ASUS TP4XE che ha il fatidico "Media Slot" modificato, a.es lo slot4 PCI ha un connettore addizionale per le schede composite SCSI/Sound prodotte dalla ASUS, ed ho avuto grossi problemi quando ho installato una Diamond Monster 3D in quello slot. Il sistema ha funzionato senza problemi quando ho messo la scheda in uno degli slot regolari. <sect1>Compile/link error: grSstWinOpen()? (Errore di compilazione/linkaggio: grSstWinOpen()?) Dato che la Linux &Glide; sarà la versione &GlVer;, questo errore non dovrebbe verificarsi. Questa funzione non era disponibile nella &Glide; e quindi anche nella Linux &Glide; 2.2; le successive non sono mai state rese pubbliche. <sect1>Compile/link error: grSstOpen()? (Errore di compilazione/linkaggio: grSstOpen()?) Il sorgente della propria applicazione è basato sulla &Glide; 2.2 e questa funzione è stata eliminata nella &Glide; 2.3. Non essendo più disponibile non può essere usata con la Linux &Glide; &GlVer;. Al suo posto si usi la funzione <tt>grSstWinOpen</tt>. Dato che l'integrazione della Linux &Glide; con Mesa era basata originariamente sulla &Glide; 2.2, le versioni precedenti di Mesa possono produrre errori in fase di compilazione. La release Mesa-2.3b3 è stata aggiornata per essere usata con la Linux &Glide; 2.3.1; ci si assicuri di avere sia la distribuzione che l'aggiornamento, o preferibilmente una nuova revisione di Mesa. <sect1>Cannot open shared object file? (Impossibile aprire il file oggetto condiviso?) <code> test25: error in loading shared libraries libglide2x.so: cannot open shared object file: No such file or directory </code> Se, per una qualche ragione, si ha ancora un file binario compilato per una versione differente della Linux &Glide; o se c'è un'inconsistenza nell'impostazione del proprio <tt>ldconfig</tt>, il programma non troverà la libreria condivisa. Si controlli il nome (a.es. <tt>libglide2x.so</tt>) ed ci si assicuri di usare le opzioni corrette quando si compila e linka - a.es. <tt>-lglide</tt> potrebbe non funzionare con l'installazione di default. Si noti che il nome delle revisioni della Linux &Glide; segue la convenzione usata nella distribuzione &c3Dfx; Windows, non la convenzione classica di Linux. <sect1>Problemi di compilazione con Mesa Ci si assicuri di settare <tt>USE_GLIDE_FULLSCREEN</tt> in <tt>fxmesa.h</tt>. Si controlli che le opzioni del linker (a.es. <tt>-lglide</tt>) corrispondano al nome della libreria Linux &Glide; installata (a.es. <tt>-lglide2x</tt> invece). Ci si assicuri di usare gli aggiornamenti alla release Mesa-2.3b3 o seguenti, dato che tutte le release Mesa fino alla 2.3b3 sono basate sulla Linux &Glide; 2.2. Vedi sopra. <sect1>Mesa funziona, ma non accede alla scheda? Ci si assicuri di aver ricompilato tutte le librerie (compresi i toolkit che i programmi dimostrativi usano - si ricorda che GLUT non supporta ancora il &VooDoo;) e di aver rimosso le vecchie librerie, si lanci <tt>ldconfig</tt> e/o si imposti il proprio <tt>LD_LIBRARY_PATH</tt> correttamente. &Mesa; supporta più driver in parallelo (puoi usare X11 SHM, off screen rendering e &VooMesa; in contemporanea), e si potrebbe dover creare e cambiare contesto esplicitamente (si veda la funzione <tt>MakeCurrent</tt>) se il &VooDoo; non è la scelta predefinita. </article>