SILENZIO PARLA John Carmack (DOOM3)

[Asy]

Name: John Carmack Email: Description: Programmer Project: ------------------------------------------------------------------------------- Jan 29, 2003 ------------ NV30 vs R300, current developments, etc At the moment, the NV30 is slightly faster on most scenes in Doom than the R300, but I can still find some scenes where the R300 pulls a little bit ahead. The issue is complicated because of the different ways the cards can choose to run the game. The R300 can run Doom in three different modes: ARB (minimum extensions, no specular highlights, no vertex programs), R200 (full featured, almost always single pass interaction rendering), ARB2 (floating point fragment shaders, minor quality improvements, always single pass). The NV30 can run DOOM in five different modes: ARB, NV10 (full featured, five rendering passes, no vertex programs), NV20 (full featured, two or three rendering passes), NV30 ( full featured, single pass), and ARB2. 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. The reason for this is that ATI does everything at high precision all the time, while Nvidia internally supports three different precisions with different performances. To make it even more complicated, the exact precision that ATI uses is in between the floating point precisions offered by Nvidia, so when Nvidia runs fragment programs, they are at a higher precision than ATI's, which is some justification for the slower speed. Nvidia assures me that there is a lot of room for improving the fragment program performance with improved driver compiler technology. The current NV30 cards do have some other disadvantages: They take up two slots, and when the cooling fan fires up they are VERY LOUD. I'm not usually one to care about fan noise, but the NV30 does annoy me. I am using an NV30 in my primary work system now, largely so I can test more of the rendering paths on one system, and because I feel Nvidia still has somewhat better driver quality (ATI continues to improve, though). For a typical consumer, I don't think the decision is at all clear cut at the moment. For developers doing forward looking work, there is a different tradeoff -- the NV30 runs fragment programs much slower, but it has a huge maximum instruction count. I have bumped into program limits on the R300 already. As always, better cards are coming soon. ------------- Doom has dropped support for vendor-specific vertex programs (NV_vertex_program and EXT_vertex_shader), in favor of using ARB_vertex_program for all rendering paths. This has been a pleasant thing to do, and both ATI and Nvidia supported the move. The standardization process for ARB_vertex_program was pretty drawn out and arduous, but in the end, it is a just-plain-better API than either of the vendor specific ones that it replaced. I fretted for a while over whether I should leave in support for the older APIs for broader driver compatibility, but the final decision was that we are going to require a modern driver for the game to run in the advanced modes. Older drivers can still fall back to either the ARB or NV10 paths. The newly-ratified ARB_vertex_buffer_object extension will probably let me do the same thing for NV_vertex_array_range and ATI_vertex_array_object. Reasonable arguments can be made for and against the OpenGL or Direct-X style of API evolution. With vendor extensions, you get immediate access to new functionality, but then there is often a period of squabbling about exact feature support from different vendors before an industry standard settles down. With central planning, you can have "phasing problems" between hardware and software releases, and there is a real danger of bad decisions hampering the entire industry, but enforced commonality does make life easier for developers. Trying to keep boneheaded-ideas-that-will-haunt-us-for-years out of Direct-X is the primary reason I have been attending the Windows Graphics Summit for the past three years, even though I still code for OpenGL. The most significant functionality in the new crop of cards is the truly flexible fragment programming, as exposed with ARB_fragment_program. Moving from the "switches and dials" style of discrete functional graphics programming to generally flexible programming with indirection and high precision is what is going to enable the next major step in graphics engines. It is going to require fairly deep, non-backwards-compatible modifications to an engine to take real advantage of the new features, but working with ARB_fragment_program is really a lot of fun, so I have added a few little tweaks to the current codebase on the ARB2 path: High dynamic color ranges are supported internally, rather than with post-blending. This gives a few more bits of color precision in the final image, but it isn't something that you really notice. Per-pixel environment mapping, rather than per-vertex. This fixes a pet-peeve of mine, which is large panes of environment mapped glass that aren't tessellated enough, giving that awful warping-around-the-triangulation effect as you move past them. Light and view vectors normalized with math, rather than a cube map. On future hardware this will likely be a performance improvement due to the decrease in bandwidth, but current hardware has the computation and bandwidth balanced such that it is pretty much a wash. What it does (in conjunction with floating point math) give you is a perfectly smooth specular highlight, instead of the pixelish blob that we get on older generations of cards. There are some more things I am playing around with, that will probably remain in the engine as novelties, but not supported features: Per-pixel reflection vector calculations for specular, instead of an interpolated half-angle. The only remaining effect that has any visual dependency on the underlying geometry is the shape of the specular highlight. Ideally, you want the same final image for a surface regardless of if it is two giant triangles, or a mesh of 1024 triangles. This will not be true if any calculation done at a vertex involves anything other than linear math operations. The specular half-angle calculation involves normalizations, so the interpolation across triangles on a surface will be dependent on exactly where the vertexes are located. The most visible end result of this is that on large, flat, shiny surfaces where you expect a clean highlight circle moving across it, you wind up with a highlight that distorts into an L shape around the triangulation line. The extra instructions to implement this did have a noticeable performance hit, and I was a little surprised to see that the highlights not only stabilized in shape, but also sharpened up quite a bit, changing the scene more than I expected. This probably isn't a good tradeoff today for a gamer, but it is nice for any kind of high-fidelity rendering. Renormalization of surface normal map samples makes significant quality improvements in magnified textures, turning tight, blurred corners into shiny, smooth pockets, but it introduces a huge amount of aliasing on minimized textures. Blending between the cases is possible with fragment programs, but the performance overhead does start piling up, and it may require stashing some information in the normal map alpha channel that varies with mip level. Doing good filtering of a specularly lit normal map texture is a fairly interesting problem, with lots of subtle issues. Bump mapped ambient lighting will give much better looking outdoor and well-lit scenes. This only became possible with dependent texture reads, and it requires new designer and tool-chain support to implement well, so it isn't easy to test globally with the current Doom datasets, but isolated demos are promising. The future is in floating point framebuffers. One of the most noticeable thing this will get you without fundamental algorithm changes is the ability to use a correct display gamma ramp without destroying the dark color precision. Unfortunately, using a floating point framebuffer on the current generation of cards is pretty difficult, because no blending operations are supported, and the primary thing we need to do is add light contributions together in the framebuffer. The workaround is to copy the part of the framebuffer you are going to reference to a texture, and have your fragment program explicitly add that texture, instead of having the separate blend unit do it. This is intrusive enough that I probably won't hack up the current codebase, instead playing around on a forked version. Floating point framebuffers and complex fragment shaders will also allow much better volumetric effects, like volumetric illumination of fogged areas with shadows and additive/subtractive eddy currents. John Carmack

BAHH

[Maury]

Uhhhh vedo che il buon John sta tirando i remi in barca in merito all'FX...il rumore lo infastidisce poi

[Cfranco]

Quindi tutti i fan Nvidia si mettano il cuore in pace , la FX non distruggerà la 9700 neppure in Doom III .

PS

DST che fine ha fatto ?

[Jo3]

Originally posted by "Cfranco"

Quindi tutti i fan Nvidia si mettano il cuore in pace , la FX non distruggerà la 9700 neppure in Doom III .

PS

DST che fine ha fatto ?

Hai dato un occhiata all'AA della FX?

[Maury]

Ecco l'AA:

9700 6x



FX 8x



ig:

[Maury]

Ecco le foto originali:


9700


http://www.hardocp.com/images/articles/10436208595cUSd31HIx_5_14_l.jpg


FX

http://www.hardocp.com/images/articles/10436208595cUSd31HIx_5_13_l.jpg

Rimaniamo in attesa di delucidazioni sulla cattura dei frame dal frame buffer dell'FX, per ora la qualità è questa ...

[LightIntoDarkness]

E'allucinante, non può essere così bassa la qualità dell'AA 8X!

[Simon82]

Originally posted by "Maury"

Ecco l'AA:

9700 6x



FX 8x



ig:

L'8x e' quello?

[Simon82]

Originally posted by "Maury"

Ecco le foto originali:


9700


http://www.hardocp.com/images/articles/10436208595cUSd31HIx_5_14_l.jpg


FX

http://www.hardocp.com/images/articles/10436208595cUSd31HIx_5_13_l.jpg

Rimaniamo in attesa di delucidazioni sulla cattura dei frame dal frame buffer dell'FX, per ora la qualità è questa ...

Non ma non sono giusti... sono venuti male perche' il gatto di HardOCP aveva il mal di testa. Dagli il tempo di modificarle con paint shop e vedrai che splendore..

[Cifer]

Traduzione automatica:

Nome: Email Del John Carmack: Descrizione: Progetto Del Programmatore: 29 gennaio 2003 NV30 contro R300, sviluppi correnti, ecc al momento, il NV30 è un po'più veloce sulla maggior parte delle scene nella sorte avversa che il R300, ma posso ancora trovare alcune scene dove il R300 tira una punta piccola avanti. L'edizione è complicata a causa dei sensi che differenti le schede possono scegliere per fare funzionare il gioco. Il R300 può fare funzionare la sorte avversa in tre modi differenti: ARB (estensioni minime, nessun punti culminanti speculari, nessun programmi di vertice), interazione del passaggio in pieno descritto e quasi sempre singolo di R200 (che rende), ARB2 (shaders del frammento della virgola mobile, miglioramenti di qualità secondari, passaggio sempre singolo). Il NV30 può fare funzionare la SORTE AVVERSA in cinque modi differenti: Passaggi di rappresentazione in pieno descritti e cinque di ARB, passaggi (di rappresentazione) in pieno descritti, due o tre di NV10 (, nessun programmi di vertice), di NV20, NV30 (passaggio in pieno caratterizzato e singolo) ed ARB2. Il percorso R200 presenta un vantaggio leggero di velocità sopra il percorso ARB2 sul R300, ma soltanto da un piccolo margine, in modo da stabilizza a per mezzo del percorso ARB2 per i miglioramenti di qualità. Il NV30 fa funzionare il percorso ARB2 MOLTO più lento del percorso NV30. Metà di velocità al momento. Ciò è sfavorevole, perché quando fate un esatto, il confronto delle mela-$$$-mele usando esattamente lo stesso api, il R300 osserva due volte veloce, ma quando utilizzate i percorsi fornitore-specifici, il NV30 vince. Il motivo per questo è che ATI fa tutto ad alta precisione tutto il tempo, mentre Nvidia internamente sostiene tre precisioni differenti con differenti prestazioni. Farlo ancor più complicato, la precisione esatta che ATI usa è fra le precisioni della virgola mobile offerte da Nvidia, in modo da quando Nvidia fa funzionare i programmi del frammento, è ad un'più alta precisione che ATI, che è una certa giustificazione per la bassa velocità. Nvidia lo assicura che ci è a.lot di stanza per migliorare le prestazioni di programma del frammento con tecnologia migliorata del compilatore del driver. Le schede correnti NV30 presentano alcuni altri svantaggi: Prendono due scanalature e quando i fuochi del ventilatore in su sono MOLTO FORTI. Non sono solitamente uno da preoccuparsi per rumore del ventilatore, ma il NV30 lo infastidisce. Ora sto usando un NV30 nel mio sistema primario del lavoro, in gran parte in modo da posso esaminare più dei percorsi di rappresentazione su un sistema e perché ritengo Nvidia ancora ha qualità piuttosto migliore del driver (ATI continua a migliorare, benchè). Per un consumatore tipico, non penso la decisione sono al taglio tutto il chiaro al momento. Per gli sviluppatori che fanno in avanti osservare lavoro, ci è un'alternanza differente -- NV30 i programmi del frammento di funzionamenti molto più lenti, ma esso ha un conteggio massimo enorme di istruzione. Ho urtato già nei limiti di programma sul R300. Come sempre, le schede migliori stanno venendo presto. La sorte avversa ha caduto il sostegno i programmi fornitore-specifici di vertice (NV_vertex_program ed EXT_vertex_shader), per usando ARB_vertex_program per tutti i percorsi di rappresentazione. Ciò è stata una cosa piacevole da fare e sia ATI che Nvidia hanno sostenuto il movimento. Il processo di normalizzazione per ARB_vertex_program era grazioso disegnato fuori ed arduo, ma alla fine, è un api appena-normale-migliore che uno dello specific del fornitore un che abbia sostituito. Mi sono corroso per un'eccedenza di istante se dovrei lasciare nel sostegno il più vecchio APIs per la più vasta compatibilità del driver, ma la decisione finale era che stiamo andando richiedere ad un driver moderno per il gioco di funzionare nei modi avanzati. I più vecchi driver possono ancora cadere di nuovo i percorsi a ARB o a NV10. L'estensione nuovo-ratificata di ARB_vertex_buffer_object probabilmente lo ha lasciato fare la stessa cosa per NV_vertex_array_range ed ATI_vertex_array_object. Le discussioni ragionevoli possono essere fatte per e contro il OpenGL o Dirigono -X lo stile di sviluppo di api. Con le estensioni del fornitore, ottenete l'accesso immediato a nuova funzionalità, ma allora ci è spesso un periodo di baruffe circa il supporto esatto della caratteristica dai fornitori differenti prima di un'industria standard si deposita giù. Con la progettazione centrale, potete avere "mettere i problemi in fase" fra fissaggi ed i rilasci di software e ci è un pericolo reale delle decisioni difettose che impediscono la l'intera industria, ma la comunanza fatta rispettare rende la vita più facile per gli sviluppatori. Provando a mantenere gli boneheaded-idea-che-$$$-frequent-noi-per-anni da Diriga -X è il motivo che principale sto assistendo alla sommità dei grafici di Windows per gli ultimi tre anni, anche se ancora codifico per OpenGL. La funzionalità più significativa nel nuovo raccolto delle schede è il frammento vero flessibile che si programma, come esposto con ARB_fragment_program. Muovendosi "dallo stile delle manopole e degli interruttori" dei grafici funzionali discreti che si programmano verso la programmazione generalmente flessibile con il indirection e l'alta precisione è che cosa sta andando permettere il punto principale seguente in motori dei grafici. Sta andando richiedere le modifiche ragionevolmente profonde e non-indietro-compatibili ad un motore per trarre vantaggio reale dalle nuove caratteristiche, ma funzionare con ARB_fragment_program è realmente a.lot di divertimento, in modo da ho aggiunto alcun piccolo tweaks al codebase corrente sul percorso ARB2: Le alte gamme dinamiche di colore sono sostenute internamente, piuttosto che con il alberino-mescolamento. Ciò dà alcuni più punte di precisione di colore nell'immagine finale, ma non è qualcosa quella voi realmente avviso. ambiente del Per-pixel che tracciano, piuttosto che per-vertice. Ciò ripara un animale domestico-peeve di mine, che è grandi lastre di vetro di vetro tracciato ambiente che non sono tessellated abbastanza, dante che effetto terribile di deform-intorno-$$$-warping-around-the-triangulation mentre vi muovete oltre loro. Vettori di vista e della luce normalizzati con per la matematica, piuttosto che un programma del cubo. Su fissaggi futuri questo probabilmente sarà un miglioramento di prestazioni dovuto la diminuzione nella larghezza di banda, ma i fissaggi correnti hanno il calcolo e la larghezza di banda ha equilibrato tali che è molto grazioso una lavata. Che cosa (insieme con per la matematica della virgola mobile) dà siete un punto culminante speculare perfettamente regolare, anziché il blob del pixelish che otteniamo sulle più vecchie generazioni delle schede. Ci sono un po'più di cose che sto giocando intorno con, quello probabilmente rimarrà nel motore come novità, ma nelle caratteristiche non sostenute: calcoli di vettore di riflessione del Per-pixel per speculare, anziché un metà-angolo interpolato. L'unico effetto restante che ha tutta la dipendenza visiva dalla geometria underlying è la figura del punto culminante speculare. Nel migliore dei casi, desiderate la stessa immagine finale per una superficie senza riguardo a se è due triangoli giganti, o una maglia di 1024 triangoli. Ciò non sarà allineare se qualunque calcolo fatto ad un vertice coinvolge qualche cosa tranne i funzionamenti lineari di per la matematica. Il calcolo speculare di metà-angolo coinvolge le normalizzazioni, in modo da l'interpolazione attraverso i triangoli su una superficie sarà dipendente sopra esattamente dove i vertici sono individuati. Il risultato finale più visibile di questo è quello sulle grandi, superfici piane e lucide in cui prevedete un cerchio pulito di punto culminante che si muove attraverso esso, voi avvolge in su con un punto culminante che storce in una L figura intorno alla linea di triangulation. Le istruzioni supplementari per effettuare questo hanno avute un colpo notevole di prestazioni ed ero poco sorprendo vedo che i punti culminanti stabilizzati non soltanto nella figura, ma anche affilati abbastanza su una punta, cambiante la scena più dell'io hanno previsto. Ciò probabilmente non è oggi una buona alternanza per un gamer, ma è piacevole per qualunque genere di rappresentazione high-fidelity. Il renormalization dei campioni normali di superficie del programma trasforma i miglioramenti di qualità significativi nelle strutture ingrandite, giranti fortemente, angoli vaghi le tasche lucide e lisce, ma introduce una quantità enorme di aliasing sulle strutture minimizzate. Mescolandosi fra i casi è possibile con i programmi del frammento, ma le spese generali di prestazioni cominciano accatastare in su e possono richiedere stashing alcune informazione nella scanalatura normale dell'alfa del programma che varia con il livello di mip. Fare la buona filtrazione dell'specularly ha illuminato la struttura normale del programma è un problema ragionevolmente interessante, con i lotti delle edizioni sottili. L'illuminazione ambientale tracciata urto darà molto più meglio sembrare scene esterne e ben illuminate. Ciò è diventato soltanto possibile con struttura dipendente legge e richiede il nuovo supporto della attrezzo-catena e del progettista effettuare bene, in modo da non è facile da esaminare globalmente con i gruppi di dati correnti di sorte avversa, ma i demos isolati sono promising. Il futuro è in framebuffer della virgola mobile One of the most noticeable thing this will get you without fundamental algorithm changes is the ability to use a correct display gamma ramp without destroying the dark color precision. Unfortunately, using a floating point framebuffer on the current generation of cards is pretty difficult, because no blending operations are supported, and the primary thing we need to do is add light contributions together in the framebuffer. The workaround is to copy the part of the framebuffer you are going to reference to a texture, and have your fragment program explicitly add that texture, instead of having the separate blend unit do it. This is intrusive enough that I probably won't hack up the current codebase, instead playing around on a forked version. Floating point framebuffers and complex fragment shaders will also allow much better volumetric effects, like volumetric illumination of fogged areas with shadows and additive/subtractive eddy currents. John Carmack

L'ultimo pezzo è inglese perchè babel fish ha il server down...

[Simon82]

Non so perche' ma ogni volta che Carmack apre bocca gli scaraventerei un server in testa..
Non si capisce bene cosa serve parlare in quel modo. Prima dice che che era il TNT a far girare Doom3 nel migliore dei modi.. .. poi ogni anno cambia storiella e ora siamo arrivati a questo.. mah.. fa ridere i polli imho. E' peggio di Mark Rein. :o

[losqualobianco]

La traduzione automatica è a dir poco agghiacciante meglio rileggersi l'originale http://www.shacknews.com/finger/[email protected]

In sostanza L'R300 conviene utilizzarlo alla max qualità (ARB2) in luogo del modo R200 perchè cmq le differenze in prestazioni sono limitate ma la differenza in qualità no.

Per L'NV30 Carmack è un po' titubante perchè utilizzato in ARB2 (massima qualità) risulta molto lento rispetto alla modalità NV30 (half speed).

In sostanza alla qualità massima (ARB2) l'R300 è più veloce dell'NV30, mentre facendo compromessi sulla qualità l'NV30 risulta più veloce.

Alla faccia che l'NV30 era stato progettato senza compromessi, a quanto pare tutte le features di maggior precisione e maggior numero di istruzioni risultano inutilizzabili a causa della lentezza, obbligando ad utilizzarlo in modalità qualitative inferiori

Carmack poi si dilunga sul fatto che ha esaurito le istruzioni da utilizzare dell'R300, sul rumore dell'NV30 ecc. e spera in una nuova generazione di gpu
Questo è tutto matto, ma doom3 quando lo vuol fare uscire? Nel 2004? Nel 2005?
Se aspetta ancora doom3 incomincerà a far compagnia a DukeNukem4Never (che cmq è imbattibile )

[Redvex]

Ma na domanda....... con una gf3 ti 500 gira bene o no?

[losqualobianco]

Originally posted by "Redvex"

Ma na domanda....... con una gf3 ti 500 gira bene o no?

DEVE! Altrimenti a chi lo vuol vendere?

Ovviamente bisognerà accettare dei compromessi (magari nella risoluzione e negli effetti).

C'è anche la modalità NV10 quindi ....

[Redvex]

Se è bello leggero come Mafia non lo compro proprio

[OverClocK79®]

se ci sono già tutte queste modalità al gioko nn manca molto per essere finito.........
qlkuno diceva che usciva il 31 marzo.........
io credo lo vedremo o a giugno o a ottobre novembre........

di + nn avrebbe senso ritardarlo........
1° perchè dovrebbe aggiungere altre istruzioni per skede che a quanto pare NV35 e R350 hanno le stesse feature di quelle che troviamo adesso nei negozi........con solo maggiore potenza di calcolo.........
e che cmq sia R300 che NV30 permettono a DOOM3 di girare nei migliori dei modi tutto a pallettone.........
2° è ORA CHE ESCA!!!!

al massimo può ritardare un po' di + per permettere al mercato di mandare in pensione qlk tnt e G1 in e comprare qlk G4/R9000 in +

BYEZZZZZZZZZz

[Milion]

Spero che l'imperativo "SILENZIO" fosse riferito a Carmak stesso.
Le figure e le dichiarazioni da buffone ancora non hanno dimostrato l'inaffidabilità di sto tizio?

Milio

[Maury]

Quest'uomo è pazzo, ma che la finisca di sparare panzane a destra e a manca :o

Mica vorrà una nuova generazione di GPU per far girare come Dio comando sto giochino!!!

Intanto U2 è uscito..fatti non pugnette

[Cfranco]

Vedrete che come Nvidia gli allungherà qualche soldo tornerà a dire che NV30 é la GPU più bella dell' universo

[Simon82]

Originally posted by "Cfranco"

Vedrete che come Nvidia gli allungherà qualche soldo tornerà a dire che NV30 é la GPU più bella dell' universo

Concordo.. poi sponsorizzera' l'NV35, l'NV40.. l'NV50.. e dira' che la scheda migliore allora sara' l'NV60.. e sperera' in una nuova famiglia di GPU per far girare Doom3.. allora saranno gia uscite 3 alpha rubate (ma ufficiali... ) in cui ci saranno altri 3 quadri.. e allora dara' la colpa ai BitBoys che l'hanno fatta trapelare..


Potrebbe aprire un circo e fare tutto da solo..:o