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.