[Riflessioni] Intervista a David Kirk di Vifani

[Banus]

Originariamente inviato da Vifani
Io sono sicuro che un'architettura come quella TBR darebbe enormi vantaggi soprattutto oggi che il calcolo per fragment si sta appesantendo con i pixel shader 2.0 e 3.0. Immaginate il risparmio di risorse di calcolo derivante dall'eliminazione di tutte le superfici nascoste?

Esattamente quello che pensavo l'annoscorso mentre si parlava di un possibile PowerVR5 con Pixel Shader 3.0

Comunque stavo pensando... il Kyro 2 andava in crisi se c'erano troppi triangoli per tile, in particolare se erano > 512, cioè più di uno per pixel. Guardando le specifiche del Unreal Engine 3 si legge che arriva a 1.2 milioni di triangoli per scena, e a 1024x768 significa in medi più di uno per pixel... Si deve complicare la circuiteria interna per gestire il culling di un maggior numero di triangoli (mantenendo buona la tecnologia degli Infinite Planes così come è descritta da Beyond 3d).
La soluzione ibrida di yossarian mi sembra molto più interessante, ma da quello che so non dovrebbe essere molto diversa da quella che Ati sfrutta con la sua HyperZ HD.

[BTinside]

Originariamente inviato da Spytek
Parli per caso della TT, o S3?

dai raga basta OT,
Simon sposta nella sezione giusta


Scherzo eh...
il motore sempre volkswagen è quindi...

[BTinside]

Originariamente inviato da BTinside
Tu dici che il fill rate doppio nel trattamento dello Z e dello Stencil buffer permertte a NV40 di eseguire la passata di rendering in cui si scrive in Z e Stencil a quasi il doppio di R420,
ma scusa l'R420 non recupera con l'HyperZ HD?
Se non è così ecco spiegata la maggior efficienza di NV40 che compete con R420 con valori di frequenze core, ram e capacità poligonale abbastanza inferiori (almeno..credo
)

Mi quoto perchè nessuno mi ha ancora risposto a questa domanda,
il doppio fill rate dell'ultrashadow di NV40 , non viene compensato da R420 con l'HyperZ??? Altrimenti come fa una X800XT PE a competere e spesso superare la 6800Ultra? Non ditemi che questo vantaggio sia solo merito delle frequenze più alte di R420

[Vifani]

Originariamente inviato da BTinside
Mi quoto perchè nessuno mi ha ancora risposto a questa domanda,
il doppio fill rate dell'ultrashadow di NV40 , non viene compensato da R420 con l'HyperZ??? Altrimenti come fa una X800XT PE a competere e spesso superare la 6800Ultra? Non ditemi che questo vantaggio sia solo merito delle frequenze più alte di R420

Ero convinto di averti risposto sto invecchiando...

Il fill rate doppio di NV40 rispetto a R420 è presente nel rendering sul solo z-buffer o sul solo stencil buffer. Queste operazioni non sono molto frequenti e vengono fatte essenzialmente per realizzare le stencil shadow in Doom III.

Quindi NV40 ha il doppio del fill rate di R420 limitatamente a quella situazione. Nella più diffusa e classica operazione di rendering contemporaneamente nello z-buffer e nello stencil buffer le due architettura si comportano allo stesso modo.

Hyper-Z HD racchiude tecniche di compressione del colore e dei dati relativi allo z-buffer oltre a tecniche per la rimozione di superfici nascoste. Il rendering fatto per le ombre di Doom III non beneficia + di tanto di queste tecniche. Solo nell'ultima passata in cui si scrive nel frame buffer si vedono i miglioramenti dovuti all'Hyper-Z HD.

[BTinside]

Originariamente inviato da Vifani
Ero convinto di averti risposto sto invecchiando...

Il fill rate doppio di NV40 rispetto a R420 è presente nel rendering sul solo z-buffer o sul solo stencil buffer. Queste operazioni non sono molto frequenti e vengono fatte essenzialmente per realizzare le stencil shadow in Doom III.

Quindi NV40 ha il doppio del fill rate di R420 limitatamente a quella situazione. Nella più diffusa e classica operazione di rendering contemporaneamente nello z-buffer e nello stencil buffer le due architettura si comportano allo stesso modo.

Hyper-Z HD racchiude tecniche di compressione del colore e dei dati relativi allo z-buffer oltre a tecniche per la rimozione di superfici nascoste. Il rendering fatto per le ombre di Doom III non beneficia + di tanto di queste tecniche. Solo nell'ultima passata in cui si scrive nel frame buffer si vedono i miglioramenti dovuti all'Hyper-Z HD.

Anche NV40 possiede una tecnica di compressione del colore o sbaglio?

[Alberto Falchi]

Originariamente inviato da BTinside
Secondo me non ne hanno proprio la voglia di produrre una soluzione basata su tbr

Il "non avere voglia" non esiste in ambito commerciale. Se non lo si fa, è perché non conviene economicamente, perché qualcuno ha già il brevetto (non è questo caso, visto che le tecnologia 3dfx sono di nVidia) o perché il gioco non vale la candela. Quando cì'è in atto una simile guerra di prodotto fra i due grossi concorrenti, "non ho voglia" è una risposta inacettabile, olter che stupida ^_^.

Pape

[Vifani]

Originariamente inviato da BTinside
Anche NV40 possiede una tecnica di compressione del colore o sbaglio?

Si certo.

[yossarian]

Originariamente inviato da Banus
La soluzione ibrida di yossarian mi sembra molto più interessante, ma da quello che so non dovrebbe essere molto diversa da quella che Ati sfrutta con la sua HyperZ HD.

in effetti non è molto differente; in questo caso, una soluzione "ibrida" è l'unico mezzo per non stravolgere la logica del chip e per ovviare ai problemi di spazio interno.
Il Kyro, infatti, è un chip molto semplice, con un'architettura 2x1 e con una sola alu per pipeline (come, d'altra parte, anche NV15, NV2x, R100 e R200), operante a 32 bit (8 per canale) in virgola fissa. Realizzato a 0,18 u ha, perciò, un notevole spazio interno per allocare buffer di varia natura e, proprio grazie a questa caratteristica, presenta soluzioni molto moderne per l'epoca in cui è stato progettato (la possibilità di applicare 8 texel per pixel per single pass, ad esempio pur disponendo di 1 sola tmu).
Nel caso dell'R300, invece, la situazione è molto diversa: elevato parallelismo, elevato numero di transistor, architettura molto complessa e poco spazio interno al chip. Perciò i registri adoperati come tile buffer (l'R300 ne utilizza 3 poichè adotta un algoritmo a 3 livelli) sono di dimensioni estremamente ridotte (4x4, 2x2 e 1) rispetto a quello del Kyro2 (16x32), però la necessità di ricorrere alla display resolution è ridotta al minimo: E' ovvio che il tbr si basa su un principio diverso nella gestione del rendering dell'immagine, però anche l'algortimo di ATi prevede la completa eliminazione di tutte le superfici nascoste e risulta persino più veloce del tbr nel caso di scansione front to back.

[shodan]

Originariamente inviato da GMCPape
Il "non avere voglia" non esiste in ambito commerciale. Se non lo si fa, è perché non conviene economicamente, perché qualcuno ha già il brevetto (non è questo caso, visto che le tecnologia 3dfx sono di nVidia) o perché il gioco non vale la candela. Quando cì'è in atto una simile guerra di prodotto fra i due grossi concorrenti, "non ho voglia" è una risposta inacettabile, olter che stupida ^_^.

Pape

Ciao,
non sono d'accordo.

A questi livelli le aziende rivali si studiano a vicenda sono in grado di capire abbastanza precisamente cosa farà l'avversario e/o anche come lo farà.

La tecnologia TBR è davvero fantastica (sebbene affetta da diversi problemi, non ultimo quello di doversi scontrare con delle API pensate per operatori di rendering immediato) e dire che non conviene usala perchè tanto si può aumentare il bus e/o la frequenza mi sembra un tantino fuori luogo. Immagina un chip della complessita (e con la potenza bruta) di NV40 accoppiato alla tecnologia TBR: se un KyroII da 350Mp/Mt per secondo teneva testa a una GF2GTS da 800Mp/1600Mt per secondo, chissa cosa potrebbe fare questo ipotetico chip...

Un'ultima cosa: la tecnologia UltraShadowII non ha nulla a che fare con il TBR. E' vero che in ultima analisi lo scopo di queste tecnologie è quello di risparmiare calcoli non processando ciò che non serve, ma il modo in cui lo fanno e i principi a cui si appoggiano (nonchè la loro efficenza) sono molto differenti...

X Yossarian: così com'è strutturato l'R300 non ha bisogno di tenere nessuna triangle list o in qualche caso è necessario anche per lui ricorrere a queste famose liste?

CIAO!

[Banus]

Originariamente inviato da yossarian
Realizzato a 0,18 u ha, perciò, un notevole spazio interno per allocare buffer di varia natura e, proprio grazie a questa caratteristica, presenta soluzioni molto moderne per l'epoca in cui è stato progettato (la possibilità di applicare 8 texel per pixel per single pass, ad esempio pur disponendo di 1 sola tmu).

Non riesco a capire la relazione fra teconlogia 0.18 e spazio per i buffer... perchè adesso i chip sono molto più complessi e rimane poco spazio per buffer di vario tipo?

E' ovvio che il tbr si basa su un principio diverso nella gestione del rendering dell'immagine, però anche l'algortimo di ATi prevede la completa eliminazione di tutte le superfici nascoste e risulta persino più veloce del tbr nel caso di scansione front to back.

Che se non vado errato è l'ordine di rendering che solitamente si sceglie per avere una corretta gestione delle trasparenze mediante alpha blending.
Un dubbio.. il Kyro doveva parte della sua efficenza alla possibilità di operare localmente su una tile tranne nella fase di texture fetch (se non ricordo male), e questo significava anche risparmio di banda.
Le attuali schede hanno per quello che si sa una specie di cache interna oppure accedono sempre direttamente al framebuffer?

[Banus]

Originariamente inviato da shodan
La tecnologia TBR è davvero fantastica (sebbene affetta da diversi problemi, non ultimo quello di doversi scontrare con delle API pensate per operatori di rendering immediato) e dire che non conviene usala perchè tanto si può aumentare il bus e/o la frequenza mi sembra un tantino fuori luogo.

C'è anche da stabilire in quali occasioni porti a un grosso miglioramento. Se le Ati riescono con un numero relativamente ridotto di calcoli a scartare la quasi totalità dei pixel nascosti non è difficile capire che avrebbero prestazioni quasi allineate con un ipotetico Kyro5. Inoltre con l'aumentare del numero dei poligoni potrebbero diventare più efficienti altre strade. Se si impone l'uso su larga scala delle displacement map con le WGF potrebbe rivelarsi più efficiente, mettiamo, un'architettura tipo Reyes.

X Yossarian: così com'è strutturato l'R300 non ha bisogno di tenere nessuna triangle list o in qualche caso è necessario anche per lui ricorrere a queste famose liste?

Mi permetto di rispondere
http://www.xbitlabs.com/articles/vid...ay/r420_9.html
Oltre allo Z-buffer c'è un "Tile Z buffer" che tiene traccia del valore Z più alto della tile.
Prende un singolo poligono e lo divide in blocchi 8x8, testando i valori Z agli angoli. Se sono tutti superiori al valore memorizzato nel "Tile Z buffer" il blocco viene scartato, altrimenti raffina a blocchi di 4x4, e se necessario, a 2x2, ovvero a livello di pixel.

[shodan]

Originariamente inviato da Banus
C'è anche da stabilire in quali occasioni porti a un grosso miglioramento. Se le Ati riescono con un numero relativamente ridotto di calcoli a scartare la quasi totalità dei pixel nascosti non è difficile capire che avrebbero prestazioni quasi allineate con un ipotetico Kyro5. Inoltre con l'aumentare del numero dei poligoni potrebbero diventare più efficienti altre strade. Se si impone l'uso su larga scala delle displacement map con le WGF potrebbe rivelarsi più efficiente, mettiamo, un'architettura tipo Reyes.


Mi permetto di rispondere
http://www.xbitlabs.com/articles/vid...ay/r420_9.html
Oltre allo Z-buffer c'è un "Tile Z buffer" che tiene traccia del valore Z più alto della tile.
Prende un singolo poligono e lo divide in blocchi 8x8, testando i valori Z agli angoli. Se sono tutti superiori al valore memorizzato nel "Tile Z buffer" il blocco viene scartato, altrimenti raffina a blocchi di 4x4, e se necessario, a 2x2, ovvero a livello di pixel.

Ciao, grazie per la risposta!

Avevo letto anche io qualcosa su come funziona l'HSR sull'R300 ed ero a conoscenza di questa "tile z buffer", però non ho capito se, per operare su una tile, deve prima generare la tringle list relativa (come nei chip Kyro).

CIAO!

[BTinside]

Originariamente inviato da GMCPape
Il "non avere voglia" non esiste in ambito commerciale. Se non lo si fa, è perché non conviene economicamente, perché qualcuno ha già il brevetto (non è questo caso, visto che le tecnologia 3dfx sono di nVidia) o perché il gioco non vale la candela. Quando cì'è in atto una simile guerra di prodotto fra i due grossi concorrenti, "non ho voglia" è una risposta inacettabile, olter che stupida ^_^.

Pape

Infatti era un "non ne hanno la voglia" generico:

è implicito e può significare tante cose
-non ne hanno la voglia...........perchè risulterebbe compromettente economicamente

[yossarian]

Originariamente inviato da shodan
X Yossarian: così com'è strutturato l'R300 non ha bisogno di tenere nessuna triangle list o in qualche caso è necessario anche per lui ricorrere a queste famose liste?

CIAO!

l'R300 utilizza una suddivisione dell'immagine in tile 4x4; ogni tile è composta di blocchi 2x2 e di ogni blocco si prende il valore maggiore (pivot) e si inserisce in un'altra lista; questa seconda è composta da blocchi 2x2 che contengono tutti i valori pivot suddetti; infine, tra i 4 valori di questa seconda tessera, si sceglie il valore maggiore in assoluto (che è anche il valore più grande della tessera di partenza 4x4); questo valore rappresenta il valore z, relativo a quella tessera, più lontano dall'osservatore. Quindi, nel caso dell'R300, abbiamo più liste che vengono caricate on chip. Quando si effettua il primo test con una texturre relativa a pixel aventi le stesse coordinate x e y di una data tessera 4x4, si confrontano i valori z della texture da applicare con quello che potremmo definire "pivot dei pivot". Se il valore z della nuova tessera è maggiore di quello di riferimento, la texture viene scartata, ina caso contrario si passa a confrontarla con i valori della tile 2x2; in caso di ulteriore dubbio si passa all'ultimo confronto, quello con la tessera campione 4x4, presa alla display resolution. Quest'ultimo confronto permette di fugare ogni ulteriore dubbio e "rigettare" o accettare la texture o parte di essa. Eseguendo una scansione front to back, poichè i primi valori ad essere caricati on chip sono quelli relativi ai layer più vicini all'osservatore, è facile prevedere che la maggior parte delle tile esaminate in seguito saranno "rigettate" già nella prima fase dell'analisi (questo permette di velocizzare molto il processo).

Da puntualizzare una cosa; a partire dalla generazione DX7 (l'R100 ad esempio) i chip non eseguono più immediate rendering (tranne, la GF2) ma hanno un algoritmo per la rimozione delle superfici nascoste. Il problema è che non tutti eseguono, newi casi dubbi, il test alla display resolution (come invece fa l'R300). Questo non permette di eliminare completamente tutti i poligono nascosti, dando luogo in alcuni casi, al fenomeno dell'overdraw che diventa tanto più grave quanto più alta è la risoluzione, maggiore il numero di poligoni e a filtri attivi.

Il TBR, invece, utilizza solo la display resolution (cioè la risoluzione reale a cui si lavora) per effettuare il test; questo permette un'analisi accurata pixel per pixel.

[yossarian]

Originariamente inviato da Banus
Le attuali schede hanno per quello che si sa una specie di cache interna oppure accedono sempre direttamente al framebuffer?

no, hanno delle cache interne, però, a parte il caso dell'R300 e, suppongo, dell'R420, non sono sicuro che gli altri effettuino test pre rendering alla display resolution; se così fosse, il fenomeno dell'overdraw non sarebbe del tutto eliminato, perchè l'analisi sullo z-buffer della ram video viene fatta in fase di post processing, ovvero a rendering effettuato.

[yossarian]

Originariamente inviato da Banus
Non riesco a capire la relazione fra teconlogia 0.18 e spazio per i buffer... perchè adesso i chip sono molto più complessi e rimane poco spazio per buffer di vario tipo?

il Kyro, ha un'architettura molto semplice: è una 2x1, con una sola alu fx8 per pipeline; questo, su un chip a 0,18 u, permette di ricavare molto spazio per utilizzare cache interne per svolgere varie funzioni (da qui la possibilità di fare multitexturing a 8 layer in single pass e di utilizzare tile di grandi dimensioni (16x32) da caricare on chip).
Al paragone, lo stesso NV15, con la sua 4x2 (e 1 alu fx4/fx8 per pipeline) o l'R100 con la 2x3 e 1 alu fx8 per pipeline, sono molto più complessi; per non parlare dell'R300, realizzato a 0,15, ma con architettura 8x1, con 2 fpu per pipe, 4 unità VS, ecc. ecc.: in un chip così complicato, che già deve implementare il numero minimo di registri per essere compatibile con il tipo di API per cui è progettato (DX9 in questo caso), non c'è molto spazio per allocare una ulteriore cache di grandi dimensioni (tipo quella del Kyro) per fare TBR (ATi, sull'R300, ha dovuto "risparmiare", cercando di ridurre al minimo la complessità dei circuiti che si occupano del LoD e dell'AF), facendo ricorso al numero minimo di bit consentiti per avere una corretta visualizzazione. Questo è il motivo per cui le dimensioni della tile alla display resolution sono state scelte di soli 4x4 pixel (R200, ad esempio, l'aveva 8x8, però on chip era caricata solo una tile a "risoluzione" ridotta, delle dimensioni di 2x2 pixel scelti col criterio dei pivot sui 4 gruppi 4x4 costituenti la tessera di partenza: infatti R200 non effettua early z-test alla display resolution ed è affetto dal fenomeno dell'overdraw).

[Banus]

Originariamente inviato da yossarian
il Kyro, ha un'architettura molto semplice: è una 2x1, con una sola alu fx8 per pipeline; questo, su un chip a 0,18 u, permette di ricavare molto spazio per utilizzare cache interne per svolgere varie funzioni

Capito, è un semplice problema di transistor budget
A proposito, mi chiedo se l'attuale tendenza a inserire molte funzioni complesse on chip sia conveniente, piuttosto che replicare molte volte le operazioni più frequenti, essenzialmente MAC e divisioni (per il calcolo delle coordinate texture), più o meno come nell'Emotion Engine, che infatti ha un numero di transistor molto ridotto (10 milioni). Ovvio che un'architettura simile significa la necessità di un buon lavoro a livello di driver

Questo è il motivo per cui le dimensioni della tile alla display resolution sono state scelte di soli 4x4 pixel (R200, ad esempio, l'aveva 8x8, però on chip era caricata solo una tile a "risoluzione" ridotta, delle dimensioni di 2x2 pixel scelti col criterio dei pivot sui 4 gruppi 4x4 costituenti la tessera di partenza: infatti R200 non effettua early z-test alla display resolution ed è affetto dal fenomeno dell'overdraw).

Su X-bit labs leggo che R420 esegue il test su blocchi di 8x8 pixel e nei casi dubbi scende fino a due livelli. Infatti si parla di Hierarchical Z buffer a 3 livelli. I blocchi 2x2 richiedono il calcolo dei valori di Z di tutti i pixel e quindi si ricade nell'Early Z:

When the polygon to be processed arrives, HyperZ HD splits it into 8x8 pixel blocks and finds minimal Z value for 64 pixels of each block: it will evidently be found on one of the corner pixels, that is why it is more than enough to check only the 4 Z values in the corners of the block.

[yossarian]

Originariamente inviato da Banus
Capito, è un semplice problema di transistor budget
A proposito, mi chiedo se l'attuale tendenza a inserire molte funzioni complesse on chip sia conveniente, piuttosto che replicare molte volte le operazioni più frequenti, essenzialmente MAC e divisioni (per il calcolo delle coordinate texture), più o meno come nell'Emotion Engine, che infatti ha un numero di transistor molto ridotto (10 milioni). Ovvio che un'architettura simile significa la necessità di un buon lavoro a livello di driver

l'attuale tendenza sta iniziando a mostrare la corda; riprova ne è il fatto della ricerca di soluzioni multi-vga, come lo SLI di nVIDIA.
E' molto probabile che la generazione prossima (R520 e NV50?) sia l'ultima con questo tipo di architettura; in seguito si dovrebbe migrare verso architetture con VS e PS unificati, il che sta a significare utilizzo di circuiti in grado di eseguire le operazioni di base comuni e renderle disponibili per entrambi i tipi di unità di calcolo complesse. Risultato: maggior parallelismo, drastica riduzione dei tempi morti nelle elaborazioni (periodi in cui uno dei due blocchi è inattivo, in attesa che l'altro termini i suoi calcoli) e, soprattutto, notevole risparmio di transistor (molte unità di calcolo elementari, attualmente contenute sia nei ps che nei vs, non saranno replicate ma saranno uniche e i risultati da esse forniti saranno a disposizione di chi ne avrà bisogno in quel momento).

Originariamente inviato da Banus


Su X-bit labs leggo che R420 esegue il test su blocchi di 8x8 pixel e nei casi dubbi scende fino a due livelli. Infatti si parla di Hierarchical Z buffer a 3 livelli. I blocchi 2x2 richiedono il calcolo dei valori di Z di tutti i pixel e quindi si ricade nell'Early Z:

si, ho letto l'articolo di x-bit; c'è da vedere se la matrice 8x8 è stato possibile caricarla "on chip), oppure se è stato possibile "imbarcare" solo la 4x4; in questo secondo caso, il chip è in grado di effettuare uno z-test a quella che è definita, in gergo "una risoluzione inferiore rispetto alla display resolution" e rappresenterebbe un passo indietro rispetto all'algoritmo implementato sull'R300 in fatto di risparmio di banda passante (anche se è pprobabile che, in termini di velocità, recupari grazie al fatto che riesce ad eliminare, in molti casi, in prima analisi, blocchi interi di 64 pixel contro i 16 dell'R300). Nel caso, invece, si sia trovato spazio per caricare la tile 8x8, allora l'early z-test dell'R420 è più veloce di quello dell'R300 a parità di efficacia.

[Banus]

Originariamente inviato da yossarian
in seguito si dovrebbe migrare verso architetture con VS e PS unificati, il che sta a significare utilizzo di circuiti in grado di eseguire le operazioni di base comuni e renderle disponibili per entrambi i tipi di unità di calcolo complesse. Risultato: maggior parallelismo, drastica riduzione dei tempi morti nelle elaborazioni (periodi in cui uno dei due blocchi è inattivo, in attesa che l'altro termini i suoi calcoli) e, soprattutto, notevole risparmio di transistor (molte unità di calcolo elementari, attualmente contenute sia nei ps che nei vs, non saranno replicate ma saranno uniche e i risultati da esse forniti saranno a disposizione di chi ne avrà bisogno in quel momento).

Di un'architettura analoga si parla del futuro Cell, di cui per ora esistono solo rumors e supposizioni basate su alcuni brevetti depositati da Sony. In particolare si parla di 8 unità di elaborazione
che a loro volta coordinano ciascuna 4 o 8 unità SIMD.
Anche le voci riguardo R500 parlano di 48 ALU dotate di un'unità vettoriale. A quanto pare è la soluzione più efficiente

si, ho letto l'articolo di x-bit; c'è da vedere se la matrice 8x8 è stato possibile caricarla "on chip), oppure se è stato possibile "imbarcare" solo la 4x4; in questo secondo caso, il chip è in grado di effettuare uno z-test a quella che è definita, in gergo "una risoluzione inferiore rispetto alla display resolution" e rappresenterebbe un passo indietro rispetto all'algoritmo implementato sull'R300 in fatto di risparmio di banda passante (anche se è pprobabile che, in termini di velocità, recupari grazie al fatto che riesce ad eliminare, in molti casi, in prima analisi, blocchi interi di 64 pixel contro i 16 dell'R300). Nel caso, invece, si sia trovato spazio per caricare la tile 8x8, allora l'early z-test dell'R420 è più veloce di quello dell'R300 a parità di efficacia.

Sono dell'idea che l'algoritmo usato nei due chip sia fondamentalmente lo stesso, infatti sul sito della Ati riguardo a R300 usa la stessa definizione:
http://www.ati.com/products/radeon97...pro/specs.html

In che senso si avrebbe risparmio di banda? andando a leggere/ scrivere solo blocchi di 4 pixel sul framebuffer non si ha un guadagno di banda? Anche copiando tutto il blocco 8x8 arrivati a livello pixel si deve eseguire uno Z-test classico perchè comunque non ci sono più blocchi da rigettare/raffinare. E sarebbe necessario copiare poi il blocco elaborato nel framebuffer. Questo andando a logica, dimmi se sto sbagliando qualcosa

[yossarian]

Originariamente inviato da Banus
Di un'architettura analoga si parla del futuro Cell, di cui per ora esistono solo rumors e supposizioni basate su alcuni brevetti depositati da Sony. In particolare si parla di 8 unità di elaborazione
che a loro volta coordinano ciascuna 4 o 8 unità SIMD.
Anche le voci riguardo R500 parlano di 48 ALU dotate di un'unità vettoriale. A quanto pare è la soluzione più efficiente

Si, R500 dovrebbe avere un'architettura con 48 alu polifunzionali più 16 texture unit; una società consociata di ATi (intrinsity) sta da tempo conducendo esperimenti su processori con unità SIMD, enormi cache interne e frequenze molto elevate (raggiungibili grazie alla semplicità del chip).

Originariamente inviato da Banus


Sono dell'idea che l'algoritmo usato nei due chip sia fondamentalmente lo stesso, infatti sul sito della Ati riguardo a R300 usa la stessa definizione:
http://www.ati.com/products/radeon97...pro/specs.html

In che senso si avrebbe risparmio di banda? andando a leggere/ scrivere solo blocchi di 4 pixel sul framebuffer non si ha un guadagno di banda? Anche copiando tutto il blocco 8x8 arrivati a livello pixel si deve eseguire uno Z-test classico perchè comunque non ci sono più blocchi da rigettare/raffinare. E sarebbe necessario copiare poi il blocco elaborato nel framebuffer. Questo andando a logica, dimmi se sto sbagliando qualcosa

anch'io sono della stessa idea, anzi credo proprio che sia esattamente lo stesso identico; questo perchè i risultati dei test di efficienza dei due algoritmi danno valori praticamente allineati.

Ho parlato di risparmio di banda perchè, nel caso la tile 8x8, quella alla display resolution, tanto per intenderci, non è caricata on chip, la sua analisi avviene in post processing, quando è già stata effettuata l'operazione di texturing; questo significa che è sempre presente il rischio di overdraw. In caso contrario, lo z-test preventivo rimuove tutti i poligoni, non si ha overdraw e lo z-test effettuato in post processing (perchè in ogni caso si effettua un doppio controllo, prima e dopo le operazioni di texturing), ha solo il compito di mero controllo