4x2 = 8x1?

[REPSOL]

Texture frattali? Mi spiegate che roba è?

THX

Ciaoz

[yossarian]

Originariamente inviato da REPSOL
Texture frattali? Mi spiegate che roba è?

THX

Ciaoz

texture che non vengono prelevate dal texture buffer ma generate "al volo" tramite appositi algoritmi che, attraverso procedure di tipo iterativo (si chiamano anche textures procedurali), arrivino a creare superfici che simulino quelle reali (muri, legno, metalli)ì, ecc).
La cosa non solo è possibile, ma anche funzionante; molti SW che si propongono la creazione di immagini fotorealistiche. Il problema è che, allo stato attuale, questo metodo è poco pratico da applicare con i giochi (le textures frattali permettono un enorme risparmio di bandwidth, ma rappresentano, nei casi di funzioni più complesse, un coìpo mortale alla velocità d'elaborazione dei chip)

ciao

[ATi7500]

ma guarda un po...io credevo che invece fosse in un altro modo:

il single texturing consente di applicare una texture per passata, il multi consente di applicarne più di una...ora più texture "sovrapposte" danno un'immagine via via migliore e ricca d'effetti..

pensavo ke l'innovazione del pixel shader fosse proprio quella di applicare effetti particolari andando aad agire sul pixel di ciascuna texture, e quindi ke bastasse solo una texture e su di essa agire con il pixel shader...credevo cioè ke ogni pixel avesse già le caratteristiche ke si volevano applicare nel momento stesso ke si applicavano...


bYeZ!

[fek]

Originariamente inviato da ATi7500
ma guarda un po...io credevo che invece fosse in un altro modo:

il single texturing consente di applicare una texture per passata, il multi consente di applicarne più di una...ora più texture "sovrapposte" danno un'immagine via via migliore e ricca d'effetti..

pensavo ke l'innovazione del pixel shader fosse proprio quella di applicare effetti particolari andando aad agire sul pixel di ciascuna texture, e quindi ke bastasse solo una texture e su di essa agire con il pixel shader...credevo cioè ke ogni pixel avesse già le caratteristiche ke si volevano applicare nel momento stesso ke si applicavano...


bYeZ!

Una texture in realta' non e' (piu') quello che si pensa comunemente, un'immagine 2D da spalmare su un oggetto.

Una texture e' una matrice di valori ed il programmatore attraverso il codice del pixel shader da' a questi valori un significato. Posso avere una matrice di colori (la classica texture), ma posso anche avere una matrice che mi rappresenta la profondita' dell'acqua, oppure una tabella che mi calcola una funzione matematica a partire da tre input, etc etc.

Se ti ricordi la demo nvidia con l'elfa che balla, per disegnare la pelle, usano una texture che rappresenta il fluire del sangue sotto la pelle col quale calcolano il colore della pelle stessa.

Si puo' usare una texture che serve per normalizzare un vettore ad esempio: dai in pasto alla texture il vettore come coordinate e ti sputa fuori lo stesso vettore normalizzato.

Ovviamente se provi a disegnare a video questa texture, non ha alcun significato "visivo" perche' non e' fatta di colori, ma di vettori.

Una texture, in generale, e' una funzione che mappa 1/2/3 input in 1/2/3 output (texture1D/2D/3D).

Un pixel shader prende un certo numero di texture, fa delle operazioni matematiche con i valori che escono da queste texture e calcola un colore da mandare a video.

[ATi7500]

quindi se ho capito bene i pixel shader sono operazioni di multitexturing in pratica...


bYeZ!

[fek]

Originariamente inviato da ATi7500
quindi se ho capito bene i pixel shader sono operazioni di multitexturing in pratica...


bYeZ!

Si', puoi pensarla cosi'
Ma tutto il modo di programmare 3d e' cambiato con l'introduzione dei PS, non si parla piu' di multitexturing, ma di programmi eseguiti per ogni pixel, dove un programma ha degl'input e gl'input, nel caso del pixel shader, sono le texture.

[ATi7500]

Originariamente inviato da fek
Si', puoi pensarla cosi'
Ma tutto il modo di programmare 3d e' cambiato con l'introduzione dei PS, non si parla piu' di multitexturing, ma di programmi eseguiti per ogni pixel, dove un programma ha degl'input e gl'input, nel caso del pixel shader, sono le texture.

cioè c'è molta più "dinamicità" nel programmare...
guarda, io all'uni studio filosofia, quindi di calcoli puramente matematici nn ci capisco moltissimo anke se cmq vengo da uno scientifico e qualcosa in testa mi entra ma mi sta affascinando proprio l'ideale tt "filosofico" ke sta dietro al mondo del 3D...numeri e funzioni ke si trasformano in effetti strabilianti...l'uomo crea attraverso la matematica...tutto ciò è stupendo ai miei occhi!
come dici nella tua sign, si è in grado di "creare le proprie visioni"
grazie ancora per le spiegazioni


bYeZ!

[ATi7500]

edit sorry

[shodan]

Originariamente inviato da yossarian
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

Davvero interessante.
Ma allora schede come KyroII e Radeon8500 (che in una passata potevano applicare 6, 8 o più texture usando più cicli di clock essendo in grado di "tornare indietro" senza passare per il frame buffer) utilizzavano già una sorta di recirculating pipe? Certo molto semplice, mentre l'R300 è già in grado di effetture un loop-back all'inizio se non sbaglio 16 volte. Nell'NV30 invece se ho ben capito questo concetto è portato all'estremo, con una possibilità di loop-back virtualmente infinita (o comunque molto alta).

CIAO!

[yossarian]

Originariamente inviato da shodan
Davvero interessante.
Ma allora schede come KyroII e Radeon8500 (che in una passata potevano applicare 6, 8 o più texture usando più cicli di clock essendo in grado di "tornare indietro" senza passare per il frame buffer) utilizzavano già una sorta di recirculating pipe? Certo molto semplice, mentre l'R300 è già in grado di effetture un loop-back all'inizio se non sbaglio 16 volte. Nell'NV30 invece se ho ben capito questo concetto è portato all'estremo, con una possibilità di loop-back virtualmente infinita (o comunque molto alta).

CIAO!

no, esiste un altro approccio, che poi è anche quello seguito da ATi con l'R3x0, che, comunque, ha pipelines più lunghe dell'R200 o del Kyro2. Questo secondo approccio consiste nell'utilizzo di un maggior numero di registri interni in cui immagazzinare tutti i dati relativi alle elaborazioni intermedie e non solo parte di essi. Secondo tale approccio, ad esempio, in un multipass rendering, durante il primo ciclo viene elaborata, diciamo una delle 4 texture da applicare; il risultato dell'elaborazione è depositato in un texture buffer temporaneo. I dati relativi al pixel sono nuovamente prelevati e ripassano all'interno della pipeline, per l'elaborazione della texture successiva che viene sovrapposta alla prima, all'interno di un combinatore; si procede così fino all'elaborazione dell'ultima texture. La differenza rispetto alle recirculating pipelines è che, nelle seconde, i dati sono in movimento continuo (o quasi) e le unità di elaborazione sono di tipo distribuito e non concentrato; di conseguenza, in una recirculating pipe un'elaborazione, per essere completa, dovrà passare attraverso molti più stadi rispetto ad una pipeline tradizionale. Si ha però il vantaggio di poter eseguire più operazioni in contemporanea, rispetto ad una pipeline tradizionale, a patto di avere un sufficiente numero di variabili e parametri da poter mettere in gioco nello stesso momento. Da ciò si deduce che una recirculating pipeline ha meno bisogno di ampi registri interni, ma comunque non può prescindere dal loro utilizzo, perchè questi ultimi determinano il numero di parametri che è possibile utilizzare in contemporanea.

spero di averti chiarito le idee.

comunque, quella delle recirculating pipelines non è una innovazione; questo tipo di tecnica è nota già da diverso tempo, solo che non era mai stata utiizzata su una GPU (d'altra parte pochi sanno che il primo processore grafico ad effettuare multitexturing utilizzando buffer interni è stato il Rage 128 che con una sola pipeline ed una sola TMU poteva applicare o 2 texture per pixel o 1 texture su 2 differenti pixels per single pass)

[shodan]

Originariamente inviato da yossarian
no, esiste un altro approccio, che poi è anche quello seguito da ATi con l'R3x0, che, comunque, ha pipelines più lunghe dell'R200 o del Kyro2. Questo secondo approccio consiste nell'utilizzo di un maggior numero di registri interni in cui immagazzinare tutti i dati relativi alle elaborazioni intermedie e non solo parte di essi. Secondo tale approccio, ad esempio, in un multipass rendering, durante il primo ciclo viene elaborata, diciamo una delle 4 texture da applicare; il risultato dell'elaborazione è depositato in un texture buffer temporaneo. I dati relativi al pixel sono nuovamente prelevati e ripassano all'interno della pipeline, per l'elaborazione della texture successiva che viene sovrapposta alla prima, all'interno di un combinatore; si procede così fino all'elaborazione dell'ultima texture. La differenza rispetto alle recirculating pipelines è che, nelle seconde, i dati sono in movimento continuo (o quasi) e le unità di elaborazione sono di tipo distribuito e non concentrato; di conseguenza, in una recirculating pipe un'elaborazione, per essere completa, dovrà passare attraverso molti più stadi rispetto ad una pipeline tradizionale. Si ha però il vantaggio di poter eseguire più operazioni in contemporanea, rispetto ad una pipeline tradizionale, a patto di avere un sufficiente numero di variabili e parametri da poter mettere in gioco nello stesso momento. Da ciò si deduce che una recirculating pipeline ha meno bisogno di ampi registri interni, ma comunque non può prescindere dal loro utilizzo, perchè questi ultimi determinano il numero di parametri che è possibile utilizzare in contemporanea.

spero di averti chiarito le idee.

Allora vediamo se ho capito...
In pratica le pipeline tradizionali immagazzinano in un buffer, alla fine del primo loop, lo stato COMPLETO del pixel (es: con applicata una texture). Fatto questo il buffer viene riletto e viene proseguito l'elaborazione.
Questo prevede che il buffer sia abbastanza grande da contenere il risultato dell'elaborazione del pixel.
In una recirculating pipe invece abbiamo le unità operative "spalmate" all'interno di pipe più lunge (superpipeline ???) che non hanno bisogno di immagazzinare in buffer intermedi il risultato delle elaborazioni ma sono in grado di passare questi dati direttamente all'inizio della pipeline stessa alla fine del ciclo. I buffer sono comunque necessari per contenere i dati che aspettano di entrare nel ciclo delle recirculating pipeline (o meglio nel tunnel della droga ).
Mi ci sono perlomeno avvicinato?

comunque, quella delle recirculating pipelines non è una innovazione; questo tipo di tecnica è nota già da diverso tempo, solo che non era mai stata utiizzata su una GPU (d'altra parte pochi sanno che il primo processore grafico ad effettuare multitexturing utilizzando buffer interni è stato il Rage 128 che con una sola pipeline ed una sola TMU poteva applicare o 2 texture per pixel o 1 texture su 2 differenti pixels per single pass)

Eheh è una delle poche cose che sapevo...

Grazie mille delle spiegazioni (passate e future ).

CIAO!

[yossarian]

Originariamente inviato da shodan
Allora vediamo se ho capito...
In pratica le pipeline tradizionali immagazzinano in un buffer, alla fine del primo loop, lo stato COMPLETO del pixel (es: con applicata una texture). Fatto questo il buffer viene riletto e viene proseguito l'elaborazione.
Questo prevede che il buffer sia abbastanza grande da contenere il risultato dell'elaborazione del pixel.
In una recirculating pipe invece abbiamo le unità operative "spalmate" all'interno di pipe più lunge (superpipeline ???) che non hanno bisogno di immagazzinare in buffer intermedi il risultato delle elaborazioni ma sono in grado di passare questi dati direttamente all'inizio della pipeline stessa alla fine del ciclo. I buffer sono comunque necessari per contenere i dati che aspettano di entrare nel ciclo delle recirculating pipeline (o meglio nel tunnel della droga ).
Mi ci sono perlomeno avvicinato?

si, diciamo che, grosso modo, le cose funzionano così. Il rischio maggiore delle recirculating pipeline è la creazione di bolle (unità di elaborazione inattive) o di code eccessivamente lunghe per le capacità dei registri temporanei. Il vantaggio, come ho detto, è la possibilità di lavorare contemporaneamente su "più fronti".

ciao

[mg13]

Mi sono letto tutto il 3d e devo fare i miei complimenti ragazzi alla vostra preparazione.
Visto la Vs. competenza in materia come la giudicate la Matrox Parhelia, con GPU a 512 bit(per il momento l'unica al mondo se non erro) e le varie caratteristiche che sicuramente conoscete?
Ciao e grazie.

[Redvex]

La parhelia x quanto riguarda l'aspetto videoludico è stato un flop clamoroso.

[ATi7500]

Originariamente inviato da Redvex
La parhelia x quanto riguarda l'aspetto videoludico è stato un flop clamoroso.

in una riga l'hai ucciso
cmq ottima architettura la parhelia ma frequenze troppo basse per supportarla alla perfezione...


bYeZ!

[Norbrek™]

Originariamente inviato da yossarian
texture che non vengono prelevate dal texture buffer ma generate "al volo" tramite appositi algoritmi che, attraverso procedure di tipo iterativo (si chiamano anche textures procedurali), arrivino a creare superfici che simulino quelle reali (muri, legno, metalli)ì, ecc).
La cosa non solo è possibile, ma anche funzionante; molti SW che si propongono la creazione di immagini fotorealistiche. Il problema è che, allo stato attuale, questo metodo è poco pratico da applicare con i giochi (le textures frattali permettono un enorme risparmio di bandwidth, ma rappresentano, nei casi di funzioni più complesse, un coìpo mortale alla velocità d'elaborazione dei chip)

ciao

Magnifico 3d complimenti a tutti!
Mi interessa questa cosa delle texture frattali, come mai con questo tipo di texture si può ottenere un realismo superiore rispetto alle texture prelevate dal texture buffer come usano le schede odierne?

[shodan]

Originariamente inviato da mg13
Mi sono letto tutto il 3d e devo fare i miei complimenti ragazzi alla vostra preparazione.
Visto la Vs. competenza in materia come la giudicate la Matrox Parhelia, con GPU a 512 bit(per il momento l'unica al mondo se non erro) e le varie caratteristiche che sicuramente conoscete?
Ciao e grazie.

Per quello che riguarda il multitexturing la parhelia è avanzatissima, in quanto ha 4 pipe ognuna con 4 TMU (in pratica si hanno fino a 16 Texture/clock).
Putroppo però nei giochi in genere il multitexute viene utilizzato a 2 livelli e spesso molti oggetti del gioco non hanno nemmeno più di una texture (si pensi al primo test del 3DMark 2003).

A proposito ragazzi, non ricordo se in questa discussione però parlando uscì fuori che il Volari Duo V8 Ultra che ha 16 pipeline in realtà ha solo 8 TMU in totale, quindi due pipeline "condividono" la stessa TMU. Si hanno notizie più precise in merito ora? Secondo voi che vantaggi/svantaggi può portare una scelta del genere (anche il Trident XP4 doveva usare un'architettura in cui le pipeline condividevano molti elementi tra di loro ma poi il chip non si rivelò molto performante...)

Per quello che riguarda le texture frattali, i vantaggi principali stanno nella ridotta quantità di memoria che usano (non immagazzinano una immagine o tabella di valori che dir si voglia; esse non sono altro che una o più funzioni matematiche che restituiscono dei valori) e nella possibilità di avere texture di risoluzione infinita (in pratica anche un singolo pixel può essere ingradito fino a riempire tutto lo schermo senza che ciò porti a un decadimento della qualità della texture su esso rappresentata).

CIAO!

[JENA PLISSKEN]

Certo ke leggere questo thread alle 2.15 è come farsi di acido....complimenti ragazzi mi avete inseganto parekkie cose...
TNX

P\S
per sicurezza me lo rileggo con calma domani

[yossarian]

Originariamente inviato da shodan
Per quello che riguarda il multitexturing la parhelia è avanzatissima, in quanto ha 4 pipe ognuna con 4 TMU (in pratica si hanno fino a 16 Texture/clock).
Putroppo però nei giochi in genere il multitexute viene utilizzato a 2 livelli e spesso molti oggetti del gioco non hanno nemmeno più di una texture (si pensi al primo test del 3DMark 2003).

A proposito ragazzi, non ricordo se in questa discussione però parlando uscì fuori che il Volari Duo V8 Ultra che ha 16 pipeline in realtà ha solo 8 TMU in totale, quindi due pipeline "condividono" la stessa TMU. Si hanno notizie più precise in merito ora? Secondo voi che vantaggi/svantaggi può portare una scelta del genere (anche il Trident XP4 doveva usare un'architettura in cui le pipeline condividevano molti elementi tra di loro ma poi il chip non si rivelò molto performante...)

Per quello che riguarda le texture frattali, i vantaggi principali stanno nella ridotta quantità di memoria che usano (non immagazzinano una immagine o tabella di valori che dir si voglia; esse non sono altro che una o più funzioni matematiche che restituiscono dei valori) e nella possibilità di avere texture di risoluzione infinita (in pratica anche un singolo pixel può essere ingradito fino a riempire tutto lo schermo senza che ciò porti a un decadimento della qualità della texture su esso rappresentata).

CIAO!

Il problema della Parhelia nell'effettuare multitexturing è che non fa uso di buffer interni per immagazzinare i dati intermedi dell'elaborazione; di conseguenza va bene fino a che non si utilizzano più di 4 texel per pixel per ogni passata (e in questo caso è l'unica ariuscire ad applicare i texel necessari in un solo ciclo di clock, mentre l'R3x0 ha bisogno di 4 cicli e l'NV3x di 2, ad esempio); quando si superano i 4 texels, però, la Parhelia deve ricorrere al frame buffer (cioè deve inviare i dati alla ram video) mentre R3x0 e NV3x possono continuare ad eleborare fino a 16 texels per passata, lavorando all'interno del chip, senza dover inviare i dati alla ram); questo rappresenta un notevole vantaggio in termini di prestazioni. Lo dimostra anche la scelta fatta da XGI per il Volari: utilizzare 8 TMU con 16 pipeline permette, potendo immagazzianre on chip i risultati intermedi dell'elaborazione, di avere un output di 16 pixel per single pass, anche non essendo riusciti a realizzare un'architettura 16x1. Uno dei vantaggi dell'R3x0 sull'NV3x, anche se non il più importante, è proprio quello di riuscire a elaborare 8 pixel per single pass contro i 4 dell'NV3x. Ovviamente questo vale in linea teorica; in pratica anche la velocità di elaborazione "on chip" può essere influenzata da tenti fattori (uno dei più importanti è proprio quello dei registri interni, soprattutto quelli temporanei)

[mg13]

Quindi se non ho capito male l'architettura della Parhelia non è proprio un flop, certo se avesse più velocità di clock sia il chip che la memoria potrebbe forse competere con i due mostri ati e nvidia?