<!DOCTYPE linuxdoc
               PUBLIC "-//LinuxDoc//DTD LinuxDoc 97//EN"
   [
        <!ENTITY   SGMLT       "SGML-Tools" >
        <!ENTITY   c3Dfx       "3Dfx"                  >
        <!ENTITY   OGL         "OpenGL"                >
        <!ENTITY   Mesa        "Mesa"                  >
        <!ENTITY   Glide       "Glide"                 >
        <!ENTITY   GlVer       "2.4"                   >
        <!ENTITY   TexUs       "TexUS"                 >
        <!ENTITY   VooDoo      "Voodoo Graphics (tm)"  >
        <!ENTITY   VooRush     "Voodoo Rush (tm)"      >
        <!ENTITY   VooMesa     "Mesa Voodoo"           >
   ] >

<!-- sgmltool
       PUBLIC "-//SGML-Tools//DTD SGML-Tools v0.9//EN" -->

<!-- ====================================================================== -->
<!--

    $Id:$

    Questo è il Linux3Dfx.sgml.
    Ricopre tutto ciò che e collegato all'uso delle schede basate sul 3Dfx
    VooDoo con Linux.

    $Log:$

    Commenti: prima stesura resa pubblica.

    Versione 0.1
      Prima versione; usata solo a scopo di correzione tipografica.
    Versione 0.2
      Aggiunta la Flash3D e la Orchid R3D alla lista delle schede funzionanti,
      altre correzioni minori. Aggiunte le FAQ riguardanti grSstWinOpen() e
      quelle riguardanti i demo con ATB. Aggiunti i riconoscimenti ai marchi.
    Versione 0.3
      Aggiunte le dichiarazioni della Quantum3D sul supporto di Linux, le
      descrizioni dei chipset e le schede Obsidian. Aggiunti i cenni
      sull'architettura VooDoo.
    Versione 0.4
      TAXONOMY ufficiale della Obsidian di Ross Q. Smith. Spiegazione di
      setuid di Daryll Strauss. Commenti sulla VooDoo GLUT di David 
      Bucciarelli.
    Versione 0.5
      Aggiornato alla Glide 2.3.1, aggiunta la Intergraph Intense.
    Versione 1.0
      Sistemata la gerarchia delle news.3dfx, aggiunti i riferimenti ai
      gruppi per i bug report, pronta al rilascio.
    Versione 1.01
      Correzioni da parte di Daryll, SST_DUALSCREEN, snapping
      vertices, eliminata la discussione su setuid/device/XAA.
    Versione 1.02
      Aggiunto il P5 ai requisiti. Rimosso il Banshee. Nessun supporto 
      Intergraph. Rivista la sezione FAQ.
    Versione 1.03
      Corretta la stesura, aggiunto il Macintosh. Cambiata la descrizione
      dell'errore grSstOpen - potrebbe essere rimossa completamente.
      Aggiunta la sezione sui problemi di compilazione con Mesa. Aggiunti i
      marchi di fabbrica della documentazione Glide. TexUS. Citata la
      documentazione ATB. Aggiornata all'imminente release 2.4.
                                                       -->
<!-- ====================================================================== -->
<article OPTS="italian">

<title>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
<p>
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. 
<p>
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
<p>
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.
<p>
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/">.
<p>
&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
<p>
<descrip>
<tag>Versione 1.03</tag>Prima versione resa pubblica.
</descrip>

<sect1>Nuove Versioni di Questa Documentazione
<p>
Puoi trovare la versione più aggiornata di questa documentazione presso
<htmlurl url="http://www.gamers.org/dEngine/xf3D/"
name="www.gamers.org/dEngine/xf3D/">.
<p>
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/">.
<p>
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.
<p>
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
<p>
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.
<p>
Prima di mandare bug report o domande, <EM>per favore si legga per intero questo
HOWTO</EM> e <EM>si inviino informazioni dettagliate sul problema</EM>.
<p>
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
<p>
Copyright (C) 1997 Bernd Kreimeier.
<p>
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.
<p>
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. 
<p>
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
<p>
Questa sezione descrive <em>molto</em> 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;. 
<p>
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.
<p>
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)
<p>
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.
<p>
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
<p>
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.
<p>
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
<p>
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
<p>
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.
<p>
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
<p>
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>
<p>
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;
<p>
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.
<p>
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).
<p>
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
<p>
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>
<p>
Le sezioni seguenti trattano ognuno di questi passi in dettaglio.

<sect1>Installare la Scheda
<p>
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&amp;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.
<p>
Dato che &c3Dfx; non sviluppa o vende nessuna scheda direttamente, è inutile
contattarla per qualche problema.

<sect2>Risoluzione dei problemi di installazione hardware
<p>
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.
<p>
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">.
<p>
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
<p>
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
<p>
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
<p>
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
<p>
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.
<p>
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.
<p>
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. 
<p>
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
<p>
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.
<p>
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;
<p>
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.
<p>
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
<p>
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
<p>
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.
<p>
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. 
<p>
Si consulti il README.test per una lista del programmi, e per altri
dettagli. 


<!-- =================================================================== -->
<sect>Risposte Alle Domande Più Frequenti
<p>
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>
<p>
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?
<p>
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?
<p>
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?
<p>
Attualmente sotto Linux è supportata la più recente revisione dei chipset
&c3Dfx; &VooDoo;. I chipset &VooRush; non sono tuttora supportati.

<sect1>Quali schede sono supportate?
<p>
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.
<p>
È 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.
<p>
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>
<p>
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".
                       <p>
                       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.
<p>
Le seguenti schede non sono ancora state testate:
<itemize>
<item>Deltron RealVision Flash 3D
</itemize>
<p>
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>
<p>
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.
<p>
Le schede non basate sui chipset &c3Dfx; (e.g. prodotte da S3, Matrox, 3Dlabs,
Videologic) <em>non</em> funzionano con i driver &c3Dfx; e esulano dagli scopi
di questa documentazione.

<sect1>È supportata la Hercules Stingray 128/3D?
<p>
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.
<p>
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?
<p>
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;?
<p>
&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;?
<p>
Il &VooDoo; è un chipset prodotto dalla &c3Dfx;. Viene usato nelle schede
acceleratrici per PC. Si veda la sezione dell'HOWTO sull'hardware
supportato. 
<p>
C'è un nuovo chipset, il &VooRush;, che attualmente non è supportato sotto
Linux.
<!-- here to the suits:
Nota che il &VooDoo; è ufficialmente chiamato &VooDoo; <em>Graphics</em>. -->

<sect1>Dove posso trovare altre informazioni sul &VooDoo;?
<p>
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;?
<p>
&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;?
<p>
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;.
<p>
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?
<p>
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;.
<p>
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;?
<p>
No. Il sorgente della &Glide; è reso disponibile solo in base ad uno
speciale accordo e un NDA con &c3Dfx;.

<sect1>La Linux &Glide; è supportata?
<p>
Attualmente la Linux &Glide; non è supportata. Essenzialmente, viene fornita
sotto le stesse restrizioni della DLL GLQuake.
<p>
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).
<p>
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;?
<p>
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;.
<p>
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?
<p>
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?
<p>
&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;?
<p>
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;?
<p>
Sì. Dato che per il momento non ci sono altri driver &VooDoo; disponibili
per Linux.

<sect1>Dovrei programmare usando l'API della Glide?
<p>
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;.
<p>
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.
<p>
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?
<p>
La versione della Linux &Glide; che sarà resa pubblica è la &GlVer;, dato
che è la prossima release della &Glide; per DOS/Windows.
<p>
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;?
<p>
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.
<p>
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;?
<p>
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&lowbar;glide.html">. Sono gratuite,
presumendo che tu abbia comprato una scheda basata sull'hardware
&c3Dfx;. Per favore si leggano il regolamento di licenza.
<p>
Come inizio, si può cercare qualcosa dei seguenti testi:
<itemize>
<item><em>Glide Release Notes</em>
<item><em>Glide Programming Guide</em>
<item><em>Glide Reference Manual</em>
<item><em>Glide Porting Guide</em>
<item><em>TexUs Texture Utility Software</em>
<item><em>ATB Release Notes</em>
<item><em>Installing and Using the Obsidian</em>
</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;?
<p>
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.
<p>
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?
<p>
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?
<p>
<sect1>Funziona con XFree86?
<p>
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.
<p>
Riassumendo: sì, funziona sotto XFree86, ma no, non è cooperante se non
si scrivono le applicazioni accortamente.

<sect1>Funziona solo a schermo intero?
<p>
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?
<p>
Ci sono un paio di problemi.
<p>
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.
<p>
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.
<p>
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?
<p>
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).
<p>
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;?
<p>
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.
<p>
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?
<p>
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&lowbar;asd/opengl-links.html">, e si proceda
da là. 

<sect1>Dove ottengo informazioni su &Mesa;?
<p>
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;?
<p>
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;?
<p>
&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.
<p>
Di OpenGL realizzate da terze parti, sono a conoscenza di tre prodotti:
<itemize>
<item>MetroLink MetroOpenGL
<item>XInside OpenGL
<item>Evans &amp; Sutherland OpenGL
</itemize>
<p>
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.
<p>
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?
<p>
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&lowbar;asd/glut3/">, e si può prendererla
comunque. La release attuale è GLUT 3.4.
<p>
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?
<p>
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?
<p>
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?
<p>
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?
<p>
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)?
<p>
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.
<p>
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)?
<p>
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)?
<p>
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)?
<p>
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.
<p>
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. 
<p>
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)?
<p>
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.
<p>
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)?
<p>
È 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?
<p>
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()?
<P>
(Errore di compilazione/linkaggio: grSstWinOpen()?)
<p>
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()?
<P>
(Errore di compilazione/linkaggio: grSstOpen()?)
<p>
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>.
<p>
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?
<P>
(Impossibile aprire il file oggetto condiviso?)
<p>
<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.
<p>
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
<p>
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?
<p>
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>




<!-- ================================================= -->
<!-- end of Linux3Dfx.sgml                             -->
<!--
     Local Variables:
     mode: sgml
     End:                                              -->
<!-- ================================================= -->
