Half-Life 2: le prime analisi prestazionali

[Clcortez]

Sarei curioso di sapere come va con le Matrox Parhelia.

[paul71]

Io credo che non sia questione di soldi pagati o meno ad una software house o ad un altra. Anche Carmak ha dichiarato quello che hanno dichiarato i Valve e cioè che Doom 3 ha un code path specifico per nv3x e invece code path generico dx 9 per r3xx come anche hl2. Non c'è nessuna differena tra questi due giochi in fatto di ottimizzazioni. Credo che questo code path specifico sia stato fatto proprio nell'interesse degli utenti nvidia (e quindi anche propri degli sviluppatori) che non potrebbero giocare decentemente con tali giochi con schede da 500/600 euro. Non c'è molto da scannarsi su questo. Anzi io da utente Ati plaudo al lavoro di questi programmatori perchè se in futuro dovessi trovarmi io nella situazione attuale degli utenti nvidia gradirei che i programmatori pensassero di rivitalizzare la mia scheda con delle ottimizzazioni. Probabilmente gli ingegneri Nvidia hanno fatto un lavoro a metà perchè sembra che le schede nv3x necessitino di api proprietarie per essere sfruttate (come le glide con la 3dfx) e che quindi mancando questa api proprietaria debbano rincorrere i vari giochi o benchmark con ottimizzazioni ad hoc per ovviare a questa mancanza. Probabilmente nv3x è un mostro che non può essere scatenato come una ferrari con i ruotini da corsa di 60 anni fa che non andrebbe molto lontano. Probabilmente i progetti nv4x saranno molto più ortodossi e non necessiteranno più di queste cose e allora si che vedremmo una bella competizione alla pari con r420. Non vedo l'ora anche perchè all'epoca prevedo di cambiare la gpu... ^_________^
Ciao

[KAISERWOOD]

Valve ha tutto l'interesse di vendere il suo gioco, perciò non credo che pensi ad ottimizzare il codice per i radeon della r3XX e il fatto che sta cercando di farlo girare bene anche sul nv3X è significativo. Il fatto che l'fx sono inferiori alle vecchie schede dx8 è un altro elemento in +. Penso che Nvidia stia ricorrendo già ai ripari nell'ottimizzazione dei driver. Non credo che abbasndo la qualità si possono ricavare + frame qua si deve riscrivere il driver.
Halve si preoccupa di vendere il suo prodotto e poiché la maggior parte dle mercatoo è dominato da nvidia c'è molta gente che ha geforcefx.

[pg08x]

Originariamente inviato da fek
Hey ciao, ti ritrovo sul piede di guerra

La mia opinione e' che con l'uscita del DX9 SDK Summer Update ci sara' sempre meno interesse in Cg (secondo me verra' abbandonato il supporto a breve, almeno e' quello che mi e' sembrato di capire nell'ultimo meeting che ho avuto con nVidia) e le ottimizzazioni specifiche per l'hw saranno sempre piu' a carico del compilatore HLSL e non del programmatore. E' una situazione molto migliore di quella attuale perche' diminuisce considerevolmente il tempo da spendere per queste ottimizzazioni ...

Ciao fex,

ti riquoto perchè mi è venuta in mente una cosa...
c'è qualcuno che dice che ATI si è sposata Microsoft per via della vicenda xbox, il compilatore HLSL è di microsoft...
Da una parte abbiamo i programmatori che, come dici tu, spenderanno molto meno tempo per queste ottimizzazioni, dall'altra microsoft che ha bell'affare di prendersi carico di implementarle direttamente nel proprio compilatore... (stiamo parlando di uno scenario in cui esce un nv40 privo di questi problemi, quindi un nv3x che ha perso interesse commerciale)... dall'altro mi confermi quelli che erano anche i miei sospetti, vale a dire che nvidia cerca di "allentare" il supporto e l'aggiornamento del cg.
Praticamente le cose stanno evolvendo esattamente come ti ripetevo più e più volte in quella lunga discussione che abbiamo avuto tempo fa, vale a dire che cg serve per favorire nv30 ma che per poterlo fare deve stare up to date.
Vedrai andrà a finire come è già successo con la 5800 ultra che è stata pompata all'inverosimile (anni di attesa) per poi essere mollata da nvidia. Quando nv40 sarà ready per le fx non ottimizzerà più nessuno

[Ciesko]

Ragazzi tenete conto che parliamo di 30 (trenta) FPS in +, il divario tra FX e 9800 è grande. Non so se i detonator 50 riescano a recuperarli tutti.. Cmq aspettiamo i "veri bench"

[Eraser|85]

una cosa bisogna dirla però.

E' vero che la nVidia ha problemi, è vero che va peggio (indipendentemente da driver, ottimizzazioni, etc..), però cavolo, chi ha comprato la fx5900ultra come si sente? Cioè ha sprecato cmq 500 e passa euro, per fare che? girare con 30 miseri fps? non penso sia una cosa giusta... e penso che in qualche modo vadano tutelati coloro che hanno fatto questo "errore", chiamiamolo così và... penso che quest'aiuto da parte di valve, e da parte della Id sia molto positivo, in modo che perlomeno l'utente nvidia possa sfruttare un pò di più il proprio hw invece di sbolognarlo subito...

Cmq temo anch'io che appena uscirà l'nv40, il progetto nv3x andrà a farsi benedire, e con esso le ottimizzazioni stile D3 e HL2...

[Wonder]

Sbolognarlo subito? e chi lo vorrebbe sentiamo? Queste sono cose che deprezzano notevolmente una sk video. GLi unici che possono risollevare le sorti sono proprio i programmatori dei driver nVidia. Spera che siano all'altezza

[Eraser|85]

beh diverse volte (in passato però.. tipo i detonator 2x.xx) hanno dimostrato di essere bravi e di aumentare le prestazioni del 20-25%.. qui però la percentuale è ben più alta..

[baldax]

Originariamente inviato da romeop
la 9500PRO va decisamente meglio della 9600PRO visto che ha 8 pipeline di rendering attive, come la 9700.
In più regge all'overclock molto bene e direi che si potrebbe arrivare a quel bench a un valore tra i 55 e i 60.

scusa ma la 9500pro va sempre più forte di una 9600pro o solo in half life 2?

ma la 9600pro non è più nuova della 9500pro?

[tasso79]

Il punto debole della geffo 5900 da quello che mi sembra di vedere, sono proprio gli shader. Così, a quanto pare in un gioco, come hl2, che li usa pesantemente, ottiene prestazioni pessime. La mia ipotesi è che non abbia creduto a sufficienza sullo sviluppo delle dx9 e non abbia temuto abbastanza quello che poteva fare Ati. Io ho una 9500Pro moddata, e non aspetto di giocare ad hl2, visto che è una grandissima figata!

[DoomIII]

Originariamente inviato da Eraser|85
Hmmm sbaglio o sono proprio le GF che perdono quando si attivano i filtri? Ahh no, quello era quando i filtri funzionavano correttamente, che filtravano qualcosa. Da quando la nVidia ha diminuito la qualità dei filtri per farli andare + velocemente, le GF perdono un pò meno...

Hmmmm scusa ancora, ma sbaglio o la nvidia ha dichiarato la serie DET.40 la serie per le DX9???? Me lo ricordo troppo bene perchè all'epoca anch'io avevo una nVidia e ho dovuto installare i det. 4x.xx perchè con le dx9 i vecchi driver davano problemi...

scusa ma perchè la prendete sempre cosi sul personale?
Cio di quello che ho detto tu hai capito una cosa che non ho assolutamente detto e cioè seconde te io avrei insinuato che la Ati con i filtri non marcia...
non sto dicendo questo... viste le performance... ho solo detto che vorrei vedere bench più precisi... sia nVidia con i driver 50 sia le varie risoluzioni e filtri attivati... OVVIAMENTE sia per nVidia che per Ati... perchè da quello che sembra non so quanto fluido possa poi essere il gioco... c'è anche da dire però che questo è un bench... non ho idea se sia una specchio del gioco o se magari esagera effetti/poligoni ecc...
cioè... il gioco potrebbe poi essere più veloce del bench ma potrebbe anche essere che nel bench manchino fisica ecc... bo... magari è stato anche detto ma nn ci ho fatto caso... hmm... qualcuno sa effettivamente sto test cosa sia?

[DoomIII]

Originariamente inviato da Kaiman
X DOOM3.....Hanno detto che non hanno usato i detonator 5x.xx perche' sembra che per far andare il gioco in questione riducano e di moplto la qualita' grafica, togliendo fogging e qualche altro effetto!!!

hmmm... non mi sembra sia stato detto... forse è stato solo supposto... ad ogni modo mi sembra troppo strano... hanno collaborato molto con nVidia per le ottimizzazioni sui detonator 50...

Originariamente inviato da Kaiman
Cnq le geffoFX hanno ENORMI problemi con le DX9, TOmb Raider AOD con gli shader attivati va' il doppio piu' veloce su una raddy 988pro che su una 5900ultra!!!
Percio' non prendetevela con la valve!!!
Il problema e' solo di Nvidia che per "SCOATTARE" con un "+" dopo Pixel shader2.0 e VertexShader 2.0 se ne e' infischiata delle specifiche Microsoft delle DX9!!! E mo sono cavoli suoi!!!

su questo non hai tutti i torti... ma come ho sempre detto nel NV30/35 gli investimenti sono stati maggiori per il futuro...
nVidia era più interessata a poter dettare i nuovi steps... un po come ha fatto all'epoca delle DX8 con gli shaders(suo brevetto).
e cosi NV30/NV35 presentano soluzioni già oltre all'attuale step tecnologico... insomma IMHO è un ibrido sperimentale...

cmq ho sempre sconsigliato l'acquisto di una scheda di questa generazione.

[fek]

Originariamente inviato da Eraser|85
Stiamo cadendo nell'assurdo, non devi fare una versione ottimizzata per una scheda e una versione "normale" senza ottimizzazioni per l'altra. Tutte le schede video devono eseguire il codice nel medesimo modo, senza aiuti, ottimizzazioni o cacchiate varie. Ogni tentativo di miglioramento tramite queste strade è indice di poca competitività di una scheda.

No no no... piano. Le due schede all'interno sono profondamente diverse ed e' normale che sia cosi'. Piu' si programma la scheda a basso livello, ad esempio scrivendo a mano gli shader in assembly, piu' bisogna stare attenti all'ottimizzazione ed il codice risultera' per forza di cose diverse.

E' un'utopia pensare di scrivere uno shader in assembly in maniera "generica": e' un controsenso. Per quello c'e' HLSL.

E' anche non particolarmente esatto dire che l'R3X0 eegue codice generico piu' velocemente dell'NV3X: in realta', per una situazione quasi casuale, scrivendo un pixel shader in maniera "generica" le istruzioni sono mischiate in maniera particolarmente adatta all'R3X0 e particolarmente sfavorevole all'NV3X. Rimischiando le istruzioni accade il contrario. Ci sono dietro discorsi molto a basso livello, non si puo' fare facili generalizzazioni come quella nel post quotato.

[fek]

Originariamente inviato da pg08x
Ciao fex,

ti riquoto perchè mi è venuta in mente una cosa...
c'è qualcuno che dice che ATI si è sposata Microsoft per via della vicenda xbox, il compilatore HLSL è di microsoft...
Da una parte abbiamo i programmatori che, come dici tu, spenderanno molto meno tempo per queste ottimizzazioni, dall'altra microsoft che ha bell'affare di prendersi carico di implementarle direttamente nel proprio compilatore... (stiamo parlando di uno scenario in cui esce un nv40 privo di questi problemi, quindi un nv3x che ha perso interesse commerciale)... dall'altro mi confermi quelli che erano anche i miei sospetti, vale a dire che nvidia cerca di "allentare" il supporto e l'aggiornamento del cg.
Praticamente le cose stanno evolvendo esattamente come ti ripetevo più e più volte in quella lunga discussione che abbiamo avuto tempo fa, vale a dire che cg serve per favorire nv30 ma che per poterlo fare deve stare up to date.
Vedrai andrà a finire come è già successo con la 5800 ultra che è stata pompata all'inverosimile (anni di attesa) per poi essere mollata da nvidia. Quando nv40 sarà ready per le fx non ottimizzerà più nessuno

Ciao

Ok, qualche informazione in piu' (ma non dite che ve l'ho detto io perche' non potrei ). La 5800 e' esattamente la stessa idea della Geforce3: una scheda per introdurre una nuova tecnologia agli sviluppatori. Con la GF3 erano gli shader con la 5800 erano gli shader 2.0. Nessuna delle due schede aveva pretese di essere un successo commerciale, perche' il successo commerciale e' la scheda successiva (GF4 e 5900).
Ora, detto questo, i piani di nVidia non sono andati puliti come con la GF3 perche' e' uscita ATI con un'ottima architettura DX9.
Tornando a Cg, Cg e HLSL sono lo stesso linguaggio, letteralmente lo stesso linguaggio. Se avessi avuto anche il minimo dubbio prima dell'ECTS, dopo aver parlato con MS ad un meeting privato, non ho alcun dubbio: mi hanno confermato che HLSL e Cg sono lo stesso linguaggio che ha preso due strade differenti in termini di compilatore.
La mia impressione e' che nVidia abbandonera' lo sviluppo del suo compilatore (ricordati che il linguaggio e' uguale), ma questa e' solo una mia impressione non confermata da nessun fatto particolare: io non ho domandato e i ragazzi di nVidia non mi hanno detto nulla. Quindi rimane solo un'opionione

Prima di questa parentesi dicevo che i piani nVidia non sono andati pulitissimi per via di ATI, ma questo non vuol dire che stiano cambiando strategia: mi hanno gia' anticipato molte caratteristiche dell'NV40 e alcune dell'NV50. E per tutte e due le generazioni accadra' che usciranno con una scheda per gli sviluppatori (l'NV40 ad esempio) e poi una scheda per il mercato, tipo l'equivalente dell'attuale 5900 o della vecchia GF4.

In altre parole, non comprate le prime schede di ogni generazione sia di ATI sia di nVidia, sono pensate per gli sviluppatori

[yossarian]

Originariamente inviato da fek
No no no... piano. Le due schede all'interno sono profondamente diverse ed e' normale che sia cosi'. Piu' si programma la scheda a basso livello, ad esempio scrivendo a mano gli shader in assembly, piu' bisogna stare attenti all'ottimizzazione ed il codice risultera' per forza di cose diverse.

E' un'utopia pensare di scrivere uno shader in assembly in maniera "generica": e' un controsenso. Per quello c'e' HLSL.

E' anche non particolarmente esatto dire che l'R3X0 eegue codice generico piu' velocemente dell'NV3X: in realta', per una situazione quasi casuale, scrivendo un pixel shader in maniera "generica" le istruzioni sono mischiate in maniera particolarmente adatta all'R3X0 e particolarmente sfavorevole all'NV3X. Rimischiando le istruzioni accade il contrario. Ci sono dietro discorsi molto a basso livello, non si puo' fare facili generalizzazioni come quella nel post quotato.

vero, però è anche vero che tutte le ottimizzazioni per far andare di più chip nVIDIA, dalla path NV30 di Doom3, alla path per HL2, vanno chiaramente in direzione di una drastica riduzione dei calcoli a carico delle unità VS e PS, oltre che di una riscrittura parziale degli stessi (a volte addirittura adoperando versioni precedenti). Questo fa pensare a problemi di architettura (SRF e cache interne sottodimensionatei, minore efficienza delle unità PS e VS, ecc.) oltre che di "interpretazione" delle istruzioni.

ciao

[fek]

Originariamente inviato da yossarian
vero, però è anche vero che tutte le ottimizzazioni per far andare di più chip nVIDIA, dalla path NV30 di Doom3, alla path per HL2, vanno chiaramente in direzione di una drastica riduzione dei calcoli a carico delle unità VS e PS, oltre che di una riscrittura parziale degli stessi (a volte addirittura adoperando versioni precedenti). Questo fa pensare a problemi di architettura (SRF e cache interne sottodimensionatei, minore efficienza delle unità PS e VS, ecc.) oltre che di "interpretazione" delle istruzioni.

ciao

Le ottimizzazioni per NV3X sono di tre tipi:

1) Partial precision

la piu' semplice, si scrive tutto in "partial precision" (a 16 bit invece che 32).

2) Instruction schdeuling

La seconda riguarda lo scheduling delle istruzioni, qui la cosa diventa un po' piu' complicata da seguire e devo scendere un po' nel tecnico. Le istruzioni che si possono eseguire in un pixel shader sono di due tipi: fetch della texture (andare a recuperare all'interno di una texture il colore per un pixel) e istruzioni ALU (calcoli semplici). L'R3X0 lavora meglio se si eseguono prima tutti i fetch delle texture e poi tutti i calcoli. L'NV3X lavora meglio se si mischiano le istruzioni di fetch con quelle di calcolo.

3) Instruction trading

Anche questa e' molto tecnica. L'idea qui e' che l'NV30 e' piu' veloce a eseguire il fetch di una texture di quanto lo sia a fare alcuni calcoli complessi, quindi in alcuni casi conviene evitare un calcolo e andarlo a recuperare all'interno di una tabella (la texture)

Ora vediamo caso per caso perche' il path cosi' detto generico (che generico non e') favorisce l'R3X0

1) Di default i calcoli sono in precisione massima che e' 32 bit per l'NV3X e 24 (correzione ) bit per l'R3X0; ovviamente di default e' piu' veloce l'R3X0 perche' esegue calcoli a precisione minore

2) Di default (ed in maniera piu' naturale) si scrivono prima i fetch delle texture e poi i calcoli, cosa che favorisce l'R3X0; quindi essendo piu' naturale scrivere in questo modo, questa naturalita' ottimizza una delle due architettura e non l'altra

3) L'R3X0 soffre meno il problema dei calcoli complicati nel pixel shader perche' il motore dei pixel shader e' piu' veloce, anche perche' e' meno complesso e ricco di funzionalita' di quello dell'NV3X (hanno preferito un'architettura meno potente e ricca ma piu' veloce)

Una piccola noticina: su NV3X e' possibile scrivere alcuni effetti complicati in una sola passata piuttosto che in piu' passate necessarie all'R3X0 (questo non e' strettamente vero per l'R350 grazie all'F-buffer) perche' il motore dei pixel shader e' piu' ricco di funzionalita' quindi in questo caso risulterebbe piu' veloce.
Credo che HL2 non abbia di questi shader particolarmente complessi da richiedere piu' di una passata su R3X0.

[Bulfio]

Ma perchè di default i calcoli sono a 32 bit per NV e a 16 bit per Ati????? Questa non l'ho proprio capita..non dovrebbe essere di default per entrabi a 32 bit?

[yossarian]

Originariamente inviato da fek
Le ottimizzazioni per NV3X sono di tre tipi:

1) Partial precision

la piu' semplice, si scrive tutto in "partial precision" (a 16 bit invece che 32).

2) Instruction schdeuling

La seconda riguarda lo scheduling delle istruzioni, qui la cosa diventa un po' piu' complicata da seguire e devo scendere un po' nel tecnico. Le istruzioni che si possono eseguire in un pixel shader sono di due tipi: fetch della texture (andare a recuperare all'interno di una texture il colore per un pixel) e istruzioni ALU (calcoli semplici). L'R3X0 lavora meglio se si eseguono prima tutti i fetch delle texture e poi tutti i calcoli. L'NV3X lavora meglio se si mischiano le istruzioni di fetch con quelle di calcolo.

3) Instruction trading

Anche questa e' molto tecnica. L'idea qui e' che l'NV30 e' piu' veloce a eseguire il fetch di una texture di quanto lo sia a fare alcuni calcoli complessi, quindi in alcuni casi conviene evitare un calcolo e andarlo a recuperare all'interno di una tabella (la texture)

Ora vediamo caso per caso perche' il path cosi' detto generico (che generico non e') favorisce l'R3X0

1) Di default i calcoli sono in precisione massima che e' 32 bit per l'NV3X e 16 bit per l'R3X0; ovviamente di default e' piu' veloce l'R3X0 perche' esegue calcoli a precisione minore

2) Di default (ed in maniera piu' naturale) si scrivono prima i fetch delle texture e poi i calcoli, cosa che favorisce l'R3X0; quindi essendo piu' naturale scrivere in questo modo, questa naturalita' ottimizza una delle due architettura e non l'altra

3) L'R3X0 soffre meno il problema dei calcoli complicati nel pixel shader perche' il motore dei pixel shader e' piu' veloce, anche perche' e' meno complesso e ricco di funzionalita' di quello dell'NV3X (hanno preferito un'architettura meno potente e ricca ma piu' veloce)

Una piccola noticina: su NV3X e' possibile scrivere alcuni effetti complicati in una sola passata piuttosto che in piu' passate necessarie all'R3X0 (questo non e' strettamente vero per l'R350 grazie all'F-buffer) perche' il motore dei pixel shader e' piu' ricco di funzionalita' quindi in questo caso risulterebbe piu' veloce.
Credo che HL2 non abbia di questi shader particolarmente complessi da richiedere piu' di una passata su R3X0.

Grazie per la spiegazione (al punto 1, però edita la max precisione per R3x0 che è 24 bit ).
Quanto dici al punto 2, tranne che per NV35, sembra in contrasto con quanto riportato in quest'articolo
http://www.3dcenter.de/artikel/cinefx/index_e.php
Inoltre i dubbi relativi alla capienza dei registri, sollevati anche da Anand in questo punto dell'articolo

So the first change that was made is to use partial-precision registers where appropriate, well what does that mean? As we've mentioned in previous articles, NVIDIA's pixel shading pipelines can either operate on 16 or 32-bit floating point numbers, with the 32-bit floats providing greater precision. Just like on a CPU, the actual FPUs that are present in the pixel shader units have a fixed number of local storage locations known as registers. Think of a register as nothing more than a place to store a number; with the NV3x architecture, each register can either hold one 32-bit floating point value or it can be used as two 16-bit floating point registers. Thus when operating in 16-bit (aka partial precision) mode, you get twice as many physical registers as when you're running in 32-bit mode.

Note that using 32-bit floating point numbers doesn't increase the amount of memory bandwidth you're using, it simply means that you're cutting down the number of physical registers your pixel shader FPUs have access to. What happens if you run out of registers? After running out of registers, the functional units (FPUs in this case) must swap data in and out of the graphics card's local memory (or caches) which takes a significantly longer time - causing stalls in the graphics pipeline or underutilization of the full processing power of the chip.

The fact that performance increased when moving to partial-precision (16-bit) registers, indicates that NVIDIA's NV3x chips may have fewer usable physical registers than ATI's R3x0 series. If we're correct, this is a tradeoff that the NVIDIA engineers have made and it is to conserve die space, but we're not here to criticize NVIDIA's engineers rather explain NVIDIA's performance here.

Next, Gabe listed the tradeoff in pixel shader instruction count for texture fetches. To sum this one up, the developers resorted to burning more texture (memory) bandwidth instead of putting a heavier load on computations in the functional units. Note that this approach is much more similar to the pre-DX9 method of game development, where we were mainly memory bandwidth bound instead of computationally bound. The fact that NVIDIA benefited from this sort of an optimization indicates that the NV3x series may not have as much raw computational power as the R3x0 GPUs (whether that means that it has fewer functional units or it is more picky about what it can execute and when is anyone's guess).

li avevo avuti anch'io a luglio (so che non sta bene citarsi, ma non sono proprio uno sprovveduto completo in fatto di architettura di chip: sicuramente conosco molto meglio l'HW del SW).
Mettendo insieme le due cose, potrebbero emergere i motivi delle non brillanti prestazioni dei motori VS e PS dellNV3x.

Per quanto riguarda il punto 3, sapevo di questi shader complessi e del vantaggio che avrebbero portato all'NV3x, però sono convinto che l'f-buffer possa essere almeno "simulato" anche sull'R300 (e non sia una peculiarità dell'R350).

Ciao

[massibirba]

vedro' come si comporta la mia sapphire7500 :l'esperienza mi ha insegnato a non credere a tutte le balle dei test,secondo me e' tutta propaganda per vendere le schede video in un mercato in recessione cronica...mha...Io uso molto il pc per giocare e fino ad esso ho sempre giocato anche agli ultimissimi giochi a 1024X768 a 32 bit senza uno scatto.Le schede supersborone servono solo se vuoi GIocare da sborone(anti-alias a 8X)cosa che se non sei ultraesigente non ti serve a niente

[fek]

Originariamente inviato da Bulfio
Ma perchè di default i calcoli sono a 32 bit per NV e a 16 bit per Ati????? Questa non l'ho proprio capita..non dovrebbe essere di default per entrabi a 32 bit?

Perche' hanno scelto cosi' in fase di design
Da una parte max a 24 e dall'altra 16/32.