Frame Rates for Half-Life 2

[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
(rende il concetto però)

[yossarian]

Originariamente inviato da R@nda
Ok

Comunque come dice qualcuno,quell'intervista la conoscono anche i sassi ormai
(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
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/nvi...index.php?p=21

http://www.beyond3d.com/reviews/ati/...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/tec..._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/tec..._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

http://www.penstarsys.com/editor/so3...004/index.html

Non conosco personalmente Josh Walrath ma ne ho apprezzato il coraggio