L'ora della verità...

[Murakami]

per ogni pipeline si possono applicare 4 filtraggi bilineari, 2 trilineari o un anisotropico (fino a 16 tap) per ciclo. Quindi, puoi applicare, ad esempio, 4 texel con filtraggio bilineare in un ciclo, oppure 2 texel con filtraggio trilineare per ciclo, ecc.
Fammi capire meglio: quindi confermi quanto riporto di seguito?
"Matrox Parhelia features 4x4 organization: 4 pixel pipelines with four texturing units each. Seems like this is going to be great advantage over competitors in polygon texturing speed. For example, ATI RADEON 8500 and NVIDIA GeForce4 Ti4600 have four pixel pipelines with two texturing units each. But the texturing units of Matrox Parhelia, unlike those of the competitors, can only take four texture samples per clock, that is, to perform bi-linear filtering only. To perform tri-linear filtering, the texturing units of Parhelia are combined in pairs and eight samples are taken from each texture (four from each of the two closest MIP-levels of the texture). When performing anisotropic filtering, texturing units again get combined in pairs thus reducing the texturing speed.
Firstly, the texturing units of Parhelia-512 cannot take eight texture samples per clock to bi-linearly filter two neighboring MIP-levels at the same time. This means that the combination of tri-linear and anisotropic filtering in Parhelia will make all four texturing units involved in the rendering of one texture. That is, if there is more than one texture to be rendered, Parhelia-512 will spend an extra clock cycle for rendering every extra texture.
This situation differs from what we see in NVIDIA GeForce3 Ti/GeForce4 Ti. These chips need extra clocks not for the growing number of textures but when the anisotropy level is increased: once clock for every extra bi-linear or tri-linear filtering operation.
As Parhelia texturing units can be re-configured, the 8-sample anisotropic filtering (level 2) for two textures or both tri-linear and 8-sample anisotropic filtering for one texture shouldn't slow sown the performance, while by NVIDIA GeForce3 Ti/ GeForce4 Ti any growth of the anisotropy level requires extra clocks to be spent." Da http://www.xbitlabs.com/articles/video/display/matrox-parhelia.html

[ReDeX]

Questi sono dei test che feci tempo fa con la GF3 Liscia. Ci sono anche test in oc.
Avevate chiesto dei test con i giochi e credo che questi dovrebbero accontentarvi... :D:D:D

LINK (http://wondercomputer.altervista.org/benchmark/Test.rar) (se avete problemi a scaricarlo con firefox provate con IE)


BYEZZZZZZZZZZZ!!!!!!!!!!!! ;)

Test.mht, con cosa lo uso?

[Murakami]

Da notare una particolarità delle pixel pipeline della parhelia: i cinque stadi di pixel shading di ogni pipeline possono essere "combinati" con quelli della pipeline adiacente. Questo permette di riconfigurare la pixel pipeline in modo tale da far fronte a istruzioi molto pesanti sia dal punto di vista delle texture fetch che da quello dei calcoli matematici. Ovviamente, il contro (per cui vale la pena di vedere se effettivamente vale la pena di fare una cosa del genere) è che si dimezza il pixel fillrate, poichè sono solo 2 le pipeline che di fatto elaborano i dati (anche se ognuna ha il doppio delle unità)
Si, questo lo sapevo: chissà come agiscono sulle pipeline i driver Matrox in presenza di certi shader e/o certi giochi...purtroppo, Matrox è molto avara di dettagli tecnici sui suoi prodotti... :(

[yossarian]

Fammi capire meglio: quindi confermi quanto riporto di seguito?
"Matrox Parhelia features 4x4 organization: 4 pixel pipelines with four texturing units each. Seems like this is going to be great advantage over competitors in polygon texturing speed. For example, ATI RADEON 8500 and NVIDIA GeForce4 Ti4600 have four pixel pipelines with two texturing units each. But the texturing units of Matrox Parhelia, unlike those of the competitors, can only take four texture samples per clock, that is, to perform bi-linear filtering only. To perform tri-linear filtering, the texturing units of Parhelia are combined in pairs and eight samples are taken from each texture (four from each of the two closest MIP-levels of the texture). When performing anisotropic filtering, texturing units again get combined in pairs thus reducing the texturing speed.
Firstly, the texturing units of Parhelia-512 cannot take eight texture samples per clock to bi-linearly filter two neighboring MIP-levels at the same time. This means that the combination of tri-linear and anisotropic filtering in Parhelia will make all four texturing units involved in the rendering of one texture. That is, if there is more than one texture to be rendered, Parhelia-512 will spend an extra clock cycle for rendering every extra texture.
This situation differs from what we see in NVIDIA GeForce3 Ti/GeForce4 Ti. These chips need extra clocks not for the growing number of textures but when the anisotropy level is increased: once clock for every extra bi-linear or tri-linear filtering operation.
As Parhelia texturing units can be re-configured, the 8-sample anisotropic filtering (level 2) for two textures or both tri-linear and 8-sample anisotropic filtering for one texture shouldn't slow sown the performance, while by NVIDIA GeForce3 Ti/ GeForce4 Ti any growth of the anisotropy level requires extra clocks to be spent." Da http://www.xbitlabs.com/articles/video/display/matrox-parhelia.html

ogni tmu può utilizzare fino a 4 sample dello stesso texel (e quindi applicare filtraggio bilineare). Questo vale per la parhelia, quanto per qualunque altro chip. Non esistono tmu in grado di fare trilinear da sole (se 1ualcuno sostiene il contrario è solo perchè i suoi chip non applicano vero trilinear ma qualcosa di analogo al brilinear)

[Murakami]

Lo sapevo che quell'articolo era fallace... :muro:

[shodan]

1) non lo so; non sono un esperto di motori grafici; questa domanda andrebbe girata a fek o a Vifani
2) per ogni pipeline si possono applicare 4 filtraggi bilineari, 2 trilineari o un anisotropico (fino a 16 tap) per ciclo. Quindi, puoi applicare, ad esempio, 4 texel con filtraggio bilineare in un ciclo, oppure 2 texel con filtraggio trilineare per ciclo, ecc.
Da notare una particolarità delle pixel pipeline della parhelia: i cinque stadi di pixel shading di ogni pipeline possono essere "combinati" con quelli della pipeline adiacente. Questo permette di riconfigurare la pixel pipeline in modo tale da far fronte a istruzioi molto pesanti sia dal punto di vista delle texture fetch che da quello dei calcoli matematici. Ovviamente, il contro (per cui vale la pena di vedere se effettivamente vale la pena di fare una cosa del genere) è che si dimezza il pixel fillrate, poichè sono solo 2 le pipeline che di fatto elaborano i dati (anche se ognuna ha il doppio delle unità)
In caso di pipeline combinate (quindi solo 2 pipeline con 10 stage ps) anche le tmu vengono sommate? In pratica, si ha una situazione di 2x8 o le altre tmu vengono "perse" e quindi si ha una soluzione di 2x4 (così mi pare di ricordare da un tuo precedente post...)?

Ciao. :)

[shodan]

As Parhelia texturing units can be re-configured, the 8-sample anisotropic filtering (level 2) for two textures or both tri-linear and 8-sample anisotropic filtering for one texture shouldn't slow sown the performance, while by NVIDIA GeForce3 Ti/ GeForce4 Ti any growth of the anisotropy level requires extra clocks to be spent."[/I] Da http://www.xbitlabs.com/articles/video/display/matrox-parhelia.html

Mmm... sta cosa non torna manco a me. Ho sempre saputo che, superate le 2 texture per pixel, i chip NV20/25 dovevano ricorrere a più cicli di clock per processare le texture (in single pass fino a 4 texture).

Yoss, puoi confermare?

Ciao. :)

[Zak84]

Test.mht, con cosa lo uso?

Internet Explorer. ;)

[Pat77]

Lo standard sm2.0 prevede un minimo di 12 registri temporanei a 32 bit; NV3x ne ha 32 a 8 bit. Utilizzando fp32, si ha che i 32 registri si riducono a soli 2x128 bit; ossia NV3x può gestire solo due vettori completi per ciclo, per ogni pipeline. Al contrario, R3x0 ha l'equivalente di 12 registri a 32 bit; utilizzando fp24, questo si traducoe in 4 gruppi di registri a 128; quindi, R3x0 può elaborare, per ogni ciclo, 4 vettori completi per pipeline.

Quindi ne r300 ne nv30 sono pienamente compatibili dx 9 sm 2.0.
Inoltre noto che in fp16 nv30 ha poi gli stessi registri temporanei di r300.
Grazie delle info comunque.

Pk77

[yossarian]

In caso di pipeline combinate (quindi solo 2 pipeline con 10 stage ps) anche le tmu vengono sommate? In pratica, si ha una situazione di 2x8 o le altre tmu vengono "perse" e quindi si ha una soluzione di 2x4 (così mi pare di ricordare da un tuo precedente post...)?

Ciao. :)

4 tmu vengono perse; tra l'altro, la Perhelia è un chip ben strano: ha 4 tmu ed è compatibile con lo sm1.3 (e non con l'1.4), però ha un numero di stadi di psu decisamente superiore a quello dei chip sm1.3 e 1.4 (NV2x e R200), un numero di registri temporanei pari a 12, da 32 bit ciascuno (come un chip sm2.0) e ha le pixel pipeline riconfigurabili in modo tale da arrivare a 10 unità in serie, come se dovesse far fronte a chissà quale mole di calcoli (situazione piuttosto anomala per lo sm1.3). Le pixel pipeline così lunghe, tra le altre cose, risultano anche meno effiicenti rispetto a quelle più corte di NV2x e R200, quando si tratta di elaborare shader con poche istruzioni (cosa abbastanza normale per lo sm1.3).
Quindi è un chip che si può definire "ibrido" a tutti gli effetti; volendo fare una battuta, sembrerebbe quasi che i progettisti, fino all'ultimo, non avessero le ideee chiare sulla tipologia di chip da realizzare :D

[yossarian]

Lo standard sm2.0 prevede un minimo di 12 registri temporanei a 32 bit; NV3x ne ha 32 a 8 bit. Utilizzando fp32, si ha che i 32 registri si riducono a soli 2x128 bit; ossia NV3x può gestire solo due vettori completi per ciclo, per ogni pipeline. Al contrario, R3x0 ha l'equivalente di 12 registri a 32 bit; utilizzando fp24, questo si traducoe in 4 gruppi di registri a 128; quindi, R3x0 può elaborare, per ogni ciclo, 4 vettori completi per pipeline.

Quindi ne r300 ne nv30 sono pienamente compatibili dx 9 sm 2.0.
Inoltre noto che in fp16 nv30 ha poi gli stessi registri temporanei di r300.
Grazie delle info comunque.

Pk77

no, l'R3x0 è sm2.0 (ha 12 registri a 32 bit, anzi, per l'esattezza, ne ha 24 da 16 bit.
Si, in fp16 la situazione per NV3x migliora decisamente, per quanto riguarda la quantità dei dati immagazzinabili nei registri temporanei: l'unico handicap resta la dipendenza tra tmu e alu principale che, soprattutto con NV30, NV31 e NV34, rende praticamente inutilizzabile la notazione in floating point. Da NV35 in poi, invece, anche se in fp16 i chip NV restano lontani dalla velocità di elaborazione in fx, però in alcuni casi rendono fruibile l'uso dei calcoli in floating point (anche se nelle indicazioni di NV si sconsiglia il ricorso a fp16 se non nei casi in cui non se ne può fare a meno; questa controindicazione è sparita da NV40 in poi, con cui si consiglia l'uso di fp16 ma per altri motivi, non legati alle carenze di registri temporanei; per l'esattezza perchè i chip NV40 e G70 hanno un circuito che si occupa di normalizzazione di vettori, che però funziona solo in fp16, mentre viene disabilitato in fp32; questo circuito di normalizzazione esegue, in un solo ciclo, una serie di operazioni che, se dovessero essere eseguite dai ps, richiederebbero lo spreco di un paio di cicli di clock).

[Pat77]

no, l'R3x0 è sm2.0 (ha 12 registri a 32 bit, anzi, per l'esattezza, ne ha 24 da 16 bit.
Si, in fp16 la situazione per NV3x migliora decisamente, per quanto riguarda la quantità dei dati immagazzinabili nei registri temporanei: l'unico handicap resta la dipendenza tra tmu e alu principale che, soprattutto con NV30, NV31 e NV34, rende praticamente inutilizzabile la notazione in floating point. Da NV35 in poi, invece, anche se in fp16 i chip NV restano lontani dalla velocità di elaborazione in fx, però in alcuni casi rendono fruibile l'uso dei calcoli in floating point (anche se nelle indicazioni di NV si sconsiglia il ricorso a fp16 se non nei casi in cui non se ne può fare a meno; questa controindicazione è sparita da NV40 in poi, con cui si consiglia l'uso di fp16 ma per altri motivi, non legati alle carenze di registri temporanei; per l'esattezza perchè i chip NV40 e G70 hanno un circuito che si occupa di normalizzazione di vettori, che però funziona solo in fp16, mentre viene disabilitato in fp32; questo circuito di normalizzazione esegue, in un solo ciclo, una serie di operazioni che, se dovessero essere eseguite dai ps, richiederebbero lo spreco di un paio di cicli di clock).


quindi ricapitorlando:

r3xx 24 registri a 16 bit x fp 24= 4 vettori
nv3x 32 registri a 8 bit x fp32= 2 vettori
nv3x 32 registri a 8 bit x fp16= 4 vettori

Riguardo all'uso di fp16 sapevo che carmack la utilizzava preferibilmente, passando a 32 solo dove serviva.
Così come valve inizialmente.

Pk77

[shodan]

4 tmu vengono perse; tra l'altro, la Perhelia è un chip ben strano: ha 4 tmu ed è compatibile con lo sm1.3 (e non con l'1.4), però ha un numero di stadi di psu decisamente superiore a quello dei chip sm1.3 e 1.4 (NV2x e R200), un numero di registri temporanei pari a 12, da 32 bit ciascuno (come un chip sm2.0) e ha le pixel pipeline riconfigurabili in modo tale da arrivare a 10 unità in serie, come se dovesse far fronte a chissà quale mole di calcoli (situazione piuttosto anomala per lo sm1.3). Le pixel pipeline così lunghe, tra le altre cose, risultano anche meno effiicenti rispetto a quelle più corte di NV2x e R200, quando si tratta di elaborare shader con poche istruzioni (cosa abbastanza normale per lo sm1.3).
Quindi è un chip che si può definire "ibrido" a tutti gli effetti; volendo fare una battuta, sembrerebbe quasi che i progettisti, fino all'ultimo, non avessero le ideee chiare sulla tipologia di chip da realizzare :D

Già, si è rivelato davvero un chip ibrido.
Alla fine però, anche per questo motivo, non è riuscito a eccellere né del calcolo PS 1.x né 2.x.

Ciao. :)

[Murakami]

Già, si è rivelato davvero un chip ibrido.
Alla fine però, anche per questo motivo, non è riuscito a eccellere né del calcolo PS 1.x né 2.x.

Ciao. :)
Beh, il calcolo PS2 non lo può eseguire, altro che eccellere... :stordita:

[yossarian]

quindi ricapitorlando:

r3xx 24 registri a 16 bit x fp 24= 4 vettori
nv3x 32 registri a 8 bit x fp32= 2 vettori
nv3x 32 registri a 8 bit x fp16= 4 vettori

Riguardo all'uso di fp16 sapevo che carmack la utilizzava preferibilmente, passando a 32 solo dove serviva.
Così come valve inizialmente.

Pk77

in realtà in Doom3 si fa poco uso anche di fp16 a cui si preferisce lo sm1.x e le operazioni matematiche sono, nella maggior parte dei casi, sostituite da operazioni di texture fetch (valori precalcolati e inviati in forma di tabelle di dati). Questo perchè Carmack, per sua stessa ammissione, ha utilizzato, come base di sviluppo, proprio l'NV30 che non ha elevate capacità matematiche ma eccelle nelle operazioni di texturing dove, invece, i chip ATi hanno dei limiti (sia R3x0 che R4x0 riescono ad essere efficienti solo per 4 operazioni consecutive di dependent texture read, raggiungendo il valore massimo nella velocità di esecuzione con 2 operazioni successive; al contrario, i chip NV restano efficienti per un numero molto più elevato di operazioni di dependent texture read, da cui traggono innegabili vantaggi)

[yossarian]

Beh, il calcolo PS2 non lo può eseguire, altro che eccellere... :stordita:

infatti; è per questo che l'ho definito un chip ibrido: ha lo stesso numero di registri temporanei di un chip dx9 nelle pixel pipeline, ha vsu teoricamente compatibili con lo sm2.0, ma poi arriva a sole 4 operazioni di texturing per ciclo (contro le 16 previste dallo sm2.0) e non ha unità di calcolo in grado di eseguire operazioni in fp, ma solo in fx con precisione che arriva fino a 16 bit

[Murakami]

"Gun Metal" è, credo, l'unico gioco che usa VS 2.0 e PS 1.3: peccato che Matrox si sia sempre rifiutata di attivare i VS 2.0 nei driver e, addirittura, di produrre un driver DX9 compatibile... :rolleyes:

[Pat77]

Quello che è successo durante lo sviluppo di Doom3 è stato, per stessa ammissione di Carmack:

Yes. NV30 class hardware can run the ARB2 path that uses ARB_fragment_program, but it is very slow, which is why I have a separate NV30 back end that uses NV_fragment_program to specify most of the operations as 12 or 16 bit instead of 32 bit.

Quindi fx e fp16.

E ancora:

The R200 path has a slight speed advantage over the ARB2 path on the R300, but only by a small margin, so it defaults to using the ARB2 path for the quality improvements. The NV30 runs the ARB2 path MUCH slower than the NV30 path. Half the speed at the moment. This is unfortunate, because when you do an exact, apples-to-apples comparison using exactly the same API, the R300 looks twice as fast, but when you use the vendor-specific paths, the NV30 wins.

Alla fine dello sviluppo, però:

1) There is word that you have removed the NV30-specific rendering path
2) The reason for the above is apparently because NVIDIA's drivers have improved to the point where NV3x hardware are running the standard ARB2 path at about equal speed with the NV30-specific path

Could you say if the above is true?

Correct.

Quindi, arb2 = a nv30 path, quello che mi sono sempre chiesto è come si sia giunti a un risultato simile, vorrei qualcosa di più corposo dei sospetti di replacement ;)

Pk77

[yossarian]

Quello che è successo durante lo sviluppo di Doom3 è stato, per stessa ammissione di Carmack:

Yes. NV30 class hardware can run the ARB2 path that uses ARB_fragment_program, but it is very slow, which is why I have a separate NV30 back end that uses NV_fragment_program to specify most of the operations as 12 or 16 bit instead of 32 bit.

Quindi fx e fp16.

E ancora:

The R200 path has a slight speed advantage over the ARB2 path on the R300, but only by a small margin, so it defaults to using the ARB2 path for the quality improvements. The NV30 runs the ARB2 path MUCH slower than the NV30 path. Half the speed at the moment. This is unfortunate, because when you do an exact, apples-to-apples comparison using exactly the same API, the R300 looks twice as fast, but when you use the vendor-specific paths, the NV30 wins.

Alla fine dello sviluppo, però:

1) There is word that you have removed the NV30-specific rendering path
2) The reason for the above is apparently because NVIDIA's drivers have improved to the point where NV3x hardware are running the standard ARB2 path at about equal speed with the NV30-specific path

Could you say if the above is true?

Correct.

Quindi, arb2 = a nv30 path, quello che mi sono sempre chiesto è come si sia giunti a un risultato simile, vorrei qualcosa di più corposo dei sospetti di replacement ;)

Pk77

non sono sospetti e quello che hai postato era già noto a tutti qui dentro; oltretutto non corrisponde a verità, anche perchè quando è stato sviluppato doom le specifiche arb non erano ancora state ratificate dal GLBoard. ARB2 non ha niente a che vedere con la path NV3x e doom3 è stato sviluppato sulla base di quelli che erano i punti di forza di NV30 (quindi molte stencil shadow, molte operazioni di texturing, niente o quasi niente fp16 e calcoli in fx12. Tra l'altro, la frase evidenziata dimostra proprio il contrario; e cioè che ARB2 non c'entra niente con NV30 path (che invece è stata, alla fine, la base di sviluppo del motore grafico del gioco).

Questa intervista, molto più recente (risale a pochi giorni fa) dimostra come Carmack si sia regolato per sviluppare l'engine di doom3

id Software's John Carmack has often commented that his engines target a particular feature set of a graphics board and he uses a certain boards for his primary development; for instance the Doom3 engine was initially targeted towards the features enabled by the GeForce 256 series of graphics processors, but overtime that was incremented to DirectX8 and 9 level boards, with NVIDIA's 5800 (NV30) being his primary development platform for a while. What has always been clear is that the PC, and the capabilities of PC graphics, was id's primary target market and development platform. From John's keynote speech, transcribed here by Beyond3D forum member aaaaa00, it would appear that this is likely to change, in the interim at least:

questo chiarisce il motivo per cui Doom3 vada così bene con chip NV e molto meno bene con la concorrenza.
Come vedi, si tratta di qualcosa di più di sospetti di replacement: si tratta della certezza che un motore grafico è stato "ritagliato" appositamente sulle specifiche di un chip in particolare. Questo significa che non è possibile utilizzare doom e derivati come parametri per le prestazioni OGL, semplicemente perchè non si tratta di OpenGL (in quel caso si sarebbero dovute utilizzare specifiche ARB e non feature basate sulle caratteristiche di un particolare chip o, addirittura, estensioni proprietarie NV).

Nell'intervista da te postata (per altro molto vecchia), Carmack ammette che con ARB2 l'R300 è il doppio più veloce di NV30. Ora, ARB è lo standard OpenGL. Domanda: perchè non è stato utilizzato uno standard OpenGL ma si è sviluppato il gioco prendendo come riferimento la path NV30 (come dimostra l'intervista successiva che ho postato)?

[Pat77]

oltretutto non corrisponde a verità, anche perchè quando è stato sviluppato doom le specifiche arb non erano ancora state ratificate dal GLBoard. ARB2 non ha niente a che vedere con la path NV3x e doom3 è stato sviluppato sulla base di quelli che erano i punti di forza di NV30

Premetto che queste sono parole di Carmack, e i suoi post me li sono letti tutti: era sì basato su Nv10 inizialmente, poi su nv25, presentato su r300, ritornato poi a dare il meglio su nv30.
Non mi pare che le sue dichiarazioni siano di parte, non avrebbe dichiarato che inizialmente con arb2 r300 andava il doppio, ne' che con r200 faceva tutto in una passata.
E' stato scelto nv30 per due motivi semplici: ai tempi nvidia dava più sicurezze e aveva driver opengl decisamente più maturi, tanto da considerarli golden sample in più di un'intervista.
Come oggi preferisce il 360, probabilmente per una questione di durabilità, sarà, infatti, la geforce 256 del 2005.

Tra l'altro, la frase evidenziata dimostra proprio il contrario; e cioè che ARB2 non c'entra niente con NV30 path (che invece è stata, alla fine, la base di sviluppo del motore grafico del gioco

Appunto, nv fragment o nv30 path erano modalità studiate per sfruttare nv3x nelle sue peculiarità, mentre arb e poi arb2 erano modelli leggermente più qualitativi, che risultavano molto più veloci su r3xx.
E' poi stato eliminato nv30 path per standarizzare tutti su arb2, che si differenzia dalla modalità nv per la fp32. (NV_fragment_program to specify most of the operations as 12 or 16 bit instead of 32 bit)
Mi scuso per essere andato off topic, direi di ritornare it, dopo un'eventuale risposta ;)

Pk77

[yossarian]

Premetto che queste sono parole di Carmack, e i suoi post me li sono letti tutti: era sì basato su Nv10 inizialmente, poi su nv25, presentato su r300, ritornato poi a dare il meglio su nv30.
Non mi pare che le sue dichiarazioni siano di parte, non avrebbe dichiarato che inizialmente con arb2 r300 andava il doppio, ne' che con r200 faceva tutto in una passata.
E' stato scelto nv30 per due motivi semplici: ai tempi nvidia dava più sicurezze e aveva driver opengl decisamente più maturi, tanto da considerarli golden sample in più di un'intervista.
Come oggi preferisce il 360, probabilmente per una questione di durabilità, sarà, infatti, la geforce 256 del 2005.



focalizza l'attenzione su queste due frasi evidenziate: con ARB2 R300 è il doppio più veloce di NV30; i driver NV in OGL erano più maturi e affidabili.
Se i driver nVIDIA erano più maturi, come mai con ARB2 (che, ripeto, è lo standard OpenGl) NV30 era veloce la metà di R300?


Appunto, nv fragment o nv30 path erano modalità studiate per sfruttare nv3x nelle sue peculiarità, mentre arb e poi arb2 erano modelli leggermente più qualitativi, che risultavano molto più veloci su r3xx.
E' poi stato eliminato nv30 path per standarizzare tutti su arb2, che si differenzia dalla modalità nv per la fp32. (NV_fragment_program to specify most of the operations as 12 or 16 bit instead of 32 bit)
Mi scuso per essere andato off topic, direi di ritornare it, dopo un'eventuale risposta ;)

Pk77

arb non è un modello più o meno qualitativo: è lo standard OpenGL. La path NV30 non è standard OpenGL ma un adattamento del motore grafico alle caratteristiche di NV30.
Al contrario: non è stata eliminata la path NV30 e non è stato standardizzato il gioco su ARB2. ARB2 prevede fp32/fp16 mentre doom non fa uso di fp32 (e raramente di fp16). Quello che è stata eliminato è stato proprio ARB2 (con cui doom ha molto poco a che vedere) ed è stata adottata come standard una path NV30 leggermente modificata che di ARB2 non è nemmeno lontana parente.

Infine, non è un mistero che in tutti i giochi o i test che fanno uso di calcoli in fp, l'intera serie NV3x e, in particolare NV30, NV31 e NV34, fanno application detect e shader replacement, facendo uso di sm1.3 (basta utilizzare un semplice SW di antidetect per accorgersene)

[yossarian]

Premetto che queste sono parole di Carmack, e i suoi post me li sono letti tutti: era sì basato su Nv10 inizialmente, poi su nv25, presentato su r300, ritornato poi a dare il meglio su nv30.
Non mi pare che le sue dichiarazioni siano di parte, non avrebbe dichiarato che inizialmente con arb2 r300 andava il doppio, ne' che con r200 faceva tutto in una passata.
E' stato scelto nv30 per due motivi semplici: ai tempi nvidia dava più sicurezze e aveva driver opengl decisamente più maturi, tanto da considerarli golden sample in più di un'intervista.
Come oggi preferisce il 360, probabilmente per una questione di durabilità, sarà, infatti, la geforce 256 del 2005.



focalizza l'attenzione su queste due frasi evidenziate: con ARB2 R300 è il doppio più veloce di NV30; i driver NV in OGL erano più maturi e affidabili.
Se i driver nVIDIA erano più maturi, come mai con ARB2 (che, ripeto, è lo standard OpenGl) NV30 era veloce la metà di R300?


Appunto, nv fragment o nv30 path erano modalità studiate per sfruttare nv3x nelle sue peculiarità, mentre arb e poi arb2 erano modelli leggermente più qualitativi, che risultavano molto più veloci su r3xx.
E' poi stato eliminato nv30 path per standarizzare tutti su arb2, che si differenzia dalla modalità nv per la fp32. (NV_fragment_program to specify most of the operations as 12 or 16 bit instead of 32 bit)
Mi scuso per essere andato off topic, direi di ritornare it, dopo un'eventuale risposta ;)

Pk77

arb non è un modello più o meno qualitativo: è lo standard OpenGL. La path NV30 non è standard OpenGL ma un adattamento del motore grafico alle caratteristiche di NV30.
Al contrario: non è stata eliminata la path NV30 e non è stato standardizzato il gioco su ARB2. ARB2 prevede fp32/fp16 mentre doom non fa uso di fp32 (e raramente di fp16). Quello che è stata eliminato è stato proprio ARB2 (con cui doom ha molto poco a che vedere) ed è stata adottata come standard una path NV30 leggermente modificata.

Why do you have NV30-specific code paths and none for the R300?

There aren't any R300-specific fragment extensions, so I really can't make an R300-specific back end. I do support their two sided stencil extension (unfortunately, slightly different than NVIDIA's...), which is orthogonal to the back end selection.

questo è quello che Carmack ha risposto alla domanda: perchè non ha utilizzato una path R300. La risposta è molto chiara: perchè non ci sono estensioni specifiche per R300. Questo, inplicitamente, significa ammettere di aver utilizzato estensioni specifiche per NV30, non necessariamente facenti parte dello standard ARB.

[Pat77]

focalizza l'attenzione su queste due frasi evidenziate: con ARB2 R300 è il doppio più veloce di NV30; i driver NV in OGL erano più maturi e affidabili.

Certo da sempre offrono un supproto ottimo all'open-gl, in parte ereditato da 3dfx, Doom3 fu pensato per essere eseguito con path specifico, anche io penso che alla fine fine si sia giunti a un compromesso a metà strada tra nv3x e arb2.

"Nvidia’s OpenGL drivers are my “gold standard", and it has been quite a while..."]

"When I have a problem on an Nvidia, I assume that it is my fault. With anyone else’s drivers, I assume it is their fault. "

Al contrario: non è stata eliminata la path NV30 e non è stato standardizzato il gioco su ARB2. ARB2 prevede fp32/fp16 mentre doom non fa uso di fp32 (e raramente di fp16). Quello che è stata eliminato è stato proprio ARB2 (con cui doom ha molto poco a che vedere) ed è stata adottata come standard una path NV30 leggermente modificata.

Questo è il mio sospetto, anche se non ho materiale per sostenere questa tesi.

Pk77

[BloodFlowers]

..in poche parole per non leggere tutto quali sono le possibili modifiche ed overclocking e modding della geffo3 Ti500?

..una sorta di sintesi anche dei driver migliori insomma..grazie

[Murakami]

..in poche parole per non leggere tutto quali sono le possibili modifiche ed overclocking e modding della geffo3 Ti500?

..una sorta di sintesi anche dei driver migliori insomma..grazie
In poche parole, in questo thread si è parlato di tutt'altro... :fagiano:

[Franx1508]

..in poche parole per non leggere tutto quali sono le possibili modifiche ed overclocking e modding della geffo3 Ti500?

..una sorta di sintesi anche dei driver migliori insomma..grazie
io andrei di ultimi ufficiali...sono più nuovi della versione che ho usato nei test.