non è in vendita la piccolina, già ho fatto na faticaccia ad acappararmela da un mio amico gnorri al quale è stata rifilata una FX5200 :sofico:

Sei proprio un amico :D

ah ma lui era contento :D :D

Io nell'armadio ho ancora una Voodoo 1 (Magic 3D) e una GeForce 256 SDR della Creative (la primissima GeForce mai uscita, pagata 550.000 Lire).

Complimenti per i test, davvero interessanti. Mi ricordo che appena uscì Gran Prix Legends, supportava (oltre alla modalità software) solo le 3Dfx in Glide e le Veritè: il tizio che aveva scritto il manuale diceva che, secondo la sua opinione, queste ultime offrivano una qualità di immagine leggermente superiore con il gioco in questione... poi molto tempo dopo uscì la Patch per il D3D. Quanti ricordi.

Già, immagino che le tue argomentazioni siano state le stesse usate da NVIDIA: supporto agli effetti cinematografici avanzati, ecc ecc... salvo poi scoprire che, con quella scheda, abilitando gli shaders il mondo si ferma nel vero senso della parola :D

Sono stato adesso giù nel archivio del ufficio dove ci sono due computer inutilizzati.
Ho avuto pochissimo tempo ma ho +o- identificato le due schede video

1. Una SIS con moduli di memoria di recente concezione (tipo le GeForce 1-2 per intenderci). Aveva solo due moduli. Non sono riuscito a leggere il modello purtroppo ma penso sia più recente di quella testata in questo thread…

2. Una Matrox!! Ha due moduli di memoria + uno slot di espansione…dovrebbe essere una G200 (AGP)

Erano montate rispettivamente su un K6 III+ e su un Athlon K7 (socket non slot)

Stasera parlo col capo e vedo di portarmi tutto a casa :p


P.S. Erano secoli che cercavo una G200!!

Io ce l'ho su un pc buttato(era di mia cugina..un k2-350)...qlc volta fa da server però. :asd:

Rieccomi con altre preziose gemme di verità... :O
Ho rifatto i test con i driver reference per il chip PCX2 (M3D), ma il risultato è scoraggiante: gli fps di "Forsaken" sono si saliti fino a 30.92, ma la qualità d'immagine è pessima (mancano degli effetti luce, oltre ai soliti problemi sull'alpha blending) e non sono riuscito a sistemarla nemmeno smanettando con tutti i parametri che il nuovo pannello di controllo mette a disposizione (strano non ci sia, tra gli altri, un profilo predefinito per Forsaken... :rolleyes: ). Già che c'ero ho provato persino la patch PowerVR per "Half Life", ma anche in questo caso sono rimasto deluso: rendering quadrettoso e assenza totale di lightmap...praticamente il gioco è tutto "grigio". Anche "Shogo" ha dato risultati mediocri: il chip è supportato ma mancano molte modalità di texture blending e permangono gli annosi problemi sulle trasparenze. Bene invece il primo "Jedi Knight" (che gira bene persino con la Mystique, pur se senza bilinear filtering e con alpha stippling anzichè blending), non fosse che alcuni oggetti (che celano chiavi essenziali per il proseguimento del gioco :mad: ) appaiono solidi anzichè trasparenti. Io ho trovato i driver 4.1.2c: se qualcuno ne ha di più recenti è il benvenuto.
Il retrogaming DOS è andato malissimo: Tomb Raider con il Voodoo 2 parte in software (forse il file che ho downlodato è sbagliato: riproverò EDIT IL FILE E' QUELLO GIUSTO NON SO CHE ALTRO FARE), mentre con il Verite 1000 non parte proprio (si spegne lo schermo... :mbe: ). Descent 2, dal canto suo, funziona molto bene con il Voodoo 2 ma il mouse, perfetto in modalità software, non vuole saperne di andare.
Al prossimo post per la comparazione di schede un pò meno vetuste... :O

Ero curioso di provare qualche scheda con la piattaforma Barton 2800+, così ho usato "Quake 2" e "Forsaken" per testare la mitica Parhelia, il GeForce 2 GTS e il Kyro 2.
Questi i risultati di Quake 2 (impossibile applicare la patch 3.20, rovina completamente la compatibilità con chip che non siano nVidia):

Software, 640x40x16: circa 106 fps (risultato coerente con il clock più che doppio rispetto al P3 933).
Parhelia, 640x480x16: 192.2 fps, costanti anche passando a 32 bit (risultato deludente ma, considerando la fama dei driver OpenGL Matrox, credo preventivabile: tenete presente, inoltre, che la Parhelia agisce in questo gioco come una 4x2, incapace di sfruttare le altre 2 unità di texturing per pipe).
GeForce 2 GTS, 640x480x16: 479.8 fps, che passano però a 368.8 semplicemente switchando il desktop a 32 bit (dato che con questo gioco e a questa risoluzione la banda passante non può essere un problema, si conferma l'incapacità di questa architettura di far lavorare tutte le pipeline in modalità 32 bit).
Kyro 2, 640x480x16: 292.4 fps che diventano 283.2 a 32 bit (in linea con le aspettative, così come il modesto calo con il rendering a 32 bit).

Passando invece a Forsaken (testato con il profilo generico per tutte, ma ho verificato che mipmapping e trilinear sono correttamente supportati)...
Software, 640x480x16: 55.36 fps (non so quanto questo risultato sia attendibile, in quanto -inspiegabilmente- con WinXp questa modalità ha grossi problemi di resa visiva, anche usando l'opzione compatibilità Win98).
Parhelia, 640x480x16: 463.54 fps (direi bene, pur potendo contare su una sola TMU su 4!), che diventano 442.90 in 800x600x32 (calo molto moderato, imputabile credo solo alla risoluzione).
GeForce 2 GTS, 640x480x16: 511.30 fps (niente male!), che diventano 323.07 in 800x600x32 (calo vistoso, ancora imputabile al rendering a 32 bit e alle peculiarità dell'architettura NV15).
Kyro 2, 640x480x16: 258.13 fps (pochi! Appare evidente come il chip fosse già massimizzato dal P3 933 -a meno che l'ambiente WinXP non influisca sulle prestazioni di questo vecchio gioco, ma così non sembra dai risultati delle altre schede-, tanto è vero che...), che diventano 148.15 in 800x600x32 (...il calo è molto vistoso salendo moderatamente di risoluzione e, certo, il passaggio a 32 bit non rappresenta un problema per questo chip). Assolutamente da rilevare la superiore qualità d'immagine del Kyro 2 nel rendering a 16 bit: è l'unico che, anche in condizioni di pesante sovrapposizione di più strati di texture -battaglie furibonde con esplosioni fragorose- non esibisce alcun fenomeno di banding.

Avrei voluto fare qualche altro test con i filtri, ma:
1) Il supersampling AA del GeForce 2 GTS non funziona con Forsaken (perfetto, invece, l'FAA della Parhelia :eek: );
2) Sono molto provato... :O

Chiudo con qualche osservazione sul chip Volari, che ho testato con "Half Life", "Jedi Knight" e "Shogo" (oltre alle prove già effettuate nel thread a lui dedicato): complessivamente, mi pare di poter affermare che il driver D3D funziona piuttosto bene (filtri inesistenti a parte), mentre è pessimo quello OpenGL (persino "Half Life" è inguardabile in OpenGL, mentre risulta perfetto in D3D).
Basta, sono stanco, vado in vacanza: provatevelo voi il Voodoo 1... :lamer:

Non voglio le Orchid ticchettanti nel mio PC... :O
Ciao Bescio, basta bere... :D

Uaz Analisi Dettagliatissima come sempre :eek:

Stupefacende vedere la Parhelia Battere la GeForce 2 GTS a 800x600x32 in Forsaken :eek:

Il Chip Kyro risente pokissimo del passaggio da 16bit @ 32bit alla risoluzione di 640X480 in Quake II

Non capisco perke' i test con forsaken invece di farli @ 640X480 16Bit e 640X480 32Bit, li hai fatti 640X480 16Bit e 800X600 32Bit :doh:

Accettavo anke 800X600 16Bit e 800X600 32Bit :mbe:


Cmq le tue recensioni mi piacciono un Casino :sofico:

Continua cosi' :eek: :D

Beh, non mi sembra tanto stupefacente vedere la Parhelia battere un GeForce 2 GTS, specie in un gioco D3D... :p E' invece abissale il distacco che si becca in OpenGL (anche se sono convinto che, salendo di risoluzione e a 32 bit, la Parhelia prevarrà sempre e comunque, a prescindere dalla tipologia del gioco)... :rolleyes:
Ho testato queste 2 schede perchè, in un gioco single texture, agiscono entrambe come una configurazione 4x1 ed entrambe hanno un clock di 200 mhz, quindi una situazione ideale per vedere l'efficienza di architettura e driver: quanto alla quantità ed ampiezza di banda della ram, certo non rappresenta un problema a 640x480x16 :D
Ho testato 800x600x32 per avere una qualche indicazione su come scalano le schede al salire della risoluzione: avrei voluto andare molto più in alto ma i driver della Parhelia, con questo gioco vetusto, non me l'hanno consentito (il testo diventa invisibile)... :rolleyes:

Ti consiglio di provarle con Colin mcrae Rally 2 , attivando il "Cubic" :mbe:

Credo di averlo visto in vendita nuovo a 7 €, oggi lo compro: se non sbaglio supporta anche l'EMBM... :oink:

Ragazzi per caso mi sono imbattuto in questo 3d e mi avete risvegliato non pochi ricordi....la mia prima Banshee ad esempio da 16Mb ,che gran scheda mi ricordo Falcon 4 in glide girava benissimo..., sostituita poi da una voodoo3 3000 ed infine dal Hercules 3dprophet Kyro2 4500 64Mb con il quale sto scrivendo adesso queste 4 righe su un vecchio Celeron 1000....bhè il Kyro per me era un gran progetto e mi sono rammaricato non poco quando la ST ha deciso di sospenderlo....con le ultime versioni dei driver andava veramente bene e non risentiva del passaggio a 32 bit....
Ciauz e complimenti per il 3d.

Grazie "capellone24" ( :eek: )

Ciao Capellone 24, sono d' accordo con te ke il Kyro 2 era un grande progetto.
Una GPU relativamente economica in grado di competere in alcuni titoli con la Geforce 2, Grazie ad un' ottimizzazione della potenza disponibile, ottenuta con l ' eliminazione del calcolo di superfici non visibili ( in pratica la Geforce 2 costruiva tutta l' immagine anke quella dietro ad altre texture e per questo non visibile :doh: mentre la Kyro 2 costruiva solo le immagini ke alla fine servivano veramente)

Dai miei test, però, il Kyro 2 è dietro abbastanza nettamente: se, poi, cominciassi ad applicare trilinear ed anisotropic, andrebbe sotto come un treno... :O

per essere dietro lo era io le ho avute entrambe...però c'è da dire che il Kyro costava circa il 40% in meno se non ricordo male...se avessero fatto un Kyro 3 (a quei tempi se ne parlava molto...poi invece lo abbandonarono...) di sicuro avrebbero recuperato il gap con Nvidia perchè sulla carta il kyro muove molti poligoni in meno del geffo2 solo che come dice Mc Turbo invece di renderizzare le texture indistintamente salvo poi fare il controllo sullo Zbuffer come faceva Geffo2 ,eseguiva prima il controllo sullo Zbuffer determinava le parti di scena effettivamente visibili e ne eseguiva il rendering diminuendo i calcoli dal 30 al 60% in media (mi pare che dichiarassero allora...)
un vero peccato anche perchè il Chip mi pare lo facessero a Catania se non sbaglio...
Ciauz.

Test fantastici Murakami, quanti ricordi hai risvegliato... :O

Due note:
-) quando non sei riuscito a toglire il v-sync eri in regime di double buffer o triple buffer? Te lo chiedo perchè nel primo caso non c'è solo il problema che gli fps massimi non possono superare la frequenza di refresh del monitor, ma anche che non possono essere diversi da un sottomultiplo della frequenza stessa (sicuramente sei a conoscenza del problema, ma non ho trovato specificato nulla al riguardo... :))
-) eseguiresti un test del fill-rate del 3dmark 2000 sulle GeForce2 a 1024x768x16 e 1024x768x32? Mi interesserebbero i risultati del test multitexture: in questo test infatti la banda passante NON rappresenta un limite, in genere neanche a 32 bit. Se le prestazioni dovessero decadere sarebbe confermata l'incapacità di NV15 di usare 2 delle sue 4 pipeline quando operante a 32 bit... ;)

Ciao complimenti ancora! :)

Ciao,
in realtà le grandi prestazioni del Kyro non erano dovute a un non disegno dei poligoni nascosti, ma alla non renderizzazione delle loro superfici. La differenza può non essere palese, ma è significativa: il chip Kyro elabora TUTTI i poligoni . Per meglio spiegarmi:
-) la CPU elabora TUTTI i vertici della scena;
-) durante l'operazione di scan line l'unita di triangle setup del Kyro elabora TUTTI i poligoni;
-) durante la selezione dei poligoni e la costruzione della triangle list appartenente a un determinato tile vengono elaborati TUTTI i poligoni (o le parti di essi) presenti nel tile stesso;
-) durante l'operazione di rendering vengono elaborate SOLO le parti visibili dei poligoni contenuti nella triangle list, questo porta il chip Kyro a renderizzare SOLO le parti visibili del frame corrente (deferred rendering).

Anche il chip Kyro elabora quindi tutta la geometria della scena.
In pratica il vantaggio prestazionale è presente "solo" nella fase di rendering. Dato però che come sosteneva 3dfx "fill-rate is the king" (affermazione che ancora la sua validità, sebbene ridimensionata parecchio rispetto a qualche anno fa), il guadagno ottenibile nel rendering permetteva al chip Kyro di avvicinare parecchio le schede GeForce2 e in alcuni casi addirittura superarle (non molto spesso però e solo con giochi aventi un alto overdraw).

Ciao. :)

La realtà è che "fill-rate is the king" è un'affermazione oggi ancora più valida che in passato anche se oggi potremmo evolverla in "pixel-shading is the king". Mi spiego: il Kyro non renderizzava le superfici nascoste e cioè, dal punto di vista poligonale le trattava come tutte le altre, solo che al momento del rendering, e cioè per l'epoca essenzialmente l'applicazione delle textures, evitava di caricare tutte quelle texture che non si vedevano. Risultato: molta banda passante risparmiata.

Oggi questo risparmio sarebbe ancora più significativo perché non si tratta più semplicemente di non applicare le texture, ma di non elaborare tutti i pixel shaders legati ai pixel delle superfici nascoste. Immaginate il risparmio non solo di banda passante, ma di calcolo in generale. Del resto PowerVR ha presentato recentemente la Serie 5 con un'architettura a shading unificato (teoricamente simile a quella di R500) e con specifiche che superano quelle delle DirectX 9.0c e OpenGL 2.0. Ahimè il suo impegno è ormai concentrato nel mercato mobile dove ovviamente è leader (poca potenza di calcolo e alte prestazioni = una manna per i chip a basso consumo energetico) e persino Intel ha acquisito la sua licenza per lo sviluppo di chip mobile. Un esempio è il chip grafico alla base del palmare Dell Axim X50v, ma sono in arrivo anche cellulari con tecnologia PowerVR prodotti da Philips ed altri.

Coloro che prevedevano un incremento mostruoso della complessità poligonale dei videogames e, quindi, una importanza sempre + secondaria del fill rate, hanno sbagliato completamente previsione perché tutte le tecniche così avanzate che vediamo oggi come il bump mapping o il parallax mapping sono volte proprio al massimo risparmio poligonale e personalmente ritengo che anche quando si inizierà ad usare il displacement mapping attraverso vertex fetch, comunque là dove si potrà risparmare geometria, lo si farà sempre. Insomma secondo me nella grafica in tempo reale si sarà sempre limitati dalla capacità di elaborare pixelshader/texture e mai limitati dalla scarsa capacità poligonale.

Be', c'è da dire che ATI e Nvidia (rispettivamente da R300 e NV30) ormai hanno sviluppato algoritmi di HSR che permettono di scartare la maggior parte (se non la totalità) dei pixel non visibili. Infatti entrambi i chip, prima di renderizzare i pixel, controllano che questi siano visibili (prima tramite comparazione dei valori Z su una tabella pivot ottenuta precedentemente e poi, se necessario, direttamente caricando on chip la tile in questione e effettuando un controllo alla display resolution, quindi pixel per pixel).
In caso disegno back-to-front comunque il Kyro dovrebbe avere un certo vantaggio, situazione che si ribalta utilizzando un rendering front-to-back.

Ciao. :)

Ormai il deferred shading in sè non è + un grandissimo vantaggio per PowerVR perché, come hai già detto tu, NVIDIA e ATI hanno sviluppato tecniche di HSR molto efficienti. Restano i vantaggi (e gli svantaggi) di un'architettura completamente Tile Based.

Il discorso back-to-front e front-to-back che fai è corretto, ma considera che è abitudine comune ormai nei motori grafici fare una prima passata solo di scrittura nello zbuffer in maniera da consentire ai processori grafici di fare HSR indipendentemente dall'ordine con cui successivamente il motore grafico invia i dati alla GPU. Quindi alla fine anche in questo campo grossi vantaggi PowerVR non ne ha più.

Perfettamente d'accordo, ma non considerando l'ottimo HSR i vantaggi propri di questo approccio si riducono notevolmente. Rimane però la capacità di applicare i filtri (in particolare l'AA) in maniera più veloce rispetto a un approccio classico, questo perchè i calcoli relativi ai filtri vengono eseguiti direttamente a livello di tile, che è completamente contenuta nella cache del chip (si libera così parecchia banda dal frame buffer). Altri vantaggi che reputo molto interessanti sono la capacità di operare senza tenere uno z-buffer nel frame buffer e l'ottimizzazione degli accessi alla RAM video (essendo le tile sempre di dimensione fissa).
Gli svantaggi però sono abbastanza onerosi:
-) è richiesta parecchia potenza elaborativa da parte del chip grafico per creare la triangle list;
-) è richiesta una cache di notevoli dimensioni on-chip per effettuare il caching di tile sempre più grandi;
-) come conseguenza delle due indicazioni precedenti in genere i chip tile based soffrono parecchio nel salire di frequenza;
-) ci possono a volte essere problemi con le trasparenze (esempio: M3D, Neon250 e, in misura molto più limitata, Kyro).

Detto questo, devo comunque riconoscere che un'architettura completamente tile based mi affascina molto, e sarei stato molto curioso di vedere cosa stava combinando Gigapixel prima dell'acquisizione da parte di 3dfx. Inoltre credo sarebbe stato davvero interessante vedere sul mercato un chip completamente tile based con potenza "grezza" paragonabile ai chip odierni: probabilmente sarebbe venuto fuori qualcosa di veramente valido.

Interessante... credevo che a usare questa tecnica fossero solo i motori di Doom3 (e derivati) e dei 3dmark2003-2005. Ci sono molto altri motori che fanno lo stesso?

Ciao. :)

Non so come e se PowerVR abbia risolto i problemi relativi alle scene dotate di un grande numero di poligoni. Proponendo oggi un'architettura unificata, presumo di si, ma in generale comunque è ovvio che la loro architettura è fatta per sistemi fillrate/pixelshader limited e non di certo per scene geometricamente molto complesse.
La dimensione delle tile è fissa (32x16 sul Kyro e Kyro II), quindi la cache non varia.
I problemi della trasparenze sono una cosa completamente a parte e slegata dall'architettura PowerVR: PCX1, PCX2 e Neon250 non supportavano letteralmente molte modalità di blending. Tutto qui. Il Kyro di problemi di blending non ha mai sofferto, anzi ha sempre sfoggiato ottimi risultati qualitativi grazie al calcolo interno sempre a 32 bit.

In generale una prima passata per motori come quello di Doom 3, Fear (che usa sempre stencil shadows) o quello del 3DMark05, è necessaria perché quando si usano le stencil shadows o le shadow maps, l'implementazione classica prevede una prima passata di rendering per inizializzare lo zbuffer, dopodiché non ci si scrive più e si fanno solo confronti usando lo stencil buffer in un caso e le depth map nell'altro. Per gli altri a dirla tutta non lo so, ma ormai penso che fare questa prima passata sia sempre conveniente a meno che non si preveda di far girare scene con un basso livello di overdraw.

P.S: Scusate per l'offtopic.

D'accordo, anche se ricordo che la tendenza era quella di allargare sempre più le tile in modo da effettuare più velocemente i calcoli di overdraw (ma potrebbe essere una tecnica usata solo sulle architetture che utilizzano delle tabelle pivot per una prima comparazione, dovrei verificare :)).
Oltre alle modalità di blending non supportate (problema che giustamente non esisteva sul Kyro) il punto è che le superfici trasparenti sono teoricamente più ostiche da gestire su un'unità a piastrelle piuttosto che su una tradizionale. Guardando il Kyro non ci se ne accorge nemmeno, dato che PowerVR ha fatto davvero un ottimo lavoro, anche se a detta degli utenti di questo chip c'è qualche gioco che ha problemi proprio con le trasparenze...
Comunque il mio era un discorso teorico, non legato direttamente al chip Kyro; probabilmente mi sono espresso male. :stordita:
Già, su scene con alto overdraw questo approccio deve dare risultati notevoli, anche se a giudicare dei vari Doom3/Fear/3Dmark non mi sembra un fulmine... :fagiano:

Ciao. :)

Beh Doom3, Fear ed il 3DMark05 hanno motori grafici caratterizzati da illuminazione quasi completamente dinamica e, in tal senso, la proiezione delle ombre di tipo stencil o shadow map è un'operazione estremamente gravosa, ecco perché sono molto pesanti. Se disabiliti le ombre le prestazioni si risollevano alla grande.

Si, infatti con il mio sistema (XP 3000+ e Radeon 9800Pro) la disabilitazione delle ombre in Doom3 comporatava parecchi frame al secondo di differenza.
Ultima domanda OT e poi la smetto, prometto :p : giochi come Doom3 si avvantaggiano automaticamente della tecnologia ultrashadow tipica dei chip NV30/NV40 oppure il gioco deve essere programmato appositamente per sfruttarla?

Ciao. :)

PS: Murakami aspetto i risultati del test che ti ho chiesto... :Prrr:

La tecnologia Ultrashadow si compone di diverse funzionalità. NV30/NV40/G70 elaborano il doppio dei pixel (anzi, sarebbe + corretto chiamarli fragment) al secondo quando scrivono nel solo zbuffer o nel solo stencil buffer, rispetto a quanti ne elaborano scrivendo verso il frame buffer. Per avvalersi di questo non si ha bisogno di alcuna ottimizzazione specifica: è sufficiente disabilitare la scrittura verso il frame buffer ed abilitare il solo z buffer o il solo stencil buffer. Una funzionalità che, invece, richiede una implementazione specifica è il depth bound test supportato dalla tecnologa ultrashadow e che, essenzialmente, nel calcolo delle stencil shadows consente di ridurre il numero di test effettuati con lo stencil buffer. Doom 3 supporta questa features.

Si, infatti ricordavo che la possibilità di scrivere due valori z per pipeline è una feature che non ha bisogno di implementazioni specifiche...
Ok, ricordavo bene anche in questo caso... :p questa feature è disponibile solo su NV30/NV40, vero? Non mi pare che i chip NV20/NV25 la supportassero (e infatti il loro vantaggio in giochi come Doom3 è ridotto...)

Complimenti per la prova, mi è piaciuta molto, poi che ricordi meravigliosi che mi ha suscitato :)

'stardiiiiii .... :ciapet:

Eccomi, mi aggiungo ufficialmente alla discussione mettendo alcuni dati sulla V5 5500.
Al momento sto scaricando la demo di UT2003 con cui farò dei bench su D3D.
Per l'OGL userò Quake3.
Datemi giusto il tempo di trovare un monitor perchè quello del babbo da 14" che avrei dovuto usare per i test è saltato :(

Grazie dei complimenti... :O
Rispondo alle tue domande:
1) Non ho modo di appurarlo (driver troppo primitivi o malfunzionanti -vedi Volari-) ma ritengo di essere stato senz'altro in regime di doppio buffer (spesso gli fps erano inchiodati su un 60 troppo spaccato con un refresh di 120 hz), quindi sono conscio che quei test non hanno quasi alcuna validità...ma, come già detto, non ho trovato modo di fare altrimenti... :(
2) Volentieri, dammi un link al programma perchè di bench me ne intendo come di merletti... :fagiano:
Aggiungo anche che oggi ho incontrato Sanford (persona squisita) e mi ha prestato il suo Voodoo 5, quindi presto la metterò alla frusta... :O
Aggiungo, inoltre, che per scrivere questo post sono al mio posto di lavoro pur essendo in ferie... :rolleyes:
Aggiungo, infine, che sto testando gli occhialini 3D stereo e che presto aprirò thread dedicato... :read:

I chip nv20 e nv25 non supportano ultrashadow nè posseggono l'abilità di renderizzare 2 valori z per pipe: l'ultrashadow comparso su nv30 è stato raffinato su nv40 (ultrashadow II).

Il supersampling del Kyro impatta meno di quello del GeForce 2 -risparmio di banda dovuto all'architettura-, ma i filtri trilinear e anisotropic comportano un drastico calo di prestazioni, non so se per l'architettura tile based o le sole 2 pipeline con 1 unità di texturing per pipe.

Riesci a fare gli stessi test che ho fatto io, "Forsaken" e "Quake 2"?

Quello non è uno svantaggio dell'architettura Kyro, ma un vantaggio di quella GeForce 2 che possiede due TMU per pipeline e quindi è in grado di applicare il filtro trilineare in una sola passata di rendering. Oggi architetture come quella del GeForce 2 non esistono più, sono tutte con una sola TMU per pipeline e per effettuare il filtro trilineare comunque in una sola passata si usano trucchetti come il filtro brilineare, ecc...

Certo, ma non mi risulta che il GeForce 1 (4x1) calasse così tanto con i filtri applicati: ecco una spiegazione del brusco calo di prestazioni del Kyro.