Frame Rates for Half-Life 2

[[KabOOm]]

Originariamente inviato da yossarian
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".

...io pensavo di aver capito che le differenze sono da ricercare nel differente approccio delle due architetture e dei due motori grafici...

...e mi pareva di capire che questo gap ci stava... a questo punto pero' se i dubbi permangono sono anche io perplesso... :mumble:

[yossarian]

Originariamente inviato da [KabOOm]
...io pensavo di aver capito che le differenze sono da ricercare nel differente approccio delle due architetture e dei due motori grafici...

...e mi pareva di capire che questo gap ci stava... a questo punto pero' se i dubbi permangono sono anche io perplesso... :mumble:


NV40 e NV3x hanno diverse analogie, però nell'effettuazione di calcoli matematici, la curva di risposta di NV40 è quasi uguale (praticamente identica, tranne nel caso di texture fetch e operazioni algebriche contemporanee) a quella di R420 e R3x0 e molto diversa da NV3x. In quest'ottica, le basse prestazioni di NV3x sono spiegabili, quelle di NV40 (in questo caso basse relativamente al potenziale del chip e non in senso assoluto) lo sono molto meno.

[Athlon 64 3000+]

Originariamente inviato da yossarian
NV40 e NV3x hanno diverse analogie, però nell'effettuazione di calcoli matematici, la curva di risposta di NV40 è quasi uguale (praticamente identica, tranne nel caso di texture fetch e operazioni algebriche contemporanee) a quella di R420 e R3x0 e molto diversa da NV3x. In quest'ottica, le basse prestazioni di NV3x sono spiegabili, quelle di NV40 (in questo caso basse relativamente al potenziale del chip e non in senso assoluto) lo sono molto meno.

Vedremo cosa succederà in futuro.

[[KabOOm]]

Originariamente inviato da yossarian
NV40 e NV3x hanno diverse analogie, però nell'effettuazione di calcoli matematici, la curva di risposta di NV40 è quasi uguale (praticamente identica, tranne nel caso di texture fetch e operazioni algebriche contemporanee) a quella di R420 e R3x0 e molto diversa da NV3x. In quest'ottica, le basse prestazioni di NV3x sono spiegabili, quelle di NV40 (in questo caso basse relativamente al potenziale del chip e non in senso assoluto) lo sono molto meno.

Quindi potrebbe essere tutto una problema di driver?
Magari non sviluppati a dovere sul lato Shader 2.0 perche' invece improntati di piu' per sfruttare le caratteristiche di di NV40?

In linea teorica, ritenete assurdo l'ipotesi che Hl2 almeno al momento si intenzionalmente piu' prestazionale su ATI piuttosto che Nvidia (e magari con successive patch questo non accadra')?

A me ersonalmente non interessa HL2 (non ho giocato neanche il primo) e pertanto poco mi tocca, adesso come adesso ho un ATI dopo due Nvidia ma per il futuro ho sempre piu' dubbi...

[yossarian]

Originariamente inviato da [KabOOm]
Quindi potrebbe essere tutto una problema di driver?
Magari non sviluppati a dovere sul lato Shader 2.0 perche' invece improntati di piu' per sfruttare le caratteristiche di di NV40?

In linea teorica, ritenete assurdo l'ipotesi che Hl2 almeno al momento si intenzionalmente piu' prestazionale su ATI piuttosto che Nvidia (e magari con successive patch questo non accadra')?

A me ersonalmente non interessa HL2 (non ho giocato neanche il primo) e pertanto poco mi tocca, adesso come adesso ho un ATI dopo due Nvidia ma per il futuro ho sempre piu' dubbi...


se fosse un problema di drivers sarei più portato a pensare a drivers "aggiustati" per NV3x che finiscono con il penalizzare NV40.
Forse è nVIDIA stessa che può risolvere questo problema.
Riguardo l'ipotesi che HL2 sia ATi frindly, credo sia ben più di un'ipotesi, ormai

[[KabOOm]]

Originariamente inviato da yossarian
se fosse un problema di drivers sarei più portato a pensare a drivers "aggiustati" per NV3x che finiscono con il penalizzare NV40.
Forse è nVIDIA stessa che può risolvere questo problema.
Riguardo l'ipotesi che HL2 sia ATi frindly, credo sia ben più di un'ipotesi, ormai

Ho letto anche l'altro 3d...

Mi spiace dovermi perdere in cose che non conosco minimamente e che riesco a capire solo in parte attingendo ai concetti base di programmazione che ho (che non bastano assolutamente).

L'ATI Friendly c'era da aspettarselo, ma la decisione di non pensare minimamente ad una ottimizzazione verso nVidia proprio non me l'aspettavo...

[yossarian]

non è un problema di drivers e credo di essere vicino alla soluzione; devo solo ridare un'occhiata al manuale delle giovani marmotte

:D

[dagon1978]

Originariamente inviato da yossarian
non è un problema di drivers e credo di essere vicino alla soluzione; devo solo ridare un'occhiata al manuale delle giovani marmotte

:D

dacci un indizio almeno :p
problema intrinseco dell'architettura nvidia o qualche magagna valve?

[Athlon 64 3000+]

Originariamente inviato da yossarian
non è un problema di drivers e credo di essere vicino alla soluzione; devo solo ridare un'occhiata al manuale delle giovani marmotte

:D


Sono molto curioso di sapere quale è la vera causa.Appena lo sai sappici dire.
Spero non sia un sgradita sorpresa.

[yossarian]

niente di cui non si sapesse l'esistenza; era necessario fare solo calcoli un po' più completi (e complessi).
Si è parlato della dipendenza tra alu e tmu delle gpu nVIDIA; bene, questo è l'esempio tipico di quanto quel fattore possa nincidere sulle prestazioni, soprattutto se il SW è programmato in modo da far intervenire il meno possibile le seconde alu (le cosiddette mini-alu) delle pipeline di rendering. Per chi non lo sapesse, queste seconde unità non sono delle vere e proprie fpu complete ma possono svolgere diverse operazioni di "supporto" nei calcoli, in modo tale che alcune operazioni che, altrimenti, richiederebbero due cicli di clock, possono essere svolte in un solo ciclo; un'altra delle funzioni di queste unità è quella di emulare, lavorando insieme alla fpu principale, il funzionamento di una fxu (unità in virgola fissa). L'efficienza di queste seconde unità è subordinata a veri fattori (tipo di istruzione da eseguire, sequenza delle istruzioni, impegno dei registri, ecc). Il problema può sorgere con istruzioni che non soddisfano i requisiti "minimi" a garantire la massima efficienza o addirittura il funzionamento di queste seconde unità. Finora avevo considerato, evidentemente sbagliando, che il SW fosse progettato in maniera tale da ottimizzare il funzionamento delle pixel pipeline (non di una particolare architettura, poichè queste mini-alu sono state introdotte con l'R300 e riprese da NV35, R420 e NV40); questo, appare chiaro omai, non è quello che si verifica con alcuni degli shader più complessi di HL2.
Se andiamo ad analizzare le pipeline dell'NV40 e quelle di R3x0 e R420, vediamo che, immaginando disabilitata la seconda alu, NV40 resta con un potenziale di sole 16 operazioni per ciclo di clock (o di tipo texture fetch o di tipo matematico); R3x0 e R420, avendo, invece, tmu e fpu indipendenti, hanno un potenziale teorico di 16 e 32 operazioni per ciclo di clock.
Come si può facilmente vedere, NV40 e R3x0, in questa situazione, hanno lo stesso potenziale di calcolo per ciclo; in più R3x0 ha una frequenza leggermente superiore e lavora a fp24; di contro, NV40 risulta un po' più efficiente (non di molto rispetto a R3x0, ma in maniera decisamente più sostanziosa, prossima al 25%, rispetto a R420, cosa naturale, del resto) nelle operazioni di texturing e, in genere, a livello di pixel pipeline (meno code, meno tempi di attesa tra un'elaborazione e l'altra, ecc): questo grazie all'architettura superscalare (di cui non entro, in questa sede, nei dettagli).
Questo spiega come mai, in "canals", le prestazioni di R3x0 e NV40 risultino stranamente allineate e giustifica anche l'enorme divario tra R420 e NV40 (a 1280 addirittura attorno al 100%).

E' una situazione che si può risolvere? Del tutto no, però si può cercare di minimizzare ottimizzando il funzionamento delle alu, magari ordinando le istruzioni in maniera diversa e, se necessario, fare qualche operazioni di shader replacement (operazione, ormai, piuttosto in voga su entrambi i fronti, soprattutto dopo le "ottimizzazioni spinte" fatte da ID e da Valve sui rispettivi titoli).
Questo, ovviamente, oltre a forzare fp16.
Risulta chiaro, ormai, che come Carmack è ricorso all'utilizzo di lookup table (il cui uso è sconsigliato da ATi che preferisce calcoli fp) a profusione, per andare incontro alle esigenze dei chip NV, Valve ha adottato le specifiche "consigliate" da ATi: molti calcoli matematici e ratio 1:1 tra texture fetch e pixel shader (ratio, ovviamente, indigesto a NV).

[Athlon 64 3000+]

Originariamente inviato da yossarian
niente di cui non si sapessa l'esistenza; era necessario fare solo calcoli un po' più completi (e complessi).
Si è parlato della dipendenza tra alu e tmu delle gpu nVIDIA; bene, questo è l'esempio tipico di quanto quel fattore possa nincidere sulle prestazioni, soprattutto se il SW è programmato in modo da far intervenire il meno possibile le seconde alu (le cosiddette mini-alu) delle pipeline di rendering. Per chi non lo sapesse, queste seconde unità non sono delle vere e proprie fpu complete ma possono svolgere diverse operazioni di "supporto" nei calcoli, in modo tale che alcune operazioni che, altrimenti, richiederebbero due cicli di clock, possono essere svolte in un solo ciclo; un'altra delle funzioni di queste unità è quella di emulare, lavorando insieme alla fpu principale, il funzionamento di una fxu (unità in virgola fissa). L'efficienza di queste seconde unità è subordinata a veri fattori (tipo di istruzione da eseguire, sequenza delle istruzioni, impegno dei registri, ecc). Il problema può sorgere con istruzioni che non soddisfano i requisiti "minimi" a garantire la massima efficienza o addirittura il funzionamento di queste seconde unità. Questo è quello che si verifica con alcuni degli shader più complessi di HL2.
Se andiamo ad analizzare le pipeline dell'NV40 e quelle di R3x0 e R420, vediamo che, immaginando disabilitata la seconda alu, NV40 resta con un potenziale di sole 16 operazioni per ciclo di clock (o di tipo texture fetch o di tipo matematico); R3x0 e R420, avendo, invece, tmu e fpu indipendenti, hanno un potenziale teorico di 16 e 32 operazioni per ciclo di clock.
Come si può facilmente vedere, NV40 e R3x0, in questa situazione, hanno lo stesso potenziale di calcolo per ciclo; in più R3x0 ha una frequenza leggermente superiore e lavora a fp24; di contro, NV40 risulta un po' più efficiente (non di molto rispetto a R3x0, ma in maniera decisamente più sostanziosa, prossima al 25%, rispetto a R420, cosa naturale, del resto) nelle operazioni di texturing e, in genere, a livello di pixel pipeline (meno code, meno tempi di attesa tra un'elaborazione e l'altra, ecc): questo grazie all'architettura superscalare (di cui non entro, in questa sede, nei dettagli).
Questo spiega come mai, in "canals", le prestazioni di R3x0 e NV40 risultino stranamente allineate e giustifica anche l'enorme divario tra R420 e NV40 (a 1280 addirittura attorno al 100%).

E' una situazione che si può risolvere? Del tutto no, però si può cercare di minimizzare ottimizzando il funzionamento delle alu, magari ordinando le istruzioni in maniera diversa e, se necessario, fare qualche operazioni di shader replacement (operazione, ormai, piuttosto in voga su entrambi i fronti, soprattutto dopo le "ottimizzazioni spinte" fatte da ID e da Valve sui rispettivi titoli).
Questo, ovviamente, oltre a forzare fp16.
Risulta chiaro, ormai, che come Carmack è ricorso all'utilizzo di lookup table (il cui uso è sconsigliato da ATi che preferisce calcoli fp) a profusione, per andare incontro alle esigenze dei chip NV, Valve ha adottato le specifiche "consigliate" da ATi: molti calcoli matematici e ratio 1:1 tra texture fetch e pixel shader (ratio, ovviamente, indigesto a NV).


Ottima spiegazione.
Quelli della valve hanno programmati degli Shader facendo venire fuori l'unico limite dell'NV40.

[BTinside]

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.

Piccolo OT: Fek ne sai niente che fine ha fatto BC, perchè è stato abbandonato il progetto?

[BTinside]

Originariamente inviato da yossarian
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:

Concordo e aggiungo che secondo me più andiamo avanti più ci saranno uguaglianze fra "differenti" architetture,
alla fine forse si vedrà solo chi sarà il "più bravo" a realizzare il chip con le stesse features, abbandonando la creatività di cui parli tu

[BTinside]

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).

Una curiosità, voi non fate altro che dire che la scena "canals" utilizza una precisione "fp32 con tutti i chip (R420, NV40 , R3XX).."
ma le Ati vanno pur sempre a 24 bit no?
Il test forza fp32 solo su NV40 quindi?
Poi capisco che Valve : Ati e si privileggiano i 24bit, ma se si sostiene che oggi FP16 è più che sufficiente dal punto di vista qualitativo, perchè usare su NV40 FP32 al posto di FP16?

[yossarian]

Originariamente inviato da BTinside
Una curiosità, voi non fate altro che dire che la scena "canals" utilizza una precisione "fp32 con tutti i chip (R420, NV40 , R3XX).."
ma le Ati vanno pur sempre a 24 bit no?
Il test forza fp32 solo su NV40 quindi?
Poi capisco che Valve : Ati e si privileggiano i 24bit, ma se si sostiene che oggi FP16 è più che sufficiente dal punto di vista qualitativo, perchè usare su NV40 FP32 al posto di FP16?


diciamo che si utilizza fp32 perchè questa è la chiamata esterna. Dal punto di vista della precisione di calcolo equivale a forzare la massima precisione possibile nelle pixel pipeline. Questo significa che Rxyz elabora a fp24 i calco,i matematici, a fp32 gli indirizzi per le texture e, in uscita, converte tutto a fp32; NVws elabora a fp32 sia i calcoli matematici che gli indirizzi per la texture.

Riguardo alla seconda parte, se effettivamente fp16 risultasse sufficiente a riprodurre tutti gli effetti senza perdita di qualità, credo che la pp sarà utilizzata molto presto (almeno a livello di drivers).

[leoneazzurro]

Originariamente inviato da yossarian
niente di cui non si sapesse l'esistenza; era necessario fare solo calcoli un po' più completi (e complessi).
Si è parlato della dipendenza tra alu e tmu delle gpu nVIDIA; bene, questo è l'esempio tipico di quanto quel fattore possa nincidere sulle prestazioni, soprattutto se il SW è programmato in modo da far intervenire il meno possibile le seconde alu (le cosiddette mini-alu) delle pipeline di rendering. Per chi non lo sapesse, queste seconde unità non sono delle vere e proprie fpu complete ma possono svolgere diverse operazioni di "supporto" nei calcoli, in modo tale che alcune operazioni che, altrimenti, richiederebbero due cicli di clock, possono essere svolte in un solo ciclo; un'altra delle funzioni di queste unità è quella di emulare, lavorando insieme alla fpu principale, il funzionamento di una fxu (unità in virgola fissa). L'efficienza di queste seconde unità è subordinata a veri fattori (tipo di istruzione da eseguire, sequenza delle istruzioni, impegno dei registri, ecc). Il problema può sorgere con istruzioni che non soddisfano i requisiti "minimi" a garantire la massima efficienza o addirittura il funzionamento di queste seconde unità. Finora avevo considerato, evidentemente sbagliando, che il SW fosse progettato in maniera tale da ottimizzare il funzionamento delle pixel pipeline (non di una particolare architettura, poichè queste mini-alu sono state introdotte con l'R300 e riprese da NV35, R420 e NV40); questo, appare chiaro omai, non è quello che si verifica con alcuni degli shader più complessi di HL2.
Se andiamo ad analizzare le pipeline dell'NV40 e quelle di R3x0 e R420, vediamo che, immaginando disabilitata la seconda alu, NV40 resta con un potenziale di sole 16 operazioni per ciclo di clock (o di tipo texture fetch o di tipo matematico); R3x0 e R420, avendo, invece, tmu e fpu indipendenti, hanno un potenziale teorico di 16 e 32 operazioni per ciclo di clock.
Come si può facilmente vedere, NV40 e R3x0, in questa situazione, hanno lo stesso potenziale di calcolo per ciclo; in più R3x0 ha una frequenza leggermente superiore e lavora a fp24; di contro, NV40 risulta un po' più efficiente (non di molto rispetto a R3x0, ma in maniera decisamente più sostanziosa, prossima al 25%, rispetto a R420, cosa naturale, del resto) nelle operazioni di texturing e, in genere, a livello di pixel pipeline (meno code, meno tempi di attesa tra un'elaborazione e l'altra, ecc): questo grazie all'architettura superscalare (di cui non entro, in questa sede, nei dettagli).
Questo spiega come mai, in "canals", le prestazioni di R3x0 e NV40 risultino stranamente allineate e giustifica anche l'enorme divario tra R420 e NV40 (a 1280 addirittura attorno al 100%).

E' una situazione che si può risolvere? Del tutto no, però si può cercare di minimizzare ottimizzando il funzionamento delle alu, magari ordinando le istruzioni in maniera diversa e, se necessario, fare qualche operazioni di shader replacement (operazione, ormai, piuttosto in voga su entrambi i fronti, soprattutto dopo le "ottimizzazioni spinte" fatte da ID e da Valve sui rispettivi titoli).
Questo, ovviamente, oltre a forzare fp16.
Risulta chiaro, ormai, che come Carmack è ricorso all'utilizzo di lookup table (il cui uso è sconsigliato da ATi che preferisce calcoli fp) a profusione, per andare incontro alle esigenze dei chip NV, Valve ha adottato le specifiche "consigliate" da ATi: molti calcoli matematici e ratio 1:1 tra texture fetch e pixel shader (ratio, ovviamente, indigesto a NV).


In parole povere si è volutamente scritto lo shader nella maniera più indigesta per NV 40. Magari (voglio essere molto cattivo) l'anno passato ad "ottimizzare" è servito proprio a trovare il punto di minimo :D.

Ad ogni modo, ritieni che in NV 50 questa benedetta interdipendenza tra TMU e ALU verrà finalmente recisa?
Credi che, data la cancellazione di NV 48, ci si possa attendere che NV 50 veda la luce in anticipo sui tempi previsti?

[BTinside]

Originariamente inviato da Athlon 64 3000+
Ottima spiegazione.
Quelli della valve hanno programmati degli Shader facendo venire fuori l'unico limite dell'NV40.

A mio parere è un limite relativamente. Semplicemente se non fosse stato un gioco Ati Friendly si sarebbe provveduto a far funzionare quella unità di supporto, le mini-alu di cui parla Yoss, e NV40 avrebbe risposto molto meglio.

Ottima spiegazione Yoss

[yossarian]

Originariamente inviato da leoneazzurro
In parole povere si è volutamente scritto lo shader nella maniera più indigesta per NV 40. Magari (voglio essere molto cattivo) l'anno passato ad "ottimizzare" è servito proprio a trovare il punto di minimo :D.

Ad ogni modo, ritieni che in NV 50 questa benedetta interdipendenza tra TMU e ALU verrà finalmente recisa?
Credi che, data la cancellazione di NV 48, ci si possa attendere che NV 50 veda la luce in anticipo sui tempi previsti?


nessuna sorpresa: Carmack ha fatto lo stesso con Doom3 nei confronti di ATi. Casualmente :rolleyes: ho una guida dal titolo "ATi DX9 optimization" in cui si sconsiglia il ricorso a più di due istruzioni dependent texture read consecutive. Ovviamente, ID si è ben guardata dal seguire questa raccomandazione

:D

Spero solo che Doom3 e HL2 restino due casi isolati

[dagon1978]

Originariamente inviato da yossarian
nessuna sorpresa: Carmack ha fatto lo stesso con Doom3 nei confronti di ATi. Casualmente :rolleyes: ho una guida dal titolo "ATi DX9 optimization" in cui si sconsiglia il ricorso a più di due istruzioni dependent texture read consecutive. Ovviamente, ID si è ben guardata dal seguire questa raccomandazione

:D

Spero solo che Doom3 e HL2 restino due casi isolati

sì, ma a vedere i bench il premio per la "migliore" cattiva programmazione (ovviamente nei riguardi della casa non amica) va a Valve, visto che è riuscita a "declassare" le 6800ultra al livello, se non sotto, le 9800pro

ora, ovviamente il mio post è ironico, un conto è mettere il bastone tra le ruote dell'avversario, ma qui si è arrivati veramente ai limite dell'immaginabile...
cmq quello che conta è che sia solo una situazione particolare all'interno di un gioco intero e che magari la Nvidia ci metta qualche pezza per risollevare un po' l'NV40, che mi pare di capire sia un buon progetto...

concludo dicendo, che spero non si verifichino altri episodi del genere, se i giochi venissero programmati sempre nel migliore dei modi possibili, credo ne guadagnerebbero tanto Valve quanto ID... oltre a noi utenti finali ;)

[BTinside]

Originariamente inviato da dagon1978
sì, ma a vedere i bench il premio per la "migliore" cattiva programmazione (ovviamente nei riguardi della casa non amica) va a Valve, visto che è riuscita a "declassare" le 6800ultra al livello, se non sotto, le 9800pro

ora, ovviamente il mio post è ironico, un conto è mettere il bastone tra le ruote dell'avversario, ma qui si è arrivati veramente ai limite dell'immaginabile...
cmq quello che conta è che sia solo una situazione particolare all'interno di un gioco intero e che magari la Nvidia ci metta qualche pezza per risollevare un po' l'NV40, che mi pare di capire sia un buon progetto...

concludo dicendo, che spero non si verifichino altri episodi del genere, se i giochi venissero programmati sempre nel migliore dei modi possibili, credo ne guadagnerebbero tanto Valve quanto ID... oltre a noi utenti finali ;)

A mio parere anche Carmack se ne avesse avuto la possibilità sarebbe arrivato al limite dll'immagginabile.
Il limite dell'immagginabile è stato raggiunto da Valve anche grazie alla dipendenza fra Alu e Tmu di NV40.
Valve ha fatto Carpe Diem,
il doppio del fill rate espresso da NV40 in Doom3 rispetto a R420 e l'Ultrashadow II non mi sembrano tali da fare la stessa differenza che c'è in HL2

[dagon1978]

Originariamente inviato da BTinside
A mio parere anche Carmack se ne avesse avuto la possibilità sarebbe arrivato al limite dll'immagginabile.
Il limite dell'immagginabile è stato raggiunto da Valve anche grazie alla dipendenza fra Alu e Tmu di NV40.
Valve ha fatto Carpe Diem,
il doppio del fill rate espresso da NV40 in Doom3 rispetto a R420 e l'Ultrashadow II non mi sembrano tali da fare la stessa differenza che c'è in HL2

quindi dici, a livello di "qualità" ( :rolleyes: )di programmazione Valve e ID si sono equivalse, ma il punto debole di NV40 è più marcato rispetto a quello di R420?
ok, pari e patta per le simpaticissime Valve e ID, a entrambe darei un bel tapiro di bronzo...
cmq, a me sembra tutta pubblicità negativa nei loro confronti ;) mi sbaglierò... hanno voluto fare tanto i furbini...

[BTinside]

Originariamente inviato da dagon1978
quindi dici, a livello di "qualità" ( :rolleyes: )di programmazione Valve e ID si sono equivalse, ma il punto debole di NV40 è più marcato rispetto a quello di R420?
ok, pari e patta per le simpaticissime Valve e ID, a entrambe darei un bel tapiro di bronzo...
cmq, a me sembra tutta pubblicità negativa nei loro confronti ;) mi sbaglierò... hanno voluto fare tanto i furbini...

Si dopo aver letto le preziosissime lezioni (tanto che potrebbero farle a pagamento) di Yoss, Raffaele e il programmatore Fek (che non mi risponde ancora su BC) questo è il mio parere.
Carmack credo abbia fatto il possibile per penalizzare Ati, e la stessa cosa Valve, solo che Valve ha avuto la strada più facile grazie ad Nvidia che si fa "autogoal"

[leoneazzurro]

Direi proprio di si, poi poni che sicuramente a livello assoluto, grazie al clock superiore, ATI tende ad essere comunque più veloce, mentre NV 40 ha diverse ineressanti features in più. Ma nel complesso non si sbaglia, qualunque strada si scelga.

[leoneazzurro]

PS Questo sono poi i motivi che spingono all'acquisto di una console: almeno lì l'hardware è uno e i programmatori non hanno queste "spintarelle" a lavorare male. :)

PPSS Ma non una PS2 altrimenti a Fek viene il mal di testa :D

[BTinside]

Originariamente inviato da leoneazzurro
Direi proprio di si, poi poni che sicuramente a livello assoluto, grazie al clock superiore, ATI tende ad essere comunque più veloce, mentre NV 40 ha diverse ineressanti features in più. Ma nel complesso non si sbaglia, qualunque strada si scelga.

Sicuramente ne capisco meno di te ma a mio parere la questione di mhz non sembra molto rilevante, perchè ci sono situazioni di parità fra i due top canadese e califoriano anche con questa differenza di fill rate e mhz, infatti sembrerebbe che NV40 sia più efficiente di R420 in taluni casi, pur avendo specifiche su carta inferiori

[BTinside]

Originariamente inviato da leoneazzurro
PS Questo sono poi i motivi che spingono all'acquisto di una console: almeno lì l'hardware è uno e i programmatori non hanno queste "spintarelle" a lavorare male. :)

PPSS Ma non una PS2 altrimenti a Fek viene il mal di testa :D

X Fek : voi personalmente fino a che periodo avete utilizzato i kit di sviluppo mediativi fra voi e PS2(se li avete usati ovviamente)?
Quando avete capito appieno in che modo utilizzare quei "soli" 4mb di RAM video che non va usata come RAM tradizionale?
Mi potresti spiegare il reale ruolo di questa "buffer" (così lo chiamano) di 4mb?
Le superiori capacità particellari di PS2 su Xbox fanno la differenza o sono comunque castrate dall'architettura?

[leoneazzurro]

Originariamente inviato da BTinside
Sicuramente ne capisco meno di te ma a mio parere la questione di mhz non sembra molto rilevante, perchè ci sono situazioni di parità fra i due top canadese e califoriano anche con questa differenza di fill rate e mhz, infatti sembrerebbe che NV40 sia più efficiente di R420 in taluni casi, pur avendo specifiche su carta inferiori

Le situazioni di parità si possono avere per altri motivi. Ad esempio quando si è CPU limited. NV 40, poi, nonostante la disparità di clock, a quanto pare riesce nei test sintetici grazie ad una notevole efficienza nell'esecuzione quasi ad eguagliare una X800 XT nell'esecuzione di PS 2.0. Nel caso dei VS invece è indietro a causa del clock. NV 40 riesce a compiere alcune istruzioni in un singolo ciclo di clock, mentre alla concorrenza ne servono due. Per altre succede il contrario. NV 40 soffre per la dipendenza tra TMU e ALU, per cui è sensibile come NV 3x al tipo di input che gli viene presentato. Insomma, dipende tutto da come è programmato il gioco. Tuttavia, in genere, X800 ha un potere computazionale più elevato, grazie al 25% in più di clock rispetto a NV 40. Poi bisogna vedere cosa succederà quando si comincerà a usare lo SM 3.0 che ha alcuni vantaggi prestazionali rispetto al 2.0

[BTinside]

Originariamente inviato da leoneazzurro
Le situazioni di parità si possono avere per altri motivi. Ad esempio quando si è CPU limited. NV 40, poi, nonostante la disparità di clock, a quanto pare riesce nei test sintetici grazie ad una notevole efficienza nell'esecuzione quasi ad eguagliare una X800 XT nell'esecuzione di PS 2.0. Nel caso dei VS invece è indietro a causa del clock. NV 40 riesce a compiere alcune istruzioni in un singolo ciclo di clock, mentre alla concorrenza ne servono due. Per altre succede il contrario. NV 40 soffre per la dipendenza tra TMU e ALU, per cui è sensibile come NV 3x al tipo di input che gli viene presentato. Insomma, dipende tutto da come è programmato il gioco. Tuttavia, in genere, X800 ha un potere computazionale più elevato, grazie al 25% in più di clock rispetto a NV 40. Poi bisogna vedere cosa succederà quando si comincerà a usare lo SM 3.0 che ha alcuni vantaggi prestazionali rispetto al 2.0

Grazie, ho capito;) , comunque in parte volevo dire ciò che hai detto tu, appunto dipende da come viene programmato l'uno o l'altro hardware,
ma quando nel futuro queste diseguaglienze fra architetture si assottigliaranno tanto da diventare pressocchè nulle, cosa spingerà l'utente finale ad acqusitare l'una o l'altra scheda?

[leoneazzurro]

Le altre cose che sono importanti, ossia prezzo, features, consumi, drivers e perche no? Le preferenze personali ;)

[BTinside]

OT su Doom3

Ho scaricato delle mappe multiplayer per Doom3 , più ci gioco più questo motore grafico non mi piace.
Giustamente creando delle mappe multiplayer da detahmatch fatte da "amatori" e che quindi si tenta di sfruttare il motore grafico in maniera leggermente diversa dallo scopo per il quale è stato pensato, ossia ambienti chiusi singlplayer, ci si accorge di quanto piccoli siano gli spazi che è in grado di gestire, oserei dire claustrofobici.
Tutte le mappe che ho provato sono addirittura più piccole di quelle del vecchio Quake 3.
Il fatto che questo gioco vada meglio su 6800 non mi da nessuna gratificazione sul fatto che le Ati vadano meglio in half life 2

[leoneazzurro]

Credo sia più che altro una questione di gusti, anche se è da apprezzare a mio parere il sistema di illuminazione dinamico.
QUELLA è la vera "chicca" di Doom3, poi IMHO solo il futuro potrà dirci cosa ne verrà tirato fuori.

[BTinside]

Originariamente inviato da leoneazzurro
Credo sia più che altro una questione di gusti, anche se è da apprezzare a mio parere il sistema di illuminazione dinamico.
QUELLA è la vera "chicca" di Doom3, poi IMHO solo il futuro potrà dirci cosa ne verrà tirato fuori.

L'apparato d'illuminazione è l'unica cosa che mi piace del gioco, per il resto.......
Chissà se avrà la flessibilità del motore di Qauke 3 (vedi Call Of Duty United Offensive)

[fek]

Originariamente inviato da BTinside
Si dopo aver letto le preziosissime lezioni (tanto che potrebbero farle a pagamento) di Yoss, Raffaele e il programmatore Fek (che non mi risponde ancora su BC) questo è il mio parere.

Forse perche' non posso? ;)

[BTinside]

Originariamente inviato da fek
Forse perche' non posso? ;)

Ecco almeno già è una risposta. Vabè se non puoi non insisto, peccato però sembrava un gioco carino;)

[rmarango]

Ho riaperto il thread per una patch che abilita i riflessi acquatici direttamente in Dx8/8.1, con un basso performance hit.
Basta installare una semplice patch disponibile qui :

http://www.steampowered.com/forums/showthread.php?threadid=197418

La patch c'e' anche per CS.

La modifica l'ho gia' provata ed e' davvero notevole.
;)

p.s. vale dalla geforce 4 ti in su...

[Gatz1980]

Originariamente inviato da rmarango
Ho riaperto il thread per una patch che abilita i riflessi acquatici direttamente in Dx8/8.1, con un basso performance hit.
Basta installare una semplice patch disponibile qui :

http://www.steampowered.com/forums/showthread.php?threadid=197418

La patch c'e' anche per CS.

La modifica l'ho gia' provata ed e' davvero notevole.
;)

p.s. vale dalla geforce 4 ti in su...

Mitico, funzia! :yeah:

Non per fare polemica... ma è così che si convince la gente a passare alle schede DX9, togliendo effetti grafici di proposito? :rolleyes:

[andreamarra]

Originariamente inviato da Gatz1980
Mitico, funzia! :yeah:

Non per fare polemica... ma è così che si convince la gente a passare alle schede DX9, togliendo effetti grafici di proposito? :rolleyes:

Di per sè, si.

Ad esempio: I giochi pompati non li fanno solo per far vedere "come siamo bravi", ma per stressare talmente tanto il pc che per poter gioire di tanta grafica occorre comprare e comprare. Guarda quanti hanno messo il banco di ram per FC, o chi ha comprato una scheda video nuova per D3 o HL2. E sarà sempre così.

E poi: prima o poi qualche nuovo titolo pompato o che gestisce certi effetti deve uscire, per preparare il fondo...

Nella fattispecie la Valve ha un contratto con la Ati. Purtroppo, come è successo tra Nvidia-Carmak si è deciso di sviluppare il gioco in modo da creare discrepanze notevoli tra ati e nvidia.

Quando ci sono i soldi di mezzo...

[Athlon 64 3000+]

Originariamente inviato da andreamarra
Di per sè, si.

Ad esempio: I giochi pompati non li fanno solo per far vedere "come siamo bravi", ma per stressare talmente tanto il pc che per poter gioire di tanta grafica occorre comprare e comprare. Guarda quanti hanno messo il banco di ram per FC, o chi ha comprato una scheda video nuova per D3 o HL2. E sarà sempre così.

E poi: prima o poi qualche nuovo titolo pompato o che gestisce certi effetti deve uscire, per preparare il fondo...

Nella fattispecie la Valve ha un contratto con la Ati. Purtroppo, come è successo tra Nvidia-Carmak si è deciso di sviluppare il gioco in modo da creare discrepanze notevoli tra ati e nvidia.

Quando ci sono i soldi di mezzo...

D'accordo.

[BTinside]

Originariamente inviato da andreamarra
Di per sè, si.

Ad esempio: I giochi pompati non li fanno solo per far vedere "come siamo bravi", ma per stressare talmente tanto il pc che per poter gioire di tanta grafica occorre comprare e comprare. Guarda quanti hanno messo il banco di ram per FC, o chi ha comprato una scheda video nuova per D3 o HL2. E sarà sempre così.

E poi: prima o poi qualche nuovo titolo pompato o che gestisce certi effetti deve uscire, per preparare il fondo...

Nella fattispecie la Valve ha un contratto con la Ati. Purtroppo, come è successo tra Nvidia-Carmak si è deciso di sviluppare il gioco in modo da creare discrepanze notevoli tra ati e nvidia.

Quando ci sono i soldi di mezzo...

Per questo io sono per le console, anche se gioco col PC e investo tanti soldi ogni anno in CPU, RAM, MOBO e VGA.

Una console ti costringe ad una spesa pressocchè sostanziosa, ma comunque inferiore al PC, una sola volta e poi per il resto ci campi 7 anni (vedi l'arco di vita di PS2 2000 - 2007).

Motivo percui spendo allora soldi in PC? L'Alta risoluzione e l'anti aliasing
non sopporto giocare nelle TV e a bassa risoluzione, preferisco progressive scan e 1024x768,
si è vero che tutti i giochi Xbox supportano il progressive scan in HDTV ma comunque a risoluzioni non troppo alte e con cali di framerate.

Se PS3 sarà nativamente collegabile ad un monitor PC allora cambierò filosofia:D

Anche se però , quì contraddico andreamarra, spesso ci lamentiamo che i giochi non sfruttano le nostre schede video ,
questo perchè, come ha anche spiegato fek una volta, bisogna adattarsi a programmare su ciò che la maggior parte della gente compra.
Se il 70% dei pc gamers ,che non ne capiscono molto nel campo delle vga ma vogliono comunque giocare, comprano una nuova scheda video solo basandosi sul quantitativo di RAM o sulla DirectX supportata e ovvio che poi i programmatori di giochi, come fek, devono adattarsi , producendo così giochi poveri di poligoni ma ricchi di effetti shader e normal maps e texturone per ben sfruttare quei abbondanti 256mb di memoria video di una vga non molto performante.
Quindi si punta sullo sfruttamento della ram video davvero eccessiva e degli effetti programmabili.
Detto questo credo che Doom3 e HL2 siano due casi veramente a parte, due casi frutto di complotti commerciali fra software houses e produttori di vga, complotti che mirano al pieno sfruttamento e ottimizzazione per l'una e l'altra architettura, fregandosene di chi ha schede video non troppo potenti.

[R@nda]

Il problema è che una console dopo 2/3 anni di vita diventa obsoleta graficamente rispetto al PC.....
E quindi dopo tale periodo abbandono un poco le console (tranne per i titoli che mi interessano davvero) e ricomincio ad aggiornare il PC...oh a me la bella grafica pice:)

[BTinside]

Originariamente inviato da R@nda
Il problema è che una console dopo 2/3 anni di vita diventa obsoleta graficamente rispetto al PC.....
E quindi dopo tale periodo abbandono un poco le console (tranne per i titoli che mi interessano davvero) e ricomincio ad aggiornare il PC...oh a me la bella grafica pice:)

Hai perfettamente ragione, perchè anche io ho fatto così come te, 3 anni di PS2 e poi via con la 9600XT, poi 9800pro e adesso 6800Gt/Ultra,
ma la colpa è solo mia, perchè se tu sei abituato alla grafica che una PS2 può offrirti (GT4 non è niente male per un chip grafico del 2000 ed è una gioia per gli occhi anche dopo Half life2 e soprattutto dopo le textures traballanti di Doom3), senza giocare mai col PC , rimarrai affascinato per tutta la durata di quella console, fin quando non uscirà quella nuova.
Ma siccome ormai sono troppo mal abituato dall'alta risoluzione e da giochi odierni per PC niente male, ritorno a fare una partita con la PS2 solo per dei giochi in particolare (tipo GT3 o GT4) che su PC non ci sono e che hanno una giocabilità che nel PC è ancora pressocchè sconosciuta (a parte l'ottimo Half Life 2).

[p233]

Ho letto solo le prime 10 pagine (perdonatemi ma non ce la faccio a leggere tutte e 28) e non sono riuscito a capire una cosuccia...

Diciamo che per esempio si ha una 5900XT, che parte solo in DX8.1 e in DX9 non visualizza l'acqua e va uno schifo. Noi attiviamo il mixed mode, mettiamo l'FP16 e quindi alla fine li vediamo i riflessi a "specchio" (DX9 completo quindi, giusto?) nell'acqua o/e otteniamo solo prestazioni accettabili? :confused:

[luca87mi2@msn.com]

nooooooooooooo! xchè la 6800 va così lenta??? ma sn attendibili quei grafici???? :confused:

[Wizard77]

Originariamente inviato da luca87mi2@msn.com
nooooooooooooo! xchè la 6800 va così lenta??? ma sn attendibili quei grafici???? :confused:

non è che vada lenta, è solo che questo gioco è stato programmato per girare al meglio sull'architettura ATI. Cmq con le nuove release dei driver dovrebbe essere minore la differenza.

[rmarango]

Originariamente inviato da p233
Ho letto solo le prime 10 pagine (perdonatemi ma non ce la faccio a leggere tutte e 28) e non sono riuscito a capire una cosuccia...

Diciamo che per esempio si ha una 5900XT, che parte solo in DX8.1 e in DX9 non visualizza l'acqua e va uno schifo. Noi attiviamo il mixed mode, mettiamo l'FP16 e quindi alla fine li vediamo i riflessi a "specchio" (DX9 completo quindi, giusto?) nell'acqua o/e otteniamo solo prestazioni accettabili? :confused:

C'e' una patch per i riflessi a specchio acquatici che ho postato qualche messaggio piu' indietro che funziona in dx8.1 senza bisogno di mettere gli Fp16.

Ciao