NV40 in dettaglio: parte 1 e 2.

[Murakami]

http://www.3dcenter.org/artikel/nv40...ne/index_e.php

Scommetto che questo topic resterà deserto...

[beppe]

sbagliato.....io sto leggendo l' articolo

[beppe]

era meglio se non lo leggevo....l'ennesima presa per i fondelli

[giampa]

http://www.3dcenter.org/artikel/nv40_pipeline/index_e.php

Scommetto che questo topic resterà deserto...

forse xchè anke a sto giro Nvidia si è arrampicata sugli specchi x stare dietro ad Ati ?

[beppe]

senza il forse

[swarzy85]

dopo due pagine mi ha già fatto a pezzi..... :
me lo rileggo sabato con più calma

[Murakami]

Le ultime 2 pagine sono molto più semplici e le puoi leggere separatamente dalle prime tre...

[yossarian]

NV40 è un chip diverso da NV3x sotto molti aspetti; purtroppo non lo è nella dipendenza tra tmu e alu (e il risultato, nonostante ciò che dicono quelli di 3DCenter) è sotto gli occhi di tutti con la mappa "canals" di HL2.
Tra l'altro, non so da dove possano aver tratto alcune informazioni, tipo la pipeline a 256 stadi e i 256 quad per pipeline (l'insiame delle pixel pipeline di NV40 ha registri temporanei per gestire non più di 512 variabili fp32 o 1024 fp16 in contemporanea e 256 stadi sono un'assurdità a livello progettuale, sia per il rischio di propagazione di "bolle" che nel caso di salti condizionati; le unità pixel shader di R200, tanto per dare un'idea, hanno 7 stadi e quelle di NV25 addirittura 4).

Per il resto, l'articolo è abbastanza interessante e dettagliato. Sulle cosiddette mini-alu il discorso è piuttosto complesso e le conclusioni a cui salta 3DCenter non sono del tutto corrette (le mini-alu dei chip R3x0, NV35, R420 e NV40 sono del tutto assimilabili ed è sbagliato considerare i chip NV come aventi una doppia unità di calcolo per fp per pipeline e i chip ATi come se ne avessero una sola (oltretutto le mini-alu si sono viste, per la prima volta, su R300 e l'idea è stata ripresa per NV35).

[Murakami]

Ben tornato! Sempre potente a quanto vedo!
Che succede nella mappa "Canals" di HL2 ai chip nVidia?

[yossarian]

Ben tornato! Sempre potente a quanto vedo!
Che succede nella mappa "Canals" di HL2 ai chip nVidia?

http://www.hwupgrade.it/articoli/1127/9.html

questi sono i risultati di HWUpgrade (ho vidìsto altrre recensioni e la situazione cambia di poco); come puoi vedere, le prestazioni della 6800 ultra sono allineate a quelle della 9800XT. Secondo me c'è una sola possibile spiegazione: i due chip, che hanno una frequenza molto prossima, compiono lo stesso numero di operazioni per ciclo; la spiegazine che più mi ha convinto finora è questa


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

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