[Thread Ufficiale] 3dfx Voodoo & Powered by ♥ 3dfx

[shodan]

Originariamente inviato da mikepedo

@ shodan
Proverò il tuo bench, il problema è che non ho attualmente il pc per farlo... adesso vedo cmq...

Riguardo l'HSR, butto li una idea non so se è fattibile: tutti i triangoli nascosti, e quindi scartati dalla cpu, li lasciamo in una cache apposita nella ram di sistema.
Nel solo caso in cui la scheda video rileva una texture con canale alpha diverso da 255 tale da rendere un triangolo trasparente, si richiamano il/i triangolo/i con coordinate xy coerenti con quello trasparente e si invia/inviano alla scheda per il rendering... Non so se è fattibile fare un simile controllo.

Mmm... l'approccio può essere interessante, ma ci vedo due problemi potenziali:

1) la scheda, mentre sta applicando la texture trasparente, dovrebbe essere in grado non solo di applicare la texture correttamente, ma anche di "avvisare" in qualche modo il driver (magari tramite un'eccezione, un IRQ o un valore contenuto in un registro) che la texture ha un canale alpha diverso da 255. Probabilmente (anzi, quasi sicuramente) la cosa è fattibile ma, non avendo mai programmato i registri e l'hardware del VSA100, non posso esserne sicuro.

2) la procedura con cui il chip, una volta rilevata una texture trasparente, passa al driver (e quindi alla CPU) i dati necessari per riprendere il controllo della situazione dovrebbe essere il più efficiente possibile, altrimenti il gioco non vale la candela. E qui ci si scontra con i limiti del bus AGP, che in upload ha una banda risicata (266 MB/S) e con la difficoltà di rendere efficiente un trasferimento dati che va in direzione opposta rispetto a quanto avviene normalmente su quel bus (in genere i dati vanno dalla CPU alla GPU; in questo caso, invece, la GPU dovrebbe comunicare col sistema).

Ovviamente questo non vuol dire a priori che l'appoccio da te suggerito sia irrealizzabile; solo che, nella grande maggioranza dei casi, il bus AGP non si è rivalto una buon scelta per quelle applicazioni che richiedevano una comunicazione bidirezionale (il bus PCI-E è perfettamente adatto, invece).

Tieni presente, inoltre, che tutti i context-swith necessari potrebbero anche rivelarsi tanto pesanti da annullare qualunque vantaggio teorico. E' per questo che, In generale, nella grafica 3D si cerca sempre di eseguire i lavori in modalità batch: cioè "sparare" i comandi nel minor tempo possibile e, una volta fatto questo, non tornare più sugli stessi dati.

Ciao.

[sanford]

NUOVO DRIVER OPENGL PER VOODOO 3/4/5 BY GERI...


TitaniumDFX is my new opengl driver for 3dfx cards. It is a full opengl implementation, coded by myself (ICD). Dont confuse with other projects with alike names.

Every 3dfx card is compatible with it starting from Voodoo3.

facts:
-TitaniumDFX needs stronger CPU. Some 3dfx features will be not usable from the driver.
-TitaniumDFX's game compatibility with the great old opengl games is mutch lower than other 3dfx card opengl drivers, it is probably much slower than them. TitaniumDFX i focused to run tons of small freeware and shareware opengl games of todays, istead of running the old AAA games.
-OpenGL version number is 1.3, and i am not plan to expand it currently.
-ALL Donations are welcome.
SERIOUS
, becouse of the huge time what a full opengl implementation needs to be created. Paypal accepted, can be accesed on http://legendgrafix.tk
-TitaniumDFX is freeware.

------------------------------
DOWNLOAD THE FIRST RELEASE
--------------------------------
Download the first release of TitaniumDFX here:
http://voodoomage.uw.hu/TitaniumDFX_Voodoo_3-4-5_R1.rar
(you may use download manager)

! ! ! Read readme.txt before you do anything ! ! !
this version is based on latest SFFT driver, the opengl driver is changed to TitaniumDFX in the package of course.
I hope i produced the inf file correctly for this release.

games tested and running with this one:
Quake3 (opengl mode)
Jedi Academy (opengl mode)
Warcraft 3 (opengl mode)
Quake2 (opengl mode)
Half Life (opengl mode)
Xmoto (opengl mode)
Tuxracer (opengl mode)
GLExcess (opengl mode)
Return To Castle Wolfenstein (opengl mode)
Call of Duty (opengl mode, missing weapon)
American McGee's Alice (opengl mode)

[Max_R]

Stò facendo da tester

[sanford]

Originariamente inviato da Max_R

Stò facendo da tester

E come minimo posterai screenshots e impressioni dal vivo, dico bene?

[mikepedo]

Originariamente inviato da shodan

Mmm... l'approccio può essere interessante, ma ci vedo due problemi potenziali:

1) la scheda, mentre sta applicando la texture trasparente, dovrebbe essere in grado non solo di applicare la texture correttamente, ma anche di "avvisare" in qualche modo il driver (magari tramite un'eccezione, un IRQ o un valore contenuto in un registro) che la texture ha un canale alpha diverso da 255. Probabilmente (anzi, quasi sicuramente) la cosa è fattibile ma, non avendo mai programmato i registri e l'hardware del VSA100, non posso esserne sicuro.

2) la procedura con cui il chip, una volta rilevata una texture trasparente, passa al driver (e quindi alla CPU) i dati necessari per riprendere il controllo della situazione dovrebbe essere il più efficiente possibile, altrimenti il gioco non vale la candela. E qui ci si scontra con i limiti del bus AGP, che in upload ha una banda risicata (266 MB/S) e con la difficoltà di rendere efficiente un trasferimento dati che va in direzione opposta rispetto a quanto avviene normalmente su quel bus (in genere i dati vanno dalla CPU alla GPU; in questo caso, invece, la GPU dovrebbe comunicare col sistema).

Ovviamente questo non vuol dire a priori che l'appoccio da te suggerito sia irrealizzabile; solo che, nella grande maggioranza dei casi, il bus AGP non si è rivalto una buon scelta per quelle applicazioni che richiedevano una comunicazione bidirezionale (il bus PCI-E è perfettamente adatto, invece).

Tieni presente, inoltre, che tutti i context-swith necessari potrebbero anche rivelarsi tanto pesanti da annullare qualunque vantaggio teorico. E' per questo che, In generale, nella grafica 3D si cerca sempre di eseguire i lavori in modalità batch: cioè "sparare" i comandi nel minor tempo possibile e, una volta fatto questo, non tornare più sugli stessi dati.

Ciao.

Sarebbe cmq da provare per vederne l'efficienza

[Kyrandia]

i giochi sono sempre gli stessi..dove gia vanno bene i drivers attuali..ricavare 5 fps in piu serve a poco..in realtà servirebbero giochi nuovi ..magari in glide..ma è cosa ancora piu difficile

[sanford]

Originariamente inviato da Kyrandia

i giochi sono sempre gli stessi..dove gia vanno bene i drivers attuali..ricavare 5 fps in piu serve a poco..

Non sono d'accordo, avere più velocità e HSR permetterebbe da una parte di sfruttare hardware meno potente per godere comunque di tutti gli effetti attivati e dall'altra di giocare a risoluzioni maggiori, nonché di implementare magari l'emulazione di qualche effetto senza gravare eccessivamente sulla cpu...tutto imho, ovviamente.

[mikepedo]

Originariamente inviato da sanford

Non sono d'accordo, avere più velocità e HSR permetterebbe da una parte di sfruttare hardware meno potente per godere comunque di tutti gli effetti attivati e dall'altra di giocare a risoluzioni maggiori, nonché di implementare magari l'emulazione di qualche effetto senza gravare eccessivamente sulla cpu...tutto imho, ovviamente.

Le schede 3dfx funzionano alla grande con tutti i giochi Glide.
Una ottimizzazione dei driver quindi deve essere fatta andando incontro ai giochi più nuovi dove queste schede soffrono, e magari sfruttare il potente hw dei giorni nostri per sgravare la scheda video (l'hsr può essere un'ottima soluzione a patto di avere una cpu molto potente).
Anche io, imho...

[sanford]

Originariamente inviato da mikepedo

Le schede 3dfx funzionano alla grande con tutti i giochi Glide.
Una ottimizzazione dei driver quindi deve essere fatta andando incontro ai giochi più nuovi dove queste schede soffrono, e magari sfruttare il potente hw dei giorni nostri per sgravare la scheda video (l'hsr può essere un'ottima soluzione a patto di avere una cpu molto potente).
Anche io, imho...

Parlavo di attivare tutti gli effetti e converrai con me che, seppur in Glide, un AA4X su P3 1000 è duro da mandare avanti, quindi la velocità serve sempre, meglio averla che non averla...ovviamente c'è da lavorare più in D3D che in Glide/OpenGL e quindi più velocità si riesce a spremere e meglio è, fermo restando che alcuni effetti andranno per forza emulati o esclusi, dato che l'hardware ha i suoi anni e i suoi limiti.

[goriath]

Sono d'accordo. Non tanto per gli ultimissimi titoli (di cui chissene, IMHO naturalmente) ma per quelli di 3 o 4 anni post 2001, dove i limiti hardware erano presenti, ma meno pesanti...ma soprattutto erano (e sono) presenti quelli software.

Ora l' HSR non è la MEGA panacea ovviamente, ma qualcosa di nuovo che concretamente può spremere quel boost prestazionale in più, fermo restando il discorso di shodan e sanford ovviamente. Inoltre dal punto di vista tecnico credo che costituirebbe una (se non la prima) delle novità più interessanti mai introdotte nello sviluppo amatoriale dei driver 3dfx.

[shodan]

Originariamente inviato da sanford

Non sono d'accordo, avere più velocità e HSR permetterebbe da una parte di sfruttare hardware meno potente per godere comunque di tutti gli effetti attivati e dall'altra di giocare a risoluzioni maggiori, nonché di implementare magari l'emulazione di qualche effetto senza gravare eccessivamente sulla cpu...tutto imho, ovviamente.

Ciao,
in realtà l'implementazione di un HSR software appesantirebbe il lavoro della CPU, e non viceversa... potrebbe però alleggerire un po' il limite dato dall fillrate della Voodoo5 (667 Mp/Mt al secondo).

Riguardo alle features implementabili su CPU, anche qui non c'è molto da fare: resterizzare pixel è, per il processore centrale, un lavoro pesantissimo. Per fare un esempio: nel 1996, il boss della 3dfx diceva che per far girare in modalità software un gioco così come poteva farlo girare il chip SST1 (Voodoo1), sarebbe servito un Pentium a 4 Ghz (!!!). Non è realistico, quindi, pensare che la CPU di sistema possa aiutare più di tanto la scheda grafica.

L'unico campo dove la CPU può dire la sua è nel calcolo e nella manipolazione dei vertici e, quindi, si può utilizzare per emulare il T&L e i vertex shader per quei giochi che vogliono per forza tali features; se non vado errato, 3danalyzer fa proprio questo (tra le altre cose).

Ciao.

[sanford]

Originariamente inviato da shodan

L'unico campo dove la CPU può dire la sua è nel calcolo e nella manipolazione dei vertici e, quindi, si può utilizzare per emulare il T&L e i vertex shader per quei giochi che vogliono per forza tali features; se non vado errato, 3danalyzer fa proprio questo (tra le altre cose).

Ciao.

E' esatto quello che dici...il punto è proprio integrare nei drivers le funzionalità di 3DAnalyze ma con codice ottimizzato in assembler che, per quanto poco, dovrebbe fare una differenza ben visibile a occhio nudo in quanto a velocità pura.

[mikepedo]

Originariamente inviato da sanford

Parlavo di attivare tutti gli effetti e converrai con me che, seppur in Glide, un AA4X su P3 1000 è duro da mandare avanti, quindi la velocità serve sempre, meglio averla che non averla...ovviamente c'è da lavorare più in D3D che in Glide/OpenGL e quindi più velocità si riesce a spremere e meglio è, fermo restando che alcuni effetti andranno per forza emulati o esclusi, dato che l'hardware ha i suoi anni e i suoi limiti.

Non fare confusione: attivare il FSAA significa caricare di lavoro la scheda video, la cpu non ne risente.
L'emulazione degli effetti sono fattibili solo ed esclusivamente sulla parte geometrica, cosa che già, di fatto, avviene. Gli effetti di rastering (pixel shader, bump mapping ecc...) non ha minimamanente senso emularli perchè è come bypassare il lavoro della scheda video e quindi "snaturare" la sua funzione. Tanto vale tenere una Trio64 AGP...

Originariamente inviato da goriath

Sono d'accordo. Non tanto per gli ultimissimi titoli (di cui chissene, IMHO naturalmente) ma per quelli di 3 o 4 anni post 2001, dove i limiti hardware erano presenti, ma meno pesanti...ma soprattutto erano (e sono) presenti quelli software.

Ora l' HSR non è la MEGA panacea ovviamente, ma qualcosa di nuovo che concretamente può spremere quel boost prestazionale in più, fermo restando il discorso di shodan e sanford ovviamente. Inoltre dal punto di vista tecnico credo che costituirebbe una (se non la prima) delle novità più interessanti mai introdotte nello sviluppo amatoriale dei driver 3dfx.

Sono d'accordo. Un HSR software, per quanto ben fatto, andrebbe poi a scontrarsi con una miriade di applicazioni e quindi situazioni, e non sempre sarà conveniente usarlo. Ma di certo sarebbe qualcosa di rivoluzionario, superiore anche al Temporal Antialias introdotto con le ultime librerie nelle applicazioni Glide/OpenGL...

Originariamente inviato da shodan

Ciao,
in realtà l'implementazione di un HSR software appesantirebbe il lavoro della CPU, e non viceversa... potrebbe però alleggerire un po' il limite dato dall fillrate della Voodoo5 (667 Mp/Mt al secondo).

Riguardo alle features implementabili su CPU, anche qui non c'è molto da fare: resterizzare pixel è, per il processore centrale, un lavoro pesantissimo. Per fare un esempio: nel 1996, il boss della 3dfx diceva che per far girare in modalità software un gioco così come poteva farlo girare il chip SST1 (Voodoo1), sarebbe servito un Pentium a 4 Ghz (!!!). Non è realistico, quindi, pensare che la CPU di sistema possa aiutare più di tanto la scheda grafica.

L'unico campo dove la CPU può dire la sua è nel calcolo e nella manipolazione dei vertici e, quindi, si può utilizzare per emulare il T&L e i vertex shader per quei giochi che vogliono per forza tali features; se non vado errato, 3danalyzer fa proprio questo (tra le altre cose).

Ciao.

Infatti è quello che ho detto sopra.
3D Analyzer è un programma che serve a "ingannare" l'applicazione, facendole vedere una scheda video con determinate caratteristiche che poi vengono semplicemente bypassate e quindi non eseguite.

[mikepedo]

Originariamente inviato da sanford

E' esatto quello che dici...il punto è proprio integrare nei drivers le funzionalità di 3DAnalyze ma con codice ottimizzato in assembler che, per quanto poco, dovrebbe fare una differenza ben visibile a occhio nudo in quanto a velocità pura.

Si era parlato di integrare queste funzionalità nei driver, ma alla fin fine che gusto ci sarebbe giocare ad un gioco che fa uso intenso dei pixel shaders o bump mapping vari??? La funzione verrebbe completamente bypassata e le textures apparirebbero inguardabili... (vedi acqua 3D Mark 2001 lanciato con 3D Analyzer).
Secondo me bisogna rinunciare all'idea di vedere l'hw 3dfx come qualcosa di "eterno", ma piuttosto ottimizzare il più possibile per migliorare le performances per quegli applicativi che già partono... Ho degli esempi: i vari UT 2003/2004, Unreal2, Half Life2, Painkiller e Painkiller Overdose... Quest'ultimo in particolare è veramente bello graficamente con le schede 3dfx (guardate nel mio profilo youtube al nick mikepedo83) però è pesantissimo. Con Athlon 2.5 Ghz e Voodoo5 6000, a dettagli medi e ris. 1024x768 ottendo fsp da 10 a 30, e la giocabilità ne risente tanto... Magari un gioco come questo, che geometricamente parlando non mi sembra così pesante, trarrebbe un bel vantaggio dall'HSR.

[NAP.]

Mi spieghereste come mai la 3dfx scomparve nonostante le ottime schede video? in prima pagina non c'è scritta la storia dell'azienda

[mikepedo]

@ Shodan:

Per quanto non mi intendo, sono dell'idea che un HSR sofware ben programmato, che magari scarta i triangoli completamente nascosti e quindi senza necessità di eseguire clipping sui triangoli parzialmente nascosti (lasciando quindi un pò di overdraw) possa essere un buon compromesso tra performance CPU e GPU. Il bello è che la scheda video neanche se ne accorge, lei renderizza solo quello che le arriva dalla cpu e questo ridurrebbe drasticamente anche gli accessi di scrittura/lettura allo Z-Buffer e frame-buffer della ram video... In applicazioni con geometria abbastanza semplice il boost sarebbe micidiale, e non è un caso che Quake3 (che ha una geometria semplice) volava con HSR inserito...

[mikepedo]

Originariamente inviato da NAP.

Mi spieghereste come mai la 3dfx scomparve nonostante le ottime schede video? in prima pagina non c'è scritta la storia dell'azienda

Le parole "ottime schede video" erano diventate soggettive dal 1999...

[Max_R]

Originariamente inviato da NAP.

Mi spieghereste come mai la 3dfx scomparve nonostante le ottime schede video? in prima pagina non c'è scritta la storia dell'azienda

Sostanzialmente a causa di ritardi nell'entrata dell'ultima serie (V4/5) nel mercato

[goriath]

Originariamente inviato da mikepedo

Si era parlato di integrare queste funzionalità nei driver, ma alla fin fine che gusto ci sarebbe giocare ad un gioco che fa uso intenso dei pixel shaders o bump mapping vari??? La funzione verrebbe completamente bypassata e le textures apparirebbero inguardabili... (vedi acqua 3D Mark 2001 lanciato con 3D Analyzer).
Secondo me bisogna rinunciare all'idea di vedere l'hw 3dfx come qualcosa di "eterno", ma piuttosto ottimizzare il più possibile per migliorare le performances per quegli applicativi che già partono... Ho degli esempi: i vari UT 2003/2004, Unreal2, Half Life2, Painkiller e Painkiller Overdose... Quest'ultimo in particolare è veramente bello graficamente con le schede 3dfx (guardate nel mio profilo youtube al nick mikepedo83) però è pesantissimo. Con Athlon 2.5 Ghz e Voodoo5 6000, a dettagli medi e ris. 1024x768 ottendo fsp da 10 a 30, e la giocabilità ne risente tanto... Magari un gioco come questo, che geometricamente parlando non mi sembra così pesante, trarrebbe un bel vantaggio dall'HSR.

Mi hai tolto le parole di bocca.

Originariamente inviato da mikepedo

Le parole "ottime schede video" erano diventate soggettive dal 1999...

Migliore sintesi mai letta al riguardo...

[shodan]

Originariamente inviato da mikepedo

@ Shodan:

Per quanto non mi intendo, sono dell'idea che un HSR sofware ben programmato, che magari scarta i triangoli completamente nascosti e quindi senza necessità di eseguire clipping sui triangoli parzialmente nascosti (lasciando quindi un pò di overdraw) possa essere un buon compromesso tra performance CPU e GPU. Il bello è che la scheda video neanche se ne accorge, lei renderizza solo quello che le arriva dalla cpu e questo ridurrebbe drasticamente anche gli accessi di scrittura/lettura allo Z-Buffer e frame-buffer della ram video... In applicazioni con geometria abbastanza semplice il boost sarebbe micidiale, e non è un caso che Quake3 (che ha una geometria semplice) volava con HSR inserito...

Ciao,
riguardo all'HSR il punto è proprio capire quali triangoli saranno davvero nascosti: come discutevamo prima, il problema delle texture trasparenti, purtroppo, non è di soluzione immediata.

Per far in modo che la scheda video "non si accorga" del trucco, dovrebbero arrivargli non solo i triangoli con Z minore (più vicini), ma anche quelli con Z maggiore ma che si trovano dietro a triangoli trasparenti.

Ma come può fare la CPU a determinare se un triangolo avrà una texture trasparente _prima_ di applicare la texture stessa e senza campionarla? Qualche post dietro suggerivo di utilizzare il formato texture, dato che una texture in un formato che non supporta l'alpha channel dovrà per forza essere opaca (con i pixel shader questo non sarebbe vero, ma in questo caso non sono un problema).

Ciao.