Frame Rates for Half-Life 2

[yossarian]

Originariamente inviato da Pat77
Fonti? Valve ha sempre parlato di 16/32 bit per la Mixed (poi rinominato path nv3x).

Pk77


questa è tratta da un'intervista a Newell da parte di B3D

Mixed Mode, so titled because it utilises a mix of precisions, is a special path created purely for the FX series. The mode uses integer precisions (PS1.3 and 1.4 shaders), partial precision (PS2.0 FP16) and full precision, as well as a other changes. One such change is that vector normalisation is done via cubmaps rather than math in the Pixel Shader, which trades off texture read and writes and memory bandwidth for ALU performance. Under the mixed mode Valve have the following performances:

In realtà di fp32 ce n'era ben poco

questa è parte della risposta di nVIDIA (a proposito delle basse prestazioni delle Fx e del fatto che Newell consigliava di trattarle come chip dx8)

Since we know that obtaining the best pixel shader performance out of GeForce FX GPUs currently requires some specialized work, our developer technology team works very closely with game developers to help them with this. Part of this is understanding that in many cases promoting PS 1.4 (DX8) to PS 2.0 (DX9) provides no image quality benefit. Sometimes this involves converting fp32 shader operations into fp16 shaders in order to obtain the performance benefit of this mode with no image quality degradation. Our goal is to provide our consumers the best experience possible, and that means games must both look and run great.


come si capisce chiaramente, il resto lo fanno i drivers (shader replacement).

questo è il link all'aerticolo

http://www.beyond3d.com/misc/hl2/

[yossarian]

Originariamente inviato da rmarango
A cosa ti riferisci in particolare...:rolleyes:

Ovviamente era una battuta, visto che l'ordine naturale delle cose e' un concetto troppo filosofico per una scheda grafica ;)


non mi risulta che l'ordine naturale delle cose sia qualcosa di trascendente o di talmente elevato da non potersi applicare ad una scheda video. Un gioco programmato in dx9 è naturale che su una vga progettata per lavorare prevalentemente in dx8 dia fps bassi; utilizzare drivers che trasformano un gioco dx9 in uno dx8 facendo credere ad incrementi prestazionali favolosi (ottenuti solo in virtù di operazioni di shader replacement) è andare contro l'ordine naturale.

[yossarian]

Originariamente inviato da rmarango
Non cominciamo con la storia dei fanboy...ti prego !


non ho iniziato io; analizza i tuoi comportamenti (anche nei confronti di Vifani, la cui preparazione e competenza non è da mettere in dubbio) e prova a chiederti come mai ho dato del fanboy a te e non ad altri.
Non è per fare polemica, però se si vuole parlare di tecnica o tecnologia è un conto; se vogliamo star qui a scandire cori da stadio è cosa del tutto diversa.

;)

[rmarango]

Originariamente inviato da yossarian
non ho iniziato io; analizza i tuoi comportamenti (anche nei confronti di Vifani, la cui preparazione e competenza non è da mettere in dubbio) e prova a chiederti come mai ho dato del fanboy a te e non ad altri.
Non è per fare polemica, però se si vuole parlare di tecnica o tecnologia è un conto; se vogliamo star qui a scandire cori da stadio è cosa del tutto diversa.

;)

Qui nessuno ha scandito cori da stadio...mi pare che stai esagerando...datti una calmata...

Vifani ha erroneamente citato una cosa e io l'ho soltato corretto, non esistono gli intoccabili.

E poi io non ho insultato nessuno...pero' se la metti su questo piano ti segnalo al moderatore...

[FreeMan]

http://www.ngi.it/forum/images/ngismiles/boni3.gif

>bYeZ<

[yossarian]

Originariamente inviato da rmarango
Qui nessuno ha scandito cori da stadio...mi pare che stai esagerando...datti una calmata...

Vifani ha erroneamente citato una cosa e io l'ho soltato corretto, non esistono gli intoccabili.

E poi io non ho insultato nessuno...pero' se la metti su questo piano ti segnalo al moderatore...


oddio che paura :sofico:

forse sei tu a doverti dare una calmata e ti consiglio di rileggere tutti i tuoi post; Vifani ha citato qualcosa di cui ha sentito parlare in giro, quindi ha semplicemente riportato una notizia o una voce (se così la si vuol chiamare). Certo che non esistono intoccabili (e ci mancherebbe); però non sta neppure in piedi che l'utilizzo di smilies più o meno allusivi faccia sentire autorizzati a dire ciò che si vuole o ad usare il tono che più ci aggrada con chiunque (salvo poi celarsi dietro al fatto che .........tanto era una battuta).
Non ho parlato io per primo di filosofi improvvisati (anche se hai editato ho fatto in tempo a leggere) e neppure ho iniziato io a fare battute sul tuo conto; anzi, a dire la verità, fino a che non hai iniziato a quotarmi a ripetizione (citando una riga per volta................strana procedura :rolleyes: ) non ti stavo calcolando proprio. Già che ci siamo, in tutto quello che ho scritto, quante inesattezze hai trovato? In questo modo potresti sicuramente apportare un contributo maggiore alla conversazione che non facendo battute di dubbio gusto

[FreeMan]

http://netace.us/custom/images/stop-sign.jpg

e non lo dico + ;)

>bYeZ<

[R@nda]

Ecco appunto,ne approfitto e lo richiedo:D

E' possibile che la Mixed non sia stata implementata alla fine perchè poteva dare difetti e artefatti?
C'è una possibilità che venga implementata con una patch se non ci sono problemi?
Infondo se la sua rimozione in caso di assenza di problemi fosse avvenuta per motivi di marketing,ormai il gioco è uscito,Ati ha stravenduto le sk video con i coupon e Hl2 ce l'hanno tantissimi.

(E poi Yoss non ci hai detto che lavoro fai!:) )

[rmarango]

Originariamente inviato da yossarian

Già che ci siamo, in tutto quello che ho scritto, quante inesattezze hai trovato? In questo modo potresti sicuramente apportare un contributo maggiore alla conversazione che non facendo battute di dubbio gusto

Cominciamo con il dire che hai parlato di precisioni infime in dx9, quando sappiamo che le nv3x lavorano in piena precisione contro i 24 bit delle Ati.

Poi il discorso dell'ordine naturale sinceramente l'ho capito solo dopo il tuo ultimo post chiarificatore...e penso che anche altri abbiano frainteso.

Ecco il perche' della battuta...comunque take it easy !

[FreeMan]

:mad:

se volete continuate in pvt.. altrimenti mi toccherà fare il cattivo

STOP! :muro:

>bYeZ<

[fek]

Originariamente inviato da R@nda
E' possibile che la Mixed non sia stata implementata alla fine perchè poteva dare difetti e artefatti?
C'è una possibilità che venga implementata con una patch se non ci sono problemi?


Credo che il motivo piu' plausibile sia il fatto che non abbiano voluto perdere tempo nello scrivere e mantenere un code path mixed, perche' a loro avviso il costo non era giustificato dal guadagno (in termini di prestazioni e qualita' immagino).

Originariamente inviato da rmarango
Cominciamo con il dire che hai parlato di precisioni infime in dx9, quando sappiamo che le nv3x lavorano in piena precisione contro i 24 bit delle Ati.


Il fatto che teoricamente l'NV3X possa lavorare a 32 bit non significa che all'atto pratico sia una strada percorribile.
Di fatto non lo e', ed affermare che le prestazioni dell'NV3X in un gioco DX9 siano infime non e' lontano dalla realta'.

[rmarango]

Originariamente inviato da fek

Il fatto che teoricamente l'NV3X possa lavorare a 32 bit non significa che all'atto pratico sia una strada percorribile.
Di fatto non lo e', ed affermare che le prestazioni dell'NV3X in un gioco DX9 siano infime non e' lontano dalla realta'.

Io non ho parlato di prestazioni, ma di precisione...a me risultava che in dx9 le nvidia lavorano a 32bit mentre le ati a 24 bit (con un margine del 25% di vantaggio in prestazioni circa solo per questa differenza in bit)

[Pat77]

Originariamente inviato da yossarian
questa è tratta da un'intervista a Newell da parte di B3D

Mixed Mode, so titled because it utilises a mix of precisions, is a special path created purely for the FX series. The mode uses integer precisions (PS1.3 and 1.4 shaders), partial precision (PS2.0 FP16) and full precision, as well as a other changes. One such change is that vector normalisation is done via cubmaps rather than math in the Pixel Shader, which trades off texture read and writes and memory bandwidth for ALU performance. Under the mixed mode Valve have the following performances:

In realtà di fp32 ce n'era ben poco

questa è parte della risposta di nVIDIA (a proposito delle basse prestazioni delle Fx e del fatto che Newell consigliava di trattarle come chip dx8)

Since we know that obtaining the best pixel shader performance out of GeForce FX GPUs currently requires some specialized work, our developer technology team works very closely with game developers to help them with this. Part of this is understanding that in many cases promoting PS 1.4 (DX8) to PS 2.0 (DX9) provides no image quality benefit. Sometimes this involves converting fp32 shader operations into fp16 shaders in order to obtain the performance benefit of this mode with no image quality degradation. Our goal is to provide our consumers the best experience possible, and that means games must both look and run great.


come si capisce chiaramente, il resto lo fanno i drivers (shader replacement).

questo è il link all'aerticolo

http://www.beyond3d.com/misc/hl2/

E' lo stesso articolo che prendevo da riverimento (con i bench a 50 fps per le fx).
Sostanzialmente si dice che sono un mix tra ps 1.1/1.4, 16bit e 32bit ps 2.0. Ma quanto utilizzo di 32/16 o ps1.1 ci sia in questa modalità non c'è dato saperlo.

Pk77

[leoneazzurro]

x Rmarango

No, le FX POSSONO lavorare in full precision a 32 bit, ma non è detto che "Direct X 9 con PS 2.0" su FX significhi 32 bit. In Direct X 9 esiste anche la modalità Partial Precision a 16 bit, che dal punto di vista pratico sulla serie 5X00 è quella più usata ed utilizzabile. ATI lavora sui PS 2.0 sempre e solo a 24 bit. E diciamo anche che spesso alcuni giochi "DX9" non usano sempre i PS 2.0

[rmarango]

Originariamente inviato da leoneazzurro
x Rmarango

No, le FX POSSONO lavorare in full precision a 32 bit, ma non è detto che "Direct X 9 con PS 2.0" su FX significhi 32 bit. In Direct X 9 esiste anche la modalità Partial Precision a 16 bit. ATI lavora sui PS 2.0 sempre e solo a 24 bit. E diciamo anche che spesso alcuni giochi "DX9" non usano sempre i PS 2.0

Infatti e' proprio come hai detto...la partial precision era stata implementata con il mixed mode, il calo prestazionale e' imputabile IMHO sopratutto al fatto che lavorano a 32 bit.

[leoneazzurro]

Non c'era solo Partial precision, diciamo che invece di utilizzare i PS 2.0 spesso e volentieri si utilizzavano i PS 1.X, ricorrendo ai PS 2.0 solo quando non se ne poteva fare a meno. Anche usando i PS 2.0 in PP le prestazioni aumentano, ma non raddoppiano, anzi.
Esempio di gioco che usa PS 2.0 per fare certe cose e PS 1.X per altre: Far Cry.

[R@nda]

Esempio di gioco che usa PS 2.0 per fare certe cose e PS 1.X per altre: Far Cry.

Appunto...esterni fluidi da paura (Ps1.X),interni da tragedia!(Ps2.0)

[yossarian]

Originariamente inviato da R@nda
Ecco appunto,ne approfitto e lo richiedo:D

E' possibile che la Mixed non sia stata implementata alla fine perchè poteva dare difetti e artefatti?
C'è una possibilità che venga implementata con una patch se non ci sono problemi?
Infondo se la sua rimozione in caso di assenza di problemi fosse avvenuta per motivi di marketing,ormai il gioco è uscito,Ati ha stravenduto le sk video con i coupon e Hl2 ce l'hanno tantissimi.



ti ha risposto fek; il gioco non valeva la candela; cercare di forzare l'utilizzo parziale di fp16 (con il solo NV35, tra l'altro) non portava a grandi benefici dal punto di vista della IQ e faceva, comunque, degradare le prestazioni rispetto ai ps1.x; inoltre costituiva un ulteriore carico di lavoro per i programmatori. Alla fine hanno deciso di abbandonare l'impresa

Originariamente inviato da R@nda

(E poi Yoss non ci hai detto che lavoro fai!:) )

prima ci sei andato mooooolto vicino.



;)

[rmarango]

Originariamente inviato da leoneazzurro
Non c'era solo Partial precision, diciamo che invece di utilizzare i PS 2.0 spesso e volentieri si utilizzavano i PS 1.X, ricorrendo ai PS 2.0 solo quando non se ne poteva fare a meno. Anche usando i PS 2.0 in PP le prestazioni aumentano, ma non raddoppiano, anzi.
Esempio di gioco che usa PS 2.0 per fare certe cose e PS 1.X per altre: Far Cry.

Cio' non toglie che in mixed mode le nv3x guadagnino parecchi fps, avvicinandosi alle prestazioni delle 9800.

Esiste un grafico che ho postato all'inizio del thread per chi fosse interessato.

[R@nda]

Ok credo allora che la situazione rimmarà questa per quanto riguarda un'eventuale patch,con buona pace di tutti.
Al limite miglioreranno le prestazioni in Dx9.

[fek]

Originariamente inviato da rmarango
Io non ho parlato di prestazioni, ma di precisione...a me risultava che in dx9 le nvidia lavorano a 32bit mentre le ati a 24 bit (con un margine del 25% di vantaggio in prestazioni circa solo per questa differenza in bit)

Ma e' un ragionamento che non ha senso visto che all'atto pratico la precisione a 32 bit e' inutilizzabile, come non ha senso dire che l'R3X0 ha un vantaggio pratico del 25% perche' nella stragrande maggioranza dei casi 16 bit sono sufficienti.

Sono ragionamenti che lasciano il tempo che trovano.

[yossarian]

Originariamente inviato da Pat77
E' lo stesso articolo che prendevo da riverimento (con i bench a 50 fps per le fx).
Sostanzialmente si dice che sono un mix tra ps 1.1/1.4, 16bit e 32bit ps 2.0. Ma quanto utilizzo di 32/16 o ps1.1 ci sia in questa modalità non c'è dato saperlo.

Pk77


l'utilizzo di fp32 era ridottissimo; quello di fp16 un po' più consistente; però poi ci pensavano i drivers NV, dai 50.xx in poi, a trasformare le istruzioni fp32 in fp16 (nella migliore delle ipotesi) o addirittura in fx12 (sm1.4).

Con queste premesse, un mixed mode era del tutto inutile.

[rmarango]

Originariamente inviato da fek
Ma e' un ragionamento che non ha senso visto che all'atto pratico la precisione a 32 bit e' inutilizzabile, come non ha senso dire che l'R3X0 ha un vantaggio pratico del 25% perche' nella stragrande maggioranza dei casi 16 bit sono sufficienti.

Sono ragionamenti che lasciano il tempo che trovano.

Attenzione... per precisione io sottintendo anche l'architettura interna, lavorare con 32 bit e' piu pesante che con 24 a prescindere dal dato che viene trattato...e' questione di parallelismo.

[yossarian]

Originariamente inviato da rmarango
Cominciamo con il dire che hai parlato di precisioni infime in dx9, quando sappiamo che le nv3x lavorano in piena precisione contro i 24 bit delle Ati.

Poi il discorso dell'ordine naturale sinceramente l'ho capito solo dopo il tuo ultimo post chiarificatore...e penso che anche altri abbiano frainteso.

Ecco il perche' della battuta...comunque take it easy !


ribadisco esattamente quello che ho detto; chi ti abbia messo in mente che le fx lavorino in fp32 è un bel mistero (e chi sa se un giorno lo scopriremo).

A tuo esclusivo beneficio, riporto di nuovo i link a test fatti con sm1.x e sm2.0 con SW con cui non è possibile "barare" con i drivers.

http://www.beyond3d.com/previews/nvidia/nv40/index.php?p=21

http://www.beyond3d.com/reviews/ati/r420_x800/index.php?p=17

ti consiglio di guardarli con calma e analizzarli a fondo; sono molto chiari e fotografano perfettamente quella che è la capacità di elaborazione dei vari chip in questione.
Come puoi notare, tra l'fp24 di R3x0 e l'fp32 di NV3x c'è ben più del 25% di differenza di cui parli (e non tieni neppure conto delle differenze di clock, tutte a favore di nVIDIA).

[fek]

Originariamente inviato da rmarango
Attenzione... per precisione io sottintendo anche l'architettura interna, lavorare con 32 bit e' piu pesante che con 24 a prescindere dal dato che viene trattato...e' questione di parallelismo.

Per precisione, in quest'ambito, si intende solo una cosa: la quantita' di bit con i quali una grandezza e' rappresentata.

Lavorare a 32 bit non e' necessariamente piu' pesante che lavorare a 24 bit (al limite utilizza piu' transistor), dipende dalle situazioni.

[leoneazzurro]

C'è da dire anche che l'architettura 4x2 di NV 35 è più penalizzante rispetto alla 8x1 di R300.

[Pat77]

Originariamente inviato da yossarian
l'utilizzo di fp32 era ridottissimo; quello di fp16 un po' più consistente; però poi ci pensavano i drivers NV, dai 50.xx in poi, a trasformare le istruzioni fp32 in fp16 (nella migliore delle ipotesi) o addirittura in fx12 (sm1.4).

Con queste premesse, un mixed mode era del tutto inutile.

Valve indica il modus operandi della mixed, ma non specifica in che quantità Hl2 utilizzava gli sm. Penso sia questo il punto.
Che i driver Nvidia diminuissero la qualità è vero in ambiti specifici (mi torna in mente Farcry, dove oltre i driver fu proprio la patch di cryotek a trasformare i ps 2.0 da 32 a 16 bit).
Io penso che per gli utenti Fx non fosse proprio così senza senso, anche con un accettabile degrado della qualità.

Pk77

[yossarian]

Originariamente inviato da Pat77
Valve indica il modus operandi della mixed, ma non specifica in che quantità Hl2 utilizzava gli sm. Penso sia questo il punto.
Che i driver Nvidia diminuissero la qualità è vero in ambiti specifici (mi torna in mente Farcry, dove oltre i driver fu proprio la patch di cryotek a trasformare i ps 2.0 da 32 a 16 bit).
Io penso che per gli utenti Fx non fosse proprio così senza senso, anche con un accettabile degrado della qualità.

Pk77


se riguardi il link che ti ho postato, la filosofia di nVIDIA appare chiara; soprattutto quando dice che è possibile utilizzare, in molti casi, ps1.4 al posto dei ps2.0 e fp16 al posto di fp32.
Tra l'altro, è molto probabile che, anche con la mixed path, non sarebbe stato possibile godere di tutti gli effetti grafici visibili con chip dx9. Il mixed mode è stato un tentativo per poter utilizzare qualche effetto ps2.0, seppure solo in fp16, anche con l'NV35; però ti renderai conto che è impensabile che ogni Software House, che decida di programmare in dx9, debba introdurre path specifiche per chip della serie NV3x. Lo stesso Gabe Newell ha più volte dichiarato di considerare, relativamente ad HL2, le fx come chip DX8.x.
Non avendo una copia di HL2 e non avendo, comunque, un chip dx8 su cui testarlo, non posso dirti quale sia la perdità in termini di IQ; però non credo che sia una cosa così drammatica, almeno a sentire i pareri di quelli che hanno una fx.

[yossarian]

Originariamente inviato da fek
Per precisione, in quest'ambito, si intende solo una cosa: la quantita' di bit con i quali una grandezza e' rappresentata.

Lavorare a 32 bit non e' necessariamente piu' pesante che lavorare a 24 bit (al limite utilizza piu' transistor), dipende dalle situazioni.


infatti, l'NV40 nei test sintetici relativi ai ps2.0, in fp16 e in fp32 ha lo stesso rendimento (anzi, in quelli di B3D va meglio con fp32, a causa di un probabile bug dei driver con fp16 e sm1.x); ovvio che, in presenza di contemporanee operazioni sulle texture, l'utilizzo di fp32 ha un impatto maggiore rispetto a quello di fp16, ma in questo caso non c'entra la capacità pura di calcolo degli shader ma subentrano altri fattori (registri, parte della circuiteria più o mneo condivisa tra alu e tmu ecc).

Per NV3x non vale assolutamente questo discorso

[rmarango]

Originariamente inviato da fek
Per precisione, in quest'ambito, si intende solo una cosa: la quantita' di bit con i quali una grandezza e' rappresentata.

Lavorare a 32 bit non e' necessariamente piu' pesante che lavorare a 24 bit (al limite utilizza piu' transistor), dipende dalle situazioni.

Guarda questo grafico :

http://www.firingsquad.com/hardware/hl2_performance_preview_part1/images/graph_taxonomy.gif

[Pat77]

Originariamente inviato da yossarian
se riguardi il link che ti ho postato, la filosofia di nVIDIA appare chiara; soprattutto quando dice che è possibile utilizzare, in molti casi, ps1.4 al posto dei ps2.0 e fp16 al posto di fp32.
Tra l'altro, è molto probabile che, anche con la mixed path, non sarebbe stato possibile godere di tutti gli effetti grafici visibili con chip dx9. Il mixed mode è stato un tentativo per poter utilizzare qualche effetto ps2.0, seppure solo in fp16, anche con l'NV35; però ti renderai conto che è impensabile che ogni Software House, che decida di programmare in dx9, debba introdurre path specifiche per chip della serie NV3x. Lo stesso Gabe Newell ha più volte dichiarato di considerare, relativamente ad HL2, le fx come chip DX8.x.
Non avendo una copia di HL2 e non avendo, comunque, un chip dx8 su cui testarlo, non posso dirti quale sia la perdità in termini di IQ; però non credo che sia una cosa così drammatica, almeno a sentire i pareri di quelli che hanno una fx.

Bhe diciamo che nvidia c'ha provato con CG (come del resto fece 3dfx con glide), e i presupposti, prima dell'uscita di Fx per sfondare c'erano tutti.
E gli unici prodotti che ne hanno sfruttato qualche peculiarità (gunmetal, ad esempio) non erano poi male.
Nella programmazione generica Ati si trova sicuramente in vantaggio rispetto alla serie Fx che necessita path specifici per rendere al meglio, oltre che essere sensibile alla sequenza delle istruzioni ps.
Ho modo di apprezzare Hl2 sia in dx 8.0 che in dx 9.0 e in effetti c'è più di qualche differenza.
Resto convinto però che a 50 fps una versione ps 16bit (con alcune componenti più evidenti a 32 e altre in ms 1.1) poteva essere offerta.

Pk77

[fek]

Originariamente inviato da rmarango
Guarda questo grafico :


Che mi dovrebbe dire che?

[rmarango]

Originariamente inviato da fek
Che mi dovrebbe dire che?

Never mind...:)

[yossarian]

Originariamente inviato da fek
Che mi dovrebbe dire che?


:D

[fek]

Originariamente inviato da rmarango
Never mind...:)

No, sono curioso, qualcosa avrai pur voluto dimostrare postando quel grafico, mi sfugge solo che cosa, me lo puoi spiegare?

Oppure lo hai postato cosi' tanto per fare?

[rmarango]

Originariamente inviato da fek
No, sono curioso, qualcosa avrai pur voluto dimostrare postando quel grafico, mi sfugge solo che cosa, me lo puoi spiegare?

Oppure lo hai postato cosi' tanto per fare?

Era per illustrare la differenza in full precision tra Nvidia e Ati...

Un grafico vale piu' di mille parole a volte...vero yossarian ?

[leoneazzurro]

OK, ma tra la POSSIBILITA' TEORICA di utilizzare una FP 32 per i PS 2.0 e la POSSIBILITA' PRATICA di utilizzarla per giochi ce ne corre.
Io ho su un PC una 5900 XT della XFX, una signora scheda, in Open GL va forte, e certo non "fa schifo". Però i suoi limiti li ha, quindi da questo punto di vista non pretendiamo l'impossibile.

[fek]

Originariamente inviato da rmarango
Era per illustrare la differenza in full precision tra Nvidia e Ati...

Un grafico vale piu' di mille parole a volte...vero yossarian ?

Ma credo che anche i sassi qui sappiano che NV3X e NV4X usano 16/32 bit e R3X0 (e derivati) usano 24 bit. Non capisco quale informazione nuova quel grafico abbia aggiunto al discorso che si sta facendo qui.

(Francamente non ho neppure capito di preciso il motivo del contendere :D)

[yossarian]

Originariamente inviato da Pat77
Bhe diciamo che nvidia c'ha provato con CG (come del resto fece 3dfx con glide), e i presupposti, prima dell'uscita di Fx per sfondare c'erano tutti.
E gli unici prodotti che ne hanno sfruttato qualche peculiarità (gunmetal, ad esempio) non erano poi male.
Nella programmazione generica Ati si trova sicuramente in vantaggio rispetto alla serie Fx che necessita path specifici per rendere al meglio, oltre che essere sensibile alla sequenza delle istruzioni ps.
Ho modo di apprezzare Hl2 sia in dx 8.0 che in dx 9.0 e in effetti c'è più di qualche differenza.
Resto convinto però che a 50 fps una versione ps 16bit (con alcune componenti più evidenti a 32 e altre in ms 1.1) poteva essere offerta.

Pk77


Il problema delle fx non è solo il riordino degli shader; amche NV40, rispetto a R3x0 o R420 (e comunque anche i chip ATi hanno compilatori interni che riordinano le istruzioni), è più "sensibile" all'ordine in cui gli vengono date in pasto le istruzioni; però, una volta riordinate nel modo corretto, le macina che è un piacere. Con NV3x era, invece, un continuo lavoro di application detect e shader replacement. Dargli istruzioni fp32 sarebbe significato un calo del 75% delle prestazioni; in fp16, per NV30 le cose non migliovano affatto, per NV35 andavano meglio ma non benissimo; lavorando in fp16, con un input del tipo fp/fp/text (caso peggiore per NV35), si hanno 24 operazioni per clock per R3x0 e 6 operazioni per clock per NV35; con un input di tipo fp/text/text 8il migliore per l'NV35) si hanno 16 operazioni per R3x0 e 8 per NV35. In fp32 le cose vanno pure peggio.

Per quanto riguarda il mixed mode, tu personalmente, avresti investito tempo e denaro per tentare di ottimizzare una path che permettesse di implementare qualche effetto dx9 su un'unica famiglia di chip (NV35/NV38)?

[yossarian]

Originariamente inviato da rmarango
Era per illustrare la differenza in full precision tra Nvidia e Ati...

Un grafico vale piu' di mille parole a volte...vero yossarian ?


come, no; soprattutto se i grafici li si sa anche interpretare

:sofico:

comunque, mille grazie per avermi insegnato che la full precision delle fx è a 32 bit

:D

[rmarango]

Originariamente inviato da fek
Ma credo che anche i sassi qui sappiano che NV3X e NV4X usano 16/32 bit e R3X0 (e derivati) usano 24 bit. Non capisco quale informazione nuova quel grafico abbia aggiunto al discorso che si sta facendo qui.

(Francamente non ho neppure capito di preciso il motivo del contendere :D)

Il fatto stesso di aver scelto un architettura a 32 bit e' penalizzante se si lavora in FP rispetto all'architettura a 24 bit (si stima di un 25%) , a prescindere dal dato trattato...tutto qui.

[rmarango]

Originariamente inviato da yossarian
comunque, mille grazie per avermi insegnato che la full precision delle fx è a 32 bit

:D

Prego, non si finisce mai di imparare nella vita...;)

[leoneazzurro]

Originariamente inviato da rmarango
Il fatto stesso di aver scelto un architettura a 32 bit e' penalizzante se si lavora in FP rispetto all'architettura a 24 bit (si stima di un 25%) , a prescindere dal dato trattato...tutto qui.

Ehm.. no. E' "penalizzante" solo in termini di grandezza del dato (leggi: banda passante) e del numero di transistor necessario. Se correttamente implementato (non come NV 3x, in pratica) in sè non è affatto più lento.

[fek]

Originariamente inviato da rmarango
Il fatto stesso di aver scelto un architettura a 32 bit e' penalizzante se si lavora in FP rispetto all'architettura a 24 bit (si stima di un 25%) , a prescindere dal dato trattato...tutto qui.

No, non e' necessariamente penalizzante, dipende dalle situazioni. Uno shader corto full 32 bit viaggia esattamente come a 16 bit.
Quando si inizia a fare uso di molte variabili temporanee a 32 bit, la GPU puo' andare in stallo (quando e come dipende da molti fattori): questo fatto rende l'utilizzo del ful 32 bit su NV3X impraticabile a fini pratici.

In sintesi, non prescinde affatto dal dato trattato, le consueguenze di scegliere 24 o 32 bit di precisione dipendono esattamente dal dato trattato e dai suoi pattern d'uso. E questo e' un concetto che un semplice grafico non puo' convogliare, da qui la mia perplessita' sul suo significato e sulla sua utilita' in questo contesto.

[rmarango]

Originariamente inviato da leoneazzurro
Ehm.. no. E' "penalizzante" solo in termini di grandezza del dato (leggi: banda passante) e del numero di transistor necessario. Se correttamente implementato (non come NV 3x, in pratica) in sè non è affatto più lento.

Infatti io intendevo a parita' di transistors...

[leoneazzurro]

Il quale confronto non è proponibile per ovvi motivi. Il discorso è: o le cose le fai per bene o forse è meglio non farle. ATI con l'R300 l'ha fatto, pur con dei compromessi, mentre Nvidia no. All'inizio nemmeno io potevo credere che avessero fatto una cacchiata, invece poi il succo della questione è proprio quello: in pratica mentre ATI ha prodotto una GPU che rendeva bene su tutti i fronti, Nvidia ha fatto una scheda che nel caso di utilizzo di PS 2.0 non ha lo stesso rendimento che non con i PS 1.X. Questo perchè probabilmente pensava che la concorrenza avrebbe fatto lo stesso, e invece....

[rmarango]

Originariamente inviato da leoneazzurro
Il quale confronto non è proponibile per ovvi motivi. Il discorso è: o le cose le fai per bene o forse è meglio non farle. ATI con l'R300 l'ha fatto, pur con dei compromessi, mentre Nvidia no. All'inizio nemmeno io potevo credere che avessero fatto una cacchiata, invece poi il succo della questione è proprio quello: in pratica mentre ATI ha prodotto una GPU che rendeva bene su tutti i fronti, Nvidia ha fatto una scheda che nel caso di utilizzo di PS 2.0 non ha lo stesso rendimento che non con i PS 1.X. Questo perchè probabilmente pensava che la concorrenza avrebbe fatto lo stesso, e invece....

Perfettamente d'accordo.

p.s. volevo solo aggiungere per rassicurare i possessori di nv3x che fortunatamente con HL2 (tornando in topic) come ha detto la maggioranza le differenze visive tra PS 1.X e PS 2.0 sono trascurabili tranne che per i riflessi sull'acqua.

[yossarian]

Originariamente inviato da rmarango
Infatti io intendevo a parita' di transistors...


non si può passare da fp24 a fp32 mantenendo invariati i circuiti e quindi il numero di transistor.

[yossarian]

Originariamente inviato da rmarango
Prego, non si finisce mai di imparare nella vita...;)


però, come dice fek, 'sta cosa, su 'sto forum, la sanno pure i sassi (e da almeno un anno e mezzo).

:fiufiu:

[rmarango]

Originariamente inviato da yossarian
non si può passare da fp24 a fp32 mantenendo invariati i circuiti e quindi il numero di transistor.

No, non hai capito...intendevo dire che e' necessario confrontare due architetture che abbiano piu' o meno lo stesso numero di transistor ...come giustamente faceva notare leoneazzurro.
Non puoi confrontare un NV35 con un NV40 dove i transistor sono molti di piu'.

[rmarango]

Comunque ritornando finalmente in topic per chi possiede Nv3x e fosse interessato a confrontare le differenze visive e prestazionali tra dx8.1 e dx9 basta che aggiunga la seguente stringa alla linea di comando :

-dxlevel 90

e le due seguenti stringhe ad un file di testo creato ex novo chiamandolo autoexec.cfg in Directory installazione\Hl2\cfg :

mat_dxlevel 90
mat_clipz 0


Infine occorre abilitare le riflessioni del mondo esterno nell'acqua nel pannello opzioni video avanzate.

Buon confronto a tutti

;)

[swarzy85]

Originariamente inviato da rmarango
Non puoi confrontare un NV35 con un NV40 dove i transistor sono molti di piu'.
avranno pure un'architettura molto diversa, no?;)

P.s. mai visto Yossarian tirar fuori un ":rolleyes:" e mai visto nessuno cerca di insegnare qualcosa a Yossarian o a Fek :rotfl:
tra l'altro in questo thread leggo i post di gente decisamente preparata che non credo abbia bisogno di lezioni basate su schemi stra :old:

[rmarango]

Originariamente inviato da swarzy85
avranno pure un'architettura molto diversa, no?;)

P.s. mai visto Yossarian tirar fuori un ":rolleyes:" e mai visto nessuno cerca di insegnare qualcosa a Yossarian o a Fek :rotfl:
tra l'altro in questo thread leggo i post di gente decisamente preparata che non credo abbia bisogno di lezioni basate su schemi stra :old:

Io non pretendo di insegnare nulla a nessuno, espongo solo il mio pensiero giusto o sbagliato che sia...cercando di non scendere sul piano personale quando e' possibile.

[street]

Originariamente inviato da swarzy85
avranno pure un'architettura molto diversa, no?;)

P.s. mai visto Yossarian tirar fuori un ":rolleyes:" e mai visto nessuno cerca di insegnare qualcosa a Yossarian o a Fek :rotfl:
tra l'altro in questo thread leggo i post di gente decisamente preparata che non credo abbia bisogno di lezioni basate su schemi stra :old:

:asd:

[yossarian]

Originariamente inviato da rmarango
No, non hai capito...intendevo dire che e' necessario confrontare due architetture che abbiano piu' o meno lo stesso numero di transistor ...come giustamente faceva notare leoneazzurro.
Non puoi confrontare un NV35 con un NV40 dove i transistor sono molti di piu'.


la differenza di prestazioni con fp32 tra NV3x e NV40 non dipende solo dal numero di transistor; R3x0 ha meno transistor di NV3x, eppure va molto meglio. Il problema è il come sono distribuiti questi transistor. NV40 ha un'architettura completamente diversa da NV3x perchè NV40 è un chip progettato per far girare codice Dx9; NV3x no: questa è l'unica differenza.
Ti ripeto l'invito di guardare i due link che ti ho postato: uno è relativo a chip nVIDIA (NV40, NV38, NV35, NV30) l'altro a chip ATi (R420, R3x0). Fai un raffronto tra i valori fatti registrare dai chip ATI della serie R3x0 e quelli nVIDIA della serie NV3x.
Puoi notare che i chip ATi sono sempre in vantaggio ma, mentre con ps1.x, il vantaggio è minore, quando si iniziano ad utilizzare i ps2.0, sia in fp16 che, ancora di più, in fp32, le differenze diventano abissali. Questo non dipende dal numero di transistor ma da come questi transistor sono utilizzati. I valori più bassi (ben inferiori al 25% di cui hai parlato) non dipendono dall'uso di fp32 contro fp24, perchè valori di molto inferiori sono fatti segnare anche con fp16 (dove, secondo i tuoi calcoli, il vantaggio del 25% dovrebbero averlo i chip NV)

[rmarango]

Originariamente inviato da yossarian
.... dove, secondo i tuoi calcoli, il vantaggio del 25% dovrebbero averlo i chip NV

Io sostenevo l'esatto contrario cioe' il 25% piu' lento l'nvidia tra 32 e 24 bit...forse non era chiaro.
E comunque non sono i miei calcoli...l'ho letto in una recensione quel numero.
Devo solo ritrovarla...datemi tempo.

[swarzy85]

Originariamente inviato da rmarango
Io non pretendo di insegnare nulla a nessuno, espongo solo il mio pensiero giusto o sbagliato che sia...cercando di non scendere sul piano personale quando e' possibile.
Certo, giustissimo :)
Sto solo cercando di farti capire che qui dentro ci sono degli utenti (leggi leoneazzurro, vifani, Fek e Yossarian....e magari ce ne sono anche altri che però non conosco abbastanza) che possono insegnare davvero tanto :)
Ed è interesse mio, tuo e di tanti altri che postino :)
Per questo, non prendere i loro post come messaggi di chi vuole mostrare di saperne di più....semplicemente hanno conoscenze tali da poter dare quel contributo in più in un thread tecnico :)

Ciao :)

[fek]

Originariamente inviato da swarzy85

P.s. mai visto Yossarian tirar fuori un ":rolleyes:" e mai visto nessuno cerca di insegnare qualcosa a Yossarian o a Fek :rotfl:

Perche' non hai mai visto Alex Evans mentre mi fa lezione di 3D :D

[swarzy85]

Originariamente inviato da fek
Perche' non hai mai visto Alex Evans mentre mi fa lezione di 3D :D
e tu non hai mai visto la mia faccia dopo una decina di pagine di spiegazioni sulle pixel pipelines (per email) da parte di Yoss :D

[yossarian]

Originariamente inviato da rmarango
Io sostenevo l'esatto contrario cioe' il 25% piu' lento l'nvidia tra 32 e 24 bit...forse non era chiaro.
E comunque non sono i miei calcoli...l'ho letto in una recensione quel numero.
Devo solo ritrovarla...datemi tempo.

hai quotato la parte sbagliata; in questa frase mi riferivo all'uso di fp16 che dovrebbe dare un vantaggio del 25% a NV rispetto all'fp24 di ATi (la differenza percentuale è sempre la stessa);
ho capito che tu lo attribuivi ai chip ATi che lavorando a fp24 dovrebbero risultare il 25% più veloci di quelli NV che lavorano a fp32 (la differenza percentuale tra 24 e 32 è proprio del 25%); però sto cercando di dirti dall'inizio che è un calcolo sbagliato: sono cifre che, nella realtà, non tornano. Non so dove tu l'abbia letto (e non metto in dubbio che l'abbia fatto) solo che chi l'ha scritto a detto una stupidaggine. Se guardi i dati sul solo utilizzo di calcoli matematici, lavorare in fp16, fp24, fp32, fx12 è del tutto indifferente. NV40 elabora codice ps2.0 a 16 o a 32 bit con la medesima velocità, come pure fanno R3x0 e R420. NV3x, invece, no; risulta più veloce (di molto) con i ps1.x, però le prestazioni precipitano con l'uso di fp16 e, ancora di più, di fp32. Questo dovrebbe far riflettere sull'architettura del chip. Ripeto, guarda i link di B3D che ho postato più indietro; sono eseguiti con un programma (rightmark, mi pare) che valuta la velocità di esecuzione dei vari chip con tutti i tipi di shader; confronta i risultati di NV35 e NV38 con ps1.x, con ps2.0 simple e in pp; confronta poi gli stessi risultati con quelli di R420, R3x0 e NV40 e potrai renderti contoo di quello che dico.

[yossarian]

Originariamente inviato da fek
Perche' non hai mai visto Alex Evans mentre mi fa lezione di 3D :D


questa è una cosa che non mi vorrei proprio perdere

:D

[rmarango]

Originariamente inviato da yossarian
hai quotato la parte sbagliata; in questa frase mi riferivo all'uso di fp16 che dovrebbe dare un vantaggio del 25% a NV rispetto all'fp24 di ATi (la differenza percentuale è sempre la stessa);
ho capito che tu lo attribuivi ai chip ATi che lavorando a fp24 dovrebbero risultare il 25% più veloci di quelli NV che lavorano a fp32 (la differenza percentuale tra 24 e 32 è proprio del 25%); però sto cercando di dirti dall'inizio che è un calcolo sbagliato: sono cifre che, nella realtà, non tornano. Non so dove tu l'abbia letto (e non metto in dubbio che l'abbia fatto) solo che chi l'ha scritto a detto una stupidaggine. Se guardi i dati sul solo utilizzo di calcoli matematici, lavorare in fp16, fp24, fp32, fx12 è del tutto indifferente. NV40 elabora codice ps2.0 a 16 o a 32 bit con la medesima velocità, come pure fanno R3x0 e R420. NV3x, invece, no; risulta più veloce (di molto) con i ps1.x, però le prestazioni precipitano con l'uso di fp16 e, ancora di più, di fp32. Questo dovrebbe far riflettere sull'architettura del chip. Ripeto, guarda i link di B3D che ho postato più indietro; sono eseguiti con un programma (rightmark, mi pare) che valuta la velocità di esecuzione dei vari chip con tutti i tipi di shader; confronta i risultati di NV35 e NV38 con ps1.x, con ps2.0 simple e in pp; confronta poi gli stessi risultati con quelli di R420, R3x0 e NV40 e potrai renderti contoo di quello che dico.

Ok, ti ringrazio molto per il chiarimento...
:)

Cerchero' comunque di rintracciare quella benedetta recensione giusto per dovere di cronaca... ;)

[yossarian]

Originariamente inviato da rmarango
Ok, ti ringrazio molto per il chiarimento...
:)

Cerchero' comunque di rintracciare quella benedetta recensione giusto per dovere di cronaca... ;)

Prego, figurati; ti consiglio di guardare le recensioni di B3D; se con l'inglese non te la cavi male, sono sempre molto interessanti e piuttosto tecniche (è uno dei siti di riferimento della comunità internazionale e il suo forum è spesso frequentato da personaggi piuttosto vicini ad ATi, nVIDIA e alle varie software house)

Dai un'occhiata, comunque, a quei due link e, se ti interessa, possiamo commentarli insieme.


ciao

[rmarango]

Originariamente inviato da yossarian
Prego, figurati; ti consiglio di guardare le recensioni di B3D; se con l'inglese non te la cavi male, sono sempre molto interessanti e piuttosto tecniche (è uno dei siti di riferimento della comunità internazionale e il suo forum è spesso frequentato da personaggi piuttosto vicini ad ATi, nVIDIA e alle varie software house)

Dai un'occhiata, comunque, a quei due link e, se ti interessa, possiamo commentarli insieme.


ciao

Ciao e Grazie
:)

[Vifani]

Originariamente inviato da rmarango
Qui nessuno ha scandito cori da stadio...mi pare che stai esagerando...datti una calmata...

Vifani ha erroneamente citato una cosa e io l'ho soltato corretto, non esistono gli intoccabili.

E poi io non ho insultato nessuno...pero' se la metti su questo piano ti segnalo al moderatore...

Io non ho fatto alcun errore e nulla di quello che ho scritto è stato scritto "per sentito dire", ma dietro diretta osservazione visto che, per la cronaca, sto eseguendo test su Half-Life 2 da quattro giorni con oltre 10 schede video differenti.

Dato di fatto numero 1: con NV3x Half-Life 2 funziona di default in modalità DX 8.1.

Dato di fatto numero 2: con NV3x è possibile abilitare la modalità DX9 con l'istruzione mat_dxlevel 90 da console (o solo "-dxlevel 90" in + nella riga di comando). Tuttavia abilitando questa modalità impostando Rifletti TUTTO (e non mondo), con i Detonator 67.02 consigliati da NVIDIA per HL2 esistono difetti grafici con l'acqua. La cosa si risolve aggiungendo il comando "mat_clipz 0" manualmente nel file di configurazione (come ho scritto già in un post precedente).

Dato di fatto numero 3: con NV3x e in modalità DX9 le prestazioni sono bassissime, molto + basse di R350 (che usa la modalità DX9) anche a risoluzioni come 1024x768 senza anisotropico e antialiasing.

Esistono ancora dubbi al riguardo o possiamo considerare chiusa la questione HL2 + NV3x ?

[^TiGeRShArK^]

Originariamente inviato da rmarango
Io non ho parlato di prestazioni, ma di precisione...a me risultava che in dx9 le nvidia lavorano a 32bit mentre le ati a 24 bit (con un margine del 25% di vantaggio in prestazioni circa solo per questa differenza in bit)

Ma x caso avete VISTO il fantomatico MIXED MODE????
ke ne sapete ke tale path di rendering non risultava TOTALEMNTE queivalente al path dx 8.1 attuale????
e mi spiegate se fosse quello il caso PERCHE' implementare il path DX 9 MIXED visto che col DX 8.1 si aveva una resa grafica equivalente con prestazioni superiori....
sono cose ke FEK e YOSSARIAN hanno ripetuto già un bel pò di volte, ma nonostante l'intervento di freeman si continua a girare sempre intorno allo stesso punto FREGANDOSENE di andare a leggersi con umiltà i link tecnici riportati in questo thread x imparare qualcosa di nuovo....

P.S. Dimenticavo anche VIFANI, chiedo umilmente perdono!:ave: :asd:

[Pat77]

Originariamente inviato da yossarian
Il problema delle fx non è solo il riordino degli shader; amche NV40, rispetto a R3x0 o R420 (e comunque anche i chip ATi hanno compilatori interni che riordinano le istruzioni), è più "sensibile" all'ordine in cui gli vengono date in pasto le istruzioni; però, una volta riordinate nel modo corretto, le macina che è un piacere. Con NV3x era, invece, un continuo lavoro di application detect e shader replacement. Dargli istruzioni fp32 sarebbe significato un calo del 75% delle prestazioni; in fp16, per NV30 le cose non migliovano affatto, per NV35 andavano meglio ma non benissimo; lavorando in fp16, con un input del tipo fp/fp/text (caso peggiore per NV35), si hanno 24 operazioni per clock per R3x0 e 6 operazioni per clock per NV35; con un input di tipo fp/text/text 8il migliore per l'NV35) si hanno 16 operazioni per R3x0 e 8 per NV35. In fp32 le cose vanno pure peggio.

Per quanto riguarda il mixed mode, tu personalmente, avresti investito tempo e denaro per tentare di ottimizzare una path che permettesse di implementare qualche effetto dx9 su un'unica famiglia di chip (NV35/NV38)?

Bhe se ho perso risorse a studiarla l'avrei implementata sicuramente, ma ribadisco che in questo caso ci sono giochi più che altro politici, imho.

Riguardo all'efficenza di nv30/35/38 sui ps 2.0 secondo me è tutta una questione di implementazione e ottimizzazione.
Anche il concetto di non utilizzare sm con precisione a 24 o 32 bit dove non è necessario mi trova cocorde.
Anzi sono convinto che in path dx 8.1 quelle riflessioni potevano essere tranquillamente rese molto simili alla dx9.0.

La serie fx comunque è stata una generazione di passaggio, fortissima nel multitexturing, ottima in dx8.1, discreta in dx9 16bit e lenta in dx9 32bit.

Pk77

[street]

Originariamente inviato da Pat77
Bhe se ho perso risorse a studiarla l'avrei implementata sicuramente, ma ribadisco che in questo caso ci sono giochi più che altro politici, imho.

Riguardo all'efficenza di nv30/35/38 sui ps 2.0 secondo me è tutta una questione di implementazione e ottimizzazione.
Anche il concetto di non utilizzare sm con precisione a 24 o 32 bit dove non è necessario mi trova cocorde.
Anzi sono convinto che in path dx 8.1 quelle riflessioni potevano essere tranquillamente rese molto simili alla dx9.0.

La serie fx comunque è stata una generazione di passaggio, fortissima nel multitexturing, ottima in dx8.1, discreta in dx9 16bit e lenta in dx9 32bit.

Pk77

non so il resto (la parte tecnica) ma per quanto riguarda la parte economica, in una società commerciale a volte si inizia un progetto (leggi implementazione del mixed mode), si fa uno stop per vedere se il gioco vale la candela dal punto di vista economico ed a quel punto si procede oppure si accantona "buttando" il lavoro effettuato.
E' una perdita economica, ma non al livello di fare tutto un progetto che poi darebbe risultati inferiori rispetto alle risorse spese.

[leoneazzurro]

Originariamente inviato da swarzy85
Certo, giustissimo :)
Sto solo cercando di farti capire che qui dentro ci sono degli utenti (leggi leoneazzurro, vifani, Fek e Yossarian....e magari ce ne sono anche altri che però non conosco abbastanza) che possono insegnare davvero tanto :)
Ed è interesse mio, tuo e di tanti altri che postino :)
Per questo, non prendere i loro post come messaggi di chi vuole mostrare di saperne di più....semplicemente hanno conoscenze tali da poter dare quel contributo in più in un thread tecnico :)

Ciao :)

Uh, non esageriamo... non mischiatemi ai mostri sacri. Io da loro imparo :D
Da parte mia, sono solo un umile appassionato ;)

[Pat77]

Originariamente inviato da ^TiGeRShArK^
Ma x caso avete VISTO il fantomatico MIXED MODE????
ke ne sapete ke tale path di rendering non risultava TOTALEMNTE queivalente al path dx 8.1 attuale????
e mi spiegate se fosse quello il caso PERCHE' implementare il path DX 9 MIXED visto che col DX 8.1 si aveva una resa grafica equivalente con prestazioni superiori....
sono cose ke FEK e YOSSARIAN hanno ripetuto già un bel pò di volte, ma nonostante l'intervento di freeman si continua a girare sempre intorno allo stesso punto FREGANDOSENE di andare a leggersi con umiltà i link tecnici riportati in questo thread x imparare qualcosa di nuovo....

P.S. Dimenticavo anche VIFANI, chiedo umilmente perdono!:ave: :asd:

No, non ho visto il mixed mode.
Quello che si sa è che SICURAMENTE era un path superiore al dx 8.1, e forse questo è l'unico dato certo (la stessa valve l'ha creato per implementare una soluzione DX9 meno raffinata).
I link, che peraltro già conoscevo, me li sono letti ma di certo non considero i dati riportati come definitivi e concludenti.
Si parla in generale di come sarebbe stato, senza specificare in che modo avrebbe privilegiato i 16-32 bit o i ps 1.1 1.4. Poi si parla di Nvidia, della sua politica di utilizzare, ove possibile, partial precision, peraltro ottica già ribadita milioni di volte.
Detto questo stranamente dal lato Nvidia ci troviamo: Fx declassate a soluzione 8.1, mancanza di Mixed Mode anche solo come opzione, soluzioni Dx 8.1 come Geforce 4 declassate a 8.0, addirittura schede sulla carta dx 9.0 diventate 8.0.
Che si sia scelto di privilegiare l'esperienza di gioco rinunciando a qualche effetto grafico è una politica che mi trova sostanzialmente daccordo, ma continuo ad avere la netta sensazione che dalle serie Geforce si sia tirato fuori davvero troppo poco.

Pk77

[R@nda]

Mi sta venendo in mente una cosa a proposito dell'acqua e degli ambienti di gioco dove è presente.
Io so che la riflessione del mondo nell'acqua equivale a ricostruire poligonalmente due volte la scena (in pratica sopra e sotto per creare l'effetto del riflesso),siccome i livelli dove è presente sono abbastanza poveri di poligoni mi chiedo se era davvero necessario sacrificarli per avere un effetto del genere.
Insomma meglio un ambiente poligonale più ricco e spettacolare e dei riflessi dell'acqua più semplici (almeno per l'hardware attuale...in futuro chi lo sa).
Ma forse mi sbaglio e oggi la costruzione di tale effetto viene ricostruita in altro modo...

[yossarian]

Originariamente inviato da Pat77
No, non ho visto il mixed mode.
Quello che si sa è che SICURAMENTE era un path superiore al dx 8.1, e forse questo è l'unico dato certo (la stessa valve l'ha creato per implementare una soluzione DX9 meno raffinata).
I link, che peraltro già conoscevo, me li sono letti ma di certo non considero i dati riportati come definitivi e concludenti.
Si parla in generale di come sarebbe stato, senza specificare in che modo avrebbe privilegiato i 16-32 bit o i ps 1.1 1.4. Poi si parla di Nvidia, della sua politica di utilizzare, ove possibile, partial precision, peraltro ottica già ribadita milioni di volte.
Detto questo stranamente dal lato Nvidia ci troviamo: Fx declassate a soluzione 8.1, mancanza di Mixed Mode anche solo come opzione, soluzioni Dx 8.1 come Geforce 4 declassate a 8.0, addirittura schede sulla carta dx 9.0 diventate 8.0.
Che si sia scelto di privilegiare l'esperienza di gioco rinunciando a qualche effetto grafico è una politica che mi trova sostanzialmente daccordo, ma continuo ad avere la netta sensazione che dalle serie Geforce si sia tirato fuori davvero troppo poco.

Pk77


ti riporto le parole di Carmack a proposito di Doom3 e NV30 e R300; quest'intervista è un po' datata però dà un quadro chiaro delle potenzialità dei vari chip, anche con un engine diverso da quello di HL2

At the moment, the NV30 is slightly faster on most scenes in Doom than the
R300, but I can still find some scenes where the R300 pulls a little bit
ahead. The issue is complicated because of the different ways the cards can
choose to run the game.

The R300 can run Doom in three different modes: ARB (minimum extensions, no
specular highlights, no vertex programs), R200 (full featured, almost always
single pass interaction rendering), ARB2 (floating point fragment shaders,
minor quality improvements, always single pass).

The NV30 can run DOOM in five different modes: ARB, NV10 (full featured, five
rendering passes, no vertex programs), NV20 (full featured, two or three
rendering passes), NV30 ( full featured, single pass), and ARB2.

The R200 path has a slight speed advantage over the ARB2 path on the R300, but
only by a small margin, so it defaults to using the ARB2 path for the quality
improvements. The NV30 runs the ARB2 path MUCH slower than the NV30 path.
Half the speed at the moment. This is unfortunate, because when you do an
exact, apples-to-apples comparison using exactly the same API, the R300 looks
twice as fast, but when you use the vendor-specific paths, the NV30 wins.

The reason for this is that ATI does everything at high precision all the
time, while Nvidia internally supports three different precisions with
different performances. To make it even more complicated, the exact
precision that ATI uses is in between the floating point precisions offered by
Nvidia, so when Nvidia runs fragment programs, they are at a higher precision
than ATI's, which is some justification for the slower speed. Nvidia assures
me that there is a lot of room for improving the fragment program performance
with improved driver compiler technology.

Ti faccio notare alcune cose:
1) in modalità standard ARB2 R300 è veloce circa il doppio rispetto a NV30 (stiamo parlando di OpenGL)
2) esiste una path specifica per NV30 e non per R300; questa path fa uso di fp32, fp16 e, addirittura, fx12
3) esiste una path R200 diversa da quella NV20 (anche in questo caso, R200 e NV2x sono differenziati; questo significa che sono chip con caratteristiche diverse (R200 è sm1.4, mentre NV25 è sm1.3 e le differenze tra i due non sono poche).

In conclusione, non mi pare scandaloso il fatto che NV2x e R200 siano stati trattati in maniera diversa in HL2 (lo ha fatto anche Carmack); non è scandaloso il fatto che per i chip derivati da NV35 si sia adottata un path diversa da quella standard DX9 (anche secondo ID NV3x in ARB2 standard era molto lento).
Come hai giustamente detto nel finale, si è voluta privilegiare l'esperienza di gioco rinunciando a qualche effetto grafico. Forse si è fatto poco per le Geforce, però, allora, dovrai convenire sul fatto che ID non ha fatto nulla per le Radeon; anzi, dal momento in cui si è rinunciato alla path NV30, questa stessa path è diventata lo standard di fatto del motore grafico del gioco (e questo ha penalizzato non poco i chip ATi).
Si tratta anche, indubbiamente, di scelte politiche (ma questo vale per tutti e due). La differenza è che con Doom3 che rappresenta l'engine più favorevole all'architettura NV le Radeon riescono a difendersi anche utilizzando la modalità "standard"; con HL2 (che rappresenta la situazione più favorevole ad ATi) le Geforce, tranne NV40, hanno, in modalità "standard", prestazioni penose. Questo significa che non si tratta solo di ordinare le istruzioni in maniera differente: quello può appena alleviare i problemi delle fx nella gestione dello sm2.0 ma non risolve affatto i problemi (che sono esclusivamente di natura architetturale).
Anche il famigerato compilatore di cui si parlava mesi fa, che avrebbe dovuto risolvere i problemi delle fx, dopo la querelle con futuremark si è scoperto che non solo riordinava gli shader ma faceva anche application detect e shader replacemnt, spesso usando calcoli in virgola fissa dove era richiesto l'uso di fp.

[yossarian]

Originariamente inviato da R@nda
Mi sta venendo in mente una cosa a proposito dell'acqua e degli ambienti di gioco dove è presente.
Io so che la riflessione del mondo nell'acqua equivale a ricostruire poligonalmente due volte la scena (in pratica sopra e sotto per creare l'effetto del riflesso),siccome i livelli dove è presente sono abbastanza poveri di poligoni mi chiedo se era davvero necessario sacrificarli per avere un effetto del genere.
Insomma meglio un ambiente poligonale più ricco e spettacolare e dei riflessi dell'acqua più semplici (almeno per l'hardware attuale...in futuro chi lo sa).
Ma forse mi sbaglio e oggi la costruzione di tale effetto viene ricostruita in altro modo...


aspettiamo fek per saperne di più

;)

[R@nda]

Originariamente inviato da yossarian
aspettiamo fek per saperne di più

;)

Ok

Comunque come dice qualcuno,quell'intervista la conoscono anche i sassi ormai:sofico:
(rende il concetto però)

[yossarian]

Originariamente inviato da R@nda
Ok

Comunque come dice qualcuno,quell'intervista la conoscono anche i sassi ormai:sofico:
(rende il concetto però)


è a beneficio delle nuove leve, non per i "nonni" del forum (in particolare delle sezioni tecniche)

;)

[Pat77]

Originariamente inviato da yossarian
ti riporto le parole di Carmack a proposito di Doom3 e NV30 e R300; quest'intervista è un po' datata però dà un quadro chiaro delle potenzialità dei vari chip, anche con un engine diverso da quello di HL2

At the moment, the NV30 is slightly faster on most scenes in Doom than the
R300, but I can still find some scenes where the R300 pulls a little bit
ahead. The issue is complicated because of the different ways the cards can
choose to run the game.

The R300 can run Doom in three different modes: ARB (minimum extensions, no
specular highlights, no vertex programs), R200 (full featured, almost always
single pass interaction rendering), ARB2 (floating point fragment shaders,
minor quality improvements, always single pass).

The NV30 can run DOOM in five different modes: ARB, NV10 (full featured, five
rendering passes, no vertex programs), NV20 (full featured, two or three
rendering passes), NV30 ( full featured, single pass), and ARB2.

The R200 path has a slight speed advantage over the ARB2 path on the R300, but
only by a small margin, so it defaults to using the ARB2 path for the quality
improvements. The NV30 runs the ARB2 path MUCH slower than the NV30 path.
Half the speed at the moment. This is unfortunate, because when you do an
exact, apples-to-apples comparison using exactly the same API, the R300 looks
twice as fast, but when you use the vendor-specific paths, the NV30 wins.

The reason for this is that ATI does everything at high precision all the
time, while Nvidia internally supports three different precisions with
different performances. To make it even more complicated, the exact
precision that ATI uses is in between the floating point precisions offered by
Nvidia, so when Nvidia runs fragment programs, they are at a higher precision
than ATI's, which is some justification for the slower speed. Nvidia assures
me that there is a lot of room for improving the fragment program performance
with improved driver compiler technology.

Ti faccio notare alcune cose:
1) in modalità standard ARB2 R300 è veloce circa il doppio rispetto a NV30 (stiamo parlando di OpenGL)
2) esiste una path specifica per NV30 e non per R300; questa path fa uso di fp32, fp16 e, addirittura, fx12
3) esiste una path R200 diversa da quella NV20 (anche in questo caso, R200 e NV2x sono differenziati; questo significa che sono chip con caratteristiche diverse (R200 è sm1.4, mentre NV25 è sm1.3 e le differenze tra i due non sono poche).

In conclusione, non mi pare scandaloso il fatto che NV2x e R200 siano stati trattati in maniera diversa in HL2 (lo ha fatto anche Carmack); non è scandaloso il fatto che per i chip derivati da NV35 si sia adottata un path diversa da quella standard DX9 (anche secondo ID NV3x in ARB2 standard era molto lento).
Come hai giustamente detto nel finale, si è voluta privilegiare l'esperienza di gioco rinunciando a qualche effetto grafico. Forse si è fatto poco per le Geforce, però, allora, dovrai convenire sul fatto che ID non ha fatto nulla per le Radeon; anzi, dal momento in cui si è rinunciato alla path NV30, questa stessa path è diventata lo standard di fatto del motore grafico del gioco (e questo ha penalizzato non poco i chip ATi).
Si tratta anche, indubbiamente, di scelte politiche (ma questo vale per tutti e due). La differenza è che con Doom3 che rappresenta l'engine più favorevole all'architettura NV le Radeon riescono a difendersi anche utilizzando la modalità "standard"; con HL2 (che rappresenta la situazione più favorevole ad ATi) le Geforce, tranne NV40, hanno, in modalità "standard", prestazioni penose. Questo significa che non si tratta solo di ordinare le istruzioni in maniera differente: quello può appena alleviare i problemi delle fx nella gestione dello sm2.0 ma non risolve affatto i problemi (che sono esclusivamente di natura architetturale).
Anche il famigerato compilatore di cui si parlava mesi fa, che avrebbe dovuto risolvere i problemi delle fx, dopo la querelle con futuremark si è scoperto che non solo riordinava gli shader ma faceva anche application detect e shader replacemnt, spesso usando calcoli in virgola fissa dove era richiesto l'uso di fp.

Da un intervista a Carmack

"I'm hoping you can clear up some apparent confusion about DOOM3's rendering paths.

1) There is word that you have removed the NV30-specific rendering path
2) The reason for the above is apparently because NVIDIA's drivers have improved to the point where NV3x hardware are running the standard ARB2 path at about equal speed with the NV30-specific path

Could you say if the above is true?

Correct."

Pk77

[Banus]

Originariamente inviato da R@nda
Io so che la riflessione del mondo nell'acqua equivale a ricostruire poligonalmente due volte la scena (in pratica sopra e sotto per creare l'effetto del riflesso),siccome i livelli dove è presente sono abbastanza poveri di poligoni mi chiedo se era davvero necessario sacrificarli per avere un effetto del genere.

Presentazione sul sito della ATI:
Half-Life 2 / Source Shading by Gary McTaggart, Valve Software (http://www2.ati.com/developer/gdc/D3DTutorial10_Half-Life2_Shading.pdf)
Lo shader dell'acqua si trova nelle ultime pagine.

Il calcolo delle riflessioni con l'opzione "world" dovrebbe limitarsi a una versione con pochi poligoni della scena. Inoltre dovrebbe essere a risoluzione più bassa dello schermo, in modo da risparmiare fillrate.
Con l'opzione "reflect all" dovrebbe rirenderizzare tutta la scena e questo spiegherebbe il sensibile calo di prestazioni.

[BTinside]

Originariamente inviato da R@nda
Appunto...esterni fluidi da paura (Ps1.X),interni da tragedia!(Ps2.0)

Strano che dici questo, io invece riscontravo sempre il contrario,
negli interni da 40 a 70fps(9800pro)
e negli esterni da 15 a 30, proprio per la vastità d'ambiente.
Forse succede così per chi gioca con Geforce FX

[R@nda]

Può darsi.
Può essere che la 9800Pro o l'R3xx renda meglio in Ps 2.0 piuttosto che in Ps 1.x (questo non lo so....è un idea).
Oppure che il carico negli esterni diventi più gravoso per la Cpu/Ram ein questo caso il 3200/1Gb si facevano sentire.

Difatto,andava e va tuttora così sul mio PC....

[BTinside]

Originariamente inviato da leoneazzurro
C'è da dire anche che l'architettura 4x2 di NV 35 è più penalizzante rispetto alla 8x1 di R300.


Volevano fare gli soboroni con il multitexturing, pensando di poter dettar legge grazie ai soldini e invece........

[yossarian]

Originariamente inviato da Pat77
Da un intervista a Carmack

"I'm hoping you can clear up some apparent confusion about DOOM3's rendering paths.

1) There is word that you have removed the NV30-specific rendering path
2) The reason for the above is apparently because NVIDIA's drivers have improved to the point where NV3x hardware are running the standard ARB2 path at about equal speed with the NV30-specific path

Could you say if the above is true?

Correct."

Pk77

Se Valve è di parte pensi che Carmack non lo sia? Cosa vuoi che dica? Certo, i drivers NV hanno fatto il "miracolo" e per questo lui ha eliminato la path NV30. Spiegazione poco credibile per una serie di motivi: i drivers per fx che davano incrementi sostanziosi con giochi e bench sintetici erano pieni di cheat (clamoroso quello dei clipping planes col 3DMark2003); il compilatore, panacea di tutti i mali, faceva operazione di shader replacement, sostiutuendo operazioni in fp con operazioni in fx (tanto che bastava una semplice patch di aggiornamento del SW per cui veniva fatta opera di detection, per disabilitare il cosiddetto "compilatore"); lo "standard" di Doom 3 è un ARB2 ritagliato sulle caratteristiche delle Geforce.
Hai notato che ho scritto "standard" e non standard?
L'ARB2 di Doom3 è fatto di poche istruzioni matematiche e molte dependent texture read (le prime indigeste le seconde ottime per i chip NV); lo standard ARB2 prevede l'uso di fp16/fp32, ma nche di calcoli in virgola fissa (e stranamente il ricorso all'utilizzo di fp, in Doom, è molto limitato e circosritto alla modalità pp). Lo "standard" di Doom prevede l'utilizzo di shadow buffer (che contiene due estensioni proprietarie NV e che è una tecnologia sviluppata da nVIDIA già dai tempi dell'NV20, anche se esposta solamente con NV30).

A proposito del lavoro svolto dai drivers, questa è un'altra dichiarazione, sempre di Carmack, sulle operazioni di shder replacement operate dai drivers ATi con A.I. in Doom3

No, I don't think it is a good thing. Drivers should be doing what you tell them, not doing a lot of analysis to try to interpret what you are trying to achieve. One specific negative impact is that if a software vendor ever makes a change to the fragment programs in a point release, all the users will freak out about the performance loss when it falls off the fast path.

However, I do realize that it seems to be pretty much inevitable for popular programs. Nvidia seems to have some very Doom-fragment-program specific optimizations in the NV30 driver paths, so I wouldn't single out ATI over it."


Interessante la parte finale; dopo aver criticato queste ottimizzazioni, conclude ammettendo che i drivers NV fanno qualcosa di analogo (anche con Doom3) e quindi si giustifica il fatto che lo faccia anche ATi


Carmack non è affatto super partes, ma è schierato almeno quanto Valve.


Inoltre, poichè si parla delle prestazioni con ps2.0, invito anche te a dare un'occhiata a questi link in cui si vede chiaramente il rendimento di NV3x con fp16 e fp32 (si tratta di test eseguiti all'uscita di NV40, quindi poco prima del lancio ufficiale di Doom3, ovvero quando, secondo Carmack, i drivers NV avevano già fatto il "miracolo")

http://www.beyond3d.com/previews/nvidia/nv40/index.php?p=21

http://www.beyond3d.com/reviews/ati/r420_x800/index.php?p=17

buona lettura

[Pat77]

Originariamente inviato da yossarian
Se Valve è di parte pensi che Carmack non lo sia? Cosa vuoi che dica? Certo, i drivers NV hanno fatto il "miracolo" e per questo lui ha eliminato la path NV30. Spiegazione poco credibile per una serie di motivi: i drivers per fx che davano incrementi sostanziosi con giochi e bench sintetici erano pieni di cheat (clamoroso quello dei clipping planes col 3DMark2003); il compilatore, panacea di tutti i mali, faceva operazione di shader replacement, sostiutuendo operazioni in fp con operazioni in fx (tanto che bastava una semplice patch di aggiornamento del SW per cui veniva fatta opera di detection, per disabilitare il cosiddetto "compilatore"); lo "standard" di Doom 3 è un ARB2 ritagliato sulle caratteristiche delle Geforce.
Hai notato che ho scritto "standard" e non standard?
L'ARB2 di Doom3 è fatto di poche istruzioni matematiche e molte dependent texture read (le prime indigeste le seconde ottime per i chip NV); lo standard ARB2 prevede l'uso di fp16/fp32, ma nche di calcoli in virgola fissa (e stranamente il ricorso all'utilizzo di fp, in Doom, è molto limitato e circosritto alla modalità pp). Lo "standard" di Doom prevede l'utilizzo di shadow buffer (che contiene due estensioni proprietarie NV e che è una tecnologia sviluppata da nVIDIA già dai tempi dell'NV20, anche se esposta solamente con NV30).

Carmack non è affatto super partes, ma è schierato almeno quanto Valve.


No penso che anche Carmack lo sia e che si sia limitato ad adattarlo per r300 piuttosto che ottimizzarlo.
Ma mentre nv3x con codice generico non si esprime, r2xx, come ho già detto, è molto meno dipendente da svariati fattori, dalla sequenza degli sp, dall'utilizzo o meno della pp, dal numero di text per clock, ecc
Se poi doom3 è influenzato dalla velocità di elaborazione dello stencil è logico che abbia qualche vantaggio nvidia.
Bisognerà valutare quando si passerà a motori nativi a 32 bit ps2.0 quale sarà l'impatto su r300, anche perchè i 24 bit non sono affatto uno standard ma solo un compromesso di passaggio.
Per quanto riguarda il compilatore, ricordo che ai tempi (quando avevo la 5900) si ottenne un buon bust in Halo che risultava leggermente più veloce della controparte ATI (almeno confrontato con 9800 pro).
Da 35 fps circa si passo a 45-50 con la medesima, identica, qualità.
Lo stesso si verificò con aquamark, dopo i primi giochetti sulla qualità, con driver più maturi e evidentemente miglior utilizzo di nv3x, le prestazioni si livellarono fino a superare, leggermente, la 9800pro (mia eterna rivale, posseduta da un mio amico con un sistema praticamente identico al mio).

Pk77

[yossarian]

Originariamente inviato da Pat77
No penso che anche Carmack lo sia e che si sia limitato ad adattarlo per r300 piuttosto che ottimizzarlo.
Ma mentre nv3x con codice generico non si esprime, r2xx, come ho già detto, è molto meno dipendente da svariati fattori, dalla sequenza degli sp, dall'utilizzo o meno della pp, dal numero di text per clock, ecc
Se poi doom3 è influenzato dalla velocità di elaborazione dello stencil è logico che abbia qualche vantaggio nvidia.
Bisognerà valutare quando si passerà a motori nativi a 32 bit ps2.0 quale sarà l'impatto su r300, anche perchè i 24 bit non sono affatto uno standard ma solo un compromesso di passaggio.
Per quanto riguarda il compilatore, ricordo che ai tempi (quando avevo la 5900) si ottenne un buon bust in Halo che risultava leggermente più veloce della controparte ATI (almeno confrontato con 9800 pro).
Da 35 fps circa si passo a 45-50 con la medesima, identica, qualità.
Lo stesso si verificò con aquamark, dopo i primi giochetti sulla qualità, con driver più maturi e evidentemente miglior utilizzo di nv3x, le prestazioni si livellarono fino a superare, leggermente, la 9800pro (mia eterna rivale, posseduta da un mio amico con un sistema praticamente identico al mio).

Pk77

ti ripeto, non è un problema di driver più o meno maturi; i giochi che hai citato sono prevalentemente DX8.x (e le NV3x si difendono bene) con qualche istruzione pseudo-DX9 che i driver NV prontamente trasformavano in ps1.x. Le operazioni di shader replacement, con le fx, erano la regola e questo perchè nVIDIA era consapevole della debolezza dell'NV3x nella gestione di calcoli in fp. Appena uscito NV30, dopo circa una settimana, vennero fuori drivers che alzavano il punteggio del 3DMark2003 di quasi 2000 punti (permettendogli di superare l'R300); dopo pochi giorni ci si accorse che utilizzavano clipping planes, ovvero, tradotto in parole povere, scene prerenderizzate, sfruttando il fatto che le immagini visualizzate erano sempre le stesse. Dopo quella "truffa" si è proceduto in maniera più sottile, fino all'arrivo del famigerato compilatore che, secondo nVIDIA, avrebbe svolto il compito di ordinare le istruzioni in maniera ottimale per NV3x; unico neo è che il compilatore era disattivato da una semplice patch di aggiornamento del SW (ergo, non era un compilatore ma un dispositivo che "individuava" l'applicazione e operava sosituzione degli shader).
Con fp32 le fx non vanno e non andranno mai: questo è un dato di fatto incontrovertibile; fp16 può essere usato, con moderazione, solo su NV35 e NV38 (e comunque fa decadere le prestazioni).
Riguardo al discorso che fp24 non è uno standard c'è da stabilire quale sia il criterio con cui si fissa uno standard; potrei risponderti che è uno degli standard delle DX9a e che perciò è uno standard; oppure potrei dirti che neppure fx12 con cui i chip NV2x, NV3x, NV4x lavorano in virgola fissa è uno standard.
L'output di R3x0, la dove l'applicazione lo richiede, è a 32 bit, anche se i calcoli sono eseguiti con una precisione inferiore (ma d'altra parte, anche se in teoria sono capaci di fp32, neppure i chip NV lavorano con precisione superiore a fp16, tranne, forse, NV40 in qualche caso).

Comunque, dà un'occhiata a quei link che ho aggiunto nel post precedente, così puoi renderti conto dell'andamento delle FX con i calcoli in fp e fare confronti con R3x0, R420 e NV40

[BTinside]

Originariamente inviato da yossarian
ti riporto le parole di Carmack a proposito di Doom3 e NV30 e R300; quest'intervista è un po' datata però dà un quadro chiaro delle potenzialità dei vari chip, anche con un engine diverso da quello di HL2

At the moment, the NV30 is slightly faster on most scenes in Doom than the
R300, but I can still find some scenes where the R300 pulls a little bit
ahead. The issue is complicated because of the different ways the cards can
choose to run the game.

The R300 can run Doom in three different modes: ARB (minimum extensions, no
specular highlights, no vertex programs), R200 (full featured, almost always
single pass interaction rendering), ARB2 (floating point fragment shaders,
minor quality improvements, always single pass).

The NV30 can run DOOM in five different modes: ARB, NV10 (full featured, five
rendering passes, no vertex programs), NV20 (full featured, two or three
rendering passes), NV30 ( full featured, single pass), and ARB2.

The R200 path has a slight speed advantage over the ARB2 path on the R300, but
only by a small margin, so it defaults to using the ARB2 path for the quality
improvements. The NV30 runs the ARB2 path MUCH slower than the NV30 path.
Half the speed at the moment. This is unfortunate, because when you do an
exact, apples-to-apples comparison using exactly the same API, the R300 looks
twice as fast, but when you use the vendor-specific paths, the NV30 wins.

The reason for this is that ATI does everything at high precision all the
time, while Nvidia internally supports three different precisions with
different performances. To make it even more complicated, the exact
precision that ATI uses is in between the floating point precisions offered by
Nvidia, so when Nvidia runs fragment programs, they are at a higher precision
than ATI's, which is some justification for the slower speed. Nvidia assures
me that there is a lot of room for improving the fragment program performance
with improved driver compiler technology.

Ti faccio notare alcune cose:
1) in modalità standard ARB2 R300 è veloce circa il doppio rispetto a NV30 (stiamo parlando di OpenGL)
2) esiste una path specifica per NV30 e non per R300; questa path fa uso di fp32, fp16 e, addirittura, fx12
3) esiste una path R200 diversa da quella NV20 (anche in questo caso, R200 e NV2x sono differenziati; questo significa che sono chip con caratteristiche diverse (R200 è sm1.4, mentre NV25 è sm1.3 e le differenze tra i due non sono poche).

In conclusione, non mi pare scandaloso il fatto che NV2x e R200 siano stati trattati in maniera diversa in HL2 (lo ha fatto anche Carmack); non è scandaloso il fatto che per i chip derivati da NV35 si sia adottata un path diversa da quella standard DX9 (anche secondo ID NV3x in ARB2 standard era molto lento).
Come hai giustamente detto nel finale, si è voluta privilegiare l'esperienza di gioco rinunciando a qualche effetto grafico. Forse si è fatto poco per le Geforce, però, allora, dovrai convenire sul fatto che ID non ha fatto nulla per le Radeon; anzi, dal momento in cui si è rinunciato alla path NV30, questa stessa path è diventata lo standard di fatto del motore grafico del gioco (e questo ha penalizzato non poco i chip ATi).
Si tratta anche, indubbiamente, di scelte politiche (ma questo vale per tutti e due). La differenza è che con Doom3 che rappresenta l'engine più favorevole all'architettura NV le Radeon riescono a difendersi anche utilizzando la modalità "standard"; con HL2 (che rappresenta la situazione più favorevole ad ATi) le Geforce, tranne NV40, hanno, in modalità "standard", prestazioni penose. Questo significa che non si tratta solo di ordinare le istruzioni in maniera differente: quello può appena alleviare i problemi delle fx nella gestione dello sm2.0 ma non risolve affatto i problemi (che sono esclusivamente di natura architetturale).
Anche il famigerato compilatore di cui si parlava mesi fa, che avrebbe dovuto risolvere i problemi delle fx, dopo la querelle con futuremark si è scoperto che non solo riordinava gli shader ma faceva anche application detect e shader replacemnt, spesso usando calcoli in virgola fissa dove era richiesto l'uso di fp.

Mi sapete spiegare con esattezza la vicenda delle ottimizzazioni forzate in "R200" nel glprogs di Doom3 piuttosto che "R300" per le schede Ati,
che anzi poi il sito Megagames rese publiche le istruzioni graize alle quali disattivare queste "anti-ottimizzazioni" abilitando così R300 e recuperando così circa 10fps, che non sono pochi?

[yossarian]

Originariamente inviato da BTinside
Mi sapete spiegare con esattezza la vicenda delle ottimizzazioni forzate in "R200" nel glprogs di Doom3 piuttosto che "R300" per le schede Ati,
che anzi poi il sito Megagames rese publiche le istruzioni graize alle quali disattivare queste "anti-ottimizzazioni" abilitando così R300 e recuperando così circa 10fps, che non sono pochi?


se è come immagino, poichè R200 è la prima GPU ad avere una pixel pipeline strutturata per effettuare operazioni di dependent read (ha 7 stadi contro i 4 dell'NV2x), è probabile che la path R200 preveda l'utilizzo di dependent read in modo copioso; R200 ha una sola unità di calcolo che lavora in fx16 e le operazioni matematiche non sono il suo punto forte; Doom3 basa molto il suo engine sulle operazioni di dependent read; al contrario R3x0 non è che non sia dotato di capacità nell'effettuare dependent read, però sse la cava molto meglio con le operazioni matematiche (rispetto a R200 il blocco preposto ad effettuare calcoli algebrici è stato di molto potenziato). Non escuderei, quindi, che la path R200 forzasse anche l'R200 ad effettuare operazioni di dependent texture read là dove poteva, invece, utilizzare operazioni matematiche (con notevole guadagno prestazionale).
Ovviamente è solo un'ipotesi, però, al momento, non la scarterei a priori.

[rmarango]

Ho trovato un articolo interessante in inglese che fa la comparazione in modo "fair" secondo me tra le due architetture di cui si parla molto in questo thread.

Per chi fosse interessato vada qui :

http://www.penstarsys.com/editor/tech/graphics/nv_ati_dx9/nv_ati_dx9_2.htm


Un piccolo stralcio dove si parla anche di Half life 2 per rimanere in topic...

A quick comparison tells us the underlying story of the two architectures. The R300 and R350/360 chips feature 8 pixel pipelines, each of which acts as a separate pixel shader. In classic pixel processing situations it can produce 8 single textured pixels per pass. Running at 325 MHz plus, it can fill an entire scene at 1600x1200x32 without a problem at fast frame rates. ATI has a very straightforward design with each pipeline in that they take all pixel inputs, whether they are FX12 integer, FP16, FP24, and FP32, and converts them into FP24. FP24 produces very acceptable results in terms of rendering fidelity, even when FP32 is indicated by an application. In today’s current applications, this is not a problem, as the shaders used for games are not as complex compared to what we see with the shader effects made for film. In very complex shaders that require many passes, FP24 is not good enough, and errors in rendering can occur in such situations, this is when FP32 is needed. However, we are not at the point with either software or hardware performance where this becomes an issue. Even the complex shaders that Valve is doing for Half-Life 2 are only a dozen instructions long at most. DX9 PS2.0 in fact specifies a maximum instruction length of 64, while the R300 can handle 96. The NV3x series can handle shaders up to 1024 instructions.

The NV3x architecture is built for maximum flexibility, and that flexibility comes at the price of overall speed in standard pixel shading operations. The NV30 and NV35 appear to have four separate pixel pipelines that handle FX12, FP16, and FP32 natively. These pipelines can sometimes act like an 8 pipeline/1 texture unit, or a 4 pixel/2 texture unit, depending on what exactly is called for in software. Each of the 4 pixel units also acts as a pixel shader, so right off the bat it appears fairly obvious that the Radeon series has an advantage here by having double the pixel shaders as the NVIDIA series. With the NV3x there is no conversion of FX12 into FP16 or 32 (as the R3x0 series does, though with FP 24). By doing this NVIDIA does not suffer a speed penalty as ATI does with the conversion, as most applications that only require FX12 based pixels and shaders run faster on the NV3x series than the R3x0 series. These include many OpenGL, DX7, and DX8 applications. The simple reason for this is internal bandwidth. Native FX12 operations take up significantly less bandwidth inside the chip than FP 24 operations. Only when PS/VS 2.0 applications show up does NVIDIA drop rapidly in performance.

[BTinside]

Originariamente inviato da yossarian
se è come immagino, poichè R200 è la prima GPU ad avere una pixel pipeline strutturata per effettuare operazioni di dependent read (ha 7 stadi contro i 4 dell'NV2x), è probabile che la path R200 preveda l'utilizzo di dependent read in modo copioso; R200 ha una sola unità di calcolo che lavora in fx16 e le operazioni matematiche non sono il suo punto forte; Doom3 basa molto il suo engine sulle operazioni di dependent read; al contrario R3x0 non è che non sia dotato di capacità nell'effettuare dependent read, però sse la cava molto meglio con le operazioni matematiche (rispetto a R200 il blocco preposto ad effettuare calcoli algebrici è stato di molto potenziato). Non escuderei, quindi, che la path R200 forzasse anche l'R200 ad effettuare operazioni di dependent texture read là dove poteva, invece, utilizzare operazioni matematiche (con notevole guadagno prestazionale).
Ovviamente è solo un'ipotesi, però, al momento, non la scarterei a priori.

Per chi ha R300 però disattivando questa opzione del glprogs ottiene circa 10fps di boost prestazionale, mentre chi aveva R200 non vedeva nessun incremento dopo aver effettuato questa operazione, secondo le istruzioni fornite da Megagames

[vegeta88]

Parlo per esperienza personale avendo avuto fino a pochi giorni fà una GeforceFX 5900XT e possedento tuttora una Radeon 9700Pro:
In tutti i casi e ripeto in tutti quando vi è una applicazione 3D facente uso di ShaderModel 2.0 la GeforceFX 5900XT tramite driver ha sempre scalato in PS1.X = es. FarCry - Aquamark 3(per quelle poche istruzioni PS2.0)- HALO - ecc.ecc. quindi VALVE ha pensato bene di fare un un unico path DX8.1 per le FX senza ulteriori problemi e remore.
Con gli applicativi sopracitati forzando l'esecuzione degli shader 2.0 ho sempre assistito ad un calo delle performance elevatissimo.Praticamente FarCry passa da 45 FPS a 20 FPS e il calo prestazionale con gli altri è pressochè uguale.
Ora che la differenza qualitativa tra PS1.X e PS2.0 non sia cosi evidente negli attuali titoli è un dato di fatto, come lo è il calo di prestazioni nel caso dell' NV3X.
Per finire quoto in tutto
yossarian e Fek.

Ciao:) :)

[R@nda]

Originariamente inviato da Myrth
In poche parole qual'è la migliore?e progetti per il futuro dell'nvidia?

Per giocare ad Hl2?

Nvidia 6600/6800/6800GT/6800U
Ati 9600Xt/9700/9700Pro/9800Pro/X600/X700/X800Tutte le versioni

Insomma come puoi ben vedere Nvidia si è ripresa alla grande con l'utlima generazione.
Dalla lista ho tolto le FX perchè in DX 9 girano maluccio,c'è poco da fare...ma come ho detto se la si possiede,ci si gioca bene lo stesso senza troppe rinunce.

Il futuro Nvidia,direi buono,ha in mano un'architettura che permette miglioramenti senza grossi stravolgimenti a lungo termine.
Il futuro Ati Idem,anche se ultimamente si sta posando sugli allori,per me la serie X850 non aveva motivo di esistere,quindi poteva puntare direttamente sul prossimo progetto (R5xx) che promette cose buone.
Naturalmente sono mie conclusioni e opinioni....

[yossarian]

Originariamente inviato da rmarango
Ho trovato un articolo interessante in inglese che fa la comparazione in modo "fair" secondo me tra le due architetture di cui si parla molto in questo thread.

Per chi fosse interessato vada qui :

http://www.penstarsys.com/editor/tech/graphics/nv_ati_dx9/nv_ati_dx9_2.htm


[/i]

conosco quell'articolo e, al contrario di quanto hanno fatto sul forum di B3D (dove l'hanno letteralmente sbranato) ho avuto modo di apprezzarne l'autore; quell'articolo contiene un mare di sciocchezze e lui stesso ha avuto il coraggio di ritrattare pubblicamente con un secondo articolo dell'ottobre 2004. E' una descrizione di come sarebbe dovuto essere NV30 secondo i proclami di nVIDIA e quanto era trapelato on line; nel successivo articolo è riportato, invece, lo stato reale delle cose. L'autore stesso ammette di non essere un esperto del settore (e c'è da credergli sulla parola), quindi, quanto scritto su NV40, R420 e, ancora di più, sul futuro dei chip grafici, prendetelo col beneficio del dubbio (ad esempio ho letto di sfuggita che R520 sarà un chip totalmente nuovo; non è vero: è un R420 con supporto SM3.0 quindi ancora derivante dall'R300); insomma, quando parte per la tangente con disquisizioni tecniche, un po' mi mette ansia :D

http://www.penstarsys.com/editor/so3d/oct_2004/index.html

Non conosco personalmente Josh Walrath ma ne ho apprezzato il coraggio

[yossarian]

Originariamente inviato da BTinside
Per chi ha R300 però disattivando questa opzione del glprogs ottiene circa 10fps di boost prestazionale, mentre chi aveva R200 non vedeva nessun incremento dopo aver effettuato questa operazione, secondo le istruzioni fornite da Megagames


se è come penso, è normale che sia così; R200 si giova delle operazioni di dependent read, R300 è molto più veloce nel calcolo di istruzioni matematiche

[yossarian]

Originariamente inviato da R@nda
Per giocare ad Hl2?

Nvidia 6600/6800/6800GT/6800U
Ati 9600Xt/9700/9700Pro/9800Pro/X600/X700/X800Tutte le versioni

Insomma come puoi ben vedere Nvidia si è ripresa alla grande con l'utlima generazione.
Dalla lista ho tolto le FX perchè in DX 9 girano maluccio,c'è poco da fare...ma come ho detto se la si possiede,ci si gioca bene lo stesso senza troppe rinunce.

Il futuro Nvidia,direi buono,ha in mano un'architettura che permette miglioramenti senza grossi stravolgimenti a lungo termine.
Il futuro Ati Idem,anche se ultimamente si sta posando sugli allori,per me la serie X850 non aveva motivo di esistere,quindi poteva puntare direttamente sul prossimo progetto (R5xx) che promette cose buone.
Naturalmente sono mie conclusioni e opinioni....


hai concluso bene; nVIDIA ha un'architettura valida che, con qualche ritocco e un refresh (con frequenze un po' più alte e processo a 0,11) le permetterà di arrivare fino alle DX next; ATi sta per presentare l'ennesima revisione dell'R300, in seguito con R520 adotterà lo SM3.0.
Insomma, fino all'adozione del modello unificato per ps e vs non dovremmo vedere architetture troppo dissimili dalle attuali. Poi sarà un'altra storia.

:cincin:

[rmarango]

Ho notato che facendo il timedemo (benchmark) con la mappa dei canali in half life 2 (la prima) con dx8.1 e poi con dx9.0, se si tolgono le riflessioni dell'acqua anche in dx9.0, gli fps rimangono praticamente gli stessi (mentre aggiungendo i riflessi gli fps dimezzano ma si puo' fare solo in dx9...)

Nessun'altro ha notato questa cosa ?

Da cosa puo' dipendere secondo voi ?


p.s. io ho una fx5900xt

[rmarango]

Originariamente inviato da yossarian
conosco quell'articolo e, al contrario di quanto hanno fatto sul forum di B3D (dove l'hanno letteralmente sbranato) ho avuto modo di apprezzarne l'autore; quell'articolo contiene un mare di sciocchezze e lui stesso ha avuto il coraggio di ritrattare pubblicamente con un secondo articolo dell'ottobre 2004. E' una descrizione di come sarebbe dovuto essere NV30 secondo i proclami di nVIDIA e quanto era trapelato on line; nel successivo articolo è riportato, invece, lo stato reale delle cose. L'autore stesso ammette di non essere un esperto del settore (e c'è da credergli sulla parola), quindi, quanto scritto su NV40, R420 e, ancora di più, sul futuro dei chip grafici, prendetelo col beneficio del dubbio (ad esempio ho letto di sfuggita che R520 sarà un chip totalmente nuovo; non è vero: è un R420 con supporto SM3.0 quindi ancora derivante dall'R300); insomma, quando parte per la tangente con disquisizioni tecniche, un po' mi mette ansia :D

http://www.penstarsys.com/editor/so3d/oct_2004/index.html

Non conosco personalmente Josh Walrath ma ne ho apprezzato il coraggio

Ok, ti ringrazio per la tua opinione.

[[KabOOm]]

Leggendo questo 3d ho capito la meta della cosa che volevo capire...

...nonostante cio' ho trovato ogni singolo lato tecnico davvero interessante :)

Oltretutto, correggetemi se sbaglio, mi pare di capire che quella differenza del doppio di prestazioni di ATI nei confronti di Nvidia e' inverosimile o meglio colmabile semplicemente con un adeguato sviluppo dei drivers (parlo della nuova generazione di schede video x800 vs 6800).

Sbaglio? :confused:

[leoneazzurro]

La differenza di fps tra le top schede attuali in HL2 si assottiglierà con lo sviluppo dei drivers, come è successo per in Doom3, ma come Nvidia è rimasta avanti in Doom3, ATI rimarrà avanti in HL2 (o meglio, in certe ambientazioni di HL2).
Questo perchè Doom 3 è stato sviluppato avendo in mente l'architettura Nvidia, mentre HL2 quella ATI. E ciò che è bene per una GPU non è bene per l'altra, così come avviene per le CPU AMD e Intel, che "gradiscono" maggiormente certi tipi di programmi (es. AMD la compilazione, Intel il video-editing, ecc.).

[Pat77]

Originariamente inviato da yossarian
ti ripeto, non è un problema di driver più o meno maturi; i giochi che hai citato sono prevalentemente DX8.x (e le NV3x si difendono bene) con qualche istruzione pseudo-DX9 che i driver NV prontamente trasformavano in ps1.x. Le operazioni di shader replacement, con le fx, erano la regola e questo perchè nVIDIA era consapevole della debolezza dell'NV3x nella gestione di calcoli in fp. Appena uscito NV30, dopo circa una settimana, vennero fuori drivers che alzavano il punteggio del 3DMark2003 di quasi 2000 punti (permettendogli di superare l'R300); dopo pochi giorni ci si accorse che utilizzavano clipping planes, ovvero, tradotto in parole povere, scene prerenderizzate, sfruttando il fatto che le immagini visualizzate erano sempre le stesse. Dopo quella "truffa" si è proceduto in maniera più sottile, fino all'arrivo del famigerato compilatore che, secondo nVIDIA, avrebbe svolto il compito di ordinare le istruzioni in maniera ottimale per NV3x; unico neo è che il compilatore era disattivato da una semplice patch di aggiornamento del SW (ergo, non era un compilatore ma un dispositivo che "individuava" l'applicazione e operava sosituzione degli shader).
Con fp32 le fx non vanno e non andranno mai: questo è un dato di fatto incontrovertibile; fp16 può essere usato, con moderazione, solo su NV35 e NV38 (e comunque fa decadere le prestazioni).
Riguardo al discorso che fp24 non è uno standard c'è da stabilire quale sia il criterio con cui si fissa uno standard; potrei risponderti che è uno degli standard delle DX9a e che perciò è uno standard; oppure potrei dirti che neppure fx12 con cui i chip NV2x, NV3x, NV4x lavorano in virgola fissa è uno standard.
L'output di R3x0, la dove l'applicazione lo richiede, è a 32 bit, anche se i calcoli sono eseguiti con una precisione inferiore (ma d'altra parte, anche se in teoria sono capaci di fp32, neppure i chip NV lavorano con precisione superiore a fp16, tranne, forse, NV40 in qualche caso).

Comunque, dà un'occhiata a quei link che ho aggiunto nel post precedente, così puoi renderti conto dell'andamento delle FX con i calcoli in fp e fare confronti con R3x0, R420 e NV40

Mi parli però di situazioni iniziali dove nVidia imbrogliò clamorosamente sul 3dmark. Oggi però tali "trucchetti" sono stati smascherati e disabilitati con una patch, i risultati di nv30, però, sono in linea, se non leggermente inferiori, a quanto ottenibile con una 9800.
Riguardo ai presunti shader replacement, o Nvidia ha trovato la panacea di tutti i mali, o qualcosa non quadra proprio: in Halo, dove di ps 2.0 c'è poco, ha soft edge migliori nelle ombre della controparte Ati; in Far cry, in fp32 (cioè non in fp16 dove era evidente il blending), ha una resa leggermente più compatta, Doom3 è programmato di suo in PP e fa largo uso di shadow maps oltre ad essere plasmato sulle caratteristiche di nv3x, Aquamark, tranne che con una vecchia release di driver, ha una resa identica su entrambe le schede (ps 1.1, pochissimo ps 2.0).
Sarà, ma se ci fosse tutto questo cambiamento di shaders qualche differenza visiva ci dovrebbe pur essere, non evidente come nel passaggio da dx8 a dx9 in Half Life 2, ma comunque quantomeno percepibile.
Il fatto che bene o male, a parità di impostazioni, le due soluzioni restituiscano IQ identiche, se non casi dove è Nvidia in vantaggio (mi viene in mente, tanto per citarne qualcuno, Splinter Cell, Jedi Outcast, UT2003), mi fa pensare che se queste presunte "sostituzioni" vi fossero, non incidendo sulla qualità nè sulla resa, sono vere e proprie ottimizzazioni.
Riguardo allo standard, sappaimo tutti che le prossime GPU sia Ati che Nvidia saranno focalizzate sull'esecuzione di codice in FP32, anche perchè alcuni effetti, come l'HDR lo richiedono già di base (si veda l'abisso qualitativo che vi è abilitandolo in Farcry).

Pk77

[[KabOOm]]

Originariamente inviato da leoneazzurro
La differenza di fps tra le top schede attuali in HL2 si assottiglierà con lo sviluppo dei drivers, come è successo per in Doom3, ma come Nvidia è rimasta avanti in Doom3, ATI rimarrà avanti in HL2 (o meglio, in certe ambientazioni di HL2).
Questo perchè Doom 3 è stato sviluppato avendo in mente l'architettura Nvidia, mentre HL2 quella ATI. E ciò che è bene per una GPU non è bene per l'altra, così come avviene per le CPU AMD e Intel, che "gradiscono" maggiormente certi tipi di programmi (es. AMD la compilazione, Intel il video-editing, ecc.).

Chiaro che sara' cosi' :)

[yossarian]

Originariamente inviato da Pat77
Mi parli però di situazioni iniziali dove nVidia imbrogliò clamorosamente sul 3dmark. Oggi però tali "trucchetti" sono stati smascherati e disabilitati con una patch, i risultati di nv30, però, sono in linea, se non leggermente inferiori, a quanto ottenibile con una 9800.
Riguardo ai presunti shader replacement, o Nvidia ha trovato la panacea di tutti i mali, o qualcosa non quadra proprio: in Halo, dove di ps 2.0 c'è poco, ha soft edge migliori nelle ombre della controparte Ati; in Far cry, in fp32 (cioè non in fp16 dove era evidente il blending), ha una resa leggermente più compatta, Doom3 è programmato di suo in PP e fa largo uso di shadow maps oltre ad essere plasmato sulle caratteristiche di nv3x, Aquamark, tranne che con una vecchia release di driver, ha una resa identica su entrambe le schede (ps 1.1, pochissimo ps 2.0).
Sarà, ma se ci fosse tutto questo cambiamento di shaders qualche differenza visiva ci dovrebbe pur essere, non evidente come nel passaggio da dx8 a dx9 in Half Life 2, ma comunque quantomeno percepibile.
Il fatto che bene o male, a parità di impostazioni, le due soluzioni restituiscano IQ identiche, se non casi dove è Nvidia in vantaggio (mi viene in mente, tanto per citarne qualcuno, Splinter Cell, Jedi Outcast, UT2003), mi fa pensare che se queste presunte "sostituzioni" vi fossero, non incidendo sulla qualità nè sulla resa, sono vere e proprie ottimizzazioni.
Riguardo allo standard, sappaimo tutti che le prossime GPU sia Ati che Nvidia saranno focalizzate sull'esecuzione di codice in FP32, anche perchè alcuni effetti, come l'HDR lo richiedono già di base (si veda l'abisso qualitativo che vi è abilitandolo in Farcry).

Pk77

se leggi quanto ha scritto vegeta88 puoi renderti conto che quanto ho affermato finora non è campato in aria. I drivers NV fanno shader replacement per ogni applicazione che faccia uso anche di una sola istruzione ps2.0. Forse quando hai parlato di blending intendevi banding? In ogni caso, se così è, stai confondendo la precisione di calcolo con l'estensione della gamma dei colori del frame buffer. Il banding deriva dall'utilizzo di un numero di sfumature inferiori a circa 2.800.000, ma questo relativamente al frame buffer. La scarsa precisione interna può determinare solo errori nei calcoli dovuti ad approssimazioni più o meno brutali, che si possono propagare, in caso di istruzioni molto lunghe o di calcoli particolari che richiedono una maggiore accuratezza, e dare luogo a fenomeni quali errori, inferiori dettagli o artefatti nella visualizzazione delle immagini. Giochi come quelli che hai citato fanno un uso molto parco di ps2.0 (e, per lo più, si tratta di istruzioni che potrebbero essere scritte tranquillamente utilizzando sm1.x, per cui la loro sostituzione è quasi del tutto indolore (in alcuni casi sono usati addirittura algoritmi che approssimano le funzione di partenza, come, ad esmepio, sviluppi in serie troncati ai primi ordini, quindi con termine d'errore anche piuttosto grande).
Le sostituzioni non sono affatto "presunte", ma reali. Se un'architettura come quella dell'NV35 è in grado, utilizzando fp16 di fare solo 6 operazioni per ciclo di clock in presenza di input del tipo misto fp/text, contro le 24 dell'R3x0 non sono certo i drivers a poter risolvere questo problema; un compilatore può, semmai, ordinare le istruzioni in maniera diversa, magari con istruzioni text prima e istruzioni fp poi (o viceversa); in tal caso si arriva a 8 istruzioni per ciclo; però più di questo non può fare. Viceversa, con un input del tipo fx/text, sia R3x0 che NV35 svolgono 12 operazioni per ciclo. POichè i giochi da te citati sono prevalentemente DX8.x (anche in HL2 non è che le istruzioni siano tutte istruzioni dx9 "vere", tutt'altro), la differenza di prestazioni è minima e, operando una sostituzione di shader, si ottiene, per l'nv3x, anche il vantaggio, in dx8.x, di una maggiore frequenza di lavoro.
L'HDR è uno di quei pochi effetti che rende al meglio utilizzando fp32; però si può implementare anche utilizzando precisioni di calcolo inferiori (come stava tentando di fare Valve con HL2 e come ha fatto un mio amico di nV Italia che ne ha fatto una versione per ATi).
Ti ripeto di non confondere la precisione di calcolo interna con la qualità dell'immagine visualizzata; tieni conto che se le istruzioni non sono lunghe al punto da originare termini d'errore piuttosto grandi e non trascurabili, al momento della visualizzazione non si nota nulla: le immagini, in qualunque formato siano elaborate, sono sempre trasformate in segnali a 8 bit per canale in virgola fissa una volta che devono essere inviate nel frame buffer.

Infine ti invito a guardare i link dei test di B3D


EDIT: volevo aggiungere qualcosa a proposito delle operazioni di shader replacement o sui cheat nei driver in genere.
Nell'effettuare un'operazione di questo tipo, non ci trovo niente di male se l'IQ non viene alterata in maniera sensibile e se viene migliorata la giocabilità. Qualora, però, si utilizzini i risultati ottenuti come probanti in un benchmark, allora la situazione è completamente diversa; un bench serve a testare la capacità di elaborazione di alcuni tipi di istruzioni da parte dei chip; se due chip girano con codice del tutto diverso (questo significa che è ammesso il riordino delle istruzioni ma non la loro sostituzione), il bench perde di ogni validità. Siccome è fin troppo facile "truccare" i risultati di molti test, personalmente continuo a far riferimento a quei pochi test sintetici che rendono impossibili operazioni di application detect o altro.

[Banus]

Originariamente inviato da Pat77
Doom3 è programmato di suo in PP e fa largo uso di shadow maps oltre ad essere plasmato sulle caratteristiche di nv3x,
Doom 3 usa le stencil shadow che sono una tecnica completamente diversa dalle shadow map.

[yossarian]

Originariamente inviato da rmarango
Ho notato che facendo il timedemo (benchmark) con la mappa dei canali in half life 2 (la prima) con dx8.1 e poi con dx9.0, se si tolgono le riflessioni dell'acqua anche in dx9.0, gli fps rimangono praticamente gli stessi (mentre aggiungendo i riflessi gli fps dimezzano ma si puo' fare solo in dx9...)

Nessun'altro ha notato questa cosa ?

Da cosa puo' dipendere secondo voi ?


p.s. io ho una fx5900xt


unica spiegazione plausibile, IMHO, è che il riflesso dell'acqua sia uno dei pochi effetti che faccia uso di un vero ps2.0.
Anche HL2, al pari di altri giochi, non è un vero full DX9. Neppure R3x0 sarebbe in grado di far girare in maniera fluida un gioco che faccia uso di tutte le feature previste dallo sm2.0 (e nache NV40 e R420 si troverebbero in difficoltà in molti casi; si pensi, ad esempio, alla possibilità di applicare fino a 16 texel per pixel per single pass: già con 4 il frame rate è ridotto a poco più di 1/4 di quello di partenza)

[yossarian]

Originariamente inviato da Banus
Doom 3 usa le stencil shadow che sono una tecnica completamente diversa dalle shadow map.


esatto; inoltre non è programmato in pp ma in un mix tra fp16 e fx12; le stencil shadow contengono almeno 2 estensioni proprietarie NV e si appoggiano sull'uso di uno shadow buffer che è un brevetto NV sin dai tempi dell'NV20.

[rmarango]

Originariamente inviato da yossarian
unica spiegazione plausibile, IMHO, è che il riflesso dell'acqua sia uno dei pochi effetti che faccia uso di un vero ps2.0.
Anche HL2, al pari di altri giochi, non è un vero full DX9. Neppure R3x0 sarebbe in grado di far girare in maniera fluida un gioco che faccia uso di tutte le feature previste dallo sm2.0 (e nache NV40 e R420 si troverebbero in difficoltà in molti casi; si pensi, ad esempio, alla possibilità di applicare fino a 16 texel per pixel per single pass: già con 4 il frame rate è ridotto a poco più di 1/4 di quello di partenza)

Mi sembra una spiegazione molto plausibile.

thanks !

[BTinside]

Originariamente inviato da yossarian
la differenza di prestazioni con fp32 tra NV3x e NV40 non dipende solo dal numero di transistor; R3x0 ha meno transistor di NV3x, eppure va molto meglio. Il problema è il come sono distribuiti questi transistor. NV40 ha un'architettura completamente diversa da NV3x perchè NV40 è un chip progettato per far girare codice Dx9; NV3x no: questa è l'unica differenza.
Ti ripeto l'invito di guardare i due link che ti ho postato: uno è relativo a chip nVIDIA (NV40, NV38, NV35, NV30) l'altro a chip ATi (R420, R3x0). Fai un raffronto tra i valori fatti registrare dai chip ATI della serie R3x0 e quelli nVIDIA della serie NV3x.
Puoi notare che i chip ATi sono sempre in vantaggio ma, mentre con ps1.x, il vantaggio è minore, quando si iniziano ad utilizzare i ps2.0, sia in fp16 che, ancora di più, in fp32, le differenze diventano abissali. Questo non dipende dal numero di transistor ma da come questi transistor sono utilizzati. I valori più bassi (ben inferiori al 25% di cui hai parlato) non dipendono dall'uso di fp32 contro fp24, perchè valori di molto inferiori sono fatti segnare anche con fp16 (dove, secondo i tuoi calcoli, il vantaggio del 25% dovrebbero averlo i chip NV)

Ma rmarango ha un NV3X percaso?
:asd:

Non vuole proprio digerirlo che è l'architettura NV3X a non andare, è inutile giustificare con fp16 o fp32

[Pat77]

Originariamente inviato da Banus
Doom 3 usa le stencil shadow che sono una tecnica completamente diversa dalle shadow map.

Mea culpa, pensavo una cosa ne ho scritta un'altra :muro:

[Banus]

Originariamente inviato da rmarango
Ho notato che facendo il timedemo (benchmark) con la mappa dei canali in half life 2 (la prima) con dx8.1 e poi con dx9.0, se si tolgono le riflessioni dell'acqua anche in dx9.0, gli fps rimangono praticamente gli stessi (mentre aggiungendo i riflessi gli fps dimezzano ma si puo' fare solo in dx9...)
Hai impostato "reflect world" o "reflect all"?
Anche senza coinvolgere gli shader 2.0, l'acqua richiede il rendering a ogni frame della scena riflessa. Questo spiega in parte la differenza di framerate.
Poi i riflessi aggiungono complessità allo shader dell'acqua, perchè aggiungono un termine di fresnel. In questo modo da vicino l'acqua è trasparente, da lontano riflette.

[BTinside]

Originariamente inviato da yossarian
unica spiegazione plausibile, IMHO, è che il riflesso dell'acqua sia uno dei pochi effetti che faccia uso di un vero ps2.0.
Anche HL2, al pari di altri giochi, non è un vero full DX9. Neppure R3x0 sarebbe in grado di far girare in maniera fluida un gioco che faccia uso di tutte le feature previste dallo sm2.0 (e nache NV40 e R420 si troverebbero in difficoltà in molti casi; si pensi, ad esempio, alla possibilità di applicare fino a 16 texel per pixel per single pass: già con 4 il frame rate è ridotto a poco più di 1/4 di quello di partenza)

Allora perchè fanno schede e giochi (vedi half-life 2) che chiamano full directx9 o full directx 9 compilant se poi in realtà abbiamo situazioni "miste" per ciò che concerne i giochi, e cali paurosi di framerate per le schede nel caso in cui queste utilizzano tutte le innovazioni previste dalla DX9 e lo shader 2.0, come per esempio come dici tu le 16 textures in contemporanea?

Se è così figuriamoci se le 6800 dovrebbero far girare un gioco con tutte le caratteristiche dello shader 3.0, sbaglio?

[BTinside]

Piccolo OT

Per Yoss e Fek:

mi spiegate le caratteristiche principali di questo CG di nvidia? come funziona? quali sono le caratteristiche puramente visive che offre? assomiglia alle glide? le tech demo nvidia sono tutte in CG?

"CG" c'entra niente con "Computer Graphics"?

e c'entra niente con le api utilizzate nel cinema per realizzare film come Toy Sory (la cui grafica e stile assomiglia molto alla tech demo "Toys" della serie FX) o Final Fanatsy?

[rmarango]

Originariamente inviato da BTinside
Ma rmarango ha un NV3X percaso?
:asd:

Non vuole proprio digerirlo che è l'architettura NV3X a non andare, è inutile giustificare con fp16 o fp32

Guarda che e' gia' stato chiarito tutto ampiamente ,se avessi avuto la bonta' di rileggerti i post precedenti te ne saresti reso conto...non mi sembra il caso di riaprire polemiche sopite.

Io comunque ho gia' scritto di avere un fx5900...

[rmarango]

Originariamente inviato da Banus
Hai impostato "reflect world" o "reflect all"?
Anche senza coinvolgere gli shader 2.0, l'acqua richiede il rendering a ogni frame della scena riflessa. Questo spiega in parte la differenza di framerate.
Poi i riflessi aggiungono complessità allo shader dell'acqua, perchè aggiungono un termine di fresnel. In questo modo da vicino l'acqua è trasparente, da lontano riflette.

reflect world.

[BTinside]

Originariamente inviato da rmarango
Guarda che e' gia' stato chiarito tutto ampiamente ,se avessi avuto la bonta' di rileggerti i post precedenti te ne saresti reso conto...non mi sembra il caso di riaprire polemiche sopite.

Io comunque ho gia' scritto di avere un fx5900...

Guarda che sono le 13:56 e ci ho messo un ora prima di intervenire, un ora propio perchè mi sono letto tutti i post da dove li avevlo lasciati e cioè alla pagina numero 13, siamo alla 19...:D

[rmarango]

Originariamente inviato da BTinside
Guarda che sono le 13:56 e ci ho messo un ora prima di intervenire, un ora propio perchè mi sono letto tutti i post da dove li avevlo lasciati e cioè alla pagina numero 13, siamo alla 19...:D

Cerca pero' di essere piu' obbiettivo nei tuoi commenti...le battute sull'fp2 lasciano il tempo che trovano...anche se poi le editi.

[BTinside]

Certo perchè ovviamente la battuta sull'fp2 era scontatamente ironica ma per quanto ironica potesse essere era troppo surreale,
perchè fp2 sugli shader 2.0 non penso proprio sia possibile, l'importante però è che mi son corretto.;)

era un amplificazione ironica dell'inefficienza di NV3X con shader model 2.0 e fp32 o 16 che sia,

infatti avevo scritto prima di cancellarla : "anche con un ipotetico fp2 negli shader 2.0 la scheda resta pur sempre inefficiente"
motivo della correzione : non si avrà mai fp2 nello shader 2.0 (almeno credo),

giusto per farti capire che dopo tutte queste pagine di forum con spiegazioni di Yossarian, Fek, leoneazzurro, swarzy etc. e le tue risposte a loro, torniamo sempre sullo stesso punto.:rolleyes:

Ma è giusto che tu da possessore di 5900 tendi a difenderla

[Banus]

Originariamente inviato da BTinside
perchè fp2 sugli shader 2.0 non penso proprio sia possibile, l'importante però è che mi son corretto.;)
Fp2 non ha proprio senso ;)
A meno che non trovi un'applicazione utile per la codifica di un numero con 1 bit di mantissa e un bit di esponente :D

[rmarango]

Originariamente inviato da BTinside
Certo perchè ovviamente la battuta sull'fp2 era scontatamente ironica ma per quanto ironica potesse essere era troppo surreale,
perchè fp2 sugli shader 2.0 non penso proprio sia possibile, l'importante però è che mi son corretto.;)

era un amplificazione ironica dell'inefficienza di NV3X con shader model 2.0 e fp32 o 16 che sia,

infatti avevo scritto prima di cancellarla : "anche con un ipotetico fp2 negli shader 2.0 la scheda resta pur sempre inefficiente"
motivo della correzione : non si avrà mai fp2 nello shader 2.0 (almeno credo),

giusto per farti capire che dopo tutte queste pagine di forum con spiegazioni di Yossarian, Fek, leoneazzurro, swarzy etc. e le tue risposte a loro, torniamo sempre sullo stesso punto.:rolleyes:

Ma è giusto che tu da possessore di 5900 tendi a difenderla

Mi sembrava che gia' tutto fosse chiaro e pacifico, non voglio riaprire polemiche e neanche difendere a tutti i costi la 5900 altrimenti mi meriterei davvero l'appellativo di fanboy...
;)

[Mark75]

Originariamente inviato da Banus
Fp2 non ha proprio senso ;)
A meno che non trovi un'applicazione utile per la codifica di un numero con 1 bit di mantissa e un bit di esponente :D

:confused:

Mazza quanto parlate difficile, mi è venuto il mal di testa

Ma fp32 significa che l'unità vertex esegue calcoli in virgola mobile con precisione a 32bit?

[leoneazzurro]

Qui si parla più di pixel unit che di vertex, Fp32 significa appunto Floating Point 32, ossia virgola mobile a 32 bit.

PS: anche io ho una 5900 XT, sarà poco DX9-like ma per il resto è una signora scheda :P

[R@nda]

Ma è giusto che tu da possessore di 5900 tendi a difenderla

Non mi trovo daccordo,visto che la possiedo anche io....e come vedi Leoneazzurro.
Ne io ne lui ci siamo impuntati sulla difensiva,perchè ci sono fatti e persone che spiegano come stanno le cose.
Ne è venuto fuori un bel thread senza fanatismi....sopratutto perchè nessuno ha fatto battute e troppa polemica.

[BTinside]

Originariamente inviato da rmarango
Mi sembrava che gia' tutto fosse chiaro e pacifico, non voglio riaprire polemiche e neanche difendere a tutti i costi la 5900 altrimenti mi meriterei davvero l'appellativo di fanboy...
;)


Perdon;)

[BTinside]

Originariamente inviato da leoneazzurro
Qui si parla più di pixel unit che di vertex, Fp32 significa appunto Floating Point 32, ossia virgola mobile a 32 bit.

PS: anche io ho una 5900 XT, sarà poco DX9-like ma per il resto è una signora scheda :P

Quanto riesci a spingerla come frequenze?

[leoneazzurro]

Dunque, sono riuscito a portarla a 440/920.
Però è una XFX; il che significa che occupa 2 slot ed ha le RAM a default a 800.

[Pat77]

Originariamente inviato da yossarian
se leggi quanto ha scritto vegeta88 puoi renderti conto che quanto ho affermato finora non è campato in aria. I drivers NV fanno shader replacement per ogni applicazione che faccia uso anche di una sola istruzione ps2.0. Forse quando hai parlato di blending intendevi banding? In ogni caso, se così è, stai confondendo la precisione di calcolo con l'estensione della gamma dei colori del frame buffer. Il banding deriva dall'utilizzo di un numero di sfumature inferiori a circa 2.800.000, ma questo relativamente al frame buffer. La scarsa precisione interna può determinare solo errori nei calcoli dovuti ad approssimazioni più o meno brutali, che si possono propagare, in caso di istruzioni molto lunghe o di calcoli particolari che richiedono una maggiore accuratezza, e dare luogo a fenomeni quali errori, inferiori dettagli o artefatti nella visualizzazione delle immagini. Giochi come quelli che hai citato fanno un uso molto parco di ps2.0 (e, per lo più, si tratta di istruzioni che potrebbero essere scritte tranquillamente utilizzando sm1.x, per cui la loro sostituzione è quasi del tutto indolore (in alcuni casi sono usati addirittura algoritmi che approssimano le funzione di partenza, come, ad esmepio, sviluppi in serie troncati ai primi ordini, quindi con termine d'errore anche piuttosto grande).
Le sostituzioni non sono affatto "presunte", ma reali. Se un'architettura come quella dell'NV35 è in grado, utilizzando fp16 di fare solo 6 operazioni per ciclo di clock in presenza di input del tipo misto fp/text, contro le 24 dell'R3x0 non sono certo i drivers a poter risolvere questo problema; un compilatore può, semmai, ordinare le istruzioni in maniera diversa, magari con istruzioni text prima e istruzioni fp poi (o viceversa); in tal caso si arriva a 8 istruzioni per ciclo; però più di questo non può fare. Viceversa, con un input del tipo fx/text, sia R3x0 che NV35 svolgono 12 operazioni per ciclo. POichè i giochi da te citati sono prevalentemente DX8.x (anche in HL2 non è che le istruzioni siano tutte istruzioni dx9 "vere", tutt'altro), la differenza di prestazioni è minima e, operando una sostituzione di shader, si ottiene, per l'nv3x, anche il vantaggio, in dx8.x, di una maggiore frequenza di lavoro.
L'HDR è uno di quei pochi effetti che rende al meglio utilizzando fp32; però si può implementare anche utilizzando precisioni di calcolo inferiori (come stava tentando di fare Valve con HL2 e come ha fatto un mio amico di nV Italia che ne ha fatto una versione per ATi).
Ti ripeto di non confondere la precisione di calcolo interna con la qualità dell'immagine visualizzata; tieni conto che se le istruzioni non sono lunghe al punto da originare termini d'errore piuttosto grandi e non trascurabili, al momento della visualizzazione non si nota nulla: le immagini, in qualunque formato siano elaborate, sono sempre trasformate in segnali a 8 bit per canale in virgola fissa una volta che devono essere inviate nel frame buffer.

Infine ti invito a guardare i link dei test di B3D


EDIT: volevo aggiungere qualcosa a proposito delle operazioni di shader replacement o sui cheat nei driver in genere.
Nell'effettuare un'operazione di questo tipo, non ci trovo niente di male se l'IQ non viene alterata in maniera sensibile e se viene migliorata la giocabilità. Qualora, però, si utilizzini i risultati ottenuti come probanti in un benchmark, allora la situazione è completamente diversa; un bench serve a testare la capacità di elaborazione di alcuni tipi di istruzioni da parte dei chip; se due chip girano con codice del tutto diverso (questo significa che è ammesso il riordino delle istruzioni ma non la loro sostituzione), il bench perde di ogni validità. Siccome è fin troppo facile "truccare" i risultati di molti test, personalmente continuo a far riferimento a quei pochi test sintetici che rendono impossibili operazioni di application detect o altro.

Una 5900 l'ho avuta anche io, per più di un anno, e per più di un anno ho confrontato i vari giochi con un mio compare dotato di 9800 pro.
L'ho confrontata nell'unico modo possibile: giocando.
E giocando, quando c'erano differenze, cheat, perdita di qualità, con la massima onestà l'ho ammesso, proprio perchè alla fine a me interessava capire più che intestardirmi.
Così come lui, in alcune circostanze (splinter cell) ha notato differenze.
Ora possiamo stare qui secoli a parlare di architetture, FPA, pixel shaders e pixel/textel output, o di replacement più presunto che concreto, ma alla fine della fiera quello che mi ritrovo nel frame buffer è il valore che conta.
Trovo assurdo sostenere che alcuni bench non siano significativi perchè ottenuti con "calcoli" differenti, non paritetici, quando il risultato sia visivo che di esperienza è identico.
Dimostrazioni di forza bruta sono fini a se stesse, imho, inoltre le architetture, se valide o meno, si scoprono negli anni: oggi come oggi possiamo valutare a 360 gradi solo le soluzioni dx8.0-8.1 di Geforce/Radeon nv2x e r2xx.

Pk77

[Vifani]

Originariamente inviato da BTinside
Piccolo OT

Per Yoss e Fek:

mi spiegate le caratteristiche principali di questo CG di nvidia? come funziona? quali sono le caratteristiche puramente visive che offre? assomiglia alle glide? le tech demo nvidia sono tutte in CG?

"CG" c'entra niente con "Computer Graphics"?

e c'entra niente con le api utilizzate nel cinema per realizzare film come Toy Sory (la cui grafica e stile assomiglia molto alla tech demo "Toys" della serie FX) o Final Fanatsy?

CG sta per "C for Graphics" ed è un linguaggio ad alto livello sviluppato da NVIDIA esattamente come l'HLSL delle DirectX 9 o il GLSL di OpenGL 1.5. La differenza sostanziale tra CG e gli altri è che il CG può lavorare sia con OpenGL che con Direct 3D: nella sua inizializzazione si decide quale "profilo" usare e, in base a questo, il compilatore CG traduce lo shader da linguaggio CG ad un linguaggio ASM per Direct 3D o per OpenGL.

In realtà comunque il CG è stato un flop in quanto:

1) E' risultato essere una copia in tutto e per tutto dell'HLSL di Microsoft (si può fare copia/incolla senza avere errori di sintassi :)).

2) E' stato proposto da NVIDIA come linguaggio per la descrizione degli shader ad alto livello per l'OpenGL, ma è stato bocciato dall'OpenGL ARB in favore del GLSLang di 3DLabs (che è il GLSL che attualmente vediamo nell'OpenGL 1.5).

La stessa NVIDIA ha ridotto il supporto per il CG visto che alla fini gli sviluppatore Direct 3D usano HLSL e quelli OpenGL useranno GLSL.

[Pat77]

Originariamente inviato da Vifani
CG sta per "C for Graphics" ed è un linguaggio ad alto livello sviluppato da NVIDIA esattamente come l'HLSL delle DirectX 9 o il GLSL di OpenGL 1.5. La differenza sostanziale tra CG e gli altri è che il CG può lavorare sia con OpenGL che con Direct 3D: nella sua inizializzazione si decide quale "profilo" usare e, in base a questo, il compilatore CG traduce lo shader da linguaggio CG ad un linguaggio ASM per Direct 3D o per OpenGL.

In realtà comunque il CG è stato un flop in quanto:

1) E' risultato essere una copia in tutto e per tutto dell'HLSL di Microsoft (si può fare copia/incolla senza avere errori di sintassi :)).

2) E' stato proposto da NVIDIA come linguaggio per la descrizione degli shader ad alto livello per l'OpenGL, ma è stato bocciato dall'OpenGL ARB in favore del GLSLang di 3DLabs (che è il GLSL che attualmente vediamo nell'OpenGL 1.5).

La stessa NVIDIA ha ridotto il supporto per il CG visto che alla fini gli sviluppatore Direct 3D usano HLSL e quelli OpenGL useranno GLSL.

Era il tentativo di standarizzare il linguaggio ad alto livello su caratteristiche "nvidia", dovuto in parte al superamento delle specifiche dx con la serie fx.
Che sia stato un flop trapela anche dalle parole della stessa nvidia che ora ha sposrtato i suoi sforzi su HLSL.

Pk77

[rmarango]

Originariamente inviato da Pat77
Era il tentativo di standarizzare il linguaggio ad alto livello su caratteristiche "nvidia", dovuto in parte al superamento delle specifiche dx con la serie fx.
Che sia stato un flop trapela anche dalle parole della stessa nvidia che ora ha sposrtato i suoi sforzi su HLSL.

Pk77

Pero' se non vado errato tutte le demo piu' spettacolari di Nvidia sono fatte proprio in Cg.

Parlo di quelle demo con la donna libellula o la sirenetta.

[BTinside]

Originariamente inviato da rmarango
Pero' se non vado errato tutte le demo piu' spettacolari di Nvidia sono fatte proprio in Cg.

Parlo di quelle demo con la donna libellula o la sirenetta.


Volevo sapere sopratutto questo
Timbury e in CG?
i film Toy Story e Final F come sono realizzati?

[rmarango]

Originariamente inviato da BTinside
Volevo sapere sopratutto questo
Timbury e in CG?
i film Toy Story e Final F come sono realizzati?

In questo link c'e' una news di hwupgrade (un po' datata) dove si parlava proprio di Cg e film d'animazione nello stile final fantasy.

http://news.hwupgrade.it/6514,1-10.html

[R@nda]

Spetta le demo sono una cosa i film in CG un altra.

Per fare i film usano programmi 3d (Maya,Renderman,Xsi in particolare) che centrano poco col CG di Nvidia.

[leoneazzurro]

I film c'entrano poco con la grafica in real-time dei giochi.

Vengono fatti mediante rendering frame per frame su delle cosiddette "render farm", ossia cluster di workstation che fanno lavoro di rendering.

[Pat77]

Poi vanno all'invidiabile frame rate di 1/2h (1 frame ogni 2 ore :D)

Pk77

[Banus]

Originariamente inviato da R@nda
Per fare i film usano programmi 3d (Maya,Renderman,Xsi in particolare) che centrano poco col CG di Nvidia.

Le sparate di Nvidia sulla convergenza CG - VG sono solo marketing ;)

Nei film ormai si usa molto il linguaggio Renderman della Pixar. So di sicuro che è stato usato in tutti i film della Pixar e nel film di FinalFantasy.
Lo shader language di Renderma è molto simile a HLSL (ha sintassi C-like) ma è molto più potente. Infatti Ati dai tempi dell'R300 ha rilasciato un tool che permette di convertire gli shader Renderman in HLSL.

[rmarango]

Originariamente inviato da R@nda
Spetta le demo sono una cosa i film in CG un altra.

Per fare i film usano programmi 3d (Maya,Renderman,Xsi in particolare) che centrano poco col CG di Nvidia.

Questo e' quello che veniva riportato:

"Uno dei principali obiettivi di nVidia con la prossima generazione di chip video è quella di avvicinare sempre più la grafica 3D dei PC ad un'esperienza real time, che quindi permetta di avere in tempo reale sul proprio monitor lo stesso livello di scene e di qualità d'immagine visualizzati nei più recenti film di animazione, come Final Fantasy".

Non escluderei a priori che si possano usare le Cg anche per dei film d'animazione.

[yossarian]

Originariamente inviato da Pat77
Una 5900 l'ho avuta anche io, per più di un anno, e per più di un anno ho confrontato i vari giochi con un mio compare dotato di 9800 pro.
L'ho confrontata nell'unico modo possibile: giocando.
E giocando, quando c'erano differenze, cheat, perdita di qualità, con la massima onestà l'ho ammesso, proprio perchè alla fine a me interessava capire più che intestardirmi.
Così come lui, in alcune circostanze (splinter cell) ha notato differenze.
Ora possiamo stare qui secoli a parlare di architetture, FPA, pixel shaders e pixel/textel output, o di replacement più presunto che concreto, ma alla fine della fiera quello che mi ritrovo nel frame buffer è il valore che conta.
Trovo assurdo sostenere che alcuni bench non siano significativi perchè ottenuti con "calcoli" differenti, non paritetici, quando il risultato sia visivo che di esperienza è identico.
Dimostrazioni di forza bruta sono fini a se stesse, imho, inoltre le architetture, se valide o meno, si scoprono negli anni: oggi come oggi possiamo valutare a 360 gradi solo le soluzioni dx8.0-8.1 di Geforce/Radeon nv2x e r2xx.

Pk77

forse giocando è l'unico modo che hai tu di confrontarle; io mi occupo di architetture e giudico la loro efficienza su altri parametri. Il gioco è tutt'altra cosa, ben distinta dal lavoro. Quindi, se vuoi affermare che con giochi praticamente DX8 non c'è differenza tra un R3x0 e un NV3x (o esistono differenze minime), allora possodartene atto; se, però, continui a sostenere tesi quali "NV3x è più avanzato ma non sfruttato a dovere", "con il CG sarebbe cambiato tutto", "in DX9 con i drivers adatti NV3x è uguale (o magari migliore) di R3x0", allora non posso che dirti di restare pure con le rtue illusioni. I fatti parlano chiaro: NV3x è un'architettura non DX9, poco efficiente e, per tanti versi, sbagliata. L'articolo postato da rmarango afferma le stesse cose che stai dicendo tu ed è stato subissato di critiche da chi frequenta forum tecnici come quello di B3D, soprattutto perchè intempestivo, in quanto uscito in un periodo in cui ormai erano noti a tutti i problemi delle fx, a cominciare da quello relativo ai registri temporanei (che posso affermare, senza falsa modestia, di essere stato il primo a sollevare, in un thread su questo forum, ben due mesi prima che uscisse l'articolo di 3DCenter che lo ha reso pubblico); lo stesso autore si è premurato di smentire quanto aveva scritto in quell'articolo, poco meno di un anno dopo, prendendone le distanze. La stessa nVIDIA ha implicitamente ammesso gli errori commessi con NV30 nel momento in cui, per NV40, ha adottato un'architettura che prende molti spunti proprio da quella dell'R300, a cominciare dall'unica tmu e dalla doppia fpu, per passare alle unità VS, praticamente identiche (esclusa texture unit e branch predictor) a quelle dell'R300, all'architettura superscalare, esasperazione della 3+1 delle pixel pipeline dell'R300 (e utile per minimizzare la dipendenza tra tmu e alu, triste eredità della serie NV3x) e per finire con l'adozione di una pattern RG per l'AA.

Per quanto riguarda il discorso benchmark, dal mio punto di vista è del tutto inaccettabile confrontare due gpu che fanno girare codice diverso; il truccare un bench con operazioni di shader replacement che facciano lavorare in fx anzichè in fp è una truffa a tutti gli effetti, indipendentemente da chi lo fa e dal livello dell'IQ, perchè i risultati non sono veritieri.

[leoneazzurro]

Le Cg sono ormai defunte, o quasi. Questo è il punto.
Inoltre la grafica nei film viene renderizzata con una precisione ed una risoluzione impensabili rispetto a quanto visibili oggi sui nostri monitor (es. ricordiamoci che si deve effettuare la proiezione su uno schermo di dimensioni gigantesche). Per quanto in futuro ci si avvicinerà a quegli standard, seppure in piccolo, il cammino è ancora lungo.....

[R@nda]

Originariamente inviato da rmarango
Questo e' quello che veniva riportato:

"Uno dei principali obiettivi di nVidia con la prossima generazione di chip video è quella di avvicinare sempre più la grafica 3D dei PC ad un'esperienza real time, che quindi permetta di avere in tempo reale sul proprio monitor lo stesso livello di scene e di qualità d'immagine visualizzati nei più recenti film di animazione, come Final Fantasy".

Non escluderei a priori che si possano usare le Cg anche per dei film d'animazione.
Quella è stata una dimostrazione da parte di Nvidia per la presentazione dell'Nv30,se ricordo bene.
Avevano ricostruito uno spezzo del film Finalfantasy in versione depotenziata tramite Cg per far vedere il risultato raggiunto.

Tutto si può fare ma il Cg non è uno strumento di animazione/creazione grafica 3d e rendering è un linguaggio di programmazione per sk grafiche consumer.
Tant'è che Nvidia adesso vende Gelato per fare questi lavori.

[yossarian]

Originariamente inviato da R@nda
Non mi trovo daccordo,visto che la possiedo anche io....e come vedi Leoneazzurro.
Ne io ne lui ci siamo impuntati sulla difensiva,perchè ci sono fatti e persone che spiegano come stanno le cose.
Ne è venuto fuori un bel thread senza fanatismi....sopratutto perchè nessuno ha fatto battute e troppa polemica.


ma, infatti, non c'è nulla di cui ci si debba difendere. Non è colpa tua o mia o di chiunque altro se le fx con i ps2.0 non vanno; dipende solo dal fatto che sono nate come chip dx8.x, con l'aggiunta di feature dx9 (necessarie perchè, nel frattempo, erano state rilasciate le nuove api MS).
Non si tratta di essere fanatici o meno; NV40 è una buona architettura (si può migliorare, però è già molto effiicente così) e nessuno credo possa obiettare al riguardo. Per quale motivo NV30 è uscito con tanto ritardo e c'è stato tanto mistero circa le sue specifiche reali (che si sono dovute scoprire di volta in volta, quando si vedeva che i risultati teorici e quelli pratici non coincidevano) e NV40 non ha subito ritardi e nVIDIA si è subito affrettata a rilasciare informazioni anche abbastanza dettagliate sulla sua architettura?

Vorrei invitare la gente a riflettere anche su queste cose.

[leoneazzurro]

Come ad esempio il fatto che non esistano praticamente benchmark riguardanti l'EMT 64.
Opss... l'ho detto. Non sparatemi! ;)

[Pat77]

NV3x è più avanzato ma non sfruttato a dovere

Dove l'avrei detto?

con il CG sarebbe cambiato tutto

Dove?

in DX9 con i drivers adatti NV3x è uguale (o magari migliore) di R3x0

Dove?

Per quanto riguarda il discorso benchmark, dal mio punto di vista è del tutto inaccettabile confrontare due gpu che fanno girare codice diverso; il truccare un bench con operazioni di shader replacement che facciano lavorare in fx anzichè in fp è una truffa a tutti gli effetti, indipendentemente da chi lo fa e dal livello dell'IQ, perchè i risultati non sono veritieri.

Certo se trucchi i bench sono daccordo, ma se ottieni il medesimo risultato per strade diverse non vedo dove sia lo scandalo, anzi.
Se no condanniamo anche il Kiro2, tutte le ottimizzazioni della banda ecc.. perchè per certi aspetti cheattano e non mostrano in termini di potenza bruta la validità di un'architettura.
Validità di un'architettura appunto che non è, non deve essere un dato puramente teorico ma deve confrontarsi con il fine, in questo caso i videogiochi.

Pk77

[vegeta88]

Originariamente inviato da Pat77

Certo se trucchi i bench sono daccordo, ma se ottieni il medesimo risultato per strade diverse non vedo dove sia lo scandalo, anzi.
Se no condanniamo anche il Kiro2, tutte le ottimizzazioni della banda ecc.. perchè per certi aspetti cheattano e non mostrano in termini di potenza bruta la validità di un'architettura.
Validità di un'architettura appunto che non è, non deve essere un dato puramente teorico ma deve confrontarsi con il fine, in questo caso i videogiochi.

Pk77

Allora se le ottimizzazioni hanno il solo scopo di poter far rendere al meglio una particolare architettura NV3X con i soli giochi ben vengano.
Però quando si tratta di bench il discorso si trasferisce sul marketing,che NVIDIA ha dovuto effettuare per far vendere i propri chip.confrontabili sia come prestazioni che come qualità alla controparte ATI R3XX e questo purtroppo per mè non è del tutto regolare.
Con queste affermazioni io non voglio criticare schede come la 5900XT , ottime sotto il profilo prezzo-prestazioni, ma bensi il fatto del presentare un'architettura DX 9.0 che all'atto pratico risulta inutilizzabile.
Me ne faccio ben poco di 5500 punti al 3dmark 2003 o di 44000 punti all'aquamark 3 perchè quando faccio partire FarCry e HalLife2 e forzo l'esecuzione delle DX 9.0 e mi ritrovo a giocare con 20FPS.

Ciao
:) :)

[Athlon 64 3000+]

Sono da 1 e anno e mezzo che si parla dell'nv3x e si sa che quella architettura è un fiasco completo,tanto che tuttora per me le fx sono dei cessi di schede,mi potete tirare tutti i nomi che vi pare ma io la penso così.
La passata generazione le Ati erano molto meglio e in HL2 viene dimostrato con il path dx 9.
Con L'NV40 Nvidia si è rifatta alla grande tanto che sono un felice possessore di una 6800GT che alla fine la ho preferita alla X800Pro e X800XT anche se una volta preferivo L'r420 ma dopo che ho letto quello che diceva Yossarian sulle 2 archittetture ho fatto la mia scelta.
Non mi venite a dire che sono di parte perchè ho avuto da aprile 2000 a maggio 2003 schede Nvidia e da maggio 2003 a novembre 2004 schede Ati e adesso dopo aver provato seriamente una 6800Gt ritengo milgiore NV40 di R420 e anche se fino a poco tempo fa preferivo R420 e NV40 ho cambiato idea.

[rmarango]

Originariamente inviato da Athlon 64 3000+
Sono da 1 e anno e mezzo che si parla dell'nv3x e si sa che quella architettura è un fiasco completo,tanto che tuttora per me le fx sono dei cessi di schede,mi potete tirare tutti i nomi che vi pare ma io la penso così.
La passata generazione le Ati erano molto meglio e in HL2 viene dimostrato con il path dx 9.
Con L'NV40 Nvidia si è rifatta alla grande tanto che sono un felice possessore di una 6800GT che alla fine la ho preferita alla X800Pro e X800XT anche se una volta preferivo L'r420 ma dopo che ho letto quello che diceva Yossarian sulle 2 archittetture ho fatto la mia scelta.
Non mi venite a dire che sono di parte perchè ho avuto da aprile 2000 a maggio 2003 schede Nvidia e da maggio 2003 a novembre 2004 schede Ati e adesso dopo aver provato seriamente una 6800Gt ritengo milgiore NV40 di R420 e anche se fino a poco tempo fa preferivo R420 e NV40 ho cambiato idea.

Finalmente un contributo moderato ed obiettivo... ;)

[rmarango]

Originariamente inviato da vegeta88
Allora se le ottimizzazioni hanno il solo scopo di poter far rendere al meglio una particolare architettura NV3X con i soli giochi ben vengano.
Però quando si tratta di bench il discorso si trasferisce sul marketing,che NVIDIA ha dovuto effettuare per far vendere i propri chip.confrontabili sia come prestazioni che come qualità alla controparte ATI R3XX e questo purtroppo per mè non è del tutto regolare.
Con queste affermazioni io non voglio criticare schede come la 5900XT , ottime sotto il profilo prezzo-prestazioni, ma bensi il fatto del presentare un'architettura DX 9.0 che all'atto pratico risulta inutilizzabile.
Me ne faccio ben poco di 5500 punti al 3dmark 2003 o di 44000 punti all'aquamark 3 perchè quando faccio partire FarCry e HalLife2 e forzo l'esecuzione delle DX 9.0 e mi ritrovo a giocare con 20FPS.

Ciao
:) :)


Perfettamente d'accordo in tutto.

[yossarian]

Originariamente inviato da Pat77
Dove l'avrei detto?



Dove?



Dove?



Certo se trucchi i bench sono daccordo, ma se ottieni il medesimo risultato per strade diverse non vedo dove sia lo scandalo, anzi.
Se no condanniamo anche il Kiro2, tutte le ottimizzazioni della banda ecc.. perchè per certi aspetti cheattano e non mostrano in termini di potenza bruta la validità di un'architettura.
Validità di un'architettura appunto che non è, non deve essere un dato puramente teorico ma deve confrontarsi con il fine, in questo caso i videogiochi.

Pk77


dove l'avresti detto? Non esplicitamente, ma continuando a dire che introdurre "ottimizzazioni" nei driver (ottimizzazioni tra "*") è una cosa lecita e che con gli utlimi driver nVIDIA ha rimesso le cose a posto senza trucchi sfruttando le vere potenzialità di NV3x (cosa non vera), parlando del CG come di qualcosa di estremamente avanzato che avrebbe dato il suo contributo all'esaltazione dell'architettura dell'NV3x, hai detto tutto questo e anche altro. Non ho parlato certo io di superamento, da parte delle fx, delle specifiche dx e del fatto che il CG avrebbe esaltato queste doti "in più" delle fx. Al contrario, ho sempre sostenuto che le fx hanno un'architettura dx8.1 (altro che "oltre le dx9") con feature dx9 (solo per potersi tacciare di compatibilità con le nuove api MS).
Continui a parlare di forza bruta; forza bruta di chi? Dell'R300? Mi pare sia stata nVIDIA a portare un chip oltre le sue specifiche di funzionamento (tanto da dover usare l'aspirapolvere per raffreddarlo)! Oppure pensi che NV30 era nato veramente con quelle frequenze e quel "coso" al posto del dissipatore? E poi, forza bruta contro cosa? Quale tipo di codice, secondo te, NV30 elabora meglio di R300, facendo riferimento alle DX9? Si è parlato, in molte presentazioni, a sproposito, del fatto che NV30 poteva gestire shader molto più lunghi di R300; si è visto, dai test, che uno shader che impegni 4 registri temporanei è macinato con disinvoltura da R300 e fa calare le prestazioni di NV30 a livelli pietosi.
Se vuoi continuare a dar retta ai proclami dei pr sei libero di farlo, come sei libero di credere alle locandine pubblicitarie, a babbo natale e persino a Vanna Marchi. Volendo possiamo anche impostare la discussione su questi parametri; però si sappia che non si parla per nozioni tecniche ma per messaggi promozionali.

Ottimizzazioni. Il Kyro 2 ottimizza cosa? Non mi risulta che modfichi le istruzioni; ribalta semplicemente l'ordine di rendering, ricorrendo ad un più logico post texturing piuttosto che all'assurdo per-texturing dei chip che lo hanno preceduto. La validità di un'architettura non è data dalla potenza bruta; R300 vale 10 volte NV30 perchè è molto più veloce e lavora a frequenze inferiori del 60%.
Dov'è lo scandalo in certe ottimizzazioni? Semplice: faccio girare sul chip A codice ps1.1 e ottengo 90 fps, sul B codice ps2.0 e ottengo 83 fps, il banch dovrebbe testare la capacità dei due chip di elaborare codice ps2.0. Qual è la conclusione del test? A è più veloce di B. Secondo te la conclusione è corretta? Per me è una truffa, perchè chi compra è convinto che A possa elaborare shader 2.0 più velocemente di B; quando A si troverà a dover realmente elaborare ps2.0, l'utente risulterà insoddisfatto e non si spiegherà il perchè delle prestazioni penose della sua schede video, pagata così cara e che fino ad allora andava così bene.
Per te è accettabile una cosa del genere?

[rmarango]

Originariamente inviato da yossarian
Per me è una truffa, perchè chi compra è convinto che A possa elaborare shader 2.0 più velocemente di B; quando A si troverà a dover realmente elaborare ps2.0, l'utente risulterà insoddisfatto e non si spiegherà il perchè delle prestazioni penose della sua schede video, pagata così cara e che fino ad allora andava così bene.


In effetti io l'ho comprata anche perche' c'era scritto DX9 compliant da qualche parte...evidentemente c'e' qualcosa che non torna, come giustamente sottolinei.
L'unica consolazione e' che ancora questo divario in termini di resa grafica tra i due shader model non sia cosi evidente con i games attuali.

[Pat77]

dove l'avresti detto? Non esplicitamente, ma continuando a dire che introdurre "ottimizzazioni" nei driver (ottimizzazioni tra "*") è una cosa lecita e che con gli utlimi driver nVIDIA ha rimesso le cose a posto senza trucchi sfruttando le vere potenzialità di NV3x (cosa non vera), parlando del CG come di qualcosa di estremamente avanzato che avrebbe dato il suo contributo all'esaltazione dell'architettura dell'NV3x, hai detto tutto questo e anche altro. Non ho parlato certo io di superamento, da parte delle fx, delle specifiche dx e del fatto che il CG avrebbe esaltato queste doti "in più" delle fx. Al contrario, ho sempre sostenuto che le fx hanno un'architettura dx8.1 (altro che "oltre le dx9") con feature dx9 (solo per potersi tacciare di compatibilità con le nuove api MS).

Andiamo con ordine: introdurre driver che guidano una GPU ad elaborare, secondo i suoi punti di forza, riproducendo immagini IDENTICHE alla controparte concorrente, vuoi per altre vie, vuoi con altri principi, vuoi come vuoi, ma avendo in fin dei conti un risultato IDENTICO in termini qualitativi, non è cheattare ma ottimizzare.

Diminuire la qualità dell'immaggine, ottenere prestazioni pilotate nei soli bench, questo è cheattare. Sia Nvidia (3dmark, aquamark, ecc..) sia Ati (quak3,ec..) hanno usato questa pratica discutibile.

Cg nacque, ti sfido a dire il contrario, per cercare di standarizzare la programmazione degli shaders con GPU nvidia e supportava tutti quei set di istruzioni che andavano oltre le specifiche di Dx 9.0 supportate dalla serie Fx.

Continui a parlare di forza bruta; forza bruta di chi? Dell'R300? Mi pare sia stata nVIDIA a portare un chip oltre le sue specifiche di funzionamento (tanto da dover usare l'aspirapolvere per raffreddarlo)! Oppure pensi che NV30 era nato veramente con quelle frequenze e quel "coso" al posto del dissipatore? E poi, forza bruta contro cosa? Quale tipo di codice, secondo te, NV30 elabora meglio di R300, facendo riferimento alle DX9? Si è parlato, in molte presentazioni, a sproposito, del fatto che NV30 poteva gestire shader molto più lunghi di R300; si è visto, dai test, che uno shader che impegni 4 registri temporanei è macinato con disinvoltura da R300 e fa calare le prestazioni di NV30 a livelli pietosi.
Se vuoi continuare a dar retta ai proclami dei pr sei libero di farlo, come sei libero di credere alle locandine pubblicitarie, a babbo natale e persino a Vanna Marchi. Volendo possiamo anche impostare la discussione su questi parametri; però si sappia che non si parla per nozioni tecniche ma per messaggi promozionali.

Io parlo di forza bruta riferendomi a r300, è evidente. Parlo di codice specifico per nv30. Penso che nei calcoli sullo Stencil abbia un certo vantaggio.
Riguardo all'ultima parte di questo tuo intervento ti prego di moderare i toni...

Ottimizzazioni. Il Kyro 2 ottimizza cosa? Non mi risulta che modfichi le istruzioni; ribalta semplicemente l'ordine di rendering, ricorrendo ad un più logico post texturing piuttosto che all'assurdo per-texturing dei chip che lo hanno preceduto. La validità di un'architettura non è data dalla potenza bruta; R300 vale 10 volte NV30 perchè è molto più veloce e lavora a frequenze inferiori del 60%.
Dov'è lo scandalo in certe ottimizzazioni? Semplice: faccio girare sul chip A codice ps1.1 e ottengo 90 fps, sul B codice ps2.0 e ottengo 83 fps, il banch dovrebbe testare la capacità dei due chip di elaborare codice ps2.0. Qual è la conclusione del test? A è più veloce di B. Secondo te la conclusione è corretta? Per me è una truffa, perchè chi compra è convinto che A possa elaborare shader 2.0 più velocemente di B; quando A si troverà a dover realmente elaborare ps2.0, l'utente risulterà insoddisfatto e non si spiegherà il perchè delle prestazioni penose della sua schede video, pagata così cara e che fino ad allora andava così bene.
Per te è accettabile una cosa del genere?

Non si può creare una regola per questo, ogni codice, ogni videogioco sono un discorso a se. Se con codice specifico nv3x ottiene una qualità simile con prestazioni in linea, come ho potuto verificare personalmente in 1 anno e 2 mesi di videogiochi (ripeto a confronto con una 9800 pro), penso che sia un'ottima soluzione.
Se parliamo di confronto diretto "brutale" con codice generico in ps 2.0, la serie r3xx ha un vantaggio di 1 a 2.

Pk77

[yossarian]

Originariamente inviato da rmarango
In effetti io l'ho comprata anche perche' c'era scritto DX9 compliant da qualche parte...evidentemente c'e' qualcosa che non torna, come giustamente sottolinei.
L'unica consolazione e' che ancora questo divario in termini di resa grafica tra i due shader model non sia cosi evidente con i games attuali.


infatti ho voluto di proposito scindere i due discorsi; da un lato l'aspetto tecnico: sappiamo che le fx hanno problemi con i ps2.0, analizziamo i motivi; dall'altro il discorso "prestazioni con i giochi attuali": in questo caso, poichè l'utilizzo di sm2.0 è ancora molto limitato ed è possibile ricorrere a operazioni di shader replacement senza compromettere la qualità in maniera troppo evidente e migliorando la giocabilità, allora niente da obiettare se si ricorre a tali "ottimizzazioni"; purchè quei risultati non si spaccino per quello che non sono (ottenuti, cioè, con ps2.0), perchè questo può influenzare i potenziali acquirenti fuorviandoli.
Infine, anche nell'ambito della stessa famiglia fx, c'è da dire che NV35 (e derivati successivi) rappresenta un piccolo passo avanti rispetto a NV30 (si è aggiustato quello su cui è stato possibile intervenire. Dai test si vede che, pur non risultando fulmini di guerra, con fp16 NV35 e NV38 vanno un po' meglio di NV30 (segno che a livello di architettura qualche miglioria c'è stata: la famosa fpu aggiunta in sostituzione della fxu). Questo, tanto per non generalizzare.

[rmarango]

Originariamente inviato da yossarian
infatti ho voluto di proposito scindere i due discorsi; da un lato l'aspetto tecnico: sappiamo che le fx hanno problemi con i ps2.0, analizziamo i motivi; dall'altro il discorso "prestazioni con i giochi attuali": in questo caso, poichè l'utilizzo di sm2.0 è ancora molto limitato ed è possibile ricorrere a operazioni di shader replacement senza compromettere la qualità in maniera troppo evidente e migliorando la giocabilità, allora niente da obiettare se si ricorre a tali "ottimizzazioni"; purchè quei risultati non si spaccino per quello che non sono (ottenuti, cioè, con ps2.0), perchè questo può influenzare i potenziali acquirenti fuorviandoli.
Infine, anche nell'ambito della stessa famiglia fx, c'è da dire che NV35 (e derivati successivi) rappresenta un piccolo passo avanti rispetto a NV30 (si è aggiustato quello su cui è stato possibile intervenire. Dai test si vede che, pur non risultando fulmini di guerra, con fp16 NV35 e NV38 vanno un po' meglio di NV30 (segno che a livello di architettura qualche miglioria c'è stata: la famosa fpu aggiunta in sostituzione della fxu). Questo, tanto per non generalizzare.

Non fa una grinza...grazie per tutte le spiegazioni. :)

[yossarian]

Originariamente inviato da Pat77
Andiamo con ordine: introdurre driver che guidano una GPU ad elaborare, secondo i suoi punti di forza, riproducendo immagini IDENTICHE alla controparte concorrente, vuoi per altre vie, vuoi con altri principi, vuoi come vuoi, ma avendo in fin dei conti un risultato IDENTICO in termini qualitativi, non è cheattare ma ottimizzare.

Diminuire la qualità dell'immaggine, ottenere prestazioni pilotate nei soli bench, questo è cheattare. Sia Nvidia (3dmark, aquamark, ecc..) sia Ati (quak3,ec..) hanno usato questa pratica discutibile.



vedo che continui a parlare di ottimizzazioni senza cognizioni di causa. Se per te un bench che testa le prestazioni con dx9 viene eseguito utilizzando ps1.1 è la stessa cosa: complimenti!


Originariamente inviato da Pat77
Cg nacque, ti sfido a dire il contrario, per cercare di standarizzare la programmazione degli shaders con GPU nvidia e supportava tutti quei set di istruzioni che andavano oltre le specifiche di Dx 9.0 supportate dalla serie Fx.





infatti dico proprio il contrario: CG è strutturato per mascherare le "magagne" di NV30 non per farlo andare oltre le specifiche DX9 che, per tua informazione, NV3x nemmeno supporta per intero a livello teorico (vedi HDR e DM tanto par citare due casi). CG è nato per utilizzare i registri costanti e i cicli di loopback al posto dei registri temporanei e di un maggior numero di operazioni matematiche contemporanee (cose in cui NV3x è carente); tanto che la stessa nVIDIA raccomandava di non utilizzare istruzioni complesse per non appoggiarsi troppo ai registri temporanei e che una delle operazioni compiute dal famoso "compilatore", oltre al già noto shader replacement, era quella di spezzare le istruzioni più lunghe in sequenze più brevi da svolgere in più cicli, appoggiandosi ai registri costanti e compiendo operazioni di loopback.

Originariamente inviato da Pat77



Io parlo di forza bruta riferendomi a r300, è evidente. Parlo di codice specifico per nv30. Penso che nei calcoli sullo Stencil abbia un certo vantaggio.
Riguardo all'ultima parte di questo tuo intervento ti prego di moderare i toni...




Tu parli di cose che conosci per sentito dire o per aver letto qualche depliant pubblicitario di nVIDIA. Ti ripeto la domanda: qual è il codice specifico per NV3x? Se ne parli, sicuramente saprai cosa stai dicendo.
Certo, utilizziomo le stencil shdow, ricorriamo alla dependent read, utilizzamo, ovunque possibile, fx12, non ricorriamo al DM (le fx non supportano le n-patches), utilizzamo estensioni proprietarie NV; praticamente facciamo, come ha fatto Carmack: ritagliamo un motore grafico adattandolo alle esigenze delle fx, evitando accuratamente di toccare tutti i loro punti deboli. Questa è la tua idea di codice specifico? Se nVIDIA ha sbagliato, perchè a farne le spese devono essere tutti gli altri (programmatori, utenti finali, ecc, ecc)?
Riguardo al resto, stai tranquillo: da questo momento ti ignorerò del tutto, tanto non c'è peggior sordo di chi non vuol sentire.


Originariamente inviato da Pat77



Non si può creare una regola per questo, ogni codice, ogni videogioco sono un discorso a se. Se con codice specifico nv3x ottiene una qualità simile con prestazioni in linea, come ho potuto verificare personalmente in 1 anno e 2 mesi di videogiochi (ripeto a confronto con una 9800 pro), penso che sia un'ottima soluzione.
Se parliamo di confronto diretto "brutale" con codice generico in ps 2.0, la serie r3xx ha un vantaggio di 1 a 2.

Pk77

qual è questo codice specifico? quale sm utilizza? Che tipo di input? Come verrebbe elaborato?

L'idea di un chip tutto forza bruta (R300) contro uno più avanzato e flessibile (NV30) era stata accarezzata da qualcuno all'epoca dell'uscita di NV30 (pochi, per la verità, poichè le critiche erano state molte di più dei consensi, incoraggiati, in qualche modo da nVIDIA); a ottobre 2003 era rimasto il solo Josh Walrath a cullare questo miraggio ("the shocking state of.....", postato da rmarango due o tre pagine fa); a ottobre 2004, persino Josh Walrath era vittima di un brutto risveglio ("the shocking state......" era diventato "the sordid state........"); a novembre 2004 scopro che c'è ancora chi ci crede. Complimenti per la costanza, senza fare umorismo, meriteresti un premio fedeltà: neppure nVIDIA ha più il coraggio di difendere NV3x in modo così accorato (una dichirazione del CEO di pochi giorni fa è emblematica e suona come:"con NV40 abbiamo ripreso la leadership.........."; questo significa forse che con NV3x l'avevano persa?

[Pat77]

vedo che continui a parlare di ottimizzazioni senza cognizioni di causa. Se per te un bench che testa le prestazioni con dx9 viene eseguito utilizzando ps1.1 è la stessa cosa: complimenti!

Questo lo stai dicendo tu, io parlo di identica qualità. Un bench in dx 8.1 non avra la stessa resa che mostra in dx 9.0.


Tu parli di cose che conosci per sentito dire o per aver letto qualche depliant pubblicitario di nVIDIA. Ti ripeto la domanda: qual è il codice specifico per NV3x? Se ne parli, sicuramente saprai cosa stai dicendo.

Parlo della mixed mode di Hl2 e il Path nv3x di Doom3. Ti ripeto modera i termini.

Riguardo al resto, stai tranquillo: da questo momento ti ignorerò del tutto, tanto non c'è peggior sordo di chi non vuol sentire.

E quel sordo che non vuol sentire, fammi indovinare, magari la pensa diversamente da te? Ma che caso..
Comunque complimenti per l'atteggiamento infantile che dimostri con queste risposte.

[yossarian]

Originariamente inviato da rmarango
Non fa una grinza...grazie per tutte le spiegazioni. :)


prego; queste discussioni dovrebbero servire proprio a cercare di andare oltre i numeretti di un bench e vedere di capire come si fa ad ottenere quei numeretti e perchè un chip va bene con un'applicazione e meno con un'altra, invece di limitarsi solo a prendere atto di questi comportamenti "anomali".
Conoscere le architetture di due chip A e B dà un quadro molto più chiaro delle loro potenzialità (presenti e future) che non vedere che A con il tale gioco fa 20 fps in più e con il tal altro 15 in meno.
Allo stato attuale, ad esempio, è molto difficile operare una scelta: R420 è un po' più veloce, ha ottimi algoritmi di compressione dati e un HSR superiore; NV40 ha un'architettura più complessa e interessante. Entrambi sono ottimi per far girare applicazioni ps2.0; NV40 ha delle feature ps3.0 in più, alcune delle quali potrebbero realmente essere utilizzate e dare qualche leggero vantaggio in futuro. La definirei una situazione di sostanziale parità (anche in prospettiva futura); personalmente, NV40 mi piace di più, perchè rappresenta una novità ed è sicuramente più stimolante (l'architettura di R300 la conosco piuttosto bene, invece).

[yossarian]

Originariamente inviato da Pat77
Questo lo stai dicendo tu, io parlo di identica qualità. Un bench in dx 8.1 non avra la stessa resa che mostra in dx 9.0.





e questo chi l'ha detto? Aquamark, TRAoD, FarCry, girano sulle fx senza far ricorso ai ps2.0



Originariamente inviato da Pat77


Parlo della mixed mode di Hl2 e il Path nv3x di Doom3. Ti ripeto modera i termini.



E quel sordo che non vuol sentire, fammi indovinare, magari la pensa diversamente da te? Ma che caso..
Comunque complimenti per l'atteggiamento infantile che dimostri con queste risposte.


continui a non rispondere alle domande; forse ti è sfuggita, perciò te la ripeto:
qual è questo codice ottimizzato per NV3x? Come funziona la path NV30? e il mixed mode di HL2? Fai qualche esempio concreto; sostieni che R300 sia solo forza bruta e che NV3x abbia potenzialità inespresse, maggior flessibilità, sia più avanzato. Questo fa presupporre che tu conosca bene quel chip; forse sai qualcosa che sfugge a tutti, compresi gli addetti ai lavori. Potresti fornire un grande contributo alla comunità di HWUpgrade e a quella internazionale, rivelando questi particolari

:eek:

[rmarango]

Originariamente inviato da yossarian
prego; queste discussioni dovrebbero servire proprio a cercare di andare oltre i numeretti di un bench e vedere di capire come si fa ad ottenere quei numeretti e perchè un chip va bene con un'applicazione e meno con un'altra, invece di limitarsi solo a prendere atto di questi comportamenti "anomali".
Conoscere le architetture di due chip A e B dà un quadro molto più chiaro delle loro potenzialità (presenti e future) che non vedere che A con il tale gioco fa 20 fps in più e con il tal altro 15 in meno.
Allo stato attuale, ad esempio, è molto difficile operare una scelta: R420 è un po' più veloce, ha ottimi algoritmi di compressione dati e un HSR superiore; NV40 ha un'architettura più complessa e interessante. Entrambi sono ottimi per far girare applicazioni ps2.0; NV40 ha delle feature ps3.0 in più, alcune delle quali potrebbero realmente essere utilizzate e dare qualche leggero vantaggio in futuro. La definirei una situazione di sostanziale parità (anche in prospettiva futura); personalmente, NV40 mi piace di più, perchè rappresenta una novità ed è sicuramente più stimolante (l'architettura di R300 la conosco piuttosto bene, invece).

Lo terro' sicuramente presente per un futuro upgrade.

Ciao e Grazie
:)

[yossarian]

Originariamente inviato da rmarango
Lo terro' sicuramente presente per un futuro upgrade.

Ciao e Grazie
:)


finchè puoi tira avanti con la 5900 e aspetta che scendano un po' i prezzi (tanto, fino alle DX next, 1Q o 2Q 2006, vedremo solo refresh di queste architetture con variazioni di poco conto).

[Pat77]

e questo chi l'ha detto? Aquamark, TRAoD, FarCry, girano sulle fx senza far ricorso ai ps2.0

E girano con la stessa qualità che puoi notare su una 9800 pro. Se tanto mi da tanto mi sa che Ati ha un compilatore tuttofare pure lei :D

sostieni che R300 sia solo forza bruta e che NV3x abbia potenzialità inespresse, maggior flessibilità, sia più avanzato

Ma da dove le estrapoli queste perle, sono costretto a riquotarmi:

La serie fx comunque è stata una generazione di passaggio, fortissima nel multitexturing, ottima in dx8.1, discreta in dx9 16bit e lenta in dx9 32bit.

Se parliamo di confronto diretto "brutale" con codice generico in ps 2.0, la serie r3xx ha un vantaggio di 1 a 2.

Pk77

[yossarian]

Originariamente inviato da Pat77
E girano con la stessa qualità che puoi notare su una 9800 pro. Se tanto mi da tanto mi sa che Ati ha un compilatore tuttofare pure lei :D




vedi che se ti impegni qualcosa di buono viene fuori
:sofico:

Certo che ATi ha un compilatore, che però permette di far girare "persino" i ps2.0 a frame rate accettabili (ora, o quelli di ATi, col SW sono più bravi, oppure quelli di nVIDIA non hanno capito niente dell'architettura che hanno progettato, oppure l'architettura di ATi si rivela migliore di quella di nVIDIA anche qualora tutte e due riordinino le istruzioni; ora, poichè io sono portato a non credere alle prime due affermazioni, non posso che optare per la terza)

http://www.beyond3d.com/reviews/ati/r420_x800/index.php?p=17

http://www.beyond3d.com/previews/nvidia/nv40/index.php?p=21


poichè non credo che tu li abbia neppure guardati, ti posto qualche risultato (fiilrate Mp/s)

ps1.1
9800 xt - 1622,0
9700 pro - 1278,1
5950 ultra - 938,3
5800 ultra - 988,8

ps1.4
9800 xt - 1622,0
9700 pro - 1278,1
5950 ultra - 887,6
5800 ultra - 935,6

ps2.0 fp32
9800 xt - 1622,0
9700 pro - 1278,1
5950 ultra - 448,7
5800 ultra - 475,1

ps2.0 fp16
9800 xt - 1622,0
9700 pro - 1278,1
5950 ultra - 889,8
5800 ultra - 631,3

ps2.0 fp32 longer
9800 xt - 816,4
9700 pro - 642,8
5950 ultra - 225,9
5800 ultra - 381,3

ps2.0 fp16 longer
9800 xt - 816,4
9700 pro - 642,8
5950 ultra - 450,1
5800 ultra - 381,3

ps2.0 fp32 longer 4 registers
9800 xt - 816,4
9700 pro - 642,8
5950 ultra - 225,2
5800 ultra - 308,2

ps2.0 fp16 longer 4 registers
9800 xt - 816,4
9700 pro - 642,8
5950 ultra - 595,1
5800 ultra - 381,3


come vedi, il compilatore di ATi pare funzionare molto meglio con i SW con cui non è possibile "ottimizzare" e l'fp32 su Nv3x è praticamente inutilizzabile (questi risultati sono relativi a soli calcoli matematici, senza l'applicazione di texture o altro) :fiufiu:

[yossarian]

Originariamente inviato da Pat77


Ma da dove le estrapoli queste perle, sono costretto a riquotarmi:





Pk77


dove le estrapolo? cosa intendi per confronto brutale con codice generico; esiste un confronto brutale e uno delicato? Non capisco questa affermazione; inoltre mi pare evidente che il vantaggio, in un confronto "brutale" sia di 2:1 con fp16, ma diventa di 4:1 circa con fp32 e i chip ATi sembrano addirittura in vantaggio con codice ps1.x dove i chip NV operano in fx12 e quelli ATi in fx16. Questo fa concludere, poichè nei calcoli in fx entrambi i chip arrivano ad un tetto massimo di 8 istruzioni per ciclo e i chip NV lavorano a frequenze sensibilmente superiori, che le fx sono meno efficienti nell'esecuzione dei calcoli matematici in genere e il chip è limitato dalla presenza di 4 sole pixel pipeline che dimezzano l'output per ciclo rispetto a R3x0; per quelli in fp subentrano anche altri problemi (il numero di operazioni per ciclo è sensibilmente inferiore rispetto a R3x0 (1/2 per NV35 e 1/4 per NV30) e, a fp32, si riduce ancora per colpa dell'insufficienza dei registri temporanei) :rolleyes:



adesso ti quoto io

Originariamente inviato da Pat77
Io parlo di forza bruta riferendomi a r300, è evidente. Parlo di codice specifico per nv30



forse hai poca memoria, visto che l'hai scritto non più di una pagina fa :D

Originariamente inviato da Pat77
Riguardo all'efficenza di nv30/35/38 sui ps 2.0 secondo me è tutta una questione di implementazione e ottimizzazione.



questa era la posizione di nVIDIA circa un anno fa (adesso l'hanno abbandonata anche loro) ed è la tua di tre pagine fa (circa)

Originariamente inviato da Pat77

Fonti? Valve ha sempre parlato di 16/32 bit per la Mixed (poi rinominato path nv3x).

Pk77



questa è di pag. 13

Originariamente inviato da Pat77
Sostanzialmente si dice che sono un mix tra ps 1.1/1.4, 16bit e 32bit ps 2.0. Ma quanto utilizzo di 32/16 o ps1.1 ci sia in questa modalità non c'è dato saperlo.

Pk77



questa è di pag. 14



i prossimi due sono ancora sulla forza bruta (chi avrebbe detto, poi, che la bontà di un'architettura si misura sulla forza bruta......)


Originariamente inviato da Pat77
Dimostrazioni di forza bruta sono fini a se stesse, imho, inoltre le architetture, se valide o meno, si scoprono negli anni: oggi come oggi possiamo valutare a 360 gradi solo le soluzioni dx8.0-8.1 di Geforce/Radeon nv2x e r2xx.

Pk77



Originariamente inviato da Pat77
Se no condanniamo anche il Kiro2, tutte le ottimizzazioni della banda ecc.. perchè per certi aspetti cheattano e non mostrano in termini di potenza bruta la validità di un'architettura.
Validità di un'architettura appunto che non è, non deve essere un dato puramente teorico ma deve confrontarsi con il fine, in questo caso i videogiochi.

Pk77




oggi siamo in grado di giudicare ampiamente anche la bonta di NV3x e R3x0, chip di cui si sa praticamente tutto; in quanto al Kyro, il discorso è completamente da ribaltare: è proprio la dimostrazione di un'architettura altamente efficiente.
Ti invito a cercare, in questo o altri thread, su questo o altri forum italiani o stranieri, un solo post in cui avrei affermato che l'efficienza si misura sulla base della forza bruta. Tu, al contrario, l'hai tirata in ballo spesso, attribuendola, come caratteristica, all'R300 (la cui architettura ti è, evidentemente, del tutto ignota); quello che continuo a chiederti è: forza bruta contrapposta a cosa? Poichè hai, di recente affermato che NV30 non ha potenzialità inespresse, non è più avanzato, non è più flessibile, mi piacerebbe sapere, allora che cosa è (oddio, non sarà mica come quegli esponenti di partito che dicono: "non siamo più........" senza dire quello che sono diventati?!? :eek: )
Ripeto (questo si che l'ho gia detto); deve esserci qualcosa sul conto di NV30, che tu sai e tutto il resto del mondo, compresi i tecnici nVIDIA (che hanno fatto carte false per far credere che il loro chip fosse al livello di quello della concorrenza, esponendosi spesso anche al ridicolo, con operazioni di cheating marchiane) evidentemente ignora.

:confused:

i dati riportati sopra sono tutt'altro che teorici; si tratta di dati pratici, sperimentali, ottenuti nel maggio 2004 (quando già esistevano i drivers miracolosi per Doom3 che avrebbero permesso di eliminare la path NV30) e il famigerato "compilatore" è all'opera (anche se, sorpresa, con questo SW "una parte" di esso, il "traduttore", non funziona :sofico: )

[vegeta88]

Originariamente inviato da Pat77
E girano con la stessa qualità che puoi notare su una 9800 pro. Se tanto mi da tanto mi sa che Ati ha un compilatore tuttofare pure lei :D

Pk77

Da prove effettuate personalmente la qualità che si ha con Aquamark, TRAoD, FarCry ecc.ecc. non forzando PS2.0 e VS2.0 e inferiore anche se di poco rispetto ad una scheda R3XX dato che i driver scalano il tutto in PS1.X . Per ora questa è la situazione e permettimi di affermare che tutto questo ha un controsenso quando vi sono comparative ad es. tra una 5900 e una 9800 poichè le schede quando eseguono bench in VS2.0 e PS2.0 non lavorano nella stessa maniera e non restituiscono la medesima qualità di immagine.

Nei titoli sopra menzionati forzando l'esecuzione dei VS2.0 e PS2.0 su una scheda NV3X la qualità risulta la stessa della controparte R3XX ma come ripetuto in altri miei post- le prestazioni calano fino a rendere ingiocabile tali titoli, infatti se provi tu stesso ti accorgerai che stai giocando con una media di 20-25 FPS se ti va bene.

Non aggiungo altro sul compilatore che sia ATI che NVIDIA hanno implementato nei loro Driver dato che yossarian l' ha spiegato più volte.
Non aggiungo altro nemmeno sulle caratteristiche dei due chip dato che non c'è ne bisogno e che yossarian , Fek e VIfani non hanno certo bisogno del mio contributo su questo, visto che ne sanno molto più di me in tal proposito e tantissimo anche più di te caro Pk77 .
Dopo che ti sono state postate prove - bench - review e dopo che ti è stato spiegato tutto in maniera perfetta , ostinarsi a seguire questa linea di condotta caro Pk77, secondo mè è errata e permettimi di dire un pò fastidiosa dato che quello che tu affermi non ha prove tangibili per essere tale.

Ciao
:) :)

[vegeta88]

Originariamente inviato da Pat77
La serie fx comunque è stata una generazione di passaggio, fortissima nel multitexturing, ottima in dx8.1, discreta in dx9 16bit e lenta in dx9 32bit.

Pk77


Quoto le due prime affermazioni e dissento totalmente sulle ultime due aggiungendo là dove è possibile è appena sufficiente con DX9.0 FP16 e disastrosa in DX9.0 FP32 sempre parlando di prestazioni.Tutto ciò viene avvalorato dal fatto che nei driver in presenza di shader model 2.0 il compilatore e lo shader replecement non scalano in FP16 ma i PS 2.0 vengono scalati in PS1.X e in rarissimi casi i PS2.0 vengono scalati con precisione FX12 , ma in quest'ultimo caso la qualità è imbarazzante.


Ciao:) :)

[Pat77]

Incredibile dictu

Ripeto a parità di qualità di immagine, utilizzando i pixel shaders, ci sono ambiti dove si ha una sostanziale parità, vedi Doom3, Halo, Aquamark.

dato che quello che tu affermi non ha prove tangibili per essere tale

Certo io nel case per 1 anno e 2 mesi ho avuto un fantasma, mentre la scheda di un mio caro amico era una Fx che funzionava con driver Ati evidentemente.

Non aggiungo altro nemmeno sulle caratteristiche dei due chip dato che non c'è ne bisogno e che yossarian , Fek e VIfani non hanno certo bisogno del mio contributo su questo, visto che ne sanno molto più di me in tal proposito e tantissimo anche più di te caro Pk77

Può darsi, ma evidentemente questa onniscenza non è poi tanto corrispondente con la realtà dei fatti.

Dopo che ti sono state postate prove - bench - review e dopo che ti è stato spiegato tutto in maniera perfetta , ostinarsi a seguire questa linea di condotta caro Pk77, secondo mè è errata e permettimi di dire un pò fastidiosa dato che quello che tu affermi non ha prove tangibili per essere tale.

E quale linea di condotta sarebbe? So benissimo quali sono i limiti di una Fx, so anche che non è una scheda così malvagia come cercate di dipingerla, perchè poi, mi è ancora del tutto ignoto.
Un'ultima cosa, l'assolutismo, è morto nel 17esimo secolo.

Pk77

[Pat77]

dove le estrapolo? cosa intendi per confronto brutale con codice generico; esiste un confronto brutale e uno delicato? Non capisco questa affermazione; inoltre mi pare evidente che il vantaggio, in un confronto "brutale" sia di 2:1 con fp16, ma diventa di 4:1 circa con fp32 e i chip ATi sembrano addirittura in vantaggio con codice ps1.x dove i chip NV operano in fx12 e quelli ATi in fx16. Questo fa concludere, poichè nei calcoli in fx entrambi i chip arrivano ad un tetto massimo di 8 istruzioni per ciclo e i chip NV lavorano a frequenze sensibilmente superiori, che le fx sono meno efficienti nell'esecuzione dei calcoli matematici in genere e il chip è limitato dalla presenza di 4 sole pixel pipeline che dimezzano l'output per ciclo rispetto a R3x0; per quelli in fp subentrano anche altri problemi (il numero di operazioni per ciclo è sensibilmente inferiore rispetto a R3x0 (1/2 per NV35 e 1/4 per NV30) e, a fp32, si riduce ancora per colpa dell'insufficienza dei registri temporanei)

Intendo un Half Life 2 in Dx 9 vs un Doom3 in ARB2.

Ti invito a cercare, in questo o altri thread, su questo o altri forum italiani o stranieri, un solo post in cui avrei affermato che l'efficienza si misura sulla base della forza bruta. Tu, al contrario, l'hai tirata in ballo spesso, attribuendola, come caratteristica, all'R300 (la cui architettura ti è, evidentemente, del tutto ignota); quello che continuo a chiederti è: forza bruta contrapposta a cosa? Poichè hai, di recente affermato che NV30 non ha potenzialità inespresse, non è più avanzato, non è più flessibile, mi piacerebbe sapere, allora che cosa è (oddio, non sarà mica come quegli esponenti di partito che dicono: "non siamo più........" senza dire quello che sono diventati?!? )

La serie fx comunque è stata una generazione di passaggio, fortissima nel multitexturing, ottima in dx8.1, discreta in dx9 16bit e lenta in dx9 32bit.

Pk77

[vegeta88]

Originariamente inviato da vegeta88
Allora se le ottimizzazioni hanno il solo scopo di poter far rendere al meglio una particolare architettura NV3X con i soli giochi ben vengano.
Però quando si tratta di bench il discorso si trasferisce sul marketing,che NVIDIA ha dovuto effettuare per far vendere i propri chip.confrontabili sia come prestazioni che come qualità alla controparte ATI R3XX e questo purtroppo per mè non è del tutto regolare.
Con queste affermazioni io non voglio criticare schede come la 5900XT , ottime sotto il profilo prezzo-prestazioni, ma bensi il fatto del presentare un'architettura DX 9.0 che all'atto pratico risulta inutilizzabile.
Me ne faccio ben poco di 5500 punti al 3dmark 2003 o di 44000 punti all'aquamark 3 perchè quando faccio partire FarCry e HalLife2 e forzo l'esecuzione delle DX 9.0 e mi ritrovo a giocare con 20FPS.

Ciao
:) :)

Mi autoquoto per risponderti caro Pat77

Ciao

[vegeta88]

Originariamente inviato da Pat77


La serie fx comunque è stata una generazione di passaggio, fortissima nel multitexturing, ottima in dx8.1, discreta in dx9 16bit e lenta in dx9 32bit.

Pk77

Dove?Quando?Perchè?

Eventuali risposte per approfondire la questione.
I miei dati e quelli di tutto il mondo dicono il contrario riguardo al supporto e alle prestazioni in DX9.0.

Ciao

[Pat77]

"The significant issue that clouds current ATI / Nvidia comparisons is fragment shader precision. Nvidia can work at 12 bit integer, 16 bit float, and 32 bit float. ATI works only at 24 bit float. There isn't actually a mode where they can be exactly compared. DX9 and ARB_fragment_program assume 32 bit float operation, and ATI just converts everything to 24 bit. For just about any given set of operations, the Nvidia card operating at 16 bit float will be faster than the ATI, while the Nvidia operating at 32 bit float will be slower. When DOOM runs the NV30 specific fragment shader, it is faster than the ATI, while if they both run the ARB2 shader, the ATI is faster."

[vegeta88]

Originariamente inviato da Pat77
"The significant issue that clouds current ATI / Nvidia comparisons is fragment shader precision. Nvidia can work at 12 bit integer, 16 bit float, and 32 bit float. ATI works only at 24 bit float. There isn't actually a mode where they can be exactly compared. DX9 and ARB_fragment_program assume 32 bit float operation, and ATI just converts everything to 24 bit. For just about any given set of operations, the Nvidia card operating at 16 bit float will be faster than the ATI, while the Nvidia operating at 32 bit float will be slower. When DOOM runs the NV30 specific fragment shader, it is faster than the ATI, while if they both run the ARB2 shader, the ATI is faster."

Scusami questo cosa vorrebbe dire?La discussione è piena di descrizioni tecniche e tu mi riporti un pezzetto di un articolo preso da qualche parte.Mah!!!!!
Mettiamo per assurdo che questo sia la situazione reale.Allora mi spieghi perchè FarCry-HL2-3D Mark 2005 vanno alla velocità invidiabile di 15-20 FPS una volta attivati i PS2.0 su NV3X?
MA sai che Doom3 fà un uso proprio minimo di VS2.0 e PS2.0 ed è ottimizzato al massimo per rendere bene con le FX?
Come mai solo in Doom3 vi è questa situazione?Te lo sei chiesto mai?
Voglio bench-review-articoli che dimostano che le FX vanno bene con le DX9.0, non te ne uscire con queste piccolezze.
Ciao
:)

[yossarian]

Originariamente inviato da Pat77
Intendo un Half Life 2 in Dx 9 vs un Doom3 in ARB2.

Pk77

continui a parlare per sentito dire; hai dimostrato di avere le idee piuttosto confuse sul mixed mode e suppongo sia così anche per la path NV30.
Qui penso che tutti (forse è il caso di dire quasi, visto il tuo atteggiamento) conoscano, ormai, i punti deboli e quelli di forza delle FX (pochi e nessuno attinente all'uso di sm2.0).
Ti ho chiesto più volte di spiegare come dovrebbe essere programmato un SW per esaltare le qualità di NV3x, ma continui a rispondere con frasi senza senso alcuno, glissando completamente su un'eventuale spiegazione.

[yossarian]

Originariamente inviato da Pat77


Può darsi, ma evidentemente questa onniscenza non è poi tanto corrispondente con la realtà dei fatti.



Pk77


e proprio perchè siamo tutti ignoranti stiamo aspettando l'illuminazione da parte tua

:sofico:


Originariamente inviato da Pat77


E quale linea di condotta sarebbe? So benissimo quali sono i limiti di una Fx, so anche che non è una scheda così malvagia come cercate di dipingerla, perchè poi, mi è ancora del tutto ignoto.
Un'ultima cosa, l'assolutismo, è morto nel 17esimo secolo.

Pk77

dici di saperlo e continui ad affermare che, se ben coadiuvata dal SW, con sm2.0 riesce ad avere prestazioni quasi allineate con quelle della concorrenza (continuando a citare delle fantomatiche path fp16/fp32 che esistono solo nella tua testa).
Ripeto, immagino che qui dentro, più o meno tutti sanno (o "credono" di sapere tutto su NV3x, sia a livello di punti deboli che di punti di forza; il "credono" è d'obbligo, poichè le tue rivelazioni potrebbero farci cambiare idea).

L'assolutismo è morto nel XVIII secolo, non nel XVII


:D

[yossarian]

Originariamente inviato da Pat77
"The significant issue that clouds current ATI / Nvidia comparisons is fragment shader precision. Nvidia can work at 12 bit integer, 16 bit float, and 32 bit float. ATI works only at 24 bit float. There isn't actually a mode where they can be exactly compared. DX9 and ARB_fragment_program assume 32 bit float operation, and ATI just converts everything to 24 bit. For just about any given set of operations, the Nvidia card operating at 16 bit float will be faster than the ATI, while the Nvidia operating at 32 bit float will be slower. When DOOM runs the NV30 specific fragment shader, it is faster than the ATI, while if they both run the ARB2 shader, the ATI is faster."


e quindi?

:D

[yossarian]

Originariamente inviato da Pat77

La serie fx comunque è stata una generazione di passaggio, fortissima nel multitexturing, ottima in dx8.1, discreta in dx9 16bit e lenta in dx9 32bit.

Pk77


motiva queste affermazioni con un'analisi tecnica del chip, suffragata da riscontri numerici probanti; bada bene, non dico che siano giuste o sbagliate: ti chiedo solo una semplice analisi tecnica; non dovrebbe essere difficile farla per uno che si permatte di dare dell'ignorante a gente come fek (che lavora come sviluppatore di SW per i LionHead Studios, non so se Black&White ti dica qualcosa) o Vifani (che non credo abbia bisogno di presentazioni visto che è una delle "punte di diamante" dello staff di HWUpgrade)

[Vifani]

Scusate, mi spiegate dove sia il problema? Si discute ancora delle prestazioni di NV3x con shaders 2.0 ?

[yossarian]

Originariamente inviato da Vifani
Scusate, mi spiegate dove sia il problema? Si discute ancora delle prestazioni di NV3x con shaders 2.0 ?


pare di si; c'è qualcuno che nell'ultimo anno e mezzo è stato piuttosto distratto.

:D

[yossarian]

Originariamente inviato da Pat77
Incredibile dictu

Ripeto a parità di qualità di immagine, utilizzando i pixel shaders, ci sono ambiti dove si ha una sostanziale parità, vedi Doom3, Halo, Aquamark.





continui a sostenere che parità di IQ significhi necessarimente uguaglianza nella precisione di calcolo utilizzata; qui è la stessa nVIDIA che ti smentisce (di loro ti fiderai, spero):

Since we know that obtaining the best pixel shader performance out of GeForce FX GPUs currently requires some specialized work, our developer technology team works very closely with game developers to help them with this. Part of this is understanding that in many cases promoting PS 1.4 (DX8) to PS 2.0 (DX9) provides no image quality benefit


questo è il link


http://www.beyond3d.com/misc/hl2/index.php?p=5

[^TiGeRShArK^]

Originariamente inviato da yossarian
L'assolutismo è morto nel XVIII secolo, non nel XVII
:D
HO capito il significato del suo nick!:O
Pat77=Pat1707..... questo spiegherebbe le sue posizioni assolute.....
kazzarola quando erano ancora convinti ke la terra fosse piatta difendevano le loro convinzioni con meno veemenza!:sofico:

[R@nda]

Il problema nasce dal fatto che sulla carta Nv3x sembra molto intelligente e prestazionale....
Per dirne una è in grado di eseguire 1024 operazioni in FP 16 o 32 bit a seconda della situazione...e uno dice oooohh che figata,si ma se poi per queste operazioni non ha fisicamente spazio per elaborarle (mi par di capire che mancano registri temporanei (cache) per poterlo fare) a che serve.
Poi le mie sono speculazioni di uno che di architetture capisce quello può...ma se uno è in grado di analizzare l'architettura capendo a fondo come funziona (e non mi pare che qui queste persone manchino) viene fuori la verità delle cose...
Che poi non vedo cosa ci sia di male,un progetto che va un pò storto può capitare a chiunque in questo campo.
Nvidia non poteva mica pretendere che il mondo si scervellasse dietro alla sua architettura per farla rendere al max...quando poi dall'altra parte ha a disposizione un'altra architettura in grado di fare le stesse cose meglio e senza troppi sforzi.

Le sk video non sono console (vedi Ps2) dove se l'architettura è difficile
ma la piattaforma vende ci si da comunque dafare perchè ne vale la pena.

[pandyno]

Ho una 5900xt@500/1000 e gioco ad HL2 a 1152x864 AF8x e AA 2x

Direi che non va malissimo ;)

Ieri ho montato una 6800gt e devo dire che la differenza tra dx9 e 8.1 per quel poco che ho visto non si nota ;)

[yossarian]

Originariamente inviato da R@nda
Il problema nasce dal fatto che sulla carta Nv3x sembra molto intelligente e prestazionale....
Per dirne una è in grado di eseguire 1024 operazioni in FP 16 o 32 bit a seconda della situazione...e uno dice oooohh che figata,si ma se poi per queste operazioni non ha fisicamente spazio per elaborarle (mi par di capire che mancano registri temporanei (cache) per poterlo fare) a che serve.
Poi le mie sono speculazioni di uno che di architetture capisce quello può...ma se uno è in grado di analizzare l'architettura capendo a fondo come funziona (e non mi pare che qui queste persone manchino) viene fuori la verità delle cose...
Che poi non vedo cosa ci sia di male,un progetto che va un pò storto può capitare a chiunque in questo campo.
Nvidia non poteva mica pretendere che il mondo si scervellasse dietro alla sua architettura per farla rendere al max...quando poi dall'altra parte ha a disposizione un'altra architettura in grado di fare le stesse cose meglio e senza troppi sforzi.

Le sk video non sono console (vedi Ps2) dove se l'architettura è difficile
ma la piattaforma vende ci si da comunque dafare perchè ne vale la pena.

si tratta di 1024 operazioni in genere, non necessariamente in fp. I problemi di NV3x con la notazione fp nascono dalla carenza di spazio nei registri temporanei e dal fatto che il chip nasce con un'architettura più portata ad elaborare codice ps1.x; la dimostrazione è che NV30, per ogni pipeline, ha 2 unità fx12 e una sola unità fp16/fp32; per giunta, quest'ultima non è neppure indipendente dalle tmu, il che vuol dire che con un input misto di istruzioni fp e texture, inmedia, per ogni ciclo di clock, solo 2 delle 4 unità fp lavorano.
In compenso, NV3x ha un numero di registri costanti superiore a quanto richiesto dalle specifiche; i registri costanti sono di sola lettura (quindi possono essere usati solo come "tabelle" dove allocare dati provenienti dal frame buffer ma non si possono usare per eseguire calcoli. In parole povere, NV3x può trasferire, rispetto alla concorrenza, un maggior quantitativo di dati dal frame buffer direttamente on chip. Questi dati possono essere usati per operazioni di sola lettura e consentono di effetture un gran numero di cicli di loopback senza accedere al frame buffer (una delle funzionalità sfruttate da Carmack in Doom3). Questa funzionalità, però trova scarse applicazioni nei calcoli in fp per i problemi elencati sopra (il primo dei quali è l'insufficienza e la scarsa ottimizzazione delle unità fp presenti sul chip). IN altre parole, NV3x non riesce a gestire operazioni più complesse in un singolo ciclo (per quello servono i registri temporanei), però è in grado di eseguire un gran numero di operazioni semplici per single pass (attenzione, non è la stessa cosa che per ciclo di clock); questo, ovviamente, a livello teorico: all'atto pratico un discorso del genere è più applicabile ad un chip come NV40 che non a NV3x che denuncia carenze nella potenza d'elaborazione (i chip della precedente generazione erano piuttosto limitati da questo punto di vista, qualli della nuova vanno decisamente meglio).
IMHO, NV3x non è frutto di un errore (anche se alcuni errori di valutazione sono stati commessi), ma di scelte progettuali ben precise: è un chip nato per elaborare principalmente codice 1.x a cui sono state aggiunte funzionalità DX9. Al contrario, NV40 è chiaramente un chip nato per lavorare in fp (e i risultati sono evidenti).
Quindi le critiche al progetto NV3x sono limitate al funzionamento con le DX9, non sono critiche in senso assoluto

[BTinside]

Originariamente inviato da R@nda
Non mi trovo daccordo,visto che la possiedo anche io....e come vedi Leoneazzurro.
Ne io ne lui ci siamo impuntati sulla difensiva,perchè ci sono fatti e persone che spiegano come stanno le cose.
Ne è venuto fuori un bel thread senza fanatismi....sopratutto perchè nessuno ha fatto battute e troppa polemica.


Ma nessuno ha mai detto che tu o leoneazzurro difendete la vostra scheda, non parlavo di voi due,
se è per questo anche io ho una 6800 ma non la difendo, anzi, tendo a privileggiare Ati in questo momento

[R@nda]

Originariamente inviato da BTinside
Ma nessuno ha mai detto che tu o leoneazzurro difendete la vostra scheda, non parlavo di voi due,
se è per questo anche io ho una 6800 ma non la difendo, anzi, tendo a privileggiare Ati in questo momento

Capito.....figurati che non vedo l'ora di avere qualcosa che spacca nel case ma mi tocca aspettare,altro che difenderla:D

[BTinside]

Originariamente inviato da yossarian
prego; queste discussioni dovrebbero servire proprio a cercare di andare oltre i numeretti di un bench e vedere di capire come si fa ad ottenere quei numeretti e perchè un chip va bene con un'applicazione e meno con un'altra, invece di limitarsi solo a prendere atto di questi comportamenti "anomali".
Conoscere le architetture di due chip A e B dà un quadro molto più chiaro delle loro potenzialità (presenti e future) che non vedere che A con il tale gioco fa 20 fps in più e con il tal altro 15 in meno.
Allo stato attuale, ad esempio, è molto difficile operare una scelta: R420 è un po' più veloce, ha ottimi algoritmi di compressione dati e un HSR superiore; NV40 ha un'architettura più complessa e interessante. Entrambi sono ottimi per far girare applicazioni ps2.0; NV40 ha delle feature ps3.0 in più, alcune delle quali potrebbero realmente essere utilizzate e dare qualche leggero vantaggio in futuro. La definirei una situazione di sostanziale parità (anche in prospettiva futura); personalmente, NV40 mi piace di più, perchè rappresenta una novità ed è sicuramente più stimolante (l'architettura di R300 la conosco piuttosto bene, invece).

E personalmente ritengo che le tue informazioni e la tua pazienza con chi pensa di saperne di più leggendo i "numeretti" dei bench sono preziosissimi.
Non provo alcuna vergogna nell'affermare che ho fatto un gran bel salto culturale in avanti sulle varie architetture leggendo questo 3ad,
grazie a Vifani, Yossarian e qualcun'altro.

[BTinside]

Originariamente inviato da R@nda
Capito.....figurati che non vedo l'ora di avere qualcosa che spacca nel case ma mi tocca aspettare,altro che difenderla:D
Per cosa sei propenso?

[R@nda]

Originariamente inviato da BTinside
Per cosa sei propenso?

Ancora non so,sicuramente un 939 con Nforce4 e 2gb di ram.....la sk video però non so,di sicuro dovrò stare su una 6800Gt o X800Pro,il tiro del prezzo sarà quello per la sk video e non credo che per i primi dell'anno prossimo ci sarà in giro chissà che altro.
Devo solo aspettare che finisca quest'anno.....poi vedrò.

[xxxyyy]

Domanda: ma l'heat haze c'e' in HL2?
In Doom3 mi ricordo che era prerogativa delle sk DX9.
Ma ho appena iniziato a giocare a Splinter Cell 2 e c'e' l'heat haze... molto bello... solo che ho una GF4Ti... anche l'acqua mi sembra migliore rispetto a quella di HL2 (in DX8.0 si intende).

[andreamarra]

Originariamente inviato da R@nda
Ancora non so,sicuramente un 939 con Nforce4 e 2gb di ram.....la sk video però non so,di sicuro dovrò stare su una 6800Gt o X800Pro,il tiro del prezzo sarà quello per la sk video e non credo che per i primi dell'anno prossimo ci sarà in giro chissà che altro.
Devo solo aspettare che finisca quest'anno.....poi vedrò.

Insomma, una fetecchia di sistema :asd: :sofico: !!!

[andreamarra]

Originariamente inviato da xxxyyy
Domanda: ma l'heat haze c'e' in HL2?
In Doom3 mi ricordo che era prerogativa delle sk DX9.
Ma ho appena iniziato a giocare a Splinter Cell 2 e c'e' l'heat haze... molto bello... solo che ho una GF4Ti... anche l'acqua mi sembra migliore rispetto a quella di HL2 (in DX8.0 si intende).

C'è questo comando nel config, l'heat haze.

Francamente però ignoro cosa sia :D, chi lo spiega :) ?

[Thunder82]

Originariamente inviato da R@nda
Ancora non so,sicuramente un 939 con Nforce4 e 2gb di ram.....la sk video però non so,di sicuro dovrò stare su una 6800Gt o X800Pro,il tiro del prezzo sarà quello per la sk video e non credo che per i primi dell'anno prossimo ci sarà in giro chissà che altro.
Devo solo aspettare che finisca quest'anno.....poi vedrò.

Esagerato :sofico: ne basta 1 giga di ram :D

[R@nda]

Come sono tanti 2gb!?In prospettiva 2005 e più direi che ci stanno.
Più che altro sono convinto del sistema ma non della schedavideo...nel senso che spendere l'anno prossimo tutti quei soldi per una 6800Gt o X800Pro mi sembra un azzardo.
Potrei benissimo risparmiare su questa e prendere una 6600Gt e aspettare comodamente l'evolversi delle cose...così mirerei alla fascia media della prossima generazione.
Insomma preferisco spendere più soldi per il sistema che non per la sk video...come sempre.

[R@nda]

Originariamente inviato da andreamarra
C'è questo comando nel config, l'heat haze.

Francamente però ignoro cosa sia :D, chi lo spiega :) ?

L'effetto calore che si ha intorno al fuoco...oppure più semplice ancora hai presente quando guardi una strada all'orizzionte sotto il sole...

[et_1975]

col mio sistema:

9800xt default
amd 64 3200+ default
xp pro + service pack 2 + norton 2004
dna detonator 4.12 beta
1 Gb ram
HD sata raid 0

risoluzione 1280 x 1024
antialias 2x
riflessioni: TUTTE

tra i 120 e i 70 frame per secondo, tranne in rarissimi casi...
dai 40 ai 50...

quadra?

[swarzy85]

Originariamente inviato da Pat77
La serie fx comunque è stata una generazione di passaggio
Stai scherzando o parli seriamente?

[TheDarkAngel]

Originariamente inviato da swarzy85
Stai scherzando o parli seriamente?

vaneggia penso

[Vifani]

E' stato pubblicato un articolo che spiega alcune cosette sul Source Engine. Forse può essere interessante leggerlo per coloro che seguono questo topic.

http://www.hwupgrade.it/articoli/1127/index.html

[yossarian]

Originariamente inviato da Vifani
E' stato pubblicato un articolo che spiega alcune cosette sul Source Engine. Forse può essere interessante leggerlo per coloro che seguono questo topic.

http://www.hwupgrade.it/articoli/1127/index.html


La tecnica del Radiosity Normal Mapping è implementata con ben 1920 diversi pixel shaders. Il più lungo conta 42 operazioni di tipo ALU e fino a sette texture fetches. Ogni cosa all’interno del Source Engine può essere eseguita in un singolo passaggio di rendering con pixel shaders 2.0 e con tre diversi passaggi con i pixel shaders 1.1.


questa è una delle operazioni in cui l'indipendenza di alu e tmu di R3x0 e R4x0 dà dei vantaggi anche a parità di clock.

Per il resto, nel confronto tra DX8 e DX9, si vede chiaramente come, nelle mappe che fanno uso di fp32 in modo più pesante (tipo canals), le prestazioni delle Fx crollino a valori pari a circa 1/4 di quelli ottenuti con ps1.x (come era lecito attendersi dalle considerazioni teoriche fatte). Nelle mappe che ricorrono ad un uso più bilanciato tra fp16 e fp32 si scende a circa 1/3, invece

[fek]

Originariamente inviato da Vifani
E' stato pubblicato un articolo che spiega alcune cosette sul Source Engine. Forse può essere interessante leggerlo per coloro che seguono questo topic.

http://www.hwupgrade.it/articoli/1127/index.html

Bell'articolo, Raffaele, e' impressionante come hai spiegato certi concetti piuttosto complessi in maniera semplice e immediata. Complimentoni.

Un solo piccolo appunto, se mi permetti, riguardo il motore di Doom3:


Eseguendo un rapido confronto con il motore di Doom III è immediatamente lampante la differente idea di base che ha spinto le due software house. John Carmak ha implementato un sistema di illuminazione dinamico in ogni sua parte ed ha completamente ignorato la componente ambientale. Il risultato è un motore grafico che da un lato mostra ombre dinamiche a tutto spiano e dall’altro produce un’immagine nera nelle zone non direttamente illuminate da alcuna fonte di luce (approccio fisicamente non corretto in quanto la componente ambientale è presente nella realtà, ma coerente con il resto del sistema di illuminazione).

Le zone in ombra appiaono nere non perche' e' stato ignorato il contributo ambientale, ma perche' il gamma e' molto basso, in altre parole e' tutto molto "scuro".

L'equazione di illuminazione di Doom3 e' qualcosa del tipo:

C = A + S1 * L1 + S2 * L2

Dove A, S1 * L1, S2 + L2 sono le diverse passate, A e' il contributo ambientale, S1 e L1 rispettivamente maschera per l'ombra e prima luce diffusiva e speculare.
C'e' in piu' una passata che inizializza lo zbuffer, ma non ci interessa ora.
Diciamo che una tipica "ottimizzazione visiva" e' non considerare l'assenza di luce come contributo zero, ma aggiungere una certa percentuale di componente diffusiva, di modo da non perdere tutti i dettagli della superficie. In Doom3 non e' stato fatto perche' tale shader non sarebbe stato visivamente compatibile con le implementazioni di classe DX8.

[Athlon 64 3000+]

Originariamente inviato da yossarian
La tecnica del Radiosity Normal Mapping è implementata con ben 1920 diversi pixel shaders. Il più lungo conta 42 operazioni di tipo ALU e fino a sette texture fetches. Ogni cosa all’interno del Source Engine può essere eseguita in un singolo passaggio di rendering con pixel shaders 2.0 e con tre diversi passaggi con i pixel shaders 1.1.


questa è una delle operazioni in cui l'indipendenza di alu e tmu di R3x0 e R4x0 dà dei vantaggi anche a parità di clock.

Per il resto, nel confronto tra DX8 e DX9, si vede chiaramente come, nelle mappe che fanno uso di fp32 in modo più pesante (tipo canals), le prestazioni delle Fx crollino a valori pari a circa 1/4 di quelli ottenuti con ps1.x (come era lecito attendersi dalle considerazioni teoriche fatte). Nelle mappe che ricorrono ad un uso più bilanciato tra fp16 e fp32 si scende a circa 1/3, invece

E come mai spiegi delle prestazioni così scadenti con L'NV40?
Ci macherebbe che abbia sbagliato a prendere la 6800GT,forse era meglio prendere la X800XT?

[fek]

Originariamente inviato da yossarian Ti ho chiesto più volte di spiegare come dovrebbe essere programmato un SW per esaltare le qualità di NV3x, ma continui a rispondere con frasi senza senso alcuno, glissando completamente su un'eventuale spiegazione.

Allineare le prestazioni e' dura anzi durissima. Diciamo che con un po' di accorgimenti, sfruttando molto i texture fetch e limitando le operazioni matematiche, limitando al minimo l'fp32 si riesce ad ottenere prestazioni con i ps2.0 decenti. E' un dato di fatto pero' che sono costretto a scalare molti effetti su NV3X, che su R3X0 mi girano quasi a pieno regime (non ci fossero le limitazioni varie del ps2.0 di mezzo) e mi girano ottimamente sul'NV40.
Proprio oggi ho dovuto scrivere tre versioni differenti dello stesso effetto di heat haze per le tre architetture. A quando un po' di convergenza nelle specifiche delle GPU?

[fek]

Originariamente inviato da andreamarra
C'è questo comando nel config, l'heat haze.

Francamente però ignoro cosa sia :D, chi lo spiega :) ?

Eccomi! Sono fresco fresco sull'argomento :D
E' la simulazione della distorsione della luce provocato dall'aria ad alta temperature, ad esempio riscaldata dal fuoco.

Stringi stringi si riduce a distorcere il la scena dietro il fuoco e applicare un po' di blur.

[Athlon 64 3000+]

Originariamente inviato da fek
Allineare le prestazioni e' dura anzi durissima. Diciamo che con un po' di accorgimenti, sfruttando molto i texture fetch e limitando le operazioni matematiche, limitando al minimo l'fp32 si riesce ad ottenere prestazioni con i ps2.0 decenti. E' un dato di fatto pero' che sono costretto a scalare molti effetti su NV3X, che su R3X0 mi girano quasi a pieno regime (non ci fossero le limitazioni varie del ps2.0 di mezzo) e mi girano ottimamente sul'NV40.
Proprio oggi ho dovuto scrivere tre versioni differenti dello stesso effetto di heat haze per le tre architetture. A quando un po' di convergenza nelle specifiche delle GPU?

Come va L'NV40 con i ps 2.0(e se è FP16 o FP32) che stai facendo per Black and White 2?
Spero che riesca a capire la domanda.

[Vifani]

Originariamente inviato da fek
Bell'articolo, Raffaele, e' impressionante come hai spiegato certi concetti piuttosto complessi in maniera semplice e immediata. Complimentoni.

Un solo piccolo appunto, se mi permetti, riguardo il motore di Doom3:



Le zone in ombra appiaono nere non perche' e' stato ignorato il contributo ambientale, ma perche' il gamma e' molto basso, in altre parole e' tutto molto "scuro".

L'equazione di illuminazione di Doom3 e' qualcosa del tipo:

C = A + S1 * L1 + S2 * L2

Dove A, S1 * L1, S2 + L2 sono le diverse passate, A e' il contributo ambientale, S1 e L1 rispettivamente maschera per l'ombra e prima luce diffusiva e speculare.
C'e' in piu' una passata che inizializza lo zbuffer, ma non ci interessa ora.
Diciamo che una tipica "ottimizzazione visiva" e' non considerare l'assenza di luce come contributo zero, ma aggiungere una certa percentuale di componente diffusiva, di modo da non perdere tutti i dettagli della superficie. In Doom3 non e' stato fatto perche' tale shader non sarebbe stato visivamente compatibile con le implementazioni di classe DX8.

Grazie mille per i complimenti fek. Secondo le mie fonti (interviste, forum di Beyond3D, ecc...) il contributo ambientale in Doom III non c'è proprio. Con le stencil shadows il contributo ambientale dovrebbe essere fatto nella prima passata, insieme all'inizializzazione dello zbuffer, mentre Carmak nella prima passata non scrive proprio nel frame buffer. L'immagine rimane nera così come è stata inizializzata alla cancellazione del frame buffer.

[MaBru]

Originariamente inviato da Pat77
Bhe diciamo che nvidia c'ha provato con CG (come del resto fece 3dfx con glide), e i presupposti, prima dell'uscita di Fx per sfondare c'erano tutti.
CG è un linguaggio ad alto livello, GLide una API. Dove sta il nesso?

[fek]

Originariamente inviato da Vifani
Grazie mille per i complimenti fek. Secondo le mie fonti (interviste, forum di Beyond3D, ecc...) il contributo ambientale in Doom III non c'è proprio. Con le stencil shadows il contributo ambientale dovrebbe essere fatto nella prima passata, insieme all'inizializzazione dello zbuffer, mentre Carmak nella prima passata non scrive proprio nel frame buffer. L'immagine rimane nera così come è stata inizializzata alla cancellazione del frame buffer.

A quanto pubblicato da Carmack in vari post sui forum tecnici, lui parla esplicitamente di una passata per lo zbuffer e una per la luce ambiente, il che pare coerente col fatto che letteralmente tutti abbiamo fatto la stessa cosa :)

[fek]

Originariamente inviato da Athlon 64 3000+
Come va L'NV40 con i ps 2.0(e se è FP16 o FP32) che stai facendo per Black and White 2?
Spero che riesca a capire la domanda.

Uso un NV40 nella macchina principale e non ho mai avuto alcun problema, e' la mia scheda di riferimento quando lavoro.
Sul muletto mi hanno montato oggi una 9600 perche' dicono che scrivo shader troppo pesanti e mi vogliono costringere ad usare una gpu piu' lenta... bah :p

Al momento sto lavorando su un framework di post processing e compositing video: praticamente una cosa simile a quello che accade nell'industria cinematografica nella fase di compositing finale, quando si applicano effetti 2d al film (tipo per ricreare scene di notte a partire da scene girate in pieno giorno). Fra i vari effetti di post processing sto lavorando su cose tipo heat haze, depth of field, blooming...

[MaBru]

Originariamente inviato da fek
CUT
Che combina Alex con il radiosity?:D

[Vifani]

Originariamente inviato da fek
A quanto pubblicato da Carmack in vari post sui forum tecnici, lui parla esplicitamente di una passata per lo zbuffer e una per la luce ambiente, il che pare coerente col fatto che letteralmente tutti abbiamo fatto la stessa cosa :)

Bene, ma non capisco perché non le faccia entrambe all'inizio.

In ogni caso il termine "ignorato" all'interno dell'articolo sta più che altro a significare "non curato". Rispetto all'implementazione del Source Engine intendo.

Comunque, che te ne pare del Source Engine? Secondo me alcune soluzioni sono davvero interessanti. Quella del Radiosity Normal Mapping è stata una vera genialata anche se effettivamente io preferisco gli approcci dinamici a quelli statici per la generazione dell'illuminazione.

[MaBru]

Originariamente inviato da Vifani
Quella del Radiosity Normal Mapping è stata una vera genialata anche se effettivamente io preferisco gli approcci dinamici a quelli statici per la generazione dell'illuminazione.
Come resa finale negli interni HL2 imho è superiore a Doom3, luce dinamica o no. Poi giudicare l'engine di D3 da come è usato in un gioco così scuro è fuorviante. Qualcosa di più preciso si potrà dire con Quake 4 o RTCW2.

[Vifani]

Originariamente inviato da MaBru
Come resa finale negli interni HL2 imho è superiore a Doom3, luce dinamica o no. Poi giudicare l'engine di D3 da come è usato in un gioco così scuro è fuorviante. Qualcosa di più preciso si potrà dire con Quake 4 o RTCW2.

Si... sono molto curioso di vedere la flessibilità di quel motore. Secondo me è molto ridotta però... chissà che non mi sbagli. Io per le schede più veloci farei estrudere la geometria completamente via vertex shader... anche se il numero di poligoni da trattare aumenterebbe moltissimo, penso che R420 e NV40 siano in grado di farlo velocemente.

[MaBru]

Originariamente inviato da Vifani
Io per le schede più veloci farei estrudere la geometria completamente via vertex shader...
Come fa il motore di Riddick.:)

[yossarian]

Originariamente inviato da Athlon 64 3000+
E come mai spiegi delle prestazioni così scadenti con L'NV40?
Ci macherebbe che abbia sbagliato a prendere la 6800GT,forse era meglio prendere la X800XT?


non è che le prestazioni con NV40 siano scadenti; Nv40 ha dei limiti, così come R420; uno shader piuttosto complesso che prevede l'utilizzo contemporaneo di texture fetch e di calcoli alu penalizza NV40 in misura maggiore di quanto non faccia con R420: questo perchè NV40 ha ereditato (unico aspetto negativo) la dipendenza prima fpu e tmu; questo significa che la prima unità di calcolo di NV40 è in grado di eseguire sia calcoli matematici che operazioni sulle texture, però non tutti e due nello stesso ciclo. Al contrario, R420, come anche R300, hanno alu e tmu separate, perciò hanno la possibilità di eseguire entrambi i tipi di calcolo nello stesso ciclo. Evidentemente gli algoritmi di illuminazione e quello relativo all'acqua (riflessioni, rifrazioni, ecc) sono tra i più complessi di HL2 e sono tra quelli in cui sono richieste texture fetch e operazioni matematiche in contemporanea: in questo tipo di calcoli sono avvantaggiati i chip ATi (prprio a livello di numero di istruzioni per ciclo, quindi indipendentemente dalla frequenza di lavoro). Non è un caso che le prestazioni peggiori, NV40 le mostri nella mappa "canals". Non è da escudere che, nei prossimi mesi, i tecnici nVIDIA lavoreranno sul riordino delle istruzioni per cercare di minimizzare il gap dovuto alla dipendenza delle unità di calcolo.
Diciamo che nel progettare il loro engine, quelli di Valve si sono preoccupati poco dell'architettura dei chip NV (come del resto ha fatto Carmack con Doom3 e i chip ATi); quindi stai tranquillo: hai fatto un buon acquisto, come lo avresti fatto se avessi preso una vga con R420.

[fek]

Originariamente inviato da Vifani
Bene, ma non capisco perché non le faccia entrambe all'inizio.

In ogni caso il termine "ignorato" all'interno dell'articolo sta più che altro a significare "non curato". Rispetto all'implementazione del Source Engine intendo.

Comunque, che te ne pare del Source Engine? Secondo me alcune soluzioni sono davvero interessanti. Quella del Radiosity Normal Mapping è stata una vera genialata anche se effettivamente io preferisco gli approcci dinamici a quelli statici per la generazione dell'illuminazione.

Sono d'accordo con te.
A livello di cura dei materiali il Source ha davvero degli ottimi shader, ma l'impostazione generale mi sembra ancora troppo legata al passato: diciamo che ci si sta muovendo nella direzione opposta. E' tutto troppo statico, le ombre sono appena abbozzate e a mio avviso un sistema di ombre dinamico e' un must. Occhio che su questo punto non tutti i programmatori 3d la pensano allo stesso modo.
Sicuramente e' molto leggero, ma non ci credo che non sia possibile forzare l'fp16 per le gpu nvidia. Sarebbe un errore troppo marchiano che un simile team di sviluppo non farebbe.

In sintesi: anch'io preferisco gli approggi dinamici e non vado matto per le lightmap.

[fek]

Originariamente inviato da Vifani
Si... sono molto curioso di vedere la flessibilità di quel motore. Secondo me è molto ridotta però... chissà che non mi sbagli. Io per le schede più veloci farei estrudere la geometria completamente via vertex shader... anche se il numero di poligoni da trattare aumenterebbe moltissimo, penso che R420 e NV40 siano in grado di farlo velocemente.

Io per le schede veloci eviterei totalmente le stencil shadow :D
Estrudere nel vertex shader e' una manciata di istruzioni e funziona benissimo con geometria non animata. Con geometria animata i problemi iniziano ad essere enormi, non ho trovato una soluzione decente e mi sono buttato sullo shadow mapping. A quanto ho letto in giro, non esiste una soluzione ottima e praticabile a quel problema.

[yossarian]

Originariamente inviato da fek
Allineare le prestazioni e' dura anzi durissima. Diciamo che con un po' di accorgimenti, sfruttando molto i texture fetch e limitando le operazioni matematiche, limitando al minimo l'fp32 si riesce ad ottenere prestazioni con i ps2.0 decenti. E' un dato di fatto pero' che sono costretto a scalare molti effetti su NV3X, che su R3X0 mi girano quasi a pieno regime (non ci fossero le limitazioni varie del ps2.0 di mezzo) e mi girano ottimamente sul'NV40.
Proprio oggi ho dovuto scrivere tre versioni differenti dello stesso effetto di heat haze per le tre architetture. A quando un po' di convergenza nelle specifiche delle GPU?


lo so; infatti la domanda era retorica (maliziosa e tendenziosa :sofico: ). Anche perchè sfruttare molto le texture fetch e ridurre al minimo i calcoli matematici in fp (soprattutto fp32) non è un approccio tipico da chip DX9 compliant come NV3x dovrebbe essere. Si tratta di operazioni che (sostituendo i pochi calcoli in fp presenti con ps1.x) potrebbero essere utilizzati anche per un qualunque chip DX8.x.
La convergenza nelle specifiche dele GPU ci sarebbe se i produttori si attenessero alle API di riferimento e fossero meno "creativi". Ci sarebbe più appiattimento nelle prestazioni, però sicuramente voi dovreste lavorare di meno e qualche compratore prenderebbe qualche fregatura in meno.
Ho l'impressione, però, che con l'architettura unificata di ps e vs ci sarà molto meno spazio per l'estro di qualcuno (almeno a livello di tipologia di unità di calcolo; purtroppo ci si potrà sempre sbizzarrire con i tipi di connessione tra unità, con la quantità e il tipo di cache interne e con troppi altri parametri, per essere sicuri che nessuno avrà future alzate d'ingegno)

:rolleyes:

[yossarian]

Originariamente inviato da fek
Sono d'accordo con te.
A livello di cura dei materiali il Source ha davvero degli ottimi shader, ma l'impostazione generale mi sembra ancora troppo legata al passato: diciamo che ci si sta muovendo nella direzione opposta. E' tutto troppo statico, le ombre sono appena abbozzate e a mio avviso un sistema di ombre dinamico e' un must. Occhio che su questo punto non tutti i programmatori 3d la pensano allo stesso modo.
Sicuramente e' molto leggero, ma non ci credo che non sia possibile forzare l'fp16 per le gpu nvidia. Sarebbe un errore troppo marchiano che un simile team di sviluppo non farebbe.

In sintesi: anch'io preferisco gli approggi dinamici e non vado matto per le lightmap.


io sono convinto che sia possibile forzare l'fp16; il problema è: chi ci guadagnerebbe?
Sia NV3x che NV4x non trarrebbero grandi vantaggi, per opposti motivi: NV3x non è brillante neppure con la pp, soprattutto nella gestione di shader lunghi e complessi; NV40 gestisce piuttosto bene anche fp32 (certo, dall'utilizzo di fp16 avrebbe comunque qualche fps in più e la cosa non guasterebbe ma neanche rivoluzionerebbe le prestazioni)

[Vifani]

Originariamente inviato da fek
Io per le schede veloci eviterei totalmente le stencil shadow :D
Estrudere nel vertex shader e' una manciata di istruzioni e funziona benissimo con geometria non animata. Con geometria animata i problemi iniziano ad essere enormi, non ho trovato una soluzione decente e mi sono buttato sullo shadow mapping. A quanto ho letto in giro, non esiste una soluzione ottima e praticabile a quel problema.

Però lo shadow mapping... non so a voi, ma le ombre del 3DMark05 a me non piacciono poi così tanto. L'aliasing regna sovrano oltre ai vari difetti qua e la (a seconda dell'angolazione delle normali, ecc....). E poi per le luci puntiformi omnidirezionali le shadowmap sono pesantissime... una cube shadow map è pesantissima da calcolare.

[yossarian]

Originariamente inviato da fek
A quanto pubblicato da Carmack in vari post sui forum tecnici, lui parla esplicitamente di una passata per lo zbuffer e una per la luce ambiente, il che pare coerente col fatto che letteralmente tutti abbiamo fatto la stessa cosa :)


cioè tutti utilizzate la prima passata solo per scrivere valori nello z-buffer? (scusa ma, come sai, la programmazione non è proprio il mio campo e sto cercando di capirci qualcosa)

;)

[Banus]

Originariamente inviato da yossarian
cioè tutti utilizzate la prima passata solo per scrivere valori nello z-buffer? (scusa ma, come sai, la programmazione non è proprio il mio campo e sto cercando di capirci qualcosa)
Se non ho capito male (le stencil non le ho mai implementate) si fa una z-pass, si effettua lo z-test sui poligoni dello shadow volume scrivendo i valori sullo stencil buffer (prima passata). A questo punto si renderizza la scena, applicando la componente ambientale solo dove c'è ombra, controllando lo stencil buffer (stencil-test). Inoltre lo z-buffer non è stato cancellato e quindi è possibile non renderizzare a priori i pixel nascosti. (seconda passata). A questo punto applica la componente diffusa e speculare solo dove non c'è ombra, con un altro stencil test (terza passata). Ulteriori due passate e due bit sullo stencil buffer per ogni luce in grado di produrre ombre.
Vifani saprà darti qualche dettaglio in più dal momento che ha programmato una demo sulle stencil ;)

[Athlon 64 3000+]

Originariamente inviato da yossarian
io sono convinto che sia possibile forzare l'fp16; il problema è: chi ci guadagnerebbe?
Sia NV3x che NV4x non trarrebbero grandi vantaggi, per opposti motivi: NV3x non è brillante neppure con la pp, soprattutto nella gestione di shader lunghi e complessi; NV40 gestisce piuttosto bene anche fp32 (certo, dall'utilizzo di fp16 avrebbe comunque qualche fps in più e la cosa non guasterebbe ma neanche rivoluzionerebbe le prestazioni)

Non riesco a percepire per bene il tuo discorso riguardo l'NV40 con la velocità di utilizzo in fp16 e fp32.

[fek]

Originariamente inviato da yossarian
io sono convinto che sia possibile forzare l'fp16; il problema è: chi ci guadagnerebbe?
Sia NV3x che NV4x non trarrebbero grandi vantaggi, per opposti motivi: NV3x non è brillante neppure con la pp, soprattutto nella gestione di shader lunghi e complessi; NV40 gestisce piuttosto bene anche fp32 (certo, dall'utilizzo di fp16 avrebbe comunque qualche fps in più e la cosa non guasterebbe ma neanche rivoluzionerebbe le prestazioni)

Io ti posso dire che in genere scrivo tutti gli shader in fp32 e poi, quando ho ottenuto l'effetto, scalo a fp16 tutto quello che posso e guadagno, mediamente, un 20/30% sia su NV3X sia su NV40. Mi sembra solo un po' forzato effettuare i benchmark di HL2 in fp32 e riportare che le NV3X non sono all'altezza: beh, e' ovvio.
Oddio, suono come un fanboy, la riformulo :)
Io avrei scalato tutto il possibile a fp16, dato in pasto al mercato delle NV3X degli shader ragionevoli e poi concluso che non sono comunque all'altezza, ma dopo un "fair test".
Sarebbe come ottimizzare qualcosa ed eseguire il profiling in debug invece che in release: i risultati che ne escono non hanno alcun valore.

Originariamente inviato da Vifani
Però lo shadow mapping... non so a voi, ma le ombre del 3DMark05 a me non piacciono poi così tanto. L'aliasing regna sovrano oltre ai vari difetti qua e la (a seconda dell'angolazione delle normali, ecc....). E poi per le luci puntiformi omnidirezionali le shadowmap sono pesantissime... una cube shadow map è pesantissima da calcolare.

Lo shadow mapping ha sicuramente problemi di aliasing ancora: i sample devono essere filtrati e poi qualche tecnica per "smussare" ulteriormente i contorni (filtri stocastici o blur basato sulla distanza dalla luce). Il punto e' che lo shadow mapping e' molto scalabile: aumenta il fillrate e linearmente aumenta la qualita' delle ombre, quindi per high end e per i motori futuri e' preferibile. Le stencil shadow sono fisse: quella e' la qualita' sempre e comunque e non e' banale migliorarla. Inoltre hanno enormi problemi con la geometria che usa alpha testing (immagina gli alberi), richiedono l'intervento della CPU per la geometria animata, e' una tecnica inerentemente multi pass. Bilanciando i pro e i contro, si stanno tutti muovendo sulle shadow map.

Le omni light, alla fine, sono paradossalmente piu' veloci di una directional light :)
E' vero che vanno renderizzate 6 facce di una cube map, ma e' anche vero che in queste sei facce il numero di oggetti e' di solito davvero esiguo: un buon algoritmo di rimozione degli oggetti nascosti risolve il problema. Mi sono trovato molto bene tanto che il mio primo tentativo con le shadow map e' stato proprio con omni light. I problemi nascono con le luci direzionali (perspective shadow mapping), ma la teoria sta facendo passi da gigante in questa direzione e nel giro di un paio d'anni dovrebbe essere una tecnica consolidata.

[fek]

Originariamente inviato da yossarian
cioè tutti utilizzate la prima passata solo per scrivere valori nello z-buffer? (scusa ma, come sai, la programmazione non è proprio il mio campo e sto cercando di capirci qualcosa)

;)

Dipende, non e' sempre conveniente.
In pratica si sta pagando il risparmio di fillrate con della geometria; il prezzo vale la candela quando il pixel shader e' molto complesso e l'overdraw della scena e' molto alto. In queste condizioni, una prima passata sullo zbuffer e tecniche come lo ZCull (o HyperZ), permettono di eseguire lo shader complesso strettamente (quasi) una volta per pixel, invece che piu' volte per pixel in situazioni di alto over draw.

(In altre parole, secondo me in Doom3 non conviene ;))

[yossarian]

Originariamente inviato da Athlon 64 3000+
Non riesco a percepire per bene il tuo discorso riguardo l'NV40 con la velocità di utilizzo in fp16 e fp32.


guarda anche la risposta di fek poco più in basso; con un guadagno del 20-30% su 8/10 fps (comr visto in canals che fa uso di shader fp32 complessi), per NV3x le cose non cambierebbero più di tanto.
NV40, invece, qualcosa guadagnerebbe, anche se, in fin dei conti, l'ultimo chip NV riesce a gestire piuttosto bene anche fp32.
Il calo vistoso in "canals" dipende dall'uso di fp32 e dalla dipendenza tra alu e tmu; l'impatto del primo si può minimizzare con il ricorso, dove possibile a fp16

[Athlon 64 3000+]

Ti chiedo come mai in alcuni benchmark additittura la 6800Ultra scende a livelli della 9800XT?
Sicuramente incide la dipendenza tra alu e Tmu(e di fatto l'R420 è superiore)ma non capisco come può andare a livello di una scheda con 8 pipeline e che ha in fill-rate che è la metà.

[yossarian]

Originariamente inviato da fek
Io ti posso dire che in genere scrivo tutti gli shader in fp32 e poi, quando ho ottenuto l'effetto, scalo a fp16 tutto quello che posso e guadagno, mediamente, un 20/30% sia su NV3X sia su NV40. Mi sembra solo un po' forzato effettuare i benchmark di HL2 in fp32 e riportare che le NV3X non sono all'altezza: beh, e' ovvio.
Oddio, suono come un fanboy, la riformulo :)
Io avrei scalato tutto il possibile a fp16, dato in pasto al mercato delle NV3X degli shader ragionevoli e poi concluso che non sono comunque all'altezza, ma dopo un "fair test".
Sarebbe come ottimizzare qualcosa ed eseguire il profiling in debug invece che in release: i risultati che ne escono non hanno alcun valore.



è propri qui che volevo arrivare; un guadagno del 20-30% su una media di 8/10 fps (o giù di li) come visto nella mappa "canals" che fa uso di shader fp32 complessi non cambierebbe la vita per NV3x. L'unico che parzialmente se ne gioverebbe e NV40 (che però riesce a "trattre" piuttosto bene anche fp32).
Capisco il tuo discorso e non è escluso che Valve abbia tentato una strada del genere. Magari facendo come dice avrebbe evitato di fare la figura di chi abbia deciso, per partito preso di boicottare le serie NV3x. Però, da tecnico del settore, ti rendi conto tu stesso della scarsa utilità della cosa.

[yossarian]

Originariamente inviato da Athlon 64 3000+
Ti chiedo come mai in alcuni benchmark additittura la 6800Ultra scende a livelli della 9800XT?
Sicuramente incide la dipendenza tra alu e Tmu(e di fatto l'R420 è superiore)ma non capisco come può andare a livello di una scheda con 8 pipeline e che ha in fill-rate che è la metà.


perchè in quei test viene fatto anche uso massiccio di shader fp32 complessi (con cui tutti i chip, anche R420, NV40, R3x0, nati per gestire sm2.0) accusano una perdita di circa il 40/50%; in più aggiungi che NV40 perde un'ulteriore percentuale a causa del fatto che i calcoli in fp32 in qualche modo incidono negativamente sulle prestazioni (specie in presenza di texture fetch in contemporanea). Diciamo che al calo dovuto alla dipendenza tra tmu e alu devi aggiungere circa un ulteriore 15-20% dovuto all'uso di fp32 (rispetto a fp24di ATi)

[Athlon 64 3000+]

Originariamente inviato da yossarian
è propri qui che volevo arrivare; un guadagno del 20-30% su una media di 8/10 fps (o giù di li) come visto nella mappa "canals" che fa uso di shader fp32 complessi non cambierebbe la vita per NV3x. L'unico che parzialmente se ne gioverebbe e NV40 (che però riesce a "trattre" piuttosto bene anche fp32).
Capisco il tuo discorso e non è escluso che Valve abbia tentato una strada del genere. Magari facendo come dice avrebbe evitato di fare la figura di chi abbia deciso, per partito preso di boicottare le serie NV3x. Però, da tecnico del settore, ti rendi conto tu stesso della scarsa utilità della cosa.

Altra cosa che mi interessa sapere è:
Nella demo canals si fa uso di shader fp32 e dici che scaldando a fp16 NV40 ne gioverebbe parzialmente e poi ti chiedo cosa intendi che riesce a "trattare" piuttosto bene anche shader fp32?
Scusami magari se non mi sono espresso bene ma non sono mai stato molto bravo a spiegarmi bene.

[Athlon 64 3000+]

Originariamente inviato da yossarian
perchè in quei test viene fatto anche uso massiccio di shader fp32 complessi (con cui tutti i chip, anche R420, NV40, R3x0, nati per gestire sm2.0) accusano una perdita di circa il 40/50%; in più aggiungi che NV40 perde un'ulteriore percentuale a causa del fatto che i calcoli in fp32 in qualche modo incidono negativamente sulle prestazioni (specie in presenza di texture fetch in contemporanea). Diciamo che al calo dovuto alla dipendenza tra tmu e alu devi aggiungere circa un ulteriore 15-20% dovuto all'uso di fp32 (rispetto a fp24di ATi)

Quindi se ho capito bene è per questo motivo che una 6800Ultra in quel particolare caso va come una 9800XT?

[yossarian]

Originariamente inviato da Athlon 64 3000+
Quindi se ho capito bene è per questo motivo che una 6800Ultra in quel particolare caso va come una 9800XT?


si; NV40, al contrario di NV3x (che non va d'accordo con i calcoli in fp e che, in particolare, con fp32 è un "chiodo"), can lo sm2.0, anche con fp32 ha una resa più che buona. Va da sé che, anche per un ottimo chip come NV40, fp32 è sicuramente un po' più pesante da gestire di quanto non lo sia fp24 e ancora di più fp16; questo soprattutto in presenza di altri tipi di calcoli in contemporanea (nell'esecuzione dei soli calcoli matematici, dai bench sintetici si vede chiaramente che NV40 gestisce fp16 e fp32 con la stessa disinvoltura con cui gestisce i calcoli in fx: questo dimostra che non è afflitto dai problemi evidenziati dalla precedente generazione).

[fek]

Originariamente inviato da yossarian
è propri qui che volevo arrivare; un guadagno del 20-30% su una media di 8/10 fps (o giù di li) come visto nella mappa "canals" che fa uso di shader fp32 complessi non cambierebbe la vita per NV3x. L'unico che parzialmente se ne gioverebbe e NV40 (che però riesce a "trattre" piuttosto bene anche fp32).
Capisco il tuo discorso e non è escluso che Valve abbia tentato una strada del genere. Magari facendo come dice avrebbe evitato di fare la figura di chi abbia deciso, per partito preso di boicottare le serie NV3x. Però, da tecnico del settore, ti rendi conto tu stesso della scarsa utilità della cosa.

Francamente non la trovo di scarsa utilita'. Tu sai meglio di me, perche' nel tuo campo e' ancora piu' importante che nel mio, che non ha senso usare un cannone per uccidere una mosca, si usano gli strumenti adeguati a risolvere il problema.
Se uno shader e' computazionalmente esattamente identico in fp16 perche' usare fp32? Non c'e' alcun motivo logico dal punto di vista ingegneristico, ed un programmatore alla Valve, che sicuramente ne sa, non farebbe mai un errore simile.

Non voglio accusare nessuno di niente, mi limito a constatare l'ovvio, che qualcosa di strano c'e'.

[R@nda]

Leggete qui....un pò macchinoso e alla carlona,però funziona.
Renderizza tutto correttamente e senza mancanze e artefatti.

http://forum.hwupgrade.it/showthread.php?s=&threadid=824334

[Athlon 64 3000+]

Originariamente inviato da yossarian
perchè in quei test viene fatto anche uso massiccio di shader fp32 complessi (con cui tutti i chip, anche R420, NV40, R3x0, nati per gestire sm2.0) accusano una perdita di circa il 40/50%; in più aggiungi che NV40 perde un'ulteriore percentuale a causa del fatto che i calcoli in fp32 in qualche modo incidono negativamente sulle prestazioni (specie in presenza di texture fetch in contemporanea). Diciamo che al calo dovuto alla dipendenza tra tmu e alu devi aggiungere circa un ulteriore 15-20% dovuto all'uso di fp32 (rispetto a fp24di ATi)

Lo riprendo un'attimo scusami magarii se sono un po' ripetitivo e concludo dicendo che è per il motovo che che c'è scritto qui sopra il perchè una 9800XT va come una 6800Ultra in quel particolare benchmark.
Con future realease di driver potra migliorare la situazione? almeno da far diventare NV40 più veloce almeno della 9800XT

[leoneazzurro]

Originariamente inviato da yossarian
si; NV40, al contrario di NV3x (che non va d'accordo con i calcoli in fp e che, in particolare, con fp32 è un "chiodo"), can lo sm2.0, anche con fp32 ha una resa più che buona. Va da sé che, anche per un ottimo chip come NV40, fp32 è sicuramente un po' più pesante da gestire di quanto non lo sia fp24 e ancora di più fp16; questo soprattutto in presenza di altri tipi di calcoli in contemporanea (nell'esecuzione dei soli calcoli matematici, dai bench sintetici si vede chiaramente che NV40 gestisce fp16 e fp32 con la stessa disinvoltura con cui gestisce i calcoli in fx: questo dimostra che non è afflitto dai problemi evidenziati dalla precedente generazione).


Scusa Yoss, ma se il calo fosse del 30% non mi sarei stupito più di tanto, qui si parla di più del 50%! A 1024x768 senza filtri, oltretutto.
Per quanto si possa esser limitati dall'architettura e dagli FP 32 mi aspetterei prestazioni perlomeno un attimino più elevate. Almeno più di una 9800XT. Sembra come non solo si siano scritti gli shader senza pensare a NV 40, ma persino nella maniera peggiore di come potessero essere scritti....

[Athlon 64 3000+]

Originariamente inviato da leoneazzurro
Scusa Yoss, ma se il calo fosse del 30% non mi sarei stupito più di tanto, qui si parla di più del 50%! A 1024x768 senza filtri, oltretutto.
Per quanto si possa esser limitati dall'architettura e dagli FP 32 mi aspetterei prestazioni perlomeno un attimino più elevate. Almeno più di una 9800XT. Sembra come non solo si siano scritti gli shader senza pensare a NV 40, ma persino nella maniera peggiore di come potessero essere scritti....

Anche a me questa situazione non mi va proprio giù,perchè mi sembra veramente troppo assurdo.Capisco che L'R420 sia più veloce ma non da arrivare a R360.

[yossarian]

Originariamente inviato da fek
Francamente non la trovo di scarsa utilita'. Tu sai meglio di me, perche' nel tuo campo e' ancora piu' importante che nel mio, che non ha senso usare un cannone per uccidere una mosca, si usano gli strumenti adeguati a risolvere il problema.
Se uno shader e' computazionalmente esattamente identico in fp16 perche' usare fp32? Non c'e' alcun motivo logico dal punto di vista ingegneristico, ed un programmatore alla Valve, che sicuramente ne sa, non farebbe mai un errore simile.

Non voglio accusare nessuno di niente, mi limito a constatare l'ovvio, che qualcosa di strano c'e'.


hai ragione, anzi nel mio campo si ha spesso il problema della "coperta corta".
Non conosco a fondo il motore di HL2 per sapere che tipo di shader sono stati usati; stando ai test postati da Raffaele, però, è evidente che gli shader della mappa "prison" sono molto meno complessi degli altri, il che farebbe pensare, se veramente fossero in fp32 anche questi, alla possibilità di sostituirli con fp16. E d'altra parte, non credo che non ci sia la possibilità di utilizzare una path dx9 ed effettuare, la dove possibile, shader replacement, scendendo anche fino ai ps1.x.
Certo che se Valve dovesse aver utilizzato, per la path dx9, solo fp32 avrebbe commesso un errore piuttosto grossolano (se di errore si è trattato).
Non si tratta di accusare o meno qualcuno, però, in effetti, sembra che ID e Valve abbiano operato scelte progettuali un po' strane e fuori dai canoni per non destare qualche sospetto.
Tu stesso hai detto, in precedenza, che nel caso specifico di Doom3 l'algoritmo di rendering adoperato da Carmack non è conveniente. La penso allo stesso modo e, da quello che ha scritto, pare che anche Raffaele sia di questa idea. L'unica cosa che può venire in mente è che quel particolare ordine di rendering conviene alle GeForce che, in presenza di soli calcoli relativi allo z-buffer, raddoppiano il pixel fillrate. Questo, di fatto, considerate anche le maggiori frequenze operative, annulla il gap tra NV3x e R3x0 e dà un buon margine di vantaggio a NV40 (nonostante le frequenze inferiori rispetto a R420).
Scelta opposta pare essere stata operata da Valve: un uso smodato e ridondante di fp32, anche dove non fosse necessario, avrebbe lo scopo (non dichiarato) di abbattere ulteriormente le prestazioni di una famiglia di chip (NV3x) che non ha molta dimestichezza con lo sm2.0, giustificandone il declassamento a chip DX8.x.
IMHO, HL2 e Doom3 rappresentano due facce della stessa medaglia: scelte progettuali opposte dettate, evidentemente, non solo da scelte tecniche "particolari" ma da alleanze politiche e di marketing

[yossarian]

Originariamente inviato da leoneazzurro
Scusa Yoss, ma se il calo fosse del 30% non mi sarei stupito più di tanto, qui si parla di più del 50%! A 1024x768 senza filtri, oltretutto.
Per quanto si possa esser limitati dall'architettura e dagli FP 32 mi aspetterei prestazioni perlomeno un attimino più elevate. Almeno più di una 9800XT. Sembra come non solo si siano scritti gli shader senza pensare a NV 40, ma persino nella maniera peggiore di come potessero essere scritti....


se ti ricordi, ne abbiamo parlato anche su nV Italia; io continuo a poensarla sempre alla stessa maniera: sia ID che Valve hanno progettato i loro engine pensando a come "far dispetto al rivale" (ATi e nVIDIA rispettivamente). Sicuramente gli shader di HL2 sono quanto di più indigesto possibile si possa concepire per l'architettura delle GeForce e, sicuramente, sono stati scritti in modo da massimizzare il problema della dipendenza tra alu e tmu, perchè il calo di NV40 è troppo elevato da essere giustificato dal solo utilizzo di fp32. Gli shader della mappa "canals" sono sicuramente complessie piuttosto lunghi: questo dovrebbe provocare (come in effetti avviene) un abbattimento delle prestazioni di tutti i chip. Solo che quelli delle ATi sono più contenuti, vuoi per l'utilizzo di fp24, vuoi per capacità di eseguire più istruzioni per ciclo grazie all'indipendenza tra alu e tmu (le 12 pipeline della X800 pro, in una situazione del genere, risultano più veloci delle 16 della 6800 ultra avendo un vantaggio di 4 operazioni per ciclo di clock che diventano 16 se il confronto si fa con le 16 pipeline della X800XT).

[Athlon 64 3000+]

Originariamente inviato da yossarian
se ti ricordi, ne abbiamo parlato anche su nV Italia; io continuo a poensarla sempre alla stessa maniera: sia ID che Valve hanno progettato i loro engine pensando a come "far dispetto al rivale" (ATi e nVIDIA rispettivamente). Sicuramente gli shader di HL2 sono quanto di più indigesto possibile si possa concepire per l'architettura delle GeForce e, sicuramente, sono stati scritti in modo da massimizzare il problema della dipendenza tra alu e tmu, perchè il calo di NV40 è troppo elevato da essere giustificato dal solo utilizzo di fp32. Gli shader della mappa "canals" sono sicuramente complessie piuttosto lunghi: questo dovrebbe provocare (come in effetti avviene) un abbattimento delle prestazioni di tutti i chip. Solo che quelli delle ATi sono più contenuti, vuoi per l'utilizzo di fp24, vuoi per capacità di eseguire più istruzioni per ciclo grazie all'indipendenza tra alu e tmu (le 12 pipeline della X800 pro, in una situazione del genere, risultano più veloci delle 16 della 6800 ultra avendo un vantaggio di 4 operazioni per ciclo di clock che diventano 16 se il confronto si fa con le 16 pipeline della X800XT).

Ottima spiegazione.
Dico solo che Valve e ID hanno fatto programmato i giochi in maniera che non mi è piaciuta per niente. Sono tutti uguali.Spero che una cosa del genere non si ripeta più.

[yossarian]

Originariamente inviato da Athlon 64 3000+
Lo riprendo un'attimo scusami magarii se sono un po' ripetitivo e concludo dicendo che è per il motovo che che c'è scritto qui sopra il perchè una 9800XT va come una 6800Ultra in quel particolare benchmark.
Con future realease di driver potra migliorare la situazione? almeno da far diventare NV40 più veloce almeno della 9800XT


penso proprio di si; intanto si dovrebbe poter ridurre il gap dovuto all'utilizzo di fp32 (non credo che questa notazione sia indispensabile in tutte le mappe e in ogni situazione); non è poi da escludere che si possa anche minimizzare il problema della dipendenza tra unità di calcolo, magari ordinando le istruzioni in modo differente. Tieni conto che, allo stato attuale, con gli shader scritti in quel modo, il vantaggio di una 6800 ultra su una 9800 XT è di sole 8 operazioni per ciclo, che la 9800 lavora ad una frequenza leggermente superiore e utilizza fp24 al posto di fp32.

[davestas]

Anche in ottica futura... AGP O PCIEXPRESS?
Ragazzi i problemi sono due: vorrei prenderlo prima di Natale, ma non
vorrei fare da betatester per le nforce4, non so davvero cosa fare
anche perchè non si vedono in giro?
Se prendessi subito un a64 3000+ o 3200+ ed una 6800gt agp o lisciacon
msi neo2platinum?
Io gioco molto in multiplayer quindi non so se mi conviene una scheda
di fascia alta o media come la 6600gt appunto....
non è questione di 939 o 754 è questione di agp o pciexpress, alcuni per esempio mi hanno consigliato di aspettare nforce4 altri nf3 perchè le prime nf4 avranno sicuramente diversi bug anche per un oc moderato per un daily use... inoltre c'e' chi mi ha cionsigliato di prendere la 6800gt per giocare davvero ad alte risoluZioni con il 959nf....altra questione: a che Ram dovrei accoppiare il tutto?
Aiutatemi per favore...

[yossarian]

Originariamente inviato da Athlon 64 3000+

Dico solo che Valve e ID hanno fatto programmato i giochi in maniera che non mi è piaciuta per niente. Sono tutti uguali.Spero che una cosa del genere non si ripeta più.


credo sia più o meno la speranza di tutti (anche se ho sempre temuto che si arrivasse a situazioni del genere)

[Athlon 64 3000+]

Originariamente inviato da yossarian
credo sia più o meno la speranza di tutti (anche se ho sempre temuto che si arrivasse a situazioni del genere)

Davvero una brutta situazione,io poi ci sono incappato tutte due le volte:
Con Doom3 la mia 9800pro andava così e così e adesso hl2 e la 6800Gt

[davestas]

ma quindi per qualità-prezzo qual'e' la scheda ideale per hl2 ed i futuri mod senza spendere 500 euro?:muro:

[Athlon 64 3000+]

Originariamente inviato da davestas
ma quindi per qualità-preo qual'e' la scheda ideale per hl2 ed i futuri mod sena spendere 500 euro?:muro:

Sarebbe la X800Pro che si trova sui 450 euro.
Se no andrebbe bene una 9800pro che viene sui 230 euro.

[leoneazzurro]

Originariamente inviato da yossarian
se ti ricordi, ne abbiamo parlato anche su nV Italia; io continuo a poensarla sempre alla stessa maniera: sia ID che Valve hanno progettato i loro engine pensando a come "far dispetto al rivale" (ATi e nVIDIA rispettivamente). Sicuramente gli shader di HL2 sono quanto di più indigesto possibile si possa concepire per l'architettura delle GeForce e, sicuramente, sono stati scritti in modo da massimizzare il problema della dipendenza tra alu e tmu, perchè il calo di NV40 è troppo elevato da essere giustificato dal solo utilizzo di fp32. Gli shader della mappa "canals" sono sicuramente complessie piuttosto lunghi: questo dovrebbe provocare (come in effetti avviene) un abbattimento delle prestazioni di tutti i chip. Solo che quelli delle ATi sono più contenuti, vuoi per l'utilizzo di fp24, vuoi per capacità di eseguire più istruzioni per ciclo grazie all'indipendenza tra alu e tmu (le 12 pipeline della X800 pro, in una situazione del genere, risultano più veloci delle 16 della 6800 ultra avendo un vantaggio di 4 operazioni per ciclo di clock che diventano 16 se il confronto si fa con le 16 pipeline della X800XT).

Si, e quello lo capisco. Ma se non erro considerando le 8 pipe delle 9800XT e i clock simili la situazione dava in comunque vantaggio NV 40, dico bene (se ricordo bene quella discussione si parlava di un 10-15% a parità di clock a favore delle X800 Pro in quei casi)? Invece in questo caso pare che vi sia di più, molta più differenza. Oltretutto cosa han fatto, han scritto uno shader dell'acqua che costringe la GPU a macinare un texture fetch e una operazione FP 32 per tutte le parti dello shader? Ammesso poi che il divario sia a causa di quello shader che penalizza NV 40 a causa della dipendenza tra TMU e FPU, e ammesso che l'acqua copra il 40% dello schermo, ed ammesso ancora che una X800 XT sia il doppio più veloce in quello shader a parità di clock, mentre nel resto della scena (come si vede dagli altri demo) vada più o meno alla stessa velocità sulle due schede, ho che dovrei avere sulle 6800 un divario del 25-30% in meno. Invece ho più del 50% . Adesso, IMHO, o c'è qualcosa che non va nel motore grafico, o nei drivers, o le 6800 hanno qualche ulteriore problemino di cui non siamo a conoscenza...

[yossarian]

Originariamente inviato da leoneazzurro
Si, e quello lo capisco. Ma se non erro considerando le 8 pipe delle 9800XT e i clock simili la situazione dava in comunque vantaggio NV 40, dico bene (se ricordo bene quella discussione si parlava di un 10-15% a parità di clock a favore delle X800 Pro in quei casi)? Invece in questo caso pare che vi sia di più, molta più differenza. Oltretutto cosa han fatto, han scritto uno shader dell'acqua che costringe la GPU a macinare un texture fetch e una operazione FP 32 per tutte le parti dello shader? Ammesso poi che il divario sia a causa di quello shader che penalizza NV 40 a causa della dipendenza tra TMU e FPU, e ammesso che l'acqua copra il 40% dello schermo, ed ammesso ancora che una X800 XT sia il doppio più veloce in quello shader a parità di clock, mentre nel resto della scena (come si vede dagli altri demo) vada più o meno alla stessa velocità sulle due schede, ho che dovrei avere sulle 6800 un divario del 25-30% in meno. Invece ho più del 50% . Adesso, IMHO, o c'è qualcosa che non va nel motore grafico, o nei drivers, o le 6800 hanno qualche ulteriore problemino di cui non siamo a conoscenza...


in effetti non hai torto; anche volendosi mettere nel caso "peggiore" per NV40 (cioè con input in forma fp/fp/text), si dovrebbe avrere, comunque, un vantaggio di circa un 12-15% a favore della 6800 Ultra rispetto alla 9800 XT.
A livello di PS , guardando anche i test sintetici, non mi viene in mente niente altro che possa penalizzare l'NV40 rispetto all'R360 (e agli altri chip ATi).
A questo punto ci sarebbe da valutare l'impatto dei VS in questa mappa (canals). Se, ad esempio, avessero adoperato un controllo di flusso statico, questo potrebbe dimezzare la resa dei vs dell'NV40, portandoli ad un valore inferiore di circa il 17% rispetto a quello ottenuto da R360 e pari, praticamente, alla metà di quello di una X800 pro.
Se il motivo fosse quest'ultimo, ci sarebbe da fare i complimenti a Valve :rolleyes: . E' evidente che, al pari di ID dall'altra parte, hanno studiato molto bene le architetture di entrambi i chip.
Comunque ho visto in giro altri bench anche con mappe diverse da quelle scelte da Raffaele e devo dire che "canals" resta l'unica mappa in cui NV40 resta così indietro. Nelle altre è molto più vicino alle prestazioni di R420. Quindi qualcosa di "particolare" pare eserci solo nelle mappe che fanno largo uso di "giochi d'acqua".

[leoneazzurro]

In effetti, sto pensando che usando l'opzione "reflect all" (come nell'articolo di HU) probabilmente si esaspera il carico sui VS (aumentano i poligoni da calcolare) e dimezzando come dici tu le capacità dei VS di Nvidia, forse i conti hanno un pò più di senso.
Speriamo in Fek, dunque :D

[davestas]

Originariamente inviato da Athlon 64 3000+
Sarebbe la X800Pro che si trova sui 450 euro.
Se no andrebbe bene una 9800pro che viene sui 230 euro.


e la 6800 liscia?

[yossarian]

Originariamente inviato da leoneazzurro
In effetti, sto pensando che usando l'opzione "reflect all" (come nell'articolo di HU) probabilmente si esaspera il carico sui VS (aumentano i poligoni da calcolare) e dimezzando come dici tu le capacità dei VS di Nvidia, forse i conti hanno un pò più di senso.
Speriamo in Fek, dunque :D


a parte il fatto che scrive shader troppo pesanti, credo sia l'unico a poterci dare lumi al riguardo

:D

EDIT: un'altra spiegazione potrebbe risiedere nella logica di funzionamento del compilatore interno (nel caso quello di NV40 e quello di NV3x non siano diversi tra loro).
NV3x non è in grado di elaborare shader molto lunghi; quindi li spezzetta e opera in più cicli. NV40, al contrario, può farlo; però se il compilatore avesse la stessa logica di funzionamento opererebbe allo stesso modo facendo perdere cicli di clock inutilmente. La mappa "canals" è una di quelle con gli shader più lunghi. Questo dovrebbe "fare la differenza" in tutte quelle mappe caratterizzate da shader piuttosto complessi.
Altra ancora nell'efficienza dell'HSR; in una scansione front to back quello di ATi può arrivare ad essere quasi il doppio più efficiente nel "rigettare" poligoni nascosti rispetto a quello nVIDIA.
Però questo dovrebbe fare sempre la differenza (almeno in presenza di un buon numero di poligoni) mentre, invece, pare che il gap maggiore si registri nelle mappe ricche di acqua.

:confused:

[yossarian]

Originariamente inviato da davestas
e la 6800 liscia?


per come è strutturato, HL2 si attaglia perfettamente all'architettura ATi. Però NV40 resta un buon chip a livello assoluto.

[fek]

Originariamente inviato da leoneazzurro
In effetti, sto pensando che usando l'opzione "reflect all" (come nell'articolo di HU) probabilmente si esaspera il carico sui VS (aumentano i poligoni da calcolare) e dimezzando come dici tu le capacità dei VS di Nvidia, forse i conti hanno un pò più di senso.
Speriamo in Fek, dunque :D

Il motore geometrico e' sovrabbondante, quello non e' un problema. Si carica pero' di altro fillrate perche' gli oggetti vanno renderizzati in una cube map (una texture map con sei facce) e poi questa cube map usata per le riflessioni.

Pero' se ricordo bene (:p), HL2 non usa una cubemap ma una texture piana per le riflessioni, infatti l'acqua e' sempre allo stesso livello; non si trovano mai due pozzanghere a due altezze diverse. Per inciso e' esattamente quello che faccio anch'io in bw2.

[fek]

Originariamente inviato da yossarian
Però questo dovrebbe fare sempre la differenza (almeno in presenza di un buon numero di poligoni) mentre, invece, pare che il gap maggiore si registri nelle mappe ricche di acqua.

:confused:

Credo che il problema sia proprio lo shader dell'acqua che tende ad essere pesantemente ati-friendly (molte istruzioni matematiche, pochi texture fetch).
Lo dico che anch'io ho lo stesso problema: l'acqua mi va molto veloce su R3X0 e relativamente piu' lenta su NV3X. Lo stesso shader, ed e' difficile renderlo piu' nvidia-friendly, proprio per il tipo di tecnica usata.

[leoneazzurro]

Però possibile che sia talmente ATi-friendly da portare una 6800 Ultra a meno di una 9800 XT, nonostante la 6800 Ultra anche nel caso peggiore (come discusso con Yoss) sia più potente di una 9800 XT? Questo era il senso del mio discorso. Cioè, IMHO NV40 dovrebbe andare a 1/4 della velocità di R3X0 -R4X0 in quello shader per giustificare quei risultati.

[Athlon 64 3000+]

Originariamente inviato da fek
Credo che il problema sia proprio lo shader dell'acqua che tende ad essere pesantemente ati-friendly (molte istruzioni matematiche, pochi texture fetch).
Lo dico che anch'io ho lo stesso problema: l'acqua mi va molto veloce su R3X0 e relativamente piu' lenta su NV3X. Lo stesso shader, ed e' difficile renderlo piu' nvidia-friendly, proprio per il tipo di tecnica usata.


e Come ti vanno con L'NV40?

[yossarian]

Originariamente inviato da fek
Credo che il problema sia proprio lo shader dell'acqua che tende ad essere pesantemente ati-friendly (molte istruzioni matematiche, pochi texture fetch).
Lo dico che anch'io ho lo stesso problema: l'acqua mi va molto veloce su R3X0 e relativamente piu' lenta su NV3X. Lo stesso shader, ed e' difficile renderlo piu' nvidia-friendly, proprio per il tipo di tecnica usata.


a conti fatti, con un input con molte operazioni matematiche e contemporanee texture fetch, il gap teorico tra X800XT e 6800 ultra si potrebbe attestare intorno al 70% come numero di operazioni per ciclo di clock. Nella mappa "canals" c'è qualcosa che non torna; a parte la risoluzione 1024x768, dove la differenza è di poco superiore al 60% (e ci potrebbe stare, considerando i dati teorici), alle altre risoluzioni il gap è di circa il 100%; questo potrebbe addirittura far pensare che a 1024x768 il limite per R420 non sia neppure il fillrate ma qualcosaltro.
Anche con altri titoli, salendo di risoluzione, i chip nViDIA, compreso Nv40, accusano cali più vistosi rispetto a quelli ATi; in questo caso particolare, però, il comportamento veramente anomalo esce fuori dal confronto tra NV40 e R360. A livello di numero di operazioni per ciclo, NV40 è sempre in vantaggio, con qualunque tipo di shader (grazie alle 16 pipeline); R360 ha come unici vantaggi la frequenza leggermente superiore e l'fp24 al posto dell'fp32. Ora, tenendo conto anche della differenza di frequenza e mettendosi nel caso peggiore per NV40, il chip NV dovrebbe avere ancora un margine di poco inferiore al 30%. Non mi risulta che il passaggio da fp32 a fp24 riesca ad azzerare questo margine. Al massimo potrebbe "rosicchiare" un 20% (e si deve tener conto anche del fatto che il motore di R3x0 elabora i calcoli matematici a 24 bit, però il texture address processor funziona a fp32 come quello di nVIDIA).
Ci sarebbe sempre un 10-15% "ballerino" che nella pratica non torna.
IMHO sarei portato a pensare ad un problema di drivers, soprattutto se, come dici, si può escludere il discorso VS.
:confused:

[fek]

Originariamente inviato da Athlon 64 3000+
e Come ti vanno con L'NV40?

Nessun problema, non rilevo quelle differenze, anzi.

[yossarian]

Originariamente inviato da fek
Nessun problema, non rilevo quelle differenze, anzi.


il punto è proprio questo: le considerazioni fatte per NV3x a proposito delle difficoltà di elaborazione di calcoli matematici in fp non sono applicabili a NV40.
Perciò prestazioni allineate a quelle di R360 (come avviane in qualche mappa di HL2) sono, come minimo, "strane".