Nvidia si è impantanata?

[yossarian]

Originariamente inviato da GMCPape
Mi diresti dove hai trovato tali informazioni? Insomma.. .una (veloce, lo ammetto) ricerca in rete mi ha solo fatto scoprire che, a un certo punto dello sviluppo, JC ha cassato il path NV30 in favore di ARB2. Ma da nessuna parte ho trovato quanto tu dici.

Doom in origine, nasce in ARB (all'epoca dell'NV20 da cui Carmack ha preso l'idea di usare lo shadow buffer per le ombre); in seguito, con l'evoluzione dell'OGL, è passato all'ARB2 che, però, prevedendo l'utilizzo di calcoli in fp anche per i ps, non si adattava ai chip più vecchi; sono quindi nate la path NV20 e R200; quando si è accorto che sulla serie NV3x girava male, ha tirato fuori la path NV30 (che non mi risulta sia stata accantonata); quindi, che io sappia, l'engine di Doom3 è in una specie di ARB2 (non proprio standard) con in aggiunta path specifiche per NV20, R200 e NV3x. Al contrario R3x0, NV40 e R420 utilizzano la modalità ARB2. Su questa modalità ARB2, c'è da dire che l'utilizzo (per carità, lecito) di texture dependent read in sostituzione di math ops in tutte le situazioni possibili, favorisce l'architettura dell'NV3x e dell'NV40 che hanno il loro punto debole nell'utilizzo simultaneo di texture ops e math ops e non favorisce R3x0 e R420 che in questa situazione raggiungono il loro picco massimo di operazioni per ciclo di clock (24 per R3x0 e 48 per R420, contro le 32 di NV40 e le 6 dell'NV35).
La path NV30, invece, non fa altro che utilizzare in maniera massiccia operazioni di shader replacement, passando dai ps2.0 agli 1.1. Ovvio che utilizzndo, la dove possibile, dependent read, almeno per la serie NV35, le operazioni di shader replacement si rendono meno necessarie (tanto più che sia le specifiche ARB2 che quelle DX9 prevedono l'utilizzo di fp16 in questo caso l'utilizzo di fp16); diversa la situazione per NV30, perchè, comunque, con quella famiglia di chip è opportuno evitare il più possibile operazioni in fp.

Originariamente inviato da GMCPape



Si, vero. R200 e ARB2 per NV40 e R420

anche su R3x0 gira in ARB2

Originariamente inviato da GMCPape


Diciamo che l'utilizzo del mixed code, a sentire nVidia, avrebbe risolto il problema. In realtà, il mixed code era uno sbattimento non da poco per i programmatori, e in effetti nessuno si è mai sbattutto troppo per implementarlo, preferendo puntare sullo standard FP24.


Pape

non lo sarebbe stato se fosse stato realmente utilizzabile; in passato, ad esempio all'epoca dell'NV15 e dell'R100, c'era una situazione simile: il Radeon lavorava, a livello di pixel pipeline sempre a 32 bit (8 per canale), la GF2 a 16 o a 32 bit a seconda delle impostazioni; il risultato era che nel primo le differenze prestazionali tra 16 e 32 bit erano ridotte a qualche fps (e molti davano la colpa ai drivers immaturi che erano buggati sui 16 bit), mentre la seconda arrivava a differenza anche del'ordine del 60-70% tra le due modalità (con notevole calo di qualità a 16 bit, però). Questo per farti capire che la filosofia della modalità singola è sempre stata nel DNA di ATi, come quella della doppia modalità in quello di nVIDIA. Ora, poiche le DX9a (e b) prevedevano l'uso di fp24 come livello di precisione minimo (in realtà ci sono delle eccezioni che permettono l'utilizzo di modalità a precisione inferiore, come l'fp16 o, addirittura, l'fx12) ATi si è attenuta strettamente a queste specifiche creando, tra le altre cose, un chip che risulta in grado di far girare codice SM2.0 in maniera accettabile; al contrario nVIDIA ha puntato a soddsfare le caratteristiche richiesta da ARB2 e dalle DX9c, però solo sulla carta; la scarsa capacità dei registri temporanei di NV30 potrebbero anche indurre a pensare ad un errore di valutazione, però l'utilizzo di sole 4 fpu (per giunta neppure indipendenti dalle tmu) contro le 8 fxu, fanno pensare ad una scelta progettuale ben precisa che orienta l'NV30 verso lo SM1.x piuttosto che verso il 2.0. Per quello sostengo che la piene compatibilità con le DX9 è più qualcosa di facciata che di realmente fruibile. Certo si può anche far girare del SW in ARB2 o utilizzando lo SM2.0 su NV30, a patto di accontentarsi di frame rate a livello di slow motion.

Originariamente inviato da GMCPape

Più che fanno vendere, non puoi fare una scheda non compatibile con le ultime DirectX. nVidia, per motivi che sa solo lei, ha preferito puntare su FP32 invece che FP24... e ne ha pagato lo scotto. Di contro, l'architettura era "pronta" per essere evoluta quando lo standard per FP sarebbe stato a 32 bit. Personalmente, non ho mai capito il perché di FP24 in directX: mi è sempre sembrato folle... ma avranno avuto i loro motivi.

ripeto quanto sopra: il problema non è fp32 al posto di fp24 ma un chip non in grado di lavorare velocemente in fp (qualcosa è migliorato con NV35 grazie alla sostituzione di 4 fxu con 4 fpu, però è rimasta la dipendenza con le tmu); NV40 non presenta gli stessi problemi di NV3x nell'utilizzo della modalità fp e nel passaggio da fp16 a fp32 perde in prestazioni come è normale che sia, ma il crollo non è così drammatico come faceva registrare la serie NV35 (con un letterale dimezzamento del frame rate). Ancora adesso, in ogni caso, la dove possibile, si fa ricorso a fp16 (in Doom l'utilizzo di fp è ridotto all'osso, se pure si usa da qualche parte, proprio grazie all'uso del dependent read che permette di effettuare calcoli in fp16).
La scelta di fp24 (come modalità minima, bada bene, non come modalità unica; quindi anche fp32 va benissimo) non è tanto folle o strana, soprattutto alla luce di quello che avveniva con le precedenti versioni. Lo SM1.1 (e quindi l'1.3) prevede l'uso di fx12 per i ps e di fp32 per i vs (modalità impiegata sui chip NV20 e NV25) mentre con le 1.4 si passa a fx16 per i ps e fp32 per i vs (come sull'R200). La modalità minima indica semplicemente il numero di bit a la tipologia di calcoli necessari a rendere al meglio gli effetti che quella API vuole introdurre. Se si è ritenuto sufficiente adottare 24 bit sarebbe stato insensato fissare come modalità minima la fp32, così come sarebbe risulatto insufficiente la fp16 (in realtà, come ho detto, le specifiche DX9 sono più complesse e prevedono l'uso di più modalità a seconda del tipo di calcolo da effettuare).

Originariamente inviato da GMCPape


Come dicevo... a quanto ne so, D3 è ARB2, ma sono pronto a farmi smentire non appena mi porti prove. Tralasciando questo, puntare su Doom 3 non è folle: insieme a Source, sarà uno degli engine più utilizzati. Ma tralasciando l'engine in se, sono proprio una serie di calcoli, come le volume shadow, a rappresentare il fulcro di tale architettura. Non a caso, anche 3d MArk 03 aveva dei test sulle volume shadows proprio perché gli engine si sarebbero mossi in quella direzione.

Doom3 è in ARB2 (con l'aggiunta di qualche estensione proprietaria NV) ma non gira in ARB2 su NV3x, ma solo su R3x0, R420 e NV40 (con i vantaggi, per NV40, di cui ho parlato sopra).
Gli engine si sono mossi anche in direzione delle n-patches per le HOS, eppure su NV3x non c'è il supporto a questa feature, introdotta da ATi con l'R200 e il truform (tanto che le stesse DX9 hanno adottato l'uso delle n-patches per generare HOS). In ogni caso il vantaggio per nVIDIA, derivante dall'uso delle volume shadow non è paragonabile a quello derivante dalle dependent read; la dimostrazione è che è stata sufficiente una patch (contenuta anche nelle ultime release di catalyst) che sostituisca dependent read con calcoli matematici per far incrementare le prestazioni dei chip ATi di un buon 25-30% (forse più) con Doom3.
L'engine di Doom3 sarà sicuramente molto usato (anche per la fama di ID e del titolo stesso), però nasce già vecchio, proprio per l'utilizzo che viene fatto dei ps.

Originariamente inviato da GMCPape



Non c'entra nulla questo. ho citato l'esempio per indicare che era già noto quale strada avesse intrapreso Carmack, e che quindi mi sembrava logico sviluppare architetture adeguate a sfruttare le sue intuizioni.

in realtà Carmack non ha avuto intuizioni geniali o meno; ha fatto semplicemente uso dello shadow buffer (già presente sull'NV20) per le volume shadow (con estensioni esposte con NV25, di cui una la ARB shadow rientrante nelle spcifiche dello SM1.4 e le ext shadow funcs, proprietarie)

Originariamente inviato da GMCPape


Anche qui non hai centrato il punto che volevo toccare. Perché nVidia punta, già da ora, su SM3, al contrario di ATI? La mia risposta è: perché Rein ha bisogno di questo. Certo, fa parte di una API, ma non solo: sarà il fulcro dell'engine. E seocndo te chi ha spinto per far entrare SM3 nelle specifiche DX?


Pape

lo SM3.0 era già noto ai tempi dell'uscita delle specifiche delle prime DX9, ossia ben prima della presentazione dell'R300; inoltre mi sembra poco credibile che MS si lasci imporre qualcosa da qualcuno. Nel 2006 non ci sarà solo l'engine di U3 a far uso dello SM3.0 (e tocca anche vedere in che misura lo useranno) e per allora ci saranno anche chip ATi SM3.0 compliant (il primo uscirà attorno alla metà del 2005 con processo a 0,9 u).
Che nVIDIA abbia già adottato lo SM3.0 è apprezzabile, però, allo stato attuale, non gli porterà benefici. La situazione presenta delle analogie con quella del 2000, con l'R100 che implementava, anche se utilizzando fixed function e in maniera piuttosto primitiva, alcune feature che sarebbero state successivamente utilizzate sui chip con unità programmabile (keyframe interpolation e skeletal animation, tanto per citarne un paio)

Originariamente inviato da GMCPape


Sicuro, però potresti anche portare delle prove a sostegno della tua tesi ^_^

Pape

se potessi, soddisferei volentieri la tua curiosità

[yossarian]

Originariamente inviato da ATi7500
cioè anke rv3x0 è capace di supportare lo sm 2.0b?


bYeZ!

si, almeno per buona parte; questa per i non addetti ai lavori è una delle tante sorprese di R3x0 e RV3x0, per gli addetti ai lavori era cosa già nota (io, comunque, vi avevo avvertiti che R300 andava oltre le specifiche Dx9.a ).
Ti faccio l'esempio del TAA (perchè è qualcosa a cui si sarebbe potuto arrivare con un semplice ragionamento) introdotto apparentemente con R420. Se si vanno ad analizzare le modalità di AA dell'R300 si vede che si ha una 4x e poi una 6x definita "ibrida", perchè non era ben chiaro con quale tipo di griglia si fosse ottenuta. In realtà è una 4x RG combinata con una 2x ottenuta dopo una rotazione delle griglia di campionamento; conclusione, la griglia dell'R300 è in grado di ruotare esattamente come quella dell'R420 (basta solo dargli le istruzioni per farlo).

[halduemilauno]

Originariamente inviato da yossarian
Doom in origine, nasce in ARB (all'epoca dell'NV20 da cui Carmack ha preso l'idea di usare lo shadow buffer per le ombre); in seguito, con l'evoluzione dell'OGL, è passato all'ARB2 che, però, prevedendo l'utilizzo di calcoli in fp anche per i ps, non si adattava ai chip più vecchi; sono quindi nate la path NV20 e R200; quando si è accorto che sulla serie NV3x girava male, ha tirato fuori la path NV30 (che non mi risulta sia stata accantonata); quindi, che io sappia, l'engine di Doom3 è in una specie di ARB2 (non proprio standard) con in aggiunta path specifiche per NV20, R200 e NV3x. Al contrario R3x0, NV40 e R420 utilizzano la modalità ARB2. Su questa modalità ARB2, c'è da dire che l'utilizzo (per carità, lecito) di texture dependent read in sostituzione di math ops in tutte le situazioni possibili, favorisce l'architettura dell'NV3x e dell'NV40 che hanno il loro punto debole nell'utilizzo simultaneo di texture ops e math ops e non favorisce R3x0 e R420 che in questa situazione raggiungono il loro picco massimo di operazioni per ciclo di clock (24 per R3x0 e 48 per R420, contro le 32 di NV40 e le 6 dell'NV35).
La path NV30, invece, non fa altro che utilizzare in maniera massiccia operazioni di shader replacement, passando dai ps2.0 agli 1.1. Ovvio che utilizzndo, la dove possibile, dependent read, almeno per la serie NV35, le operazioni di shader replacement si rendono meno necessarie (tanto più che sia le specifiche ARB2 che quelle DX9 prevedono l'utilizzo di fp16 in questo caso l'utilizzo di fp16); diversa la situazione per NV30, perchè, comunque, con quella famiglia di chip è opportuno evitare il più possibile operazioni in fp.



anche su R3x0 gira in ARB2




non lo sarebbe stato se fosse stato realmente utilizzabile; in passato, ad esempio all'epoca dell'NV15 e dell'R100, c'era una situazione simile: il Radeon lavorava, a livello di pixel pipeline sempre a 32 bit (8 per canale), la GF2 a 16 o a 32 bit a seconda delle impostazioni; il risultato era che nel primo le differenze prestazionali tra 16 e 32 bit erano ridotte a qualche fps (e molti davano la colpa ai drivers immaturi che erano buggati sui 16 bit), mentre la seconda arrivava a differenza anche del'ordine del 60-70% tra le due modalità (con notevole calo di qualità a 16 bit, però). Questo per farti capire che la filosofia della modalità singola è sempre stata nel DNA di ATi, come quella della doppia modalità in quello di nVIDIA. Ora, poiche le DX9a (e b) prevedevano l'uso di fp24 come livello di precisione minimo (in realtà ci sono delle eccezioni che permettono l'utilizzo di modalità a precisione inferiore, come l'fp16 o, addirittura, l'fx12) ATi si è attenuta strettamente a queste specifiche creando, tra le altre cose, un chip che risulta in grado di far girare codice SM2.0 in maniera accettabile; al contrario nVIDIA ha puntato a soddsfare le caratteristiche richiesta da ARB2 e dalle DX9c, però solo sulla carta; la scarsa capacità dei registri temporanei di NV30 potrebbero anche indurre a pensare ad un errore di valutazione, però l'utilizzo di sole 4 fpu (per giunta neppure indipendenti dalle tmu) contro le 8 fxu, fanno pensare ad una scelta progettuale ben precisa che orienta l'NV30 verso lo SM1.x piuttosto che verso il 2.0. Per quello sostengo che la piene compatibilità con le DX9 è più qualcosa di facciata che di realmente fruibile. Certo si può anche far girare del SW in ARB2 o utilizzando lo SM2.0 su NV30, a patto di accontentarsi di frame rate a livello di slow motion.



ripeto quanto sopra: il problema non è fp32 al posto di fp24 ma un chip non in grado di lavorare velocemente in fp (qualcosa è migliorato con NV35 grazie alla sostituzione di 4 fxu con 4 fpu, però è rimasta la dipendenza con le tmu); NV40 non presenta gli stessi problemi di NV3x nell'utilizzo della modalità fp e nel passaggio da fp16 a fp32 perde in prestazioni come è normale che sia, ma il crollo non è così drammatico come faceva registrare la serie NV35 (con un letterale dimezzamento del frame rate). Ancora adesso, in ogni caso, la dove possibile, si fa ricorso a fp16 (in Doom l'utilizzo di fp è ridotto all'osso, se pure si usa da qualche parte, proprio grazie all'uso del dependent read che permette di effettuare calcoli in fp16).
La scelta di fp24 (come modalità minima, bada bene, non come modalità unica; quindi anche fp32 va benissimo) non è tanto folle o strana, soprattutto alla luce di quello che avveniva con le precedenti versioni. Lo SM1.1 (e quindi l'1.3) prevede l'uso di fx12 per i ps e di fp32 per i vs (modalità impiegata sui chip NV20 e NV25) mentre con le 1.4 si passa a fx16 per i ps e fp32 per i vs (come sull'R200). La modalità minima indica semplicemente il numero di bit a la tipologia di calcoli necessari a rendere al meglio gli effetti che quella API vuole introdurre. Se si è ritenuto sufficiente adottare 24 bit sarebbe stato insensato fissare come modalità minima la fp32, così come sarebbe risulatto insufficiente la fp16 (in realtà, come ho detto, le specifiche DX9 sono più complesse e prevedono l'uso di più modalità a seconda del tipo di calcolo da effettuare).



Doom3 è in ARB2 (con l'aggiunta di qualche estensione proprietaria NV) ma non gira in ARB2 su NV3x, ma solo su R3x0, R420 e NV40 (con i vantaggi, per NV40, di cui ho parlato sopra).
Gli engine si sono mossi anche in direzione delle n-patches per le HOS, eppure su NV3x non c'è il supporto a questa feature, introdotta da ATi con l'R200 e il truform (tanto che le stesse DX9 hanno adottato l'uso delle n-patches per generare HOS). In ogni caso il vantaggio per nVIDIA, derivante dall'uso delle volume shadow non è paragonabile a quello derivante dalle dependent read; la dimostrazione è che è stata sufficiente una patch (contenuta anche nelle ultime release di catalyst) che sostituisca dependent read con calcoli matematici per far incrementare le prestazioni dei chip ATi di un buon 25-30% (forse più) con Doom3.
L'engine di Doom3 sarà sicuramente molto usato (anche per la fama di ID e del titolo stesso), però nasce già vecchio, proprio per l'utilizzo che viene fatto dei ps.



in realtà Carmack non ha avuto intuizioni geniali o meno; ha fatto semplicemente uso dello shadow buffer (già presente sull'NV20) per le volume shadow (con estensioni esposte con NV25, di cui una la ARB shadow rientrante nelle spcifiche dello SM1.4 e le ext shadow funcs, proprietarie)



lo SM3.0 era già noto ai tempi dell'uscita delle specifiche delle prime DX9, ossia ben prima della presentazione dell'R300; inoltre mi sembra poco credibile che MS si lasci imporre qualcosa da qualcuno. Nel 2006 non ci sarà solo l'engine di U3 a far uso dello SM3.0 (e tocca anche vedere in che misura lo useranno) e per allora ci saranno anche chip ATi SM3.0 compliant (il primo uscirà attorno alla metà del 2005 con processo a 0,9 u).
Che nVIDIA abbia già adottato lo SM3.0 è apprezzabile, però, allo stato attuale, non gli porterà benefici. La situazione presenta delle analogie con quella del 2000, con l'R100 che implementava, anche se utilizzando fixed function e in maniera piuttosto primitiva, alcune feature che sarebbero state successivamente utilizzate sui chip con unità programmabile (keyframe interpolation e skeletal animation, tanto per citarne un paio)



se potessi, soddisferei volentieri la tua curiosità

capito tutto. tranne una cosa. chi è o cos'è il Dunsinane?
ciao Yossi sei troppo forte.

[yossarian]

Originariamente inviato da halduemilauno
capito tutto. tranne una cosa. chi è o cos'è il Dunsinane?
ciao Yossi sei troppo forte.

l'ho preso dal MacBeth; è la frase che una delle tre streghe dice a MacBeth, dopo che gli è stato predetto che sarebbe diventato re.
Dunsinane è il castello di MacBeth e il bosco di Birnan è un bosco nei paraggi.

ciao Hal

[Alberto Falchi]

Originariamente inviato da yossarian
in seguito, con l'evoluzione dell'OGL, è passato all'ARB2 che, però, prevedendo l'utilizzo di calcoli in fp anche per i ps, non si adattava ai chip più vecchi; sono quindi nate la path NV20 e R200; quando si è accorto che sulla serie NV3x girava male, ha tirato fuori la path NV30 (che non mi risulta sia stata accantonata);

Comprendo la necessità di questo path ai tempi (l'architettura nVidia, soprattutto su fascia medio/bassa, era molto diffusa allora, e deteneva gran parte del mercato).

Su questa modalità ARB2, c'è da dire che l'utilizzo (per carità, lecito) di texture dependent read in sostituzione di math ops in tutte le situazioni possibili, favorisce l'architettura dell'NV3x e dell'NV40 che hanno il loro punto debole nell'utilizzo simultaneo di texture ops e math ops e non favorisce R3x0 e R420 che in questa situazione raggiungono il loro picco massimo di operazioni per ciclo di clock (24 per R3x0 e 48 per R420, contro le 32 di NV40 e le 6 dell'NV35).

Esatto. Ma rimane da capire (edè il fulcro di questo scambio di opinioni) se la scelta di tali operazioni sia stata fatta per favorire nVidia o per motivi di carattere tecnico. OK, il TDR favorisce nVidia, e siamo d'accordo, ma siamo sicuro che non fosse la via migliore da utiilizzare (perché è più veloce in genreale, peché meglio si adatta a certi calcoli, o semplicemente perché a JC piace programmare così)?.

ATi si è attenuta strettamente a queste specifiche creando, tra le altre cose, un chip che risulta in grado di far girare codice SM2.0 in maniera accettabile; al contrario nVIDIA ha puntato a soddsfare le caratteristiche richiesta da ARB2 e dalle DX9c, però solo sulla carta; la scarsa capacità dei registri temporanei di NV30 potrebbero anche indurre a pensare ad un errore di valutazione, però l'utilizzo di sole 4 fpu (per giunta neppure indipendenti dalle tmu) contro le 8 fxu, fanno pensare ad una scelta progettuale ben precisa che orienta l'NV30 verso lo SM1.x piuttosto che verso il 2.0. Per quello sostengo che la piene compatibilità con le DX9 è più qualcosa di facciata che di realmente fruibile.

Su questo siamo pienamente d'accordo: la serie NV3X non era all'altezza della concorrenza nel caso di SM2. Più che di facciata, però, si trattava di necessità: non vorrai fare mica una scheda non compatibile (anche se lenta) con le DX più recenti? Un errore di progetto, sicuramente, e nVidia lo ha pagato caro.

Se si è ritenuto sufficiente adottare 24 bit sarebbe stato insensato fissare come modalità minima la fp32, così come sarebbe risulatto insufficiente la fp16 (in realtà, come ho detto, le specifiche DX9 sono più complesse e prevedono l'uso di più modalità a seconda del tipo di calcolo da effettuare).

Il punto è proprio questo. Siamo sicuro che 24 bit bastassero? Io non ne sono certo, e infatti non si è visto uso di HDR, fino a ora. Del resto, nella maggior parte dei casi 16 bit bastano e avanzano, mentre quando davvero servono precisioni elevate, come nel caso di HDR, 24 non sono sufficienti. è per questo che mi chiedo come mai non è stato introdotto da subito FP32, passando per gli "inutili" FP24. ATI è stata ovviamente avvantaggiata in quanto, nel caso di nVidia, la FP era troppo lenta, e la PP a 16 bit presentava gli evidenti problemi di banding che tutti conoscono. Ciò in ogni caso non toglie che la serie NV3X non fosse all'altezza della situazione.

In ogni caso il vantaggio per nVIDIA, derivante dall'uso delle volume shadow non è paragonabile a quello derivante dalle dependent read; la dimostrazione è che è stata sufficiente una patch (contenuta anche nelle ultime release di catalyst) che sostituisca dependent read con calcoli matematici per far incrementare le prestazioni dei chip ATi di un buon 25-30% (forse più) con Doom3.

Creando tra l'altro problemi di visualizzazione, come fa notare lo stesso Carmack. Humus ha fatto un'enorme idiozia con tale patch, danneggiando tra l'altro l'azienda per cui lavora. Un 20/30% di guadagno coisì ottenuto è pari alle cheat di nVidia su 3D MArk, o a quelle di ATI sulle vecchie Radeon con Q3.

L'engine di Doom3 sarà sicuramente molto usato (anche per la fama di ID e del titolo stesso), però nasce già vecchio, proprio per l'utilizzo che viene fatto dei ps.

Nasce sicuramente "vecchio", ma considerando il lungo periodo di gestazione, non me ne stupisco. Del resto, non credo nemmeno che Source nasca "nuovissimo", pur supportando anche 3Dc. Calcolando che per fare un engine a tali livelli ci vogliono anni, non mi stupisco che alcune scelte alla base si possano considerare anacronistiche rispetto al potenziale delle ultime GPU.
Del resto il focus di D3 sono le ombre, non certo gli shader. Come si puòà vedere dai limiti di alcune texture, probabilmente dovuti anche alla mancanza di un HLSL di qualità in ambito OGL.

in realtà Carmack non ha avuto intuizioni geniali o meno; ha fatto semplicemente uso dello shadow buffer (già presente sull'NV20) per le volume shadow (con estensioni esposte con NV25, di cui una la ARB shadow rientrante nelle spcifiche dello SM1.4 e le ext shadow funcs, proprietarie)

la genialità è stato l'utilizzo creativo che ne ha fatto. Le volume shadow non sono una novità in ambito tecnico, ma in ambito di gameplay.

lo SM3.0 era già noto ai tempi dell'uscita delle specifiche delle prime DX9, ossia ben prima della presentazione dell'R300; inoltre mi sembra poco credibile che MS si lasci imporre qualcosa da qualcuno.

MS ha creato delle DX senza ascoltare gli sviluppatori. E per anni, infatti,. tutti i giochi 3D usavano Glide oppure OGL. Dalla release 6 in poi, l'azienda di Redmond ha capito che le sue DX dovevano essere uno strumento per i programmatori, e ha iniziato a sviluppare in relazione alle loro esigenze. A MS non interessa imporre certe specifiche: MS non fa GPU. A MS interessa un ambiente comodo per gli sviluppatori, che li porti ad abbandonare OGL per dedicarsi solo alla piattaforma Windows (e xbox, ovviamente). Quindi ha tutto l'interesse a "farsi imporre" le specifiche.

Nel 2006 non ci sarà solo l'engine di U3 a far uso dello SM3.0 (e tocca anche vedere in che misura lo useranno) e per allora ci saranno anche chip ATi SM3.0 compliant (il primo uscirà attorno alla metà del 2005 con processo a 0,9 u).

Sicuro. Però allo stato attuale Rein collabora attivamente (come ha fatto Carmack in passato per NV30 e NV40) con nVidia per lo sviluppo di NV50.

Che nVIDIA abbia già adottato lo SM3.0 è apprezzabile, però, allo stato attuale, non gli porterà benefici. La situazione presenta delle analogie con quella del 2000, con l'R100 che implementava, anche se utilizzando fixed function e in maniera piuttosto primitiva, alcune feature che sarebbero state successivamente utilizzate sui chip con unità programmabile (keyframe interpolation e skeletal animation, tanto per citarne un paio)

Ora come ora non serve, ma l'averlo introdotto adesso permette a tutti i programmatori di prendere confidenza con l'ambiente, e all'azienda californiana di scoprire in anticipo eventuali magagne, in modo da fare il possibile per poterle correggere in tempo quando uscirà la nuova generazione.

Pape

[fek]

Originariamente inviato da GMCPape
Si, ma le api di riferimento come vengono scelte? Dai produttori, come indichi giustamente. Ma i produttori, a quanto mi è dato di sapere, si consultano eccome coi guru della programmazione per capire quali siano le loro reali necessità. Le API alla fine sono basate sulle principali esigenze di chi il 3D lo realizza. E esiste un Deus ex Machina che dal nulla decide quali siano le spec più importanti per uno sviluppatore di giochi innovatore, quale un Carmak o un Rein?

L'API delle DirectX e' disegnata da Microsoft in base ai suggerimenti che vengono da un consorzio del quale fanno parte gli IHV (NVIDIA e ATI) e alcuni sviluppatori (ID, Valve, Lionhead, Blizzard e altri che a memoria non ricordo).

Il processo di definizione di OpenGL e' simile.

[rob-roy]

Si dovrebbe mettere in evidenza questo thread per leggerlo con calma...ho già comprato il marmo per le vostre statue....

[R@nda]

Come si puòà vedere dai limiti di alcune texture, probabilmente dovuti anche alla mancanza di un HLSL di qualità in ambito OGL.

I limiti sulle texture dipendono dalla memoria video onboard che abbiamo attualmente sulle sk video,la colpa dell'insufficienza di memoria è dovuta alla tecnica utilizzata per le ombre in Doom3.

[Alberto Falchi]

Originariamente inviato da R@nda
I limiti sulle texture dipendono dalla memoria video onboard che abbiamo attualmente sulle sk video,la colpa dell'insufficienza di memoria è dovuta alla tecnica utilizzata per le ombre in Doom3.

Non intendevo le dimensioni delle texture, quanto l'utilizzo dei PS su di esse. Texture anche semplici possono miracolosamente miglirare con un accorto uso di PS, ma in Doom 3 oggettivamente si è puntato su altro

Pape

[R@nda]

Ah ok,si è vero,più volte qui si sono lamentati della semplicità degli shader in Doom3.

(Comunque gira gira si torna sempre a parlare di Doom3...non è possibile ).

[yossarian]

Originariamente inviato da GMCPape


Esatto. Ma rimane da capire (edè il fulcro di questo scambio di opinioni) se la scelta di tali operazioni sia stata fatta per favorire nVidia o per motivi di carattere tecnico. OK, il TDR favorisce nVidia, e siamo d'accordo, ma siamo sicuro che non fosse la via migliore da utiilizzare (perché è più veloce in genreale, peché meglio si adatta a certi calcoli, o semplicemente perché a JC piace programmare così)?.

in realtà non esistono prove (e meno male ) che Carmack abbia voluto favorire nVIDIA, però resta il fatto che tutte le sue scelte vanno nella stessa direzione e questo non sposta la questione: le scelte di Carmack hanno, in ogni caso, favorito nVIDIA, prendendo spunto da tecniche proprietarie o utilizzando modalità di rendering più amichevoli con i chip NV; d'altra parte, per sua stessa ammissione, ha sviluppato Doom su NV30; ora, se lo ha fatto perchè riteneva l'architettura nVIDIA più consona alle sue idee o se lo ha fatto per favorire i chip NV (che, oggettivamente, erano quelli più bisognosi di aiuto), non cambia nella sostanza il risultato. Sicuramente le DTR sono più veloci sui chip NV (le specifiche SM2.0 prevedono un massimo di 4 dependent texture, mentre lo SM3.0 ne prevede un numero illimitato, limitato, ovviamente, solo dalla capacità fisica del registro); per i chip ATi sarebbe stato meglio fare massiccio ricorso all'utilizzo di istruzioni matematiche

Originariamente inviato da GMCPape





Il punto è proprio questo. Siamo sicuro che 24 bit bastassero? Io non ne sono certo, e infatti non si è visto uso di HDR, fino a ora. Del resto, nella maggior parte dei casi 16 bit bastano e avanzano, mentre quando davvero servono precisioni elevate, come nel caso di HDR, 24 non sono sufficienti. è per questo che mi chiedo come mai non è stato introdotto da subito FP32, passando per gli "inutili" FP24. ATI è stata ovviamente avvantaggiata in quanto, nel caso di nVidia, la FP era troppo lenta, e la PP a 16 bit presentava gli evidenti problemi di banding che tutti conoscono. Ciò in ogni caso non toglie che la serie NV3X non fosse all'altezza della situazione.

con le specifiche 9b i 24 bit minimi erano sufficienti; se finora non si è visto l'HDR (che si potrebbe ottenere anche con 16 bit, come ha tentato di fare Valve e non so se ci sia riuscita o meno) è perchè l'HW di riferimento non era in grado di far elaborarlo con un frame rate accettabile; inoltre il supporto all'HDR della serie NV3x è praticamente inesistente, per l'R3x0 e l'R420 e solo parziale e, quindi, deve essere, almeno in parte, emulato (con ulteriore calo del framerate). NV40 è l'unico chip con supporto completo in HW (anche se, poi, è da vedere come girerebbe con HDR a fp32).
I problemi di banding sono stati un po' enfatizzati quando si è presentata l'fp32; la full precision è necessaria solo in alcuni casi particolarissimi, oppure in presenza di shader molto lunghi in cui gli errori di approssimazione si sommano, dando luogo ad un errore finale non accettabile. Finora, però, gli shader adoperati sono molto corti e questo fa si che non sia mai stato richiesto l'uso di una modalità superiore a fp16. Inoltre, una volta minimizzato il problema della propagazione degli errori, bisogna tener conto del fatto che le immagini, formate nel frame buffer, hanno solo 8 bit per ciascuno dei 4 canali (10+10+10+4 per Parhelia e R3x0).

Originariamente inviato da GMCPape



Creando tra l'altro problemi di visualizzazione, come fa notare lo stesso Carmack. Humus ha fatto un'enorme idiozia con tale patch, danneggiando tra l'altro l'azienda per cui lavora. Un 20/30% di guadagno coisì ottenuto è pari alle cheat di nVidia su 3D MArk, o a quelle di ATI sulle vecchie Radeon con Q3.

non mi riferivo alla patch di humus (che ha solo aperto la strada e il cui guadagno si aggira intorno ad un 40%) ma a quelkla analoga (anche se meno "spinta") dei catalyst che non mi risulta dia problemi di visualizzaione.

Originariamente inviato da GMCPape



Nasce sicuramente "vecchio", ma considerando il lungo periodo di gestazione, non me ne stupisco. Del resto, non credo nemmeno che Source nasca "nuovissimo", pur supportando anche 3Dc. Calcolando che per fare un engine a tali livelli ci vogliono anni, non mi stupisco che alcune scelte alla base si possano considerare anacronistiche rispetto al potenziale delle ultime GPU.
Del resto il focus di D3 sono le ombre, non certo gli shader. Come si puòà vedere dai limiti di alcune texture, probabilmente dovuti anche alla mancanza di un HLSL di qualità in ambito OGL.

beh, un GLSL è stato introdotto, seppure opzionale, con le OGL1.5 (anzi le OGL1.5 sono state "inventate" proprio per introdurre un linguaggio ad alto livello, visto che non ci si decide a far uscire le 2.0 a causa di disaccordi sulle estensioni da includere in questa versione).

Originariamente inviato da GMCPape


la genialità è stato l'utilizzo creativo che ne ha fatto. Le volume shadow non sono una novità in ambito tecnico, ma in ambito di gameplay.

però ha, comunque, sfruttato una feature proposta di nVIDIA; per carità, sicuramente valida (anche se l'utilizzo dello shadow buffer non sempre è possibile). Non metto in dubbio la genialità di Carmack, ma mi lasciano perplesso certe sue scelte

Originariamente inviato da GMCPape


MS ha creato delle DX senza ascoltare gli sviluppatori. E per anni, infatti,. tutti i giochi 3D usavano Glide oppure OGL. Dalla release 6 in poi, l'azienda di Redmond ha capito che le sue DX dovevano essere uno strumento per i programmatori, e ha iniziato a sviluppare in relazione alle loro esigenze. A MS non interessa imporre certe specifiche: MS non fa GPU. A MS interessa un ambiente comodo per gli sviluppatori, che li porti ad abbandonare OGL per dedicarsi solo alla piattaforma Windows (e xbox, ovviamente). Quindi ha tutto l'interesse a "farsi imporre" le specifiche.

MS ascolta gli sviluppatori, ascolta i produttori di HW, però, alla fine decide lei cosa fare e come farlo; è ovvio che ci si consulti con chi deve utilizzare quelle API per creare giochi e con chi deve progettare HW per farle girare, ma non c'è nessuno che può "imporre" una sua scelta senza l'avallo di MS. Non è detto che le sue scelte siano dettate sempre da ragioni tecniche e siano le più corrette, però è così. Un esempio è quello delle n-patches: sono uno dei tanti algoritmi per generare HOS e non è detto che, in assoluto, sia il migliore; però è stato scelto ufficialemnte per le specifiche DX9 ed è stato scelto in un periodo in cui si iniziaveno ad allacciare rapporti "cordiali" tra ATi e MS, in previsione della realizzazione dell'x-box2. Risultato NV3x non ha il supporto per le n-patches (per scelta di nVIDIA) e quindi non è compatibile in HW con la generazione di HOS.
Carmack non ne ha fatto uso in Doom3 (engine con un numero esiguo di poligoni se paragonato ad altri) dicendo che l'impiego di questa tecnica avrebbe creato problemi con la gestione delle ombre, causando rallentamenti nell'elaborazione. Avrà sicuramente ragione lui, però molti programmatori sono scettici; sicuramente l'utilizzo di n-patches avrebbe penalizzato i chip NV3x che avrebbero dovuto emulare queste funzioni.

Originariamente inviato da GMCPape



Sicuro. Però allo stato attuale Rein collabora attivamente (come ha fatto Carmack in passato per NV30 e NV40) con nVidia per lo sviluppo di NV50.

Rein ha collaborato anche in passato con nVIDIA; c'è stato un caso, col motore di UT2003 che ha fatto gridare al cheating nei confronti di ATi e poi si è scoperto che dipendeva dalla scelta non convenzionale del valore del LoD da parte di Epic che dava artefatti sull'R3x0, mentre era visualizzato correttamente su NV3x (il discorso è piuttosto lungo e coinvolge le scelte fatte da ATi e nVIDIA suk numero di bit per rappresentare il LoD e le scelte di Epic sul LoD minimo per il texture mapping).

Originariamente inviato da GMCPape


Ora come ora non serve, ma l'averlo introdotto adesso permette a tutti i programmatori di prendere confidenza con l'ambiente, e all'azienda californiana di scoprire in anticipo eventuali magagne, in modo da fare il possibile per poterle correggere in tempo quando uscirà la nuova generazione.

Pape

questo è sicuramente vero

ciao

[yossarian]

Originariamente inviato da fek
L'API delle DirectX e' disegnata da Microsoft in base ai suggerimenti che vengono da un consorzio del quale fanno parte gli IHV (NVIDIA e ATI) e alcuni sviluppatori (ID, Valve, Lionhead, Blizzard e altri che a memoria non ricordo).

Il processo di definizione di OpenGL e' simile.

non ci posso credere..................il mio sviluppatore di SW preferito

[Alberto Falchi]

Originariamente inviato da yossarian
in realtà non esistono prove (e meno male ) che Carmack abbia voluto favorire nVIDIA, però resta il fatto che tutte le sue scelte vanno nella stessa direzione e questo non sposta la questione: le scelte di Carmack hanno, in ogni caso, favorito nVIDIA, prendendo spunto da tecniche proprietarie o utilizzando modalità di rendering più amichevoli con i chip NV; d'altra parte, per sua stessa ammissione, ha sviluppato Doom su NV30; ora, se lo ha fatto perchè riteneva l'architettura nVIDIA più consona alle sue idee o se lo ha fatto per favorire i chip NV (che, oggettivamente, erano quelli più bisognosi di aiuto), non cambia nella sostanza il risultato. Sicuramente le DTR sono più veloci sui chip NV (le specifiche SM2.0 prevedono un massimo di 4 dependent texture, mentre lo SM3.0 ne prevede un numero illimitato, limitato, ovviamente, solo dalla capacità fisica del registro); per i chip ATi sarebbe stato meglio fare massiccio ricorso all'utilizzo di istruzioni matematiche

In generale, indipendentemente dai motivi, D3 gira meglio su nVidia, e su questo ci siamo. Come HL sembra digerire meglio ATI, del resto. Per fortuna, direi anche ^_^. I programmatori sono parecchi, e ognuno sceglie la tecnica che più gli aggrada, il che è un bene in quanto non viene decretata una sola architettura, ma vengono valorizzate tutte quelle esistenti. Quesitoni di marketing o di casualità che siano, credo sia un bene per giocatori.

con le specifiche 9b i 24 bit minimi erano sufficienti; se finora non si è visto l'HDR (che si potrebbe ottenere anche con 16 bit, come ha tentato di fare Valve e non so se ci sia riuscita o meno) è perchè l'HW di riferimento non era in grado di far elaborarlo con un frame rate accettabile; inoltre il supporto all'HDR della serie NV3x è praticamente inesistente, per l'R3x0 e l'R420 e solo parziale e, quindi, deve essere, almeno in parte, emulato (con ulteriore calo del framerate).

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.

NV40 è l'unico chip con supporto completo in HW (anche se, poi, è da vedere come girerebbe con HDR a fp32).
I problemi di banding sono stati un po' enfatizzati quando si è presentata l'fp32; la full precision è necessaria solo in alcuni casi particolarissimi, oppure in presenza di shader molto lunghi in cui gli errori di approssimazione si sommano, dando luogo ad un errore finale non accettabile. Finora, però, gli shader adoperati sono molto corti e questo fa si che non sia mai stato richiesto l'uso di una modalità superiore a fp16.

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.

Inoltre, una volta minimizzato il problema della propagazione degli errori, bisogna tener conto del fatto che le immagini, formate nel frame buffer, hanno solo 8 bit per ciascuno dei 4 canali (10+10+10+4 per Parhelia e R3x0).

NOn sono certo che R3X0 supporti un FB a 10 bit.. mi sembra che sia una peculiarità di Parhelia, ma potrei sbagliarmi. In ogni caso, tali vantaggi sono relativi sino all'uscita di Longhorn, dato che WinXP non supporta i 10 bit di canale per colore, e quindi tale vantaggio è limitato a pochi casi. Ritengo che sia più importante il supporto a FP32 che al FB da 10 bit per canale, ora come ora. Con Longhorn, tale feature sarà invece molto importante.

non mi riferivo alla patch di humus (che ha solo aperto la strada e il cui guadagno si aggira intorno ad un 40%) ma a quelkla analoga (anche se meno "spinta") dei catalyst che non mi risulta dia problemi di visualizzaione.

Su questo non saprei che dirti, dato che non ho avuto modo di provarla.

beh, un GLSL è stato introdotto, seppure opzionale, con le OGL1.5 (anzi le OGL1.5 sono state "inventate" proprio per introdurre un linguaggio ad alto livello, visto che non ci si decide a far uscire le 2.0 a causa di disaccordi sulle estensioni da includere in questa versione).

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.

[quote]
però ha, comunque, sfruttato una feature proposta di nVIDIA; per carità, sicuramente valida (anche se l'utilizzo dell'o shadow buffer non sempre è possibile). Non metto in dubbio la genialità di Carmack, ma mi lasciano perplesso certe sue scelte
[quote]

Attenzione: è nato prima l'uovo o la gallina. Da che mi ricordo, la proposta di nVidia è sempre stata pubblicizzata come punto di forza per D3. Ergo, continuo a credere che sia NVX ad aver puntato sulle scelte di Carmack che viceversa.

MS ascolta gli sviluppatori, ascolta i produttori di HW, però, alla fine decide lei cosa fare e come farlo. Non è detto che le sue scelte siano dettate sempre da ragioni tecniche e siano le più corrette, però è così.

Diciamo che tira le somme, e in certi casi non lo fa nella maniera migliore, questo è ovvio. Però sarebbe stupido da parte sua non tenere conto delle richieste dei player più importanti in questo mercato.

Un esempio è quello delle n-patches: sono uno dei tanti algoritmi per generare HOS e non è detto che, in assoluto, sia il migliore; però è stato scelto ufficialemnte per le specifiche DX9 ed è stato scelto in un periodo in cui si iniziaveno ad allacciare rapporti "cordiali" tra ATi e MS, in previsione della realizzazione dell'x-box2.

Ovviamente ^_^

Risultato NV3x non ha il supporto per le n-patches (per scelta di nVIDIA) e quindi non è compatibile in HW con la generazione di HOS.
Carmack non ne ha fatto uso in Doom3 (engine con un numero esiguo di poligoni se paragonato ad altri) dicendo che l'impiego di questa tecnica avrebbe creato problemi con la gestione delle ombre, causando rallentamenti nell'elaborazione. Avrà sicuramente ragione lui, però molti programmatori sono scettici; sicuramente l'utilizzo di n-patches avrebbe penalizzato i chip NV3x che avrebbero dovuto emulare queste funzioni.

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.

Rein ha collaborato anche in passato con nVIDIA; c'è stato un caso, col motore di UT2003 che ha fatto gridare al cheating nei confronti di ATi e poi si è scoperto che dipendeva dalla scelta non convenzionale del valore del LoD da parte di Epic che dava artefatti sull'R3x0, mentre era visualizzato correttamente su NV3x (il discorso è piuttosto lungo e coinvolge le scelte fatte da ATi e nVIDIA suk numero di bit per rappresentare il LoD e le scelte di Epic sul LoD minimo per il texture mapping).

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

[fek]

Originariamente inviato da yossarian
non ci posso credere..................il mio sviluppatore di SW preferito

con le specifiche 9b i 24 bit minimi erano sufficienti; se finora non si è visto l'HDR (che si potrebbe ottenere anche con 16 bit, come ha tentato di fare Valve e non so se ci sia riuscita o meno) è perchè l'HW di riferimento non era in grado di far elaborarlo con un frame rate accettabile; inoltre il supporto all'HDR della serie NV3x è praticamente inesistente, per l'R3x0 e l'R420 e solo parziale e, quindi, deve essere, almeno in parte, emulato (con ulteriore calo del framerate). NV40 è l'unico chip con supporto completo in HW (anche se, poi, è da vedere come girerebbe con HDR a fp32).

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.

[Maury]

Quando comincia Yoss mi prendo un caffè, una sigaretta tra le dita, poi chiudo la porta dell'ufficio ... e comincio la lettura.

Poi riparto da capo xchè non ho capito un ca@@o

Grande amico

[Spytek]

Originariamente inviato da Maury
Quando comincia Yoss mi prendo un caffè, una sigaretta tra le dita, poi chiudo la porta dell'ufficio ... e comincio la lettura.

Poi riparto da capo xchè non ho capito un ca@@o

Grande amico

E' vero!!!
Anche Fek e Pape però non scherzano!!
Grandi tutti e tre!!

[TripleX]

beh....i test del 3d2005 con uso di sm3.0 sono all'occhio di tutti....vantaggi prestazionali = a O anzi lieve svantaggio.....imho e' inutile avere oggi qualcosa che cmq verra' sfruttata domani e sicuramente a livello di supporto sara' completamente rivoluzionata da parte delle gpu....che gia' oggi hanno sopratutto in ambito vs (vedi nvidia) grosse difficolta' a gestire....in puro 2.0....il 3.0 e' un mero specchietto per le allodole allo stato attuale....diverso il discorso sulle shadow maps che comporta reali vantaggi prestazionali....
allo stato attuale esistono pochi games full dx9.0 anzi pochi e' dir "troppo"....inesistenti i DX9c compliant....quindi meglio valutare un acquisto alla luce di quanto supporta il software e dell'hw che esso richiede e non fare il contrario...quando i games saranno sm3.0 dipendenti e le architetture gpu aottimizzate per lavorare in maniera "pura" per tale mod...e lo stesso il software allora si che' servira' e ci saranno reali vantaggi....imho la scelta conservatrice di ATi e' la giusta via....del resto il chip nv30 sulla carta evoluto piu' do ogni altro abbiamo visto di quali lacune era affetto....meglio non anticipare il futuro...perche' potrebbe anche non essere sm3.0 come oggi lo intendiamo....basta vedere le specifiche dx10 per capire che il "vero salto" ci sara' solo tra 9 e 10 e che gli shader 3.0 non siano altro che un mero aggiornamento che allo stato attuale non porta benefici...visto che entrambe le gpu nv40 e r420 nascono per essere sm2.0 dx9 optimized e che sm3.0 sia solo un passo avanti per saggiare cio' che sara' il futuro....
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....

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

[fek]

Originariamente inviato da Spytek

E' vero!!!
Anche Fek e Pape però non scherzano!!
Grandi tutti e tre!!

Nah... se quando scrivo qualcosa chi legge non capisce, e' colpa mia

[fek]

Originariamente inviato da TripleX
beh....i test del 3d2005 con uso di sm3.0 sono all'occhio di tutti....vantaggi prestazionali = a O anzi lieve svantaggio.....

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.