4x2 = 8x1?

[CS25]

Originariamente inviato da shodan
E' vero che nelle schede moderne hanno estrema importanza le prestazioni delle unità shader, però credo che anche l'efficenza nell'applicazione di texture sia molto importante perchè fin quando non si utilizzeranno in larga misura le texture frattali i textel andranno sempre letti da una texture... Inoltre in questo contesto vedo molto meglio un chip che abbia un elevato numero di pipe e altrettante unità pixel shader (una per pipe, l'R300 se non sbaglio è fatto così) rispetto a un chip con meno pipe (e relative minori unità pixel shader)

Visto che yoss ha gia' esposto il lato tecnico, per rispondere alla tua domanda mi limito a portarti un esempio piuttosto recente : FX 5600 vs FX 5700.
Come vedi a parita' di pipe e tmu in dx9 la seconda vanta guadagni prestazionali fino al 50%, il tutto grazie alla sostituzione di unita' di calcolo integer con unita' di calcolo fp.
Cio' dimostra come per questa generazione di schede sia fortemente ingannevole basarsi solo sui dati che citi tu. E' ovvio e innegabile che avere piu' pipeline o tmu possa portare dei vantaggi, ma la cosa non e' piu' automatica e proporzionale come accadeva un tempo, il tutto sempre riferendoci alle dx9.
Come ti ha sottolineato yoss, non e' consequenziale il concetto "meno pipe = meno unita' PS", il dato e' assolutamente svincolato.

[yossarian]

Originariamente inviato da ATi7500
l'occhio umano riuscirebbe a distinguere differenze tangibili tra FP24 e FP32? o già FP24 darebbe modo di aumentare la qualità a livelli assurdi?


bYeZ!

a dire la verità, l'occhio umano fa difficoltà a distinguere già oltre i 32 bit complessivi, ossia gli 8 bit per colore; utilizzando 8 bit per colore, come fa la serie FX e quasi tutti i chip precedenti (dalla Matrox Millennium II in poi), cioè la famosa profondità di colore a 32 bit a livello di frame buffer, si può notare, in casi particolari, solo un leggero effetto di banding; con l'utilizzo dei 10 bit per colore (Parhelia, VP10, R3x0), scelti, più che altro, per compatibilità con lo standard HDTV, sparisce anche l'effetto banding. Quindi i 16, i 24, i 32 bit per colore non sono affatto necessari. Quella che invece, in alcuni casi è necessaria, è la precisione di calcolo a 32 bit per canale; alcuni calcoli producono risultati solo grossolanamente approssimabili dall'utilizzo di una precisione inferiore. Questo si che può causare artefatti visibili o perdità di qualità nell'immagine. Quindi una elevata precisione di calcolo è importante in fase di elaborazione molto più che non a livello di visualizzazione.

ciao

[shodan]

Ok yossarian ora hai davvero destato la mia curiosità...
Innanzitutto complimenti, sei impressionate!
Ora passiamo a cose serie

Originariamente inviato da yossarian
In realtà il fillrate è determinato da diversi fattori, tra cui il numero di TMU per il texel fillrate e il numero di pipeline per il pixel fillrate; tra i fattori che incidono sul fillrate, c'è l'efficienza di calcolo delle unità presenti nelle pipeline (TMU e ALU); sull'efficienza di calcolo incide, in maniera determinante, la quantità di trip che devono essere effettuati tra gpu e frame buffer. Sicuramente, a livello di efficienza, la 8x1 della 9500 pro è superiore alla 4x1 della 9600 pro, però, la cosa che mi ha fatto pensare ad un problema di registri (e di conseguenza alla necessità di più viaggi verso il frame buffer) è il calo brusco con AA4x, che non segue la logica delle prestazioni con AA2x, ad esempio, o con l'applicazione dell'anisotropic. Non è tanto l'andamento relativo a quello della 9600, quanto l'andamento in senso assoluto, con AA4x, a presentare un'anomalia (c'è a tutti gli effetti, un picco negativo che fa pensare ad un utilizzo elevato del frame buffer)

Ok ora ho capito cosa volevi dire: mentre tu parlavi del calo percentualmente molto maggiore che si ha nella 9600PRO dal passaggio da AA2X e AA4X rispetto allo stesso calo misurabile sulla 9500PRO, io avevo frainteso e ragionavo in termini assoluti.
Sorry!

Hai un po' semplificato l'architettura dell'R3x0, che ha 8 pipelines, con una TMU e due unità FP96 su ogni pipeline; si tratta di tutte unità di tipo vettoriale, composte da 4 unità scalari FP24.

Scusami ma qui forse non ho capito bene (ebbene si sono un po' limitato a seguirvi in questi dottissimi discorsi )
L'R300 ha 8 pipe ognuno con una TMU 2 unita FP96? Queste 2 unità compongono entrambe un'unita PS? E quando dici "si tratta di tutte unità di tipo vettoriale, composte da 4 unità scalari FP24" vuoi dire che ogni singola unità FP96 è composta da 4 unità FP24 (1 per canale colore e alpha)?

d'altronde, i chip Volari hanno un numeor di pipelines doppio rispetto al numero delle TMU: ciò non significa che le TMU siano al di fuori della pipeline di rendering. Anticipo la tua prossima domanda: ogni TMU fa uso di due serie di buffer interni in cui immagazzinare i risultati delle elaborazioni fatte; ogni serie di buffer è relativo ad una pipeline, quindi ogni TMU serve di fatto due pipelines. Il motivo della scelta è semplice: XGI ha fatto la tua stessa considerazione: meglio avere un numero di pixels in output il più elevato possibile. Non essendo possibile un'architettura 16x1, per motivi di spazio, hanno optato per due architetture con 8 pipeline e 4 TMU ciascuna.

Davvero interessante. Sembra un approccio simile a quello adottato tempo fa da Trident per l'XP 4 (che purtroppo non si rivelò gran che). E forse è anche per questo motivo che non hanno scelto di dotare ogni GPU con un bus verso la memoria di 256bit (oltre che per semplificare i collegamenti è ovvio).

Un array tipo VP10, è anch'esso composto da 16 unità FP32 (nel caso specifico del VP10 sono proprio 16), ognuno dei quali lavora, però, su un valore scalare in input e non su una coordinata scalare di un vettore.

E qui si vedono tutti i miei limiti...
Vediamo se ho capito!
In pratica un'unità VS diciamo dell'R300 può lavorare contemporaneamente su ognuna della 4 coordinate necessarie per gestire correttamente un vertice (a proposito, le coordinate sono la x, y, z e ???) e fa questo raggruppando le unità di calcolo 4 a 4. In questo contesto però un'unità di calcolo nel suo gruppo da 4 può gestire solo un determinato tipo di valore, o per lo meno le 4 unità del gruppo devono necessariamente lavorare su coordinate diverse (es: una con la x, una con la y, ecc.). In un processore come il VP10 invece questo raggruppamento non esiste e le sue unità possono gestire uno qualsiasi delle coordinate di qualsiasi vertice, quindi potremmo trovarci in un caso in cui tutte e 16 le unità di calcolo stanno calcolando la coordinata x di 16 vertici diversi.
Giusto (mmm... credo che così sia troooooppo semplice... c'è sicuramente qualcosa che mi sfugge).
Ancora: in una GPU come l'R300 ogni unità di calcolo può lavorare su qualsiasi coordinata (es: in una circostanza può ritrovarsi a lavorare con la x, in un'altra con la y, ecc.) oppure sono ottimizzate per eseguire i calcoli sempre su una determinata coordinata, ad es. sempre e solo sulla x (mi sembrerebbe strano però se fosse così...).
Un'ultima domanda: cos'è che fa perdere prestazioni (parli di 1/3) alle unità VS del VP10? A proposito credo non sia nemmeno appropriato parlare di unità VS, visto che da quello che ho capito il VP10 "costruisce" le unità a seconda dei calcoli e delle esigenze da soddisfare... giusto?

Scusatemi per la palese ignoranza e per la lunghezza del post, ma quando
ci vuole ci vuole (e che cavolo... le ultime discussioni hanno un tasso di contenuto tecnico a volte bassissimo; il 90% non sono altro che collezioni di cori da stadio! ).

CIAO!

[shodan]

Originariamente inviato da CS25
Visto che yoss ha gia' esposto il lato tecnico, per rispondere alla tua domanda mi limito a portarti un esempio piuttosto recente : FX 5600 vs FX 5700.
Come vedi a parita' di pipe e tmu in dx9 la seconda vanta guadagni prestazionali fino al 50%, il tutto grazie alla sostituzione di unita' di calcolo integer con unita' di calcolo fp.
Cio' dimostra come per questa generazione di schede sia fortemente ingannevole basarsi solo sui dati che citi tu. E' ovvio e innegabile che avere piu' pipeline o tmu possa portare dei vantaggi, ma la cosa non e' piu' automatica e proporzionale come accadeva un tempo, il tutto sempre riferendoci alle dx9.
Come ti ha sottolineato yoss, non e' consequenziale il concetto "meno pipe = meno unita' PS", il dato e' assolutamente svincolato.

Sisi CS25 su questo hai ragionissima e forse mi sono espresso male io. Volevo solo indicare che secondo me (quindi è tutto da verificare ) il numero di pipeline di rendering riveste ancora un'importanza fondamentale, anche se molto ridotta rispetto al passato (dove in pratica era il loro numero e la banda a disposizione a decretare la velocità della scheda grafica, driver a parte naturalmente).
Prova a pensare a un'ipotetica 5700 con sole due pipeline: sicuramente andrebbe molto meno.
A proposito, da qualche parte lessi un articolo molto ben fatto dove veniva dimostrato che la 5600 (e quindi suppongo anche la 5700) in realtà avevano una struttura molto flessibile, che permetteva a queste schede di comportarsi come 2x2 o 4x1 a seconda dei casi... qualcuno sa qualcosa del genere?

CIAO!

[shodan]

Originariamente inviato da yossarian
a dire la verità, l'occhio umano fa difficoltà a distinguere già oltre i 32 bit complessivi, ossia gli 8 bit per colore; utilizzando 8 bit per colore, come fa la serie FX e quasi tutti i chip precedenti (dalla Matrox Millennium II in poi), cioè la famosa profondità di colore a 32 bit a livello di frame buffer, si può notare, in casi particolari, solo un leggero effetto di banding; con l'utilizzo dei 10 bit per colore (Parhelia, VP10, R3x0), scelti, più che altro, per compatibilità con lo standard HDTV, sparisce anche l'effetto banding. Quindi i 16, i 24, i 32 bit per colore non sono affatto necessari. Quella che invece, in alcuni casi è necessaria, è la precisione di calcolo a 32 bit per canale; alcuni calcoli producono risultati solo grossolanamente approssimabili dall'utilizzo di una precisione inferiore. Questo si che può causare artefatti visibili o perdità di qualità nell'immagine. Quindi una elevata precisione di calcolo è importante in fase di elaborazione molto più che non a livello di visualizzazione.

ciao

Già, è un po' quello che succedeva mettendo a confronto l'output di una Voodoo3 o KyroII a 16 bit rispetto a quello per esempio di TNT2 e GeForce.
La Voodoo e la KyroII anche a 16 bit eseguivano internamente i calcoli a una profondita superiore (la Kyro sempre a 32 bit) e quindi, anche quando questi erano scalati a 16 bit in modo da essere "compatibili" con la profondità del framebuffer, il risultato a 16 bit era comunque migliore (a volte di molto) rispetto a quello di altre schede sempre a 16 bit (in genere le schede da me sopra menzionate offrivano un dithering molto meno visibile).
E' anche vero che la Voodoo3 aggiungeva un post-filter che poteva cambiare anche significativamente la qualità dell'output (in genere in meglio naturalmente), però credo che come esempio sia comunque valido...

CIAO!

[fek]

Originariamente inviato da ATi7500
reputo la scelta di ATi di promuovere un'architettura 8x1 molto intelligente, in quanto il multitexturing era utile in pratica quando i pixel e i vertex shader nn erano ancora diffusi, adesso si possono dare effetti strabilianti usando sempre il single texturing ke, a differenza del multi, "pesa" poco sulla banda della memoria...


bYeZ!

No, e' il contrario

Proprio adesso che si hanno a disposizione i pixel shader il multitexturing e' diventato praticamente quotidiano.
Praticamente ogni shader che ho visto o che ho scritto usa al minimo due texture, spesso tre, quattro (ne ho scritto uno con 8 accessi per passata!).

La differenza fra 4x2 e 8x1 non e' tanto data dal single o dal multitexturing ma da quanti accessi a texture si fanno in un blocco di istruzioni o, in altre parole, dal rapport fra istruzioni matematiche e accessi a texture nel pixel shader.

Faccio un esempio.

Immaginiamo di avere un pixel shader che faccia le seguenti operazioni:

1) accesso a texture
2) somma
3) somma
4) moltiplicazione
5) accesso a texture

Ed immaginiamo che la pipeline possa eseguire nello stesso colpo di clock due accessi e a texture e due operazioni matematiche (NV35).

Le istruzioni 1, 2 e 3 vengono eseguite in un colpo di clock e poi vengono eseguite le istruzioni 4 e 5.
In entrambi i casi, pur essendoci due accessi a texture nel pixel shader (multitexturing), questi vengono eseguiti in due colpi di clock sulle 4 pipeline. In pratica per ogni colpo di clock spreco un accesso a texture che mi sarebbe stato fatto gratis (relativamente).

Immaginiamo ora di avere una pipeline che esegue un accesso a texture e due operazioni matematiche (NV40) per colpo di clock, il pixel shader di cui sopra viene eseguito sempre in due colpi di clock ma usa l'hardware al massimo (non spreco nulla).

Ovviamente il secondo caso e' piu' veloce perche' ho il doppio di pipeline e quindi riesco a processare il doppio dei pixel nello stesso tempo.

[yossarian]

Originariamente inviato da shodan
Sisi CS25 su questo hai ragionissima e forse mi sono espresso male io. Volevo solo indicare che secondo me (quindi è tutto da verificare ) il numero di pipeline di rendering riveste ancora un'importanza fondamentale, anche se molto ridotta rispetto al passato (dove in pratica era il loro numero e la banda a disposizione a decretare la velocità della scheda grafica, driver a parte naturalmente).
Prova a pensare a un'ipotetica 5700 con sole due pipeline: sicuramente andrebbe molto meno.
A proposito, da qualche parte lessi un articolo molto ben fatto dove veniva dimostrato che la 5600 (e quindi suppongo anche la 5700) in realtà avevano una struttura molto flessibile, che permetteva a queste schede di comportarsi come 2x2 o 4x1 a seconda dei casi... qualcuno sa qualcosa del genere?

CIAO!

la cosa è ancora abbastanza controversa; l'architettura è una 4x1, però, in alcuni casi e, in particolare, sembrerebbe con l'applicazione di un numero dispari di texture, presenta un comportamento anomalo (strani cali prestazionali, ad esempio tra 2 e 3 texture e non tra 3 e 4, dove il calo, invece è graduale, quasi fisiologico). Questo ha indotto a pensare che, in caso di multitexturing, il comportamento sia di una 2x2 o, quantomeno, di un chip dotato di due sole pipelines di rendering. Non si tratta però di conclusioni certe, ma di speculazioni basate sull'osservazione del comportamento del chip e, pertanto, passibili di ulteriori analisi ed approfondimenti.

[checo]

Originariamente inviato da ATi7500
l'occhio umano riuscirebbe a distinguere differenze tangibili tra FP24 e FP32? o già FP24 darebbe modo di aumentare la qualità a livelli assurdi?


bYeZ!

se si spinge su fp32 credo che le differenze si vedano, al momento no, questo perchè le dx9 vengono sfruttate minimamente se si applicasse massivamente tutto quello che pùò variare il colore del pixel (luci ombre, trasparenze, bump etc) credo che si noterebbe la differenza

[checo]

Originariamente inviato da fek
No, e' il contrario

e te da dove salti fuori?
azz lavori alla lionhead!
mitico!

[yossarian]

Originariamente inviato da fek
No, e' il contrario

Proprio adesso che si hanno a disposizione i pixel shader il multitexturing e' diventato praticamente quotidiano.
Praticamente ogni shader che ho visto o che ho scritto usa al minimo due texture, spesso tre, quattro (ne ho scritto uno con 8 accessi per passata!).

La differenza fra 4x2 e 8x1 non e' tanto data dal single o dal multitexturing ma da quanti accessi a texture si fanno in un blocco di istruzioni o, in altre parole, dal rapport fra istruzioni matematiche e accessi a texture nel pixel shader.

Faccio un esempio.

Immaginiamo di avere un pixel shader che faccia le seguenti operazioni:

1) accesso a texture
2) somma
3) somma
4) moltiplicazione
5) accesso a texture

Ed immaginiamo che la pipeline possa eseguire nello stesso colpo di clock due accessi e a texture e due operazioni matematiche (NV35).

Le istruzioni 1, 2 e 3 vengono eseguite in un colpo di clock e poi vengono eseguite le istruzioni 4 e 5.
In entrambi i casi, pur essendoci due accessi a texture nel pixel shader (multitexturing), questi vengono eseguiti in due colpi di clock sulle 4 pipeline. In pratica per ogni colpo di clock spreco un accesso a texture che mi sarebbe stato fatto gratis (relativamente).

Immaginiamo ora di avere una pipeline che esegue un accesso a texture e due operazioni matematiche (NV40) per colpo di clock, il pixel shader di cui sopra viene eseguito sempre in due colpi di clock ma usa l'hardware al massimo (non spreco nulla).

Ovviamente il secondo caso e' piu' veloce perche' ho il doppio di pipeline e quindi riesco a processare il doppio dei pixel nello stesso tempo.

1 unità per texture op + 2 unità per math ops rappresentano esattamente lo stesso schema di pipeline che sta funzionando così bene sull'R3x0. Diciamo che, da questo punto di vista, nVIDIA è andata sul sicuro. Se non ci sono sorprese da altre parti (v. caso registri con la serie NV3x), stavolta le premesse sono buone.

ciao

[fek]

Originariamente inviato da yossarian
1 unità per texture op + 2 unità per math ops rappresentano esattamente lo stesso schema di pipeline che sta funzionando così bene sull'R3x0. Diciamo che, da questo punto di vista, nVIDIA è andata sul sicuro. Se non ci sono sorprese da altre parti (v. caso registri con la serie NV3x), stavolta le premesse sono buone.

ciao

Esatto. Come mi hanno detto ieri, hanno imparato dai loro errori in questa generazione. E hanno aggiunto che ne commetteranno sicuramente altri

Sono piuttosto fiducioso per questo chip.

[checo]

Originariamente inviato da fek
E hanno aggiunto che ne commetteranno sicuramente altri

come già detto il chiup dx9 definitivo è ancora lonatno sia per nv che per ati

[fek]

Originariamente inviato da checo
come già detto il chiup dx9 definitivo è ancora lonatno sia per nv che per ati

Non credo. Penso proprio che la prossima generazione sia per entrambe il "chip definitivo" per le DX9.

L'NV40 implementera' tutte del DX9.1 e sicuramente sara' lo stesso per ATI. Purtroppo sull'R4X0 non ho alcuna informazione.

[yossarian]

Originariamente inviato da fek
Non credo. Penso proprio che la prossima generazione sia per entrambe il "chip definitivo" per le DX9.

L'NV40 implementera' tutte del DX9.1 e sicuramente sara' lo stesso per ATI. Purtroppo sull'R4X0 non ho alcuna informazione.

molto dipendarà da quanto si riusciranno ad ottimizzare i cicli interni e da quanti dati sarà possibile processare ad ogni ciclo di clock; con le attuali gpu il calo di prestazioni quando si applicano più textures è ancora imbarazzante. I parametri su cui si sta lavorando e si dovrà lavorare in futuro sono proprio questi due: questo è il motivo per cui l'utilizzo di registri interni sta acquistando sempre maggiore importanza; la difficoltà è trovare un equilibrio tra le varie componenti, tenendo conto delle dimensioni fisiche del die, che non permettono di integrare tutto ciò che si vorrebbe.

[checo]

Originariamente inviato da fek
L'NV40 implementera' tutte del DX9.1 e sicuramente sara' lo stesso per ATI. Purtroppo sull'R4X0 non ho alcuna informazione.

vedremo

dico così perchè se considere che una 9800xt su un p4 da 4ghz iperovercloccato da 9000 punti al 3mark2k3 fa 50 fps nel g3 e g4

considera che il 3dmark non sfrutta massivamente le dx9

considera che aa ed aniso erano disabilitati

converrai con me che è ben distante dalll'essere il chip definitivo dx9

vedremo loki

[shodan]

Originariamente inviato da fek
No, e' il contrario

Proprio adesso che si hanno a disposizione i pixel shader il multitexturing e' diventato praticamente quotidiano.
Praticamente ogni shader che ho visto o che ho scritto usa al minimo due texture, spesso tre, quattro (ne ho scritto uno con 8 accessi per passata!).

La differenza fra 4x2 e 8x1 non e' tanto data dal single o dal multitexturing ma da quanti accessi a texture si fanno in un blocco di istruzioni o, in altre parole, dal rapport fra istruzioni matematiche e accessi a texture nel pixel shader.

Faccio un esempio.

Immaginiamo di avere un pixel shader che faccia le seguenti operazioni:

1) accesso a texture
2) somma
3) somma
4) moltiplicazione
5) accesso a texture

Ed immaginiamo che la pipeline possa eseguire nello stesso colpo di clock due accessi e a texture e due operazioni matematiche (NV35).

Le istruzioni 1, 2 e 3 vengono eseguite in un colpo di clock e poi vengono eseguite le istruzioni 4 e 5.
In entrambi i casi, pur essendoci due accessi a texture nel pixel shader (multitexturing), questi vengono eseguiti in due colpi di clock sulle 4 pipeline. In pratica per ogni colpo di clock spreco un accesso a texture che mi sarebbe stato fatto gratis (relativamente).

Immaginiamo ora di avere una pipeline che esegue un accesso a texture e due operazioni matematiche (NV40) per colpo di clock, il pixel shader di cui sopra viene eseguito sempre in due colpi di clock ma usa l'hardware al massimo (non spreco nulla).

Ovviamente il secondo caso e' piu' veloce perche' ho il doppio di pipeline e quindi riesco a processare il doppio dei pixel nello stesso tempo.

E' proprio questo che intendevo quando prima ho postato scrivendo che secondo me la capacità di applicare velocemente più texture ad un pixel, e quindi il fill rate (dato da un calcolo SOLO TEORICO dal risultato di n.° pipeline x TMU di ogni pipe) è ancora molto importante (anche se come abbiamo detto prima è in parte ridimensionato): con l'uso di shader dalle possibilità sempre più elevate è normale che si utilizzi un maggior numero di texture per fornire effetti sempre più strabilianti. Questo fino a quando non useremo tutti allegramente texture frattali... ma credo che per questo dovremo aspettare un bel po'!

CIAO!

[shodan]

Yossarian posso farti una domada?
Vedo che parli spesso di recirculating pipeline... potresti spiegarmi cosa sono e che vantaggi/svataggi apportano?

Ciao e grazie.

[fek]

Originariamente inviato da checo
dico così perchè se considere che una 9800xt su un p4 da 4ghz iperovercloccato da 9000 punti al 3mark2k3 fa 50 fps nel g3 e g4

considera che il 3dmark non sfrutta massivamente le dx9

No no, io non considero proprio il 3d mark... e' la cosa piu' inutile del mondo

Originariamente inviato da shodan
Questo fino a quando non useremo tutti allegramente texture frattali... ma credo che per questo dovremo aspettare un bel po'!

CIAO!

Direi un tempo infinito

[tiranium 4200]

Originariamente inviato da checo
vedremo

dico così perchè se considere che una 9800xt su un p4 da 4ghz iperovercloccato da 9000 punti al 3mark2k3 fa 50 fps nel g3 e g4

considera che il 3dmark non sfrutta massivamente le dx9

considera che aa ed aniso erano disabilitati

converrai con me che è ben distante dalll'essere il chip definitivo dx9

vedremo loki

un test schifoso cosi, con motori ottimizzati col cul@ nn è da prendere in considerazione come abdra un gioco, poi nn è manco dx9 e pure scatta, ma siamo fuori? quelli della futuremark so stupidi inbecilli. ci prendono in giro, o forse c'è l'allenaza futuremark,nvidia,ati cosi la gente stupida vede che i test vanno a 5 fps e si comprano la scheda da 1000 €

[yossarian]

Originariamente inviato da shodan
Yossarian posso farti una domada?
Vedo che parli spesso di recirculating pipeline... potresti spiegarmi cosa sono e che vantaggi/svataggi apportano?

Ciao e grazie.

in breve, si tratta di un approccio diverso nei confronti delle elaborazioni multipass. Sono delle pipelines molto lunghe, con unità di calcolo che effettuano, ciascuna, solo parte delle operazioni necessarie all'elaborazione completa di un pixel, disseminate lungo la pipeline. Fanno uso massiccio di operazioni di loop back, ossia, quando i dati arrivano sul fondo della pipeline, se l'elaborazione non è completa, sono re-indirizzati di nuovo in cima alla stessa pipeline per passare nuovamente attraverso le unità di calcolo necessarie a completare l'elaborazione. Il funzionamneto è analogo alle pipelines tradizionali, con la differenza, però, che nelle recirculating pipelines, i dati sono fatti circolare in modo pressochè continuo (cioè i tempi di stasi all'interno di registri temporanei, in attesa di essere richiamati per l'elaborazione) sono ridotti al minimo; perciò è necessario servirsi di pipelines molto lunghe e coordinare l'input in modo che non si formino bolle, ossia momenti in cui ci sono unità disoccupate, oppure code d'attesa. I vantaggi principali sono: ridotto utilizzo di registri interni rispetto ad una pipeline tradizionale che svolge lo stesso quantitativo di calcoli; ridotto numero di accessi al frame buffer (questo ha indotto nVIDIA, erroneamente, in questo caso, a pensare che per l'NV30 fosse sufficiente un bus a 128 bit). Gli svantaggi principali sono invece: texture buffer di dimensioni maggiori (parlo di quello allocato nel frame buffer), perchè più texture sono chiamate iin ballo durante un singolo passaggio d'elaborazione, e possibilmente frazionato in più parti, con possibilità di effettuare texture spilling da più cache); numero di variabili interne contemporanee e di cicli possibili per l'elaborazione multipass limitati, rispettivamente, dalla capacità dei registri temporanei presenti all'interno del chip e dalle dimensioni della state table (limitazioni che, invece, sono superabili con l'adozione di un certo numero di registri interni o esterni, in modalità FIFO, in cui appoggiare temporaneamente i risultati intermedi dell'elaborazione, come ha fatto ATi con l'f-buffer; ovviamente, però, in caso di utilizzo di f-buffers esterni, ossia nel frame buffer, si ha lo svantaggio di essere obbligati ad accessi multitpli alla ram video, con rallentamento delle operazioni e calo del frame rate. I due approcci, f-buffer e recirculating pipelines, di fatto, possono essere combinati in maniera opportuna per tentare di superare i limiti intrinseci di entrambi).

ciao