2. Tecnologia degli Acceleratori Grafici

2.1 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 OpenGL.

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 Graphics (tm) e Voodoo Rush (tm), 3Dfx, ha deciso di supportare l'uso delle schede basate sul Voodoo Graphics (tm) con Linux. Ciò che si prefigge questa documentazione è di descrivere il supporto attualmente disponibile.

2.2 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 3Dfx basate sul Voodoo Graphics (tm) 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.

2.3 Limiti di Prestazioni

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.

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.

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.

2.4 Caratteristiche dell'Accelerazione Hardware

Le operazioni di rendering solitamente supportate dagli acceleratori hardware che si rispettino sono:

• Texture mapping con correzione prospettica
• Alpha-blending, Nebbia
• Anti-aliasing
• Filtering bi-lineare delle texture
• Livello di dettaglio (LOD) MIP mapping
• Correzione a livello sub-pixel
• Ombreggiatura Gouraud basata sui poligoni e modulazione delle texture
• Double buffering
• Buffering di profondità, stencil buffer

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.

2.5 Cenni sull'Architettura Voodoo Graphics (tm)

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 Graphics (tm) 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 Graphics (tm) può usare due TMU (unità di gestione delle texture o texelfx), ed infine, due Voodoo Graphics (tm) 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.

Hosting by: hurra.com
Generated: 2007-01-26 17:56:13