Nvidia si è impantanata?

[Vash88]

Da quello che sapevo io dava un leggero vantaggio, ma la scheda nei test rimaneva sotto lo stesso.

[Spytek]

Originariamente inviato da fek
Lieve svantaggio? Non so proprio da dove possa arrivare.
Prendere il 3d2005 come indice di prestazioni di qualunque cosa e' sbagliato.

Lo stesso shader scritto in 2.0 o 3.0, al limite, va uguale: il set di istruzioni dei ps3.0 e' un superset di quello dei ps2.0.

Sicuramente sono d'accordo con la tua affermazione riguardo al 3d mark 2005 come giudice assoluto di tutto .Nè lui,nè tantomeno le versioni precedenti lo sono stati!
A mio avviso,lo score ottenuto dal 3d mark 2005 non fornisce dati attendibili , ma credo invece che ogni test, preso singolarmente,possa fornire dati attraverso i quali è possibile comparare schede video di tipologia diversa.

[DNA_RNA]

Originariamente inviato da fek
Lieve svantaggio? Non so proprio da dove possa arrivare.
Prendere il 3d2005 come indice di prestazioni di qualunque cosa e' sbagliato.

Lo stesso shader scritto in 2.0 o 3.0, al limite, va uguale: il set di istruzioni dei ps3.0 e' un superset di quello dei ps2.0.

Se non sbaglio il leggero svantaggio dovuto all'uso dei PS 2.0 e 2.0 era dovuto alla disabilitazione forzata del DST.

[yossarian]

Originariamente inviato da fek




Il problema dell'HDR in questa generazione e' un altro e non ha a che vedere con il problema 16/24 bit per componente. Ho ultimamente fatto un po' di esperimenti con l'HDR e gli shader che ho scritto sono tutti a 16 bit per componente, a parte alcune istruzioni che hanno a che fare con la distanza del pixel dall'osservatore che ha bisogno di almeno 24 bit.

Il problema risiede nel blending in floating point, che e' al momento supportato solo dall'NV40. Per cercare di semplificare il discorso, tutte le gpu a parte di NV40 non sono in grado di eseguire la seguente operazione "aggiungi il contributo di questa luce al colore di un pixel" se il risultato dell'operazione e' un buffer in HDR dove i valori non sono strettamente da 0 a 1, ma sono in floating point, quindi possono variare da -valore_molto_grande a +valore_molto_grande.
Simulare questa operazione sulle GPU che non sono in grado di svolgerla esplicitamente e' possibile ma porta a rallentamenti inaccettabili in una tecnica che gia' di per se' e' lenta. Per questo, immagino, la Valve ha abbandonato l'idea, giustamente a mio avviso. Il mio prototipo, ad esempio, gira solo su NV40.

Infatti, è quello che intendevo quando ho detto che R3x0 e R420 hanno un supporto solo parziale il che costringe alla modalità "emulazione" (solo che tu sei stato più tecnico, trattandosi del tuo campo). In effetti Valve aveva fatto qualche tentativo ma, in seguito al fatto che su NV3x non andava proprio e che su R3x0 andava al rallentatore, ha giustamente abbandonato l'idea.

[yossarian]

[quote]Originariamente inviato da GMCPape


HDR probabilmente su NV3X sarebbe stato lento, ma credo che usato intelligentemente sarebbe stato implementabile in molti engine, almeno attraverso un intelligente uso di FP16 e FP32. Ovviamente, essendo la generazione precedente dettata da ATI, i programmatori non hanno sentito la necessità di inserirlo a tutti i costi. Ma credo che sarà una feature fondamentale, d'ora in poi.


[quote]

HDR su NV3x non girava proprio e su R3x0 andava al rallentatore. I motivi li ha illustrati in precedenza fek

Originariamente inviato da GMCPape

Esatto, ma chiediamoci perché gli shader sono corti. L'architettura nVidia, sebbene meno efficiente, avrebbe permesso l'uso di shader lunghi e di HDR, ma non essendo supportati da ATI, sarebbe stato un suicidio puntare su queste feature. Insomma.. ATI (un plauso a lei) si è imposta, e questo ha creato anche dei problemi alle feature positive dell'architettura nVidia, che non ha potuto esprimere al meglio il proprio potenziale.

al di là delle chiacchiere da salotto dei pr, resta il fatto che nVIDIA è dovuta ricorrere, per la serie NV3x, ad un "compilatore" che spezzettava istruzioni troppo lunghe in altre più brevi, riordinandole a piccoli gruppi (e in presenza di shader 2.0, spesso faceva shader replacement); certo, sulla carta, NV30 è stato presentato come un chip in grado di macinare shader molto lunghi, di lavorare con più quad in contemporanea, di utilizzare la decantata (proprio da Epic) modalità fp32; in pratica si è mostrato incapace di fare tutto ciò per limiti architetturali (non certo per colpa di ATi) e tutto l'anno scorso nVIDIA è dovuta ricorrere a continui sotterfugi, truccando i drivers, per mantenere i suoi chip competitivi. Per fortuna NV40 è di tutt'altra pasta

Originariamente inviato da GMCPape



Si, ma non è certo all'altezza di quello, ormai standard, di MS. Anche perché OGL ormai è principalmente dedito alla grafica professionale, che ha ben altre esigenze rispetto a quella per i gamer.

il GLSL è stato definito da parecchio (da prima dell'uscita di NV30), insieme a molte delle specifiche OGL2.0; se non si è ancora adottata questa versione delle API e si è dovuti ricorrere alle 1.5 solo per introdurre l'uso di un liguaggio ad alto livello (opzionale) e poco altro, è stato solo perchè non ci si è ancora messi d'accordo su altre estensioni da introdurre o meno. Quindi, non lo definirei poi così acerbo.

Originariamente inviato da GMCPape



Sinceramente non so se abbia ragione JC o lo scetticismo degli altri programmatori. Sono però certo che, per come è strutturato D3, un elevato numero di poligoni non avrebbe migliorato notevolmente l'impatto visivo, consideando che il design di livelli e mostri è basato su altro. Calcola che le ombre di D3 sono viste come veri e propri poligoni, del resto, e forse JC non ha tutti i torti a dire che l'utilizzo di HOS avrebbe interferito (per qualità o prestazioni) sui fragment del programma.

Carmack ha parlato di calo notevole di prestazioni a causa di superlavoro dei vs. La cosa strana è che ad effettuare la maggior mole di lavoro sono, nella stragrande maggioranza dei casi, i ps (la cui capacità di calcolo determina il limite effettivo delle prestazioni di un chip). In ogni caso i dubbi restano.

Originariamente inviato da GMCPape


Ero presente a quell'Editor's Day, in cui Rein "accusava" ATI. In realtà, non ha parlato di cheat (nonostante qualche giornalista troppo zelante e propenso alla polemica abbia riportato ciò), bensì di problemi di visualizzazione su schede ATI. E tale discorso era inserito nel contesto del TWIMTBP, dove Mark indicava che non si trattava di prestazioni, quanto di una resa grafica identica a quella prevista dagli sviluppatori.


Pape

Rein non è stato chiaro e le sue parole sono state equivocate da più di qualcuno; i difetti di visualizzazione dipendevano dall'utilizzo da parte di Epic di un valore di LoD positivo, per incrementare le prestazioni (il vantaggio calcolato è stato, forzando il LoD a 0, di un 1% circa peer ATi, con difetti nella visualizzazione di alcune aree e di circa il 4% per nVIDIA, senza artefatti). Il punto è che, avendo ATi utilizzato un circuito semplificato per il LoD (cosa che ha fatto anche per l'anisotropic), con conseguente uso di un numero inferiore di bit (5, ossia il valore minimo previsto per questa applicazione), si è trovata spiazzata quando Epic è ricorsa ad un valore positivo. L'esempio, però, l'ho portato solo perchè testimone di una scelta di Epic fatta conoscendo le caratteristiche dell'NV3x e basandosi su di esse; quindi, la collaborazione tra Epic e nVIDIA non è relativa al solo sviluppo di un'architettura SM3.0 ma è un bel po' più datata.

[yossarian]

Originariamente inviato da R@nda
X yossarian

Ma scrivevi sul forum di PS2.it ai tempi della sua uscita ?(post sempre molto tecnici ed esaustivi).
Non ricordo il nome dell'utente..ma avete lo stesso stile.

no, non ero io però mi piacerebbe leggere qualcosa di quello che ha scritto.

[yossarian]

Originariamente inviato da TripleX
inoltre pare incredibile ma gia' oggi un gioco dx9 metterebbe in ginocchio qualsiasi gpu "state of the art" inutile andare oltre se manca potenza di calcolo....

in effetti le cose stanno proprio così e non è un caso che si inizi a pensare a soluzioni multichip o con più vga in parallelo; questo in attesa delle nuove architetture che dovrebbero fornire il boost prestazionale necessario e la flessibilità richiesta dai programmatori.

[Alberto Falchi]

Originariamente inviato da yossarian
al di là delle chiacchiere da salotto dei pr, resta il fatto che nVIDIA è dovuta ricorrere, per la serie NV3x, ad un "compilatore" che spezzettava istruzioni troppo lunghe in altre più brevi, riordinandole a piccoli gruppi (e in presenza di shader 2.0, spesso faceva shader replacement); certo, sulla carta, NV30 è stato presentato come un chip in grado di macinare shader molto lunghi, di lavorare con più quad in contemporanea, di utilizzare la decantata (proprio da Epic) modalità fp32; in pratica si è mostrato incapace di fare tutto ciò per limiti architetturali (non certo per colpa di ATi) e tutto l'anno scorso nVIDIA è dovuta ricorrere a continui sotterfugi, truccando i drivers, per mantenere i suoi chip competitivi. Per fortuna NV40 è di tutt'altra pasta

NOn è corretto. Il compilatore di nVidia non spezzettava in istruzioni più corte, bensì riordinava i dati in maniera più digeribile dall'architettura di NV3X. Che in certi casi venissero fatti shader replacemente, è un discorso diverso, e a me frega poco, sino a che la qualità dell'immagine non viene toccata. Anche ATI lo fa, del resto, e nessuno se ne può accorgere, se appunto il rendering rimane identico. La modalità FP32, insieme a FP16, a detta di programmatori non era poi così lenta, ma necessitava di un lavoro di ottimizzazione che i programmatori non sempre facevano. E li posso comprendere: perché impazzire per ottimizzare un'architettura quando era più semplice utilizzare altri metodi, per quanto limitanti sotto il profilo o qualitativo o prestazionale? La "colpa" è di ATI nel senso che la sua architettura gestiva molto meglio il codice standard, senza necessitare di ottimizzazioni particolari, e quindi era molto più apprezzata da chi doveva scrivere codice.

il GLSL è stato definito da parecchio (da prima dell'uscita di NV30), insieme a molte delle specifiche OGL2.0; se non si è ancora adottata questa versione delle API e si è dovuti ricorrere alle 1.5 solo per introdurre l'uso di un liguaggio ad alto livello (opzionale) e poco altro, è stato solo perchè non ci si è ancora messi d'accordo su altre estensioni da introdurre o meno. Quindi, non lo definirei poi così acerbo.

Acerbo in relazione a quello di MS, che è lo standard.

Carmack ha parlato di calo notevole di prestazioni a causa di superlavoro dei vs. La cosa strana è che ad effettuare la maggior mole di lavoro sono, nella stragrande maggioranza dei casi, i ps (la cui capacità di calcolo determina il limite effettivo delle prestazioni di un chip). In ogni caso i dubbi restano.

Dipende tutto da come programmi e da cosa devi fare. I PS sono un limite ora, ma principalmente perché non vengono spinte a pieno le unità di VS. Probabilmente, Carmack ne ha fatto invece un pesante utilizzo nel suo engine. Per lo meno stando a quanto dice ^_^

Rein non è stato chiaro e le sue parole sono state equivocate da più di qualcuno; i difetti di visualizzazione dipendevano dall'utilizzo da parte di Epic di un valore di LoD positivo, per incrementare le prestazioni (il vantaggio calcolato è stato, forzando il LoD a 0, di un 1% circa peer ATi, con difetti nella visualizzazione di alcune aree e di circa il 4% per nVIDIA, senza artefatti). Il punto è che, avendo ATi utilizzato un circuito semplificato per il LoD (cosa che ha fatto anche per l'anisotropic), con conseguente uso di un numero inferiore di bit (5, ossia il valore minimo previsto per questa applicazione), si è trovata spiazzata quando Epic è ricorsa ad un valore positivo.

OK, questa è la motivazione. Ma, per l'appunto, non si parlava di cheat o che, quanto di rendering non corretto con ATI. E, come ti ho detto, era un esempio per far capire il significato del logo TWIMBP: il rendering. Le motivazioni poi lasciano il tempo che trovano: che sia colpa di ATI o di Epic, è innegabile che il risultato sia diverso da qiello del reference rasterizer.

L'esempio, però, l'ho portato solo perchè testimone di una scelta di Epic fatta conoscendo le caratteristiche dell'NV3x e basandosi su di esse; quindi, la collaborazione tra Epic e nVIDIA non è relativa al solo sviluppo di un'architettura SM3.0 ma è un bel po' più datata.

Ancora non hai capito cosa voglio dire. Si, diciamo che Epic si è basata su NV3X, e si sta basando su NV50 per U3 Engine, ma si basa su quello perché sono le feature che Sweeney ritiene fondamentali, e la collaborazione con i produttori di GPU serve proprio a far sì che i chip soddisfino queste necessità. ATI, da ultima arrivata sul mercato del 3D (e lo fa con stile, non è certo una critica), si limita a realizzare architetture efficienti e aderenti allo standard. Ma le manca la capacità di innovare, anche a causa del fatto che fino a ora non ha mai avuto un rapporto di collaborazione con i developer come invece tende a fare nVidia. Del resto, alle presetnazioni di ATI ho visto sempre e solo Valve, al contrario di nVidia che porta sviluppatori di ogni software house. è normale: nVidia ha vari individui provenienti da 3dfx fra le sue fila, e ha un'esperienza nel 3D sicuramente più "antica". Ati sembra che ora si stia smuovendo anche sotto questo profilo. Sarà che ha capito che non basta milgiorare, ma è anche necessario innovare per non rischiare di trovarsi indietro?

Pape

[Alberto Falchi]

Originariamente inviato da yossarian
in effetti le cose stanno proprio così e non è un caso che si inizi a pensare a soluzioni multichip o con più vga in parallelo; questo in attesa delle nuove architetture che dovrebbero fornire il boost prestazionale necessario e la flessibilità richiesta dai programmatori.

Mettere in ginocchio si, ma dipende da cosa si intende per "full DX9". Se si intende un lavoro come Far Cry siamo d'accordo. Ma FC è il miglio esempio di incapacità di design. Tanti effetti buttati a muzzo ovunque, senza un minimo di studio o di ricerca su come e dove utilizzarli. Se invece gli effetti venissero utilizzati solo dove serve, in maniera intelligente, tutte el feature di DX9 sarebbero accessibili senza problemi alle schede attuali. O hai bisogno di mettere PS 2.0 su ogni superfice? Io sono convinto che chi realizza giochi per PC dovrebbe imparare dalle console: non tanto per la qualità del codice, quanto per le scelte stilistiche e la taratura del frame rate perfetta che vedo sulle "piccole" macchine da gioco. Perché sono rari i giochi PC dove il frame rate è costante? Perché le aree di FC non sono state studiate in maniera da non appesantirle con PS 2.0 su ogni sasso?

Pape

[yossarian]

Originariamente inviato da GMCPape
NOn è corretto. Il compilatore di nVidia non spezzettava in istruzioni più corte, bensì riordinava i dati in maniera più digeribile dall'architettura di NV3X. Che in certi casi venissero fatti shader replacemente, è un discorso diverso, e a me frega poco, sino a che la qualità dell'immagine non viene toccata. Anche ATI lo fa, del resto, e nessuno se ne può accorgere, se appunto il rendering rimane identico. La modalità FP32, insieme a FP16, a detta di programmatori non era poi così lenta, ma necessitava di un lavoro di ottimizzazione che i programmatori non sempre facevano. E li posso comprendere: perché impazzire per ottimizzare un'architettura quando era più semplice utilizzare altri metodi, per quanto limitanti sotto il profilo o qualitativo o prestazionale? La "colpa" è di ATI nel senso che la sua architettura gestiva molto meglio il codice standard, senza necessitare di ottimizzazioni particolari, e quindi era molto più apprezzata da chi doveva scrivere codice.

per rendere i dati più digeribili all'architettura dell'NV3x ci sono solo due sistemi: minimizzare il numero di registri coinvolti nei calcoli e utilizzare il più possibile shader 1.x; queste due cose non fanno il paio con shader più lunghi o con il semplice riordino degli shader. La modalità fp32 insieme a fp16 non è lenta su NV3x? Strano che siano stati così tanti a darsi da fare per ottimizzare codice per le FX (Carmack e la stessa Valve che per HL2 ha previsto e consigliato di far girare NV30 con codice DX8) e nessuno è riuscito a far rendere questa modalità mista; in fondo non sarebbe stato così difficile, sarebbe bastato programmare tutto in fp16 (visto che fp32 è praticamente inutilizzata) per rendere le cose molto semplici; tanto, comunque, ATi avrebbe continuato a lavorare in fp24 a livello di pipeline salvo poi fare downscaling per passare a fp16. Eppure non l'ha fatto nessuno o, quanto meno, nessuno è riuscito a far andare le fx al livello della concorrenza, neppure in fp16.
L'operazione di shader replacement, quando fatta per alterare i risultati di un bench che dovrebbe servire a decretare la "presunta" bontà di un prodotto, che alteri o meno la qualità di immagine, dalle mie parti si chiama truffa. Diverso il discorso nel caso in cui si effettua e si dice:"ok, ho guadagnato 20 fps, però sto facendo shader replacement".

Originariamente inviato da GMCPape


Dipende tutto da come programmi e da cosa devi fare. I PS sono un limite ora, ma principalmente perché non vengono spinte a pieno le unità di VS. Probabilmente, Carmack ne ha fatto invece un pesante utilizzo nel suo engine. Per lo meno stando a quanto dice ^_^

spingere a pieno le unità vs significa aumentare il lavoro anche delle unità ps; nella precedente generazione, il rapporto tra ps e vs era, per ATi, di 2:1 e per nVIDIA di 4:3; adesso si è passati, per entrambe, a 3:8 e, nonnostante tutto, il freno è rappresentato sempre dalle psu.

Originariamente inviato da GMCPape


OK, questa è la motivazione. Ma, per l'appunto, non si parlava di cheat o che, quanto di rendering non corretto con ATI. E, come ti ho detto, era un esempio per far capire il significato del logo TWIMBP: il rendering. Le motivazioni poi lasciano il tempo che trovano: che sia colpa di ATI o di Epic, è innegabile che il risultato sia diverso da qiello del reference rasterizer.

purchè ci si limiti a situazioni come questa, non ci sono problemi, anche perchè la cosa è facilemte risolvibile (in questo caso forzando un diverso valore del LoD); purchè non si vada oltre a scapito di quelli che non scelgono questa o quella casa.

Originariamente inviato da GMCPape


Ancora non hai capito cosa voglio dire. Si, diciamo che Epic si è basata su NV3X, e si sta basando su NV50 per U3 Engine, ma si basa su quello perché sono le feature che Sweeney ritiene fondamentali, e la collaborazione con i produttori di GPU serve proprio a far sì che i chip soddisfino queste necessità. ATI, da ultima arrivata sul mercato del 3D (e lo fa con stile, non è certo una critica), si limita a realizzare architetture efficienti e aderenti allo standard. Ma le manca la capacità di innovare, anche a causa del fatto che fino a ora non ha mai avuto un rapporto di collaborazione con i developer come invece tende a fare nVidia. Del resto, alle presetnazioni di ATI ho visto sempre e solo Valve, al contrario di nVidia che porta sviluppatori di ogni software house. è normale: nVidia ha vari individui provenienti da 3dfx fra le sue fila, e ha un'esperienza nel 3D sicuramente più "antica". Ati sembra che ora si stia smuovendo anche sotto questo profilo. Sarà che ha capito che non basta milgiorare, ma è anche necessario innovare per non rischiare di trovarsi indietro?

Pape

ingegneri 3dfx lavorano anche da ATi che, oltretutto, collabora con SGI in maniera più stretta di quanto non faccia NV. In quanto a innovazioni, si potrebbe affermarem senza tema di smentita che l'R100 era di gran lunga più innovativo dell'NV15, così come l'R200 lo è stato rispetto all'NV20; si potrebbe anche dire che quella dell'R300 è stata l'architettura di riferimento per questa generazione di chip grafici.
Sei così sicuro che il motivo del mancato supporto risieda nel fatto che ATi non ha mai innovato?

[yossarian]

Originariamente inviato da GMCPape
Mettere in ginocchio si, ma dipende da cosa si intende per "full DX9". Se si intende un lavoro come Far Cry siamo d'accordo. Ma FC è il miglio esempio di incapacità di design. Tanti effetti buttati a muzzo ovunque, senza un minimo di studio o di ricerca su come e dove utilizzarli. Se invece gli effetti venissero utilizzati solo dove serve, in maniera intelligente, tutte el feature di DX9 sarebbero accessibili senza problemi alle schede attuali. O hai bisogno di mettere PS 2.0 su ogni superfice? Io sono convinto che chi realizza giochi per PC dovrebbe imparare dalle console: non tanto per la qualità del codice, quanto per le scelte stilistiche e la taratura del frame rate perfetta che vedo sulle "piccole" macchine da gioco. Perché sono rari i giochi PC dove il frame rate è costante? Perché le aree di FC non sono state studiate in maniera da non appesantirle con PS 2.0 su ogni sasso?

Pape

ad esempio le specifiche dx9 prevedono anche l'applicazione di 16 texel per pixel per pass; al di là dell'utilità di una tale feature, allo stato attuale, a che frame rate pensi che lavorerebbero R420 o NV40 in una situazione del genere? (questo senza contare HDR e quant'altro). Sulle consolle è più facile lavorare: si ha un'architettura di riferimento e si sa che per 3 o 4 anni rimarrà la stessa; per il pc le cose stanno in modo molto diverso: architetture differenti, evoluzione molto più rapida e motori grafici che diventano presto obsoleti

[Alberto Falchi]

Originariamente inviato da yossarian
per rendere i dati più digeribili all'architettura dell'NV3x ci sono solo due sistemi: minimizzare il numero di registri coinvolti nei calcoli e utilizzare il più possibile shader 1.x; queste due cose non fanno il paio con shader più lunghi o con il semplice riordino degli shader.

E chi ha parlato di riordino shader? Io parlavo del riordino delle istruzioni. La struttura 4x2 di NV30 (contro gli 8x1 di R300) era particolarmente sensibile all'ordine in cui arrivavano le istruzioni (e non gli shader), perché in molti casi si lasciava sprecato del potenziale mentre le unità erano inoperanti, in attesa di istruzioni.

La modalità fp32 insieme a fp16 non è lenta su NV3x? Strano che siano stati così tanti a darsi da fare per ottimizzare codice per le FX (Carmack e la stessa Valve che per HL2 ha previsto e consigliato di far girare NV30 con codice DX8) e nessuno è riuscito a far rendere questa modalità mista; in fondo non sarebbe stato così difficile, sarebbe bastato programmare tutto in fp16 (visto che fp32 è praticamente inutilizzata) per rendere le cose molto semplici;

La FP è richiesta solo da pochissime istruzioni, non ha senso utilizzarla ovunque. In molti dei casi, la PP è più che adeguata e non crea banding o altri artefatti. Certo, non siamo all'altezza di ATI come risultati, ma un'utilizzo più accorto sicuramente avrebbe aiutato le GPU NV3X. Ovviamente, i programmatori non sono obbligati a sbattersi da morire per far funzionare al meglio un titolo: se rimane giocabile, perché impazzire solo per favorire un titolo nei bench? Puoi dirmi tutto cià che vuoi sui limiti di NV3X, e spesso sarò d'accordo con te, ma i giochi ci giravano bene sopra. Più lenti che con ATI, sicuro, ma che senso aveva impazzire per far salire nVidia nei bench se tanto il titolo era più che giocabile e, tranne in rari casi, la qualità visiva era identica?

tanto, comunque, ATi avrebbe continuato a lavorare in fp24 a livello di pipeline salvo poi fare downscaling per passare a fp16. Eppure non l'ha fatto nessuno o, quanto meno, nessuno è riuscito a far andare le fx al livello della concorrenza, neppure in fp16.

Appunto, ATI andava meglio. MA chi se ne frega di 90 o 70 frame? Sino a che non scatta, a me va bene.

L'operazione di shader replacement, quando fatta per alterare i risultati di un bench che dovrebbe servire a decretare la "presunta" bontà di un prodotto, che alteri o meno la qualità di immagine, dalle mie parti si chiama truffa.

Dipende. Se il bench è un gioco, ottimizzi anche il gioco, almeno teoricamente. E se non cambia la qualità visiva, va più che bene, visto che nessuno viene "derubato" di che. Se lo fai col 3D Mark, fai bene lo stesso (sempre che non cheatti usando stati precalcolati o che): 3D Mark è uno strumento di marketing, punto. Ha senso se saputo correttamente interpretare. Se utilizzi il numerino alla fine... beh.. non significa nulla.

Diverso il discorso nel caso in cui si effettua e si dice:"ok, ho guadagnato 20 fps, però sto facendo shader replacement".

Lo fanno tutti, sia ATI sia nVidia. E non te ne accorgerai mai. Se ti rimane invisibile, che te ne frega?

purchè ci si limiti a situazioni come questa, non ci sono problemi, anche perchè la cosa è facilemte risolvibile (in questo caso forzando un diverso valore del LoD); purchè non si vada oltre a scapito di quelli che non scelgono questa o quella casa.

E perché dovrebbe capitare? Sarebbe un suicido da parte di chi produce giochi non supportare tutti i chipset al meglio. Poi ovvio, ATI farà sempre girare meglio qulche gioco, per altri titoli il primato sarà di nVidia. Dal momento che non esiste un leader incontrastato del mercato, è una situazione ovvia. Ma, per l'appunto, si tratta di piccolezze: quale programmatore non farebbe il massimo pur di ottenere la medesima qualità su tutte le schede più diffuse?

ingegneri 3dfx lavorano anche da ATi che, oltretutto, collabora con SGI in maniera più stretta di quanto non faccia NV.

Non si tratta di ingegneri. Ma di persone che coordinano R&D e sviluppatori di giochi. Chiamali evangelisti, uomini di marketing o che, ma sono queste persone che devono mettere a contatto il mondo degli ingegneri e quello dei developer.

In quanto a innovazioni, si potrebbe affermarem senza tema di smentita che l'R100 era di gran lunga più innovativo dell'NV15, così come l'R200 lo è stato rispetto all'NV20; si potrebbe anche dire che quella dell'R300 è stata l'architettura di riferimento per questa generazione di chip grafici.

COsa hanno apportato a livello di feature? Hanno aggiunto qualcosa? O hanno semplicemente fatto meglio ciò che gli altri già facevano? Se io faccio un xbox con una CPU a 2 Ghz e 1 GB di RAM, ho fatto meglio di MS, ma non ho innovato una cippa.

Sei così sicuro che il motivo del mancato supporto risieda nel fatto che ATi non ha mai innovato?

No, del contrario. Cioé che la carenza di innovazioni di ATI sia dovuta ai suoi scarsi contatti coi developer. Contatti inteso come sedersi a tavolino e cercare di capire cosa succederà fra 6 anni, quali feature serviranno, come implementarle e così via.

Pape

[Alberto Falchi]

Originariamente inviato da yossarian
Sulle consolle è più facile lavorare: si ha un'architettura di riferimento e si sa che per 3 o 4 anni rimarrà la stessa; per il pc le cose stanno in modo molto diverso: architetture differenti, evoluzione molto più rapida e motori grafici che diventano presto obsoleti

E tanta incapacità a livello di desinng, per come la vedo io. Anche sulle console i giochi escono continuamente, rincorrendosi per la palma del migliore. Ma, al ocntrario del PC, i giochi per console sono curati enormemente meglio. Ma anche perché i giocatori su console valutano il gameplay molto più della tecnica, al contrario di quanto accade nel mercato del PC, dove più il gioco stupisce, più è bello. Del resto, questo forum è indicativo: giochi che venhgono criticati perché le texture non sono all'altezza di XXX, perché non vengono usati i PS come YYY. Niente di male in questo, ma un gioco deve divertire. La tecnica è un ottimo spunto di discussione, ma deve rimanere una piccola parte nella valutazione di un gioco.

Pape

[R@nda]

Originariamente inviato da yossarian
no, non ero io però mi piacerebbe leggere qualcosa di quello che ha scritto.

Si,credo ti sarebbe piaciuto,peccato che il forum Ps2.it non esiste più...adesso c'è uno shop ps2 senza nessun forum al suo posto.

Scusate l'OT

[yossarian]

Originariamente inviato da GMCPape
E chi ha parlato di riordino shader? Io parlavo del riordino delle istruzioni. La struttura 4x2 di NV30 (contro gli 8x1 di R300) era particolarmente sensibile all'ordine in cui arrivavano le istruzioni (e non gli shader), perché in molti casi si lasciava sprecato del potenziale mentre le unità erano inoperanti, in attesa di istruzioni.

gli shader sono istruzioni. C'era una leggenda metropolitana che diceva che l'architettura 4x2 lasciva inoperose le seconde tmu; ma era, appunto, una leggenda: bastava valutare il comportamento in multitexturing per rendersi conto che le seconde tmu funzionavano regolarmente. Il problema principale della serie NV3x con i calcoli in floating era l'organizzazione delle fpu e delle tmu. NV30 ha 4 sole fpu, una per pipeline, dipendenti dalle tmu; questo significa che, mediamente, con istruzioni miste (text/fp) 2 pipeline elaboravano operazioni matematiche (in tutto 2) e 2 calcoli sulle texture (al massimo 4); perciò il picco massimo raggiungilbile da NV30 era di 6 operazioni. Altro handicap, i registri temporanei insufficienti che riduce la quantità di variabili che contemporaneamente possono essere messe in gioco; questo, come è facile intendere, fa diminuire il numero di operazioni che si possono svolgere in contemporanea e, quindi, la lunghezza delle istruzioni che è possibile far "digerire" al chip.
Di contro, invece, si avevano 8 unità fx (2 per pipeline), operanti in fx12.
Su NV35 4 unità fx12 sono state sostituite con altrettante unità fp32, però è rimasta la dipendenza tra fpu e tmu e si è aggravato il problema dei registri (una fpu è molto più voluminosa di una fxu e, di conseguenza, lo spazio si è dovuto recuperare altrove).

Originariamente inviato da GMCPape


La FP è richiesta solo da pochissime istruzioni, non ha senso utilizzarla ovunque. In molti dei casi, la PP è più che adeguata e non crea banding o altri artefatti. Certo, non siamo all'altezza di ATI come risultati, ma un'utilizzo più accorto sicuramente avrebbe aiutato le GPU NV3X. Ovviamente, i programmatori non sono obbligati a sbattersi da morire per far funzionare al meglio un titolo: se rimane giocabile, perché impazzire solo per favorire un titolo nei bench? Puoi dirmi tutto cià che vuoi sui limiti di NV3X, e spesso sarò d'accordo con te, ma i giochi ci giravano bene sopra. Più lenti che con ATI, sicuro, ma che senso aveva impazzire per far salire nVidia nei bench se tanto il titolo era più che giocabile e, tranne in rari casi, la qualità visiva era identica?

è quello che ho detto: sarebbe stato molto semplice programmare tutto in fp (utilizzando al massimo 16 bit), andando così incontro alle esigenze delle fx; però o non è stato fatto (non credo che nessuno ci abbia provato) oppure anche l'utilizzo della modalità fp16 non dava la resa sperata.
Certo che con NV3x i titoli passati erano più che giocabili: erano programmati con SM1.x e, nei pochi casi di utilizzo di SM2.0, provvedevano i drivers NV a fare shader replacement. Con i calcoli in virgola fissa, la serie NV3x va tutt'altro che male. L'NV30, parlando dal punto di vista dell'architettura, è un NV25 con in aggiunta una vsu, una fxu e una fpu per pipeline con ovvio aumento del numero di registri (questo volendo riassumere a grandi linee).

Originariamente inviato da GMCPape


Dipende. Se il bench è un gioco, ottimizzi anche il gioco, almeno teoricamente. E se non cambia la qualità visiva, va più che bene, visto che nessuno viene "derubato" di che. Se lo fai col 3D Mark, fai bene lo stesso (sempre che non cheatti usando stati precalcolati o che): 3D Mark è uno strumento di marketing, punto. Ha senso se saputo correttamente interpretare. Se utilizzi il numerino alla fine... beh.. non significa nulla.

se il bench è usato per vendere non è corretto spacciare per buoni risultati fasulli; i ps1.1 sono molto più leggeri dei 2.0 e il frame rate ottenuto è sicuramente più elevato (soprattutto su un chip che ha problemi intrinseci con i 2.0)

Originariamente inviato da GMCPape


Lo fanno tutti, sia ATI sia nVidia. E non te ne accorgerai mai. Se ti rimane invisibile, che te ne frega?

ci sono vari modo per accorgersi se si fa o meno shader replacement; il più semplice è quello di vedere il boost prestazionale di una release di drivers rispetto alla precedente, quando si conosce l'architettura di un chip; un boost eccessivo desta sospetti, si indaga e, puntualmente, si scopre l'inghippo

Originariamente inviato da GMCPape

E perché dovrebbe capitare? Sarebbe un suicido da parte di chi produce giochi non supportare tutti i chipset al meglio. Poi ovvio, ATI farà sempre girare meglio qulche gioco, per altri titoli il primato sarà di nVidia. Dal momento che non esiste un leader incontrastato del mercato, è una situazione ovvia. Ma, per l'appunto, si tratta di piccolezze: quale programmatore non farebbe il massimo pur di ottenere la medesima qualità su tutte le schede più diffuse?

bella domanda: forse quello che riceve qualcosa per far andare un certo prodotto un po' più della concorrenza (senza esagerare, possibilmente)

Originariamente inviato da GMCPape



Non si tratta di ingegneri. Ma di persone che coordinano R&D e sviluppatori di giochi. Chiamali evangelisti, uomini di marketing o che, ma sono queste persone che devono mettere a contatto il mondo degli ingegneri e quello dei developer.

una delle razze peggiori dopo i pr, insomma

Originariamente inviato da GMCPape


COsa hanno apportato a livello di feature? Hanno aggiunto qualcosa? O hanno semplicemente fatto meglio ciò che gli altri già facevano? Se io faccio un xbox con una CPU a 2 Ghz e 1 GB di RAM, ho fatto meglio di MS, ma non ho innovato una cippa.

tanto per citarne qualcuna, le dependent texture read (con l'R200), le n-patches (con l'R200), forme primitive di keyframe interpolation e skeletal animation, seppure realizzate con le fixed function (con l'R100 che aveva 4 istruzioni per le operazioni sui vertici, contro le 2 previste dalle DX7 e implementate sull'NV15).
L'utilizzo di buffer (ormai usati da per tutto) per le operazioni di texturing (Rage128); dell'R300 è inutile parlare, visto che si tratta di un'architettura ancora attuale e competitiva dopo oltre due anni dalla sua uscita.

Originariamente inviato da GMCPape

No, del contrario. Cioé che la carenza di innovazioni di ATI sia dovuta ai suoi scarsi contatti coi developer. Contatti inteso come sedersi a tavolino e cercare di capire cosa succederà fra 6 anni, quali feature serviranno, come implementarle e così via.

Pape

non sono d'accordo con la carenza di innovazioni da parte di ATi

[yossarian]

Originariamente inviato da GMCPape
E tanta incapacità a livello di desinng, per come la vedo io. Anche sulle console i giochi escono continuamente, rincorrendosi per la palma del migliore. Ma, al ocntrario del PC, i giochi per console sono curati enormemente meglio. Ma anche perché i giocatori su console valutano il gameplay molto più della tecnica, al contrario di quanto accade nel mercato del PC, dove più il gioco stupisce, più è bello. Del resto, questo forum è indicativo: giochi che venhgono criticati perché le texture non sono all'altezza di XXX, perché non vengono usati i PS come YYY. Niente di male in questo, ma un gioco deve divertire. La tecnica è un ottimo spunto di discussione, ma deve rimanere una piccola parte nella valutazione di un gioco.

Pape

ti quoto perchè, per quanto riguarda la bellezza di un gioco sono d'accordo con te. Un gioco deve, innanzitutto essere coinvolgente; se, poi, ha anche una bella grafica, è solo un valore aggiunto. Un gioco con una grafica da urlo ma poco interessante lo si guarda per un po' e poi si passa ad altro.

Per quanto riguarda il discorso consolle, è vero che escono giochi in continuazione, però esiste un punto di riferimento saldo, ossia un'architettura unica, ben conosciuta, immutabile per diversi anni. Con i pc si ha un continuo rincorrersi di giochi, ma anche di API, di architetture, ecc. Questo rende tutto più complicato anche per chi deve sviluppare un gioco.

[Alberto Falchi]

Originariamente inviato da yossarian
gli shader sono istruzioni. C'era una leggenda metropolitana che diceva che l'architettura 4x2 lasciva inoperose le seconde tmu; ma era, appunto, una leggenda: bastava valutare il comportamento in multitexturing per rendersi conto che le seconde tmu funzionavano regolarmente. Il problema principale della serie NV3x con i calcoli in floating era l'organizzazione delle fpu e delle tmu. NV30 ha 4 sole fpu, una per pipeline, dipendenti dalle tmu; questo significa che, mediamente, con istruzioni miste (text/fp) 2 pipeline elaboravano operazioni matematiche (in tutto 2) e 2 calcoli sulle texture (al massimo 4); perciò il picco massimo raggiungilbile da NV30 era di 6 operazioni.

Inutilizzate è stato un termine infelice, te ne do atto. MI correggo e specifico "non utilizzate al meglio". Poi sulla questione più tecnica hai ragione, ma non hai specificato una piccola cosa: che nella maggior parte dei casi, per come erano programmati i giochi, il massimo delle 6 operazioni non veniva mai sfruttato. Non ti voglio certo dire che NV3X fosse migliore di R3X0 (anzi, sono d'accordo con te che ATI abbia fatto meglio in quella generazione), ma che il divario esagerato era, per l'appunto, dipendente anche da fattori di mancata ottimizzazione. O, meglio, di un'architettura non digerita al meglio dai programmatori. Questi avrebbero potuto fare indubbiamente meglio, se avessero voluto, ma questioni di tempo e di comodità coi compilatori standard, hanno privilegiato ulteriormente l'architettura di ATI.

E, tornando alla radice del discorso, è stata una differenta scelta architetturale. Che si è rivelata errata da parte di nVidia, sicuramente, ma non priva di fondamento.
nVidia aveva puntato su una maggiore versatilità, e principalmente su shader più complessi e meno precisi. I limiti che evidenzi non tengono conto del fatto che, al cotnrario della concorrenza, nVidia aveva delle unità di shading più versatili, che le permettevano (in teoria) di opn avere limiti sul numero delle istruzioni presenti negli shader, e che già da allora ponevano le basi per il dynamic branching presente poi in SM3. Non ti so dire se tale potenziale sarebbe poi stato esprimibile in relazione alla potenza della GPU, ma è un dato di fatto che R3X0 era "limitata" sotto questo profilo. In ogni caso, i limiti di ATI erano indubbiamente meno pesanti rispetto a quelli di nVidia, ma più che di errori nella progettazione, credo che si tratti di intuizioni sbagliate su come avrebbero sfruttato gli shader i programmatori.

è quello che ho detto: sarebbe stato molto semplice programmare tutto in fp (utilizzando al massimo 16 bit), andando così incontro alle esigenze delle fx; però o non è stato fatto (non credo che nessuno ci abbia provato) oppure anche l'utilizzo della modalità fp16 non dava la resa sperata.

In certi casi la resa di FP16 non basta. Ed è necessario passare alla full precision. In molti engine, però (e nei bench sintetici quali 3D Mark), si è fatto un'uso esagerato di FP, favorendo ATI. Ovviamente non per cattiveria e pigrizia da parte dei deevloper, ma per delle loro scelte. E se posso capire la necessità di utilizzare FP nei bench sintentici per valutare le prestazioni in quell'ambito, non capisco il perché sia stato così usato nei motori di gioco. Guardando i bench utilizzati, uno dove nVidia ha sempre sofferto in grossa misura è stato proprio Far Cry, che a mio personalissimo avviso è uno dei peggiori motori mai visti (oltre che un titolo mediocre, ma questo non ha attinenza col discorso). Di contro, molti dei motori più utilizzati nei giochi, ma non sempre utilizzati come bench, davano ragione a nVidia (sempre per piccoli divari, cmq). MI vengono in mente le tonnellate di giochi basati su Q3, ma soprattutto il motore degli ISI (F1 Challenge), raramente usato per valutare le performance ma molto usati dai giochi di guida (e relativi mod).
Un altro esempio che mi viene in mente di bench favrevole ad ATI ma non rappresentativo di nulla è stato Halo: un massiccio utilizzo, inutile, di PS 2.0, che non aggiungevano nulla alla qualità dei Ps 1.4. Anche lì, a mio avviso, è stata una pessima scelta che ha tarpato enormemente le prestazioni a ogni architettura, senza aggiungere nulla. Fortunatamente, il gioco è una figata, però ^_^.

Certo che con NV3x i titoli passati erano più che giocabili: erano programmati con SM1.x e, nei pochi casi di utilizzo di SM2.0, provvedevano i drivers NV a fare shader replacement. Con i calcoli in virgola fissa, la serie NV3x va tutt'altro che male. L'NV30, parlando dal punto di vista dell'architettura, è un NV25 con in aggiunta una vsu, una fxu e una fpu per pipeline con ovvio aumento del numero di registri (questo volendo riassumere a grandi linee).

Ma su quanti di questi titoli vedevi artefatti di qualsiasi tipo? Alla fine, al giocatore interessa che la resa finale non cambi, e tranne rari casi, i giochi erano visivamente identici.

se il bench è usato per vendere non è corretto spacciare per buoni risultati fasulli; i ps1.1 sono molto più leggeri dei 2.0 e il frame rate ottenuto è sicuramente più elevato (soprattutto su un chip che ha problemi intrinseci con i 2.0)

Se il risultato visivo è identico, cosa interessa cosa fa il driver? Certo, inficia i risultati. Ma non esisterà mai un bench intoccabile, per quanto ne so. E i trucchetti li usano sia ati sia nVidia. La lotta è dura ^_^

ci sono vari modo per accorgersi se si fa o meno shader replacement; il più semplice è quello di vedere il boost prestazionale di una release di drivers rispetto alla precedente, quando si conosce l'architettura di un chip; un boost eccessivo desta sospetti, si indaga e, puntualmente, si scopre l'inghippo

Ribadisco: se non ti accorgi di differenze, cosa cambia?

bella domanda: forse quello che riceve qualcosa per far andare un certo prodotto un po' più della concorrenza (senza esagerare, possibilmente)

Forse, si. Ma a quel punto, indipendentemente dalla bontà dell'architettura, vince chi ha più soldi. Ma voglio sperare che non succeda, sebbene alcuni particolari (Far Cry patch 1.2 così come HL2) mi facciano sorgere dei sospetti. Su entrambe le aziende. Ma, chi perderebbe veramente la faccia in caso salti fuori la cosa, sarebbe lo sviluppatore, più che la casa che lo "corrompe".

una delle razze peggiori dopo i pr, insomma

Non dire così, dai. ho fatto il PR anche io, in passato ;-) non sono così cattivi come sembrano... è chi si fa abbindolare da loro, al massimo, a sbagliare.

tanto per citarne qualcuna, le dependent texture read (con l'R200), le n-patches (con l'R200), forme primitive di keyframe interpolation e skeletal animation, seppure realizzate con le fixed function (con l'R100 che aveva 4 istruzioni per le operazioni sui vertici, contro le 2 previste dalle DX7 e implementate sull'NV15)
L'utilizzo di buffer (ormai usati da per tutto) per le operazioni di texturing (Rage128); dell'R300 è inutile parlare, visto che si tratta di un'architettura ancora attuale e competitiva dopo oltre due anni dalla sua uscita.

Quante di queste sono state sfruttate dagli sviluppatori ai tempi? Certo, Trueform era una figata... ma non basta l'idea.. devi anche saperla vendere. E ATI non ci è mai riuscita. Vedremo che saprà fare con 3Dc.

Pape

[yossarian]

Originariamente inviato da GMCPape
Inutilizzate è stato un termine infelice, te ne do atto. MI correggo e specifico "non utilizzate al meglio". Poi sulla questione più tecnica hai ragione, ma non hai specificato una piccola cosa: che nella maggior parte dei casi, per come erano programmati i giochi, il massimo delle 6 operazioni non veniva mai sfruttato. Non ti voglio certo dire che NV3X fosse migliore di R3X0 (anzi, sono d'accordo con te che ATI abbia fatto meglio in quella generazione), ma che il divario esagerato era, per l'appunto, dipendente anche da fattori di mancata ottimizzazione. O, meglio, di un'architettura non digerita al meglio dai programmatori. Questi avrebbero potuto fare indubbiamente meglio, se avessero voluto, ma questioni di tempo e di comodità coi compilatori standard, hanno privilegiato ulteriormente l'architettura di ATI.

non è che non erano utilizzate le 6 operazioni, ma è che era preferibile avere un input "spezzettato" del tipo math*4 e text*8, cercando di privilegiare queste ultime (come ha fatto Carmack in Doom); lavorando il più possibile con le textue, si può arrivare a 8 operazioni per ciclo. Questo, ovviamente, se i calcoli sono in fp; se sono in fx, invece, con un input del tipo math/text/text per pipeline si arriva a 12 operazioni per ciclo (esattamente quante quelle dell'R300); questo è esattamente quello che fa il compilatore/ottimizzatore introdotto da nVIDIA dai 52.16 in poi.

Comunque, c'è qualcosa che non mi torna nella sua arringa, avvocato ; da un lato mi dice che ATi collabora poco con gli sviluppatori e, di conseguenza, questi fanno riferimento più ai chip nVIDIA per sviluppare i loro titoli, poichè sono quelli che vanno più incontro alle loro esigenza; dall'altro afferma che la serie NV3x (quella che nVIDIA aveva definito come la più rivoluzionaria), sarebbe stata boicottata dalle SWHouse che avrebbero preferito attenersi alle specifiche standard, meglio interpretate da ATi (cosa vera questa)

Originariamente inviato da GMCPape

E, tornando alla radice del discorso, è stata una differenta scelta architetturale. Che si è rivelata errata da parte di nVidia, sicuramente, ma non priva di fondamento.
nVidia aveva puntato su una maggiore versatilità, e principalmente su shader più complessi e meno precisi. I limiti che evidenzi non tengono conto del fatto che, al cotnrario della concorrenza, nVidia aveva delle unità di shading più versatili, che le permettevano (in teoria) di opn avere limiti sul numero delle istruzioni presenti negli shader, e che già da allora ponevano le basi per il dynamic branching presente poi in SM3. Non ti so dire se tale potenziale sarebbe poi stato esprimibile in relazione alla potenza della GPU, ma è un dato di fatto che R3X0 era "limitata" sotto questo profilo. In ogni caso, i limiti di ATI erano indubbiamente meno pesanti rispetto a quelli di nVidia, ma più che di errori nella progettazione, credo che si tratti di intuizioni sbagliate su come avrebbero sfruttato gli shader i programmatori.

hai detto bene: "in teoria"; una raccomandazione che faceva spesso nVIDIA ai programmatori era quella di adoperare il meno possibile i registri temporanei dei ps; ora, proclamare di poter eseguire un numero teoricamente infinito di operazioni quando si sa che il numero di operazioni possibili e direttamente proporzionali al numero di variabili temporanee che si possono mettere in gioco; ora, anche disponendo di una pipeline più lunga (molto probabilmente di tipo recirculating) che richiede un numero di variabili un po' inferiori allo standard, i calcoli erano ugualmente sbagliati. Per quanto riguarda il dynamic branching, per i ps non c'è potenza di calcolo sufficiente neppure con questa generazione di gpu (e inoltre si pongono altri problemi che diventa troppo lungo elencare ed esaminare in dettaglio); diverso il discorso per i vs per cui la cosa, adesso, sarebbe fattibile.
NV3x è nato da idee concettualmente vecchie: non serviva l'architettura nx2 che è un retaggio del periodo in cui ops per clock e per pass coincidevano (si sarebbe potuta già abbandonare con NV20 e, d'altronde, il Kyro poteva applicare fino ad 8 texture per pass con un'architettura 2x1 e il Rage 128 poteva applicare 2 texel su uno stesso pixel o un texel su due diversi pixel, sempre per pass, con un'architettura 1x1); l'utilizzo di 2 fxu per pipeline e dell'architettura interna a 256 bit (con bus a 128 bit per bilanciare il passaggio dei dati da esterno ad interno e viceversa erano un'eredità dell'NV25); non si tratta di errate valutazioni sull'impiego degli shader, ma di un'impostazione orientata verso le DX8.x piuttosto che verso le DX9 (che può anche essere condivisibile, visto che ancora sono le API più usate).

Originariamente inviato da GMCPape


In certi casi la resa di FP16 non basta. Ed è necessario passare alla full precision. In molti engine, però (e nei bench sintetici quali 3D Mark), si è fatto un'uso esagerato di FP, favorendo ATI. Ovviamente non per cattiveria e pigrizia da parte dei deevloper, ma per delle loro scelte. E se posso capire la necessità di utilizzare FP nei bench sintentici per valutare le prestazioni in quell'ambito, non capisco il perché sia stato così usato nei motori di gioco. Guardando i bench utilizzati, uno dove nVidia ha sempre sofferto in grossa misura è stato proprio Far Cry, che a mio personalissimo avviso è uno dei peggiori motori mai visti (oltre che un titolo mediocre, ma questo non ha attinenza col discorso). Di contro, molti dei motori più utilizzati nei giochi, ma non sempre utilizzati come bench, davano ragione a nVidia (sempre per piccoli divari, cmq). MI vengono in mente le tonnellate di giochi basati su Q3, ma soprattutto il motore degli ISI (F1 Challenge), raramente usato per valutare le performance ma molto usati dai giochi di guida (e relativi mod).
Un altro esempio che mi viene in mente di bench favrevole ad ATI ma non rappresentativo di nulla è stato Halo: un massiccio utilizzo, inutile, di PS 2.0, che non aggiungevano nulla alla qualità dei Ps 1.4. Anche lì, a mio avviso, è stata una pessima scelta che ha tarpato enormemente le prestazioni a ogni architettura, senza aggiungere nulla. Fortunatamente, il gioco è una figata, però ^_^.

il 3DMark2003 faceva uso, si e no, di tre istruzioni SM2.0, Aquamark arrivava forse a 4; non ho i dettagli di Halo e di FC (ma che ti ha fatto? ); sicuramente sulla qualità e la quantità di effetti dello SM2.0 implementati in questi giochi fek può esere più preciso ed esaustivo di me. Gli altri esempi che hai fatto sono di titoli che, al massimo, utilizzano qualche feature DX8.x. Le mie critiche alle FX non sono da intendere in senso assoluto, ma solo relativamente alla gestione dei PS2.0 e successivi; con i PS1.x si difendono piuttosto bene (anche se, non dimentichiamo che con i PS1.x le FX lavorano a fx12 e le Radeon a fx16).

Originariamente inviato da GMCPape


Ma su quanti di questi titoli vedevi artefatti di qualsiasi tipo? Alla fine, al giocatore interessa che la resa finale non cambi, e tranne rari casi, i giochi erano visivamente identici.

anche i risultati dei ps3.0 possono essere ottenuti utilizzando i 2.0 e, tranne qualche rara feature, anche i ps1.x; l'evoluzione nel linguaggio di programmazione c'è stata anche per andare incontro alle esigenze di chi programma e per facilitargli il lavoro.

Originariamente inviato da GMCPape

Se il risultato visivo è identico, cosa interessa cosa fa il driver? Certo, inficia i risultati. Ma non esisterà mai un bench intoccabile, per quanto ne so. E i trucchetti li usano sia ati sia nVidia. La lotta è dura ^_^

se il risultato mi serve per dimostrare che il mio prodotto è più veloce di quello della concorrenza e, di conseguenza, per vendere di più, allora sto barando: è una questione di etica e la mia filosofia non è quella del "principe" di Machiavelli; siccome i bench non sono fatti per essere fini a sé stessi..................
Bench non truccabili ci sono; ad esempio lo shadermark non permette l'utilizzo di clipping planes ed è dotato di sofisticati strumenti di antidetect (ed è stato uno degli strumenti che ha evidenziato le difficoltà delle FX con i calcoli in fp).

Originariamente inviato da GMCPape


Forse, si. Ma a quel punto, indipendentemente dalla bontà dell'architettura, vince chi ha più soldi. Ma voglio sperare che non succeda, sebbene alcuni particolari (Far Cry patch 1.2 così come HL2) mi facciano sorgere dei sospetti. Su entrambe le aziende. Ma, chi perderebbe veramente la faccia in caso salti fuori la cosa, sarebbe lo sviluppatore, più che la casa che lo "corrompe".

io di sospetti ne ho sempre avuti (e anche ID ed Epic non mi convincono da questo punto di vista). Per fortuna io i chip li valuto in base all'architettura e non ai risultati dei bench

Originariamente inviato da GMCPape

Non dire così, dai. ho fatto il PR anche io, in passato ;-) non sono così cattivi come sembrano... è che sio fa abbindolare da loro, al massimo, a sbagliare.

Originariamente inviato da GMCPape



Quante di queste sono state sfruttate dagli sviluppatori ai tempi? Certo, Trueform era una figata... ma non basta l'idea.. devi anche saperla vendere. E ATI non ci è mai riuscita. Vedremo che saprà fare con 3Dc.

Pape

il truform è diventata la base per il DM introdotto con le DX9 che fa uso, appunto, delle n-patches; per altre cose (i buffer per il multitexturing) ad esmepio, si era troppo in anticipo sui tempi (adesso, senza, non si saprebbe come fare); le DTR sono parte integrante delle DX dalla versione SM1.4 in poi, nonchè dell'OGL, dalla 1.3 in poi. L'architettura dell'R300 l'ha venduta bene, visto che l'ha comprata persino la concorrenza

Forse non sarà stata all'altezza di nVIDIA, però non si può dire che non abbia innovato e che ciò che ha introdotto sia passato nel dimenticatoio.

ciao

[Alberto Falchi]

Originariamente inviato da yossarian
non si tratta di errate valutazioni sull'impiego degli shader, ma di un'impostazione orientata verso le DX8.x piuttosto che verso le DX9 (che può anche essere condivisibile, visto che ancora sono le API più usate).

Beh, speravo che leggessi fra le righe ;-)
Il tuo discorro non può essere letto "mettiamo i PS 2.0 perché dobbiamo (compatibilità DX, bau bau da strillare, pizza e fichi, etc) ma puntiamo a far funzionare ciò che serve (e a porre le basi per il futuro come diciamo noi)?"
Ha perso sì la guerra dei benchmark, ma quantomeno non ha deluso troppo i suoi utenti, che cmq giocavano adeguatamente. Del resto, le schede di fascia alta vendute da nVidia erano quasi tutte 5900 o 5950, visto che la 5800 (per fortuna!) praticamente non è stata distribuita.

il 3DMark2003 faceva uso, si e no, di tre istruzioni SM2.0, Aquamark arrivava forse a 4; non ho i dettagli di Halo e di FC (ma che ti ha fatto? ); sicuramente sulla qualità e la quantità di effetti dello SM2.0 implementati in questi giochi fek può esere più preciso ed esaustivo di me.

Non è di quante, ma ne fa uso ampiamente, nel benchamrk. O, più correttamente, lo score della sezione PS di 3D Mark ne era influenzato non poco.
In FC e Halo non so dirti quante fossero le istruzioni, ma a guardando il gioco, mi sembra palese che vengano usati in maniera massiccia. Ben più massiccia che nella maggior parte degli altri titoli, per lo meno.

Gli altri esempi che hai fatto sono di titoli che, al massimo, utilizzano qualche feature DX8.x.

Forse che ci ho azzeccato all'inizio di questo msg? :-)

anche i risultati dei ps3.0 possono essere ottenuti utilizzando i 2.0 e, tranne qualche rara feature, anche i ps1.x; l'evoluzione nel linguaggio di programmazione c'è stata anche per andare incontro alle esigenze di chi programma e per facilitargli il lavoro.

E per passare a gradi e senza salti netti alle successive evoluzioni. Invece di ottimizzare pesantemente per ottenere gli stessi risultati, si usa un'astrazione maggiore per velocizzare. Un po' come passare dall'assembler al C (certo che in assembly fai le stesse cose... ma perdio, quanto ci metti?). O, anche, come passare dallo schema di sviluppo attuale a uno più evoluto, passaggio che potrebbe essere velocizzato e semplificato da XNA (sempre che il progetto vada in porto).

se il risultato mi serve per dimostrare che il mio prodotto è più veloce di quello della concorrenza e, di conseguenza, per vendere di più, allora sto barando: è una questione di etica e la mia filosofia non è quella del "principe" di Machiavelli; siccome i bench non sono fatti per essere fini a sé stessi..................

E siccome la filosofia di Machiavelli si adatta al mercato più di quella del buon sammaritano...

Bench non truccabili ci sono; ad esempio lo shadermark non permette l'utilizzo di clipping planes ed è dotato di sofisticati strumenti di antidetect (ed è stato uno degli strumenti che ha evidenziato le difficoltà delle FX con i calcoli in fp).

Ma, per l'appunto, punta tutto sugli shader, rendendolo molto simile alla sezione shading del 3D Mark. Diciamo che shadermark conferma tale test, lo integra, e non lo userei a sé stante (come non prenderei il punteggio finale di 3D Mark a sè stante).

io di sospetti ne ho sempre avuti (e anche ID ed Epic non mi convincono da questo punto di vista). Per fortuna io i chip li valuto in base all'architettura e non ai risultati dei bench

Io ti ho detto come la penso, nei preedenti messaggi, sulle scelte architetturali. Poi, attorno a queste, non escludo ci siano i giochetti marketing delle aziende. Ma il marketing si adatta al prodotto, non viceversa. Almeno nell'alta tecnologia.. se parliamo di trend, ovviamente le cose cambiano ^_^

L'architettura dell'R300 l'ha venduta bene, visto che l'ha comprata persino la concorrenza

?

Forse non sarà stata all'altezza di nVIDIA, però non si può dire che non abbia innovato e che ciò che ha introdotto sia passato nel dimenticatoio.

Non certo dimenticatoio nè inutile. Del resto, per anni ATI ha dettato sul 2D, ora ha un vantaggio inferiore, ma rimane ancora imbattuta (escludendo forse Matrox) in molti ambiti, HTPC in particolare.
Certo è che sul 3D si è mossa tardi, e che secondo me ha dato contributi meno significativi di quanto abbiano fatto 3dfx e nVidia. Anche l'architettura col Kyro avevano delle ottime intuizioni... eppure non sono bastate.

Pape

[Maury]

Originariamente inviato da GMCPape
Guardando i bench utilizzati, uno dove nVidia ha sempre sofferto in grossa misura è stato proprio Far Cry, che a mio personalissimo avviso è uno dei peggiori motori mai visti (oltre che un titolo mediocre, ma questo non ha attinenza col discorso).

Ma stai scherzando o stai dicendo sul serio ?

Per fortuna che non ho mai comprato la rivista presso la quale militi ... passi il fatto che ti possa piacere poco/nulla, ma sul motore grafico non sono ammissibili simili commenti.