4x2 = 8x1?

[shodan]

Originariamente inviato da yossarian
no, infatti, il principale motivo per cui la Parhelia viene considerata "solo" PS1.3 compliant è proprio la sua incapacità di applicare più di 4 texture per single pass; questo pur essendo, per molti altri aspetti, molto più avanzata delle DX8.1. Ad esempio ha 256 registri di tipo INT (non temporanei), esattamente quanti ne hanno NV30 e R300 (si tratta del numero minimo previsto per i PS2.0) e le pipeline lavorano in FP24 (come quelle dell'R300).



si, in assetto 2x4 andrebbero "perse" 8 TMU complessive, ma questo viene fatto quando si è in presenza di molti calcoli algebrici e poche texture. Questo perchè ogni due pipeline sono pilotate da una sorta di controller dei dati in input che gestisce la configurazione delle pipeline.
Si, si tratta delle unità PS




lo farei volentiri se mi riuscissi a ripescarle (su nV Italia di discussioni su NV30 e R300 di questo tenore se ne sono fatte a iosa e non mi ricordo neppure qual è la discussione a cui fa riferimento pandyno, anche se mi ricordo bene che era venuta fuori la storia del full FP32 per l'R3x0)

ciao

Ok, hai fatto luce nella mia mente!!
Quindi in presenza di molti calcoli logici la parhelia è "costretta" a utilizzare una configurazione 2x4 perchè non ha buffer interni in cui immagazzinare un risultato intermedio prodotto dalle unità logiche? Cioè, non bastando i 5 stage di una singola unità PS l'unico modo che ha per completare il calcolo senza far ricorso al framebuffer è quello mi "accodare" una pipe all'altra in modo da portare gli stage totali a 10 per pipe, giusto?

[EDIT]:
Ho letto tutto d'un fiato la discussione postata da te e pandyno, grazie mille!!!
C'è una cosa che però mi è poco chiara: in un pasaggio parli delle differenze tra FP24 e FP16, facendo giustamente notare che con la seconda ci potrebbero essere delle alterazioni dovute all'ingrandimento sempre maggiore degli errori dovuti all'arrotandamento. Fai notare inoltre che la modalità FP16 rappresenta solo 65536 colori.
A questo punto però mi viene in mente che i 65536 colori sono PER CANALE, e quindi sono comunque davvero una quantità elevatissima rispetto ai nostri 32 bit complessivi (8+8+8+8 in genere). Davvero con una profondità di colore così alta (65536 colori per canale) potremmo assistere a fenomeni di degradazione della qualità d'immagine?
[FINE EDIT]

Scusa se ti stresso, ma hai sempre una risposta e quindi è normale che io ti faccia domande!!!

Ciao e grazie.

PS: grazie anche per il link, sia a te che a pandyno!

[shodan]

UP!

[Redvex]

Credo ke molto dipenda anke dalla fase di allineamento di Marte rispetto a Giove

[checo]

Originariamente inviato da shodan

[EDIT]:
Ho letto tutto d'un fiato la discussione postata da te e pandyno, grazie mille!!!
C'è una cosa che però mi è poco chiara: in un pasaggio parli delle differenze tra FP24 e FP16, facendo giustamente notare che con la seconda ci potrebbero essere delle alterazioni dovute all'ingrandimento sempre maggiore degli errori dovuti all'arrotandamento. Fai notare inoltre che la modalità FP16 rappresenta solo 65536 colori.
A questo punto però mi viene in mente che i 65536 colori sono PER CANALE, e quindi sono comunque davvero una quantità elevatissima rispetto ai nostri 32 bit complessivi (8+8+8+8 in genere). Davvero con una profondità di colore così alta (65536 colori per canale) potremmo assistere a fenomeni di degradazione della qualità d'immagine?
[FINE EDIT]

sono 16 bit per canale, ma non visualizzati, si usano 16 bit per calcolare il colore, ma in questi 16 rientrano trasparenze etc-

[shodan]

Originariamente inviato da checo
sono 16 bit per canale, ma non visualizzati, si usano 16 bit per calcolare il colore, ma in questi 16 rientrano trasparenze etc-

Si questo è vero, però se penso che oggi lavoriamo con soli 8bit per canale, 16 bit per canale mi sembrano gia taaaanti!!!
E sono sorpreso che anche a questa profondità di colore si possano avere degli errori significativi dovuti a approssimazioni troppo grandi.
Tutto ciò non può che far riflettere sull'enorme sviluppo che si sta avendo nel campo della grafica 3D... chissa se tra qualche generazione di chip avremo una di quelle stazioni per la realtà virtuale nel palmo di una mano (o meglio dentro il case! ).

CIAO!

[checo]

cosa intendi per oggi lavoriamo a 8 bit per canale?

[shodan]

Originariamente inviato da checo
cosa intendi per oggi lavoriamo a 8 bit per canale?

Mmm... in effetti mi fai riflettere. Nelle specifiche DX8, relativamente ai PS si utilizzano calcoli di tipo integer, però mi sembra che anche in questo caso i bit per canale possano essere 16 o 12...
Nelle sche un po' vecchiotte però (tipo le voodoo o le GF2) mi risulta che i dati internamente vengano elaborati utilizzando complessivamente 32 bit per pixel, quindi 8 bit per canale.
In ogni caso, ciò che mi sorprende è il fatto che anche con l'FP16 (quindi sedici bit per canale con tipo floating point) ci siano notevoli problemi di approssimazione: cavolo sono 65536 sfumature per canale! Davvero tanto, o almeno pensavo...

CIAO!

[pandyno]

8+8+8+8=32bit

Qualche tempo fa (secoli) veniva mostrato il game 4 presumibilmente in FP16 su di una FX, beh la differenza si vedeva eccome rispetto FP24 di R3xx.

[shodan]

Originariamente inviato da pandyno
8+8+8+8=32bit

Qualche tempo fa (secoli) veniva mostrato il game 4 presumibilmente in FP16 su di una FX, beh la differenza si vedeva eccome rispetto FP24 di R3xx.

Sisi che la differenza ci sia non lo metto in dubbio, ci mancherebbe!!!
Quello che mi sorprende è solo che, nonostante la 65536 sfumature per canale, queste differenze siano così evidenti come in quella comparazione da te indicata (ricordo di aver visto le due immagini una di fianco all'altra e in effetti le differenze c'erano, anche se non sono sicuro se fossero il risultato anche di altre ottimizzazioni di nvidia...).

CIAO!

[fek]

Originariamente inviato da shodan
In ogni caso, ciò che mi sorprende è il fatto che anche con l'FP16 (quindi sedici bit per canale con tipo floating point) ci siano notevoli problemi di approssimazione: cavolo sono 65536 sfumature per canale! Davvero tanto, o almeno pensavo...

CIAO!

Fai bene a sorprenderti perche' queste differenze praticamente non esistono negli shader con la lunghezza di oggi. Shader piu' lunghi non verrebbero eseguiti a dovere sulle attuali architetture.

16 bit per canale (e non per colore, quindi non stiamo parlando di 65k colori), sono piu' che sufficienti al giorno d'oggi. Per poter apprezzare le differenze fra 16 e 32 bit per canale servirebbero molte approssimazioni, quindi molte operazioni quindi shader molto lunghi, che, come ho detto prima, non sarebbero comunque eseguibili in pratica in maniera soddisfacente.

[shodan]

Originariamente inviato da fek
Fai bene a sorprenderti perche' queste differenze praticamente non esistono negli shader con la lunghezza di oggi. Shader piu' lunghi non verrebbero eseguiti a dovere sulle attuali architetture.

16 bit per canale (e non per colore, quindi non stiamo parlando di 65k colori), sono piu' che sufficienti al giorno d'oggi. Per poter apprezzare le differenze fra 16 e 32 bit per canale servirebbero molte approssimazioni, quindi molte operazioni quindi shader molto lunghi, che, come ho detto prima, non sarebbero comunque eseguibili in pratica in maniera soddisfacente.

Quindi nei giochi odierni (o meglio in quelli a venire a breve) usare FP16 o FP24 o FP32 non dovrebbe comportare un decadimento della qualità visiva? Allora nel Game 4 del 3DMark il decadimento della qualità era dato per lo più da orrimizzazioni specifiche, non dalla diminuizione della precisione di calcolo, giusto?

Un'altra domanda (visto il tuo sapere ti sfrutto un po ): le schede DX7 (come il GeForce) usano 8 bit per canale giusto? Mentre la DX8 sfruttano anche 12 o 16 bit per canale (sempre calcoli di tipo int però)? Se si questa maggiore precisione è presente all'interno delle unità PS o anche in nelle operazioni di texturing semplici (quelle che non richiedono l'intervento delle unità PS)?. E infine, una domanda forse stupida: nelle moderne schede DX8 e DX9 le operazioni di texturing (il fetch e l'applicazione della texture ad esempio) vengono fatte dalle unità PS oppure no (credo la risposta giusta sia la seconda, vero?)?

Grazie e scusa per le interminabili domande!

[yossarian]

Originariamente inviato da shodan
Quindi nei giochi odierni (o meglio in quelli a venire a breve) usare FP16 o FP24 o FP32 non dovrebbe comportare un decadimento della qualità visiva? Allora nel Game 4 del 3DMark il decadimento della qualità era dato per lo più da orrimizzazioni specifiche, non dalla diminuizione della precisione di calcolo, giusto?

Un'altra domanda (visto il tuo sapere ti sfrutto un po ): le schede DX7 (come il GeForce) usano 8 bit per canale giusto? Mentre la DX8 sfruttano anche 12 o 16 bit per canale (sempre calcoli di tipo int però)? Se si questa maggiore precisione è presente all'interno delle unità PS o anche in nelle operazioni di texturing semplici (quelle che non richiedono l'intervento delle unità PS)?. E infine, una domanda forse stupida: nelle moderne schede DX8 e DX9 le operazioni di texturing (il fetch e l'applicazione della texture ad esempio) vengono fatte dalle unità PS oppure no (credo la risposta giusta sia la seconda, vero?)?

Grazie e scusa per le interminabili domande!

no, in effetti, tranne alcuni casi particolari, allo stato attuale 16 bit per canale sono sufficienti ad ottenere una buona approssimazione. Come ha detto fek, il problema sorge nell'esecuzione di shader più lunghi: un gran numero di istruzioni consecutive, dipendenti le une dai risultati delle altre, potrebbero dar luogo al problema della crescitas incontrollata del termine d'errore. Questo problema è, invece, di minore rilevanza quando l'approssimazione si effettua sull'ultima operazione; questo è il motivo per cui è possibile utilizzare nel frame buffer, 8 o 10 bit per canale anche se a livello di pipeline si utilizzano 16, 24 o 32 bit per canale, senza che il risultato sia troppo "degradato".
La maggior precisione è presente anche a livello di operazioni sulle texture.
Le operazioni sulle texture non sono eseguite dalle unità definite "strettamente" PS, ma da unità di calcolo dedicate che, in alcuni casi, (p.es. nell'NV3x) non hanno funzionamento indipendente dalle unità logiche, poichè hanno con esse alcuni elementi (registri temporanei) condivisi e non utilizzabili contemporaneamente da entrambe.

Sulla Parhelia e sull'utilizzo dell'architettura 2x4 c'è da dire che si tratta di una scelta dei progettisti che non è dettata solo dall'esigenza di svolgere più operazioni logiche anche in assenza di buffer interni; si tratta anche di una scelta che permette di aumentare la velocità di elaborazione del chip, poichè ogni pipeline risulta capace di 10 operazioni vettoriali di tipo logico contemporanee, contro le 2 dell'R3x0 e le 3 dell'NV3x (in assenza di texture fetch).

[shodan]

Originariamente inviato da yossarian
no, in effetti, tranne alcuni casi particolari, allo stato attuale 16 bit per canale sono sufficienti ad ottenere una buona approssimazione. Come ha detto fek, il problema sorge nell'esecuzione di shader più lunghi: un gran numero di istruzioni consecutive, dipendenti le une dai risultati delle altre, potrebbero dar luogo al problema della crescitas incontrollata del termine d'errore. Questo problema è, invece, di minore rilevanza quando l'approssimazione si effettua sull'ultima operazione; questo è il motivo per cui è possibile utilizzare nel frame buffer, 8 o 10 bit per canale anche se a livello di pipeline si utilizzano 16, 24 o 32 bit per canale, senza che il risultato sia troppo "degradato".
La maggior precisione è presente anche a livello di operazioni sulle texture.
Le operazioni sulle texture non sono eseguite dalle unità definite "strettamente" PS, ma da unità di calcolo dedicate che, in alcuni casi, (p.es. nell'NV3x) non hanno funzionamento indipendente dalle unità logiche, poichè hanno con esse alcuni elementi (registri temporanei) condivisi e non utilizzabili contemporaneamente da entrambe.

Sulla Parhelia e sull'utilizzo dell'architettura 2x4 c'è da dire che si tratta di una scelta dei progettisti che non è dettata solo dall'esigenza di svolgere più operazioni logiche anche in assenza di buffer interni; si tratta anche di una scelta che permette di aumentare la velocità di elaborazione del chip, poichè ogni pipeline risulta capace di 10 operazioni vettoriali di tipo logico contemporanee, contro le 2 dell'R3x0 e le 3 dell'NV3x (in assenza di texture fetch).

Sei stato molto esauriente!
Grazie mille!