4x2 = 8x1? [Archivio] - Hardware Upgrade Forum

shodan

17-10-2003, 20:14

Mmm... credo che checo si riferisca a quando trova scritto che l'R300 può applicare 16 texture per passata. Questo però è ben diverso dal poter applicare 16 texture per clock. Tanto per capirci vi faccio un esempio quasi banale: il Radeon 8500 supporta l'applicazione di 2 texture per clock per pixel e 6 texture per pixel per passata. Dov'è la differenza? Con la prima affermazione si dice che può applicare allo stesso pixel due texture nello stesso ciclo di clock, con la seconda ci si riferisce alla capacità della scheda di poter applicare fino a 6 texture su un singolo pixel senza dover per questo rileggere il valore del pixel nel framebuffer e senza doverne riprocessare la geometria (basta solo un ulteriore accesso al texture buffer per leggere il nuovo textel da applicare). Quindi in un gioco con un multitexture di 6 livelli, un radeon 8500 impiegherebbe 3 cicli di clock per ogni pixel per applicare sullo stesso 6 texture. Dov'è il vantaggio allora? E' che non dovendosi appoggiare al framebuffer, sarebbe comunque molto più veloce di un GeForce2 che, nonostante abbia una "configurazione" delle pipeline identica (4x2 in entrambi i casi) richiederebbe ben 3 passate (quindi un numero decisamente maggiore di letture e scritture da/verso il framebuffer).

Spero di non aver detto troppe imprecisioni! ;)

CIAO! :)

shodan

04-11-2003, 20:10

Azz raga nessuno che posta più? Mi sembrava interessante come discussione...

CIAO! :)

ironmanu

04-11-2003, 22:37

ciao,è interessante si'!!!la ti4200 cos'è una 2X2?

shodan

04-11-2003, 23:02

Originariamente inviato da ironmanu
ciao,è interessante si'!!!la ti4200 cos'è una 2X2?

No, è anch'essa 4x2 ;)

CIAO! :)

tiranium 4200

04-11-2003, 23:04

ma matematicamente 4x2=8 e 8x1=8 allora?:D

nn menatemi:p

shodan

05-11-2003, 09:56

Originariamente inviato da tiranium 4200
ma matematicamente 4x2=8 e 8x1=8 allora?:D

nn menatemi:p

Questa operazione è giusta, ma solo nei giochi che utilizzano il multitexture... altrimenti una scheda 4x2 equivarrebbe in realtà a una 4x1 (proprio perchè non può utilizzare la sua seconda texure unit). Questo incoveniente non accade con le schede che hanno una sola TMU (in ogni caso una texture va applicata)...

CIAO! :)

ATi7500

05-11-2003, 10:06

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!

seccio

05-11-2003, 10:47

prestazionalmente ormai nVidia con una 4x2 (5900ultra)
è abbastanza allineata alla 8x1 ATi......nn credete?

che ne pensate allora dei prox chip video?
NV40 si parla di un bel 8x2.....mentre per l'R420 di un 12x1.....

è stavolta matematicamente e basta....nVidia potrebbe essere avvantaggiata....poi è tutto da vedere!

CS25

05-11-2003, 11:05

Cio' che conta e contera' sempre di piu' in dx9 non e' il numero delle pipeline, bensi' il numero e la natura delle unita' di calcolo PS e VS, della capacita' di calcolo in FP e la capienza dei registri interni nonche' la loro flessibilita'.

Jedi_Master

05-11-2003, 11:19

Originariamente inviato da CS25
Cio' che conta e contera' sempre di piu' in dx9 non e' il numero delle pipeline, bensi' il numero e la natura delle unita' di calcolo PS e VS, della capacita' di calcolo in FP e la capienza dei registri interni nonche' la loro flessibilita'.

Ciao!
(hai visto i bench su HL2, giusto?)
Sono d'accordo con te anche se effettivamente si sente la mancanza di un VERO bench dx9 e soprattutto FULL dx9.
Ma chissa' quando.........
Domanda cosa intendi con flessibilita' dei registri??
:)

CS25

05-11-2003, 11:54

Il problema del bench dx9 e' moooolto piu' articolato di quello che puo' sembrare.
Innanzitutto non vi e' una comunione di intenti tra i due attuali poli grafici : Ati spinge per l'fp24 nell'attuale generazione di schede, Nvidia per la combinazione fp16+fp32. Di conseguenza cosa testi in un bench e cosa confronti?

- Se fai un test full fp32, favorisci Ati in quanto le Radeon accettano di eseguirli ma scalano ad fp24, mentre le FX di Nvidia lavorerebbero ad fp32 con impatto prestazionale elevatissimo.

- Se fai un test solo fp16 saresti pazzo, perche' con la sola partial precision non vai da nessuna parte

- Se fai un test che faccia fare fp16-32 a Nvidia ed fp24 ad Ati hai risultati non comparabili : la resa qualitativa sarebbe differente in determinati frangenti a favore dell'una o dell'altra. Pero' stringi stringi e' forse l'unica soluzione "accettabile"...

Se sommiamo a queste considerazioni il fatto che sviluppatori e produttori vogliono che lo standard diventi l'fp32, ti rendi conto come NESSUNA delle schede attuali sia pronta : Ati proprio non lo fa, Nvidia va troppo lenta.

Riguardo la tua altra domanda, uno dei problemi che affligge l'architettura della FX e' il numero di registri disponibili, che e' inferiore a quello delle schede Ati e che oltretutto non sono indipendenti : con gli stessi registri le FX svolgono sia operazioni in PS che altre operazioni. Ecco perche' parlavo di flessibilita'.

halduemilauno

05-11-2003, 12:03

Originariamente inviato da ironmanu
ciao,è interessante si'!!!la ti4200 cos'è una 2X2?

4x2

Jedi_Master

05-11-2003, 12:28

x CS25:

Non mi ricordo dove l'ho letto, ma ti risulta che le DX9 richiedono almeno una precision di 16, ma come 'standard' per Microsoft diciamo era implicitamente consigliato il 24, che infatti e' quello che ha fatto Ati senza stare li' a farsi troppe pippe mentali??
:confused:

CS25

05-11-2003, 12:57

Le specifiche delle dx9 prevedevano una precisione di calcolo minima in base alle necessita'. Si va da addirittura il calcolo integer per determinate cose, alla precisione floating point per altre (PS in testa).
In molte specifiche il minimo richiesto e' FP16, ma in molte altre e' per l'appunto FP24, consigliato pero' l'FP32 che garantisce una maggiore precisione di calcolo.
Il punto e' che il fine e' di arrivare proprio al FP32, anche se con la generazione attuale di schede e' poco utilizzabile.
Di conseguenza Ati ha interpretato MEGLIO le specifiche dx9, mentre Nvidia da un lato ha cercato di precorrere i tempi (fp32), dall'altro degli errori di valutazione a livello architetturale l'hanno spinta ad affiancare la partial precision per mediare tra prestazioni e qualita'.

david-1

05-11-2003, 13:31

Originariamente inviato da CS25
Le specifiche delle dx9 prevedevano una precisione di calcolo minima in base alle necessita'. Si va da addirittura il calcolo integer per determinate cose, alla precisione floating point per altre (PS in testa).
In molte specifiche il minimo richiesto e' FP16, ma in molte altre e' per l'appunto FP24, consigliato pero' l'FP32 che garantisce una maggiore precisione di calcolo.
Il punto e' che il fine e' di arrivare proprio al FP32, anche se con la generazione attuale di schede e' poco utilizzabile.
Di conseguenza Ati ha interpretato MEGLIO le specifiche dx9, mentre Nvidia da un lato ha cercato di precorrere i tempi (fp32), dall'altro degli errori di valutazione a livello architetturale l'hanno spinta ad affiancare la partial precision per mediare tra prestazioni e qualita'.
Ora ti sparo una domanda allucinante..... :p
In poche parole riesci a spiegarmi cosa s'intende x precisione di calcolo?:eek:

-=Krynn=-

05-11-2003, 14:14

Originariamente inviato da CS25

Se sommiamo a queste considerazioni il fatto che sviluppatori e produttori vogliono che lo standard diventi l'fp32, ti rendi conto come NESSUNA delle schede attuali sia pronta : Ati proprio non lo fa, Nvidia va troppo lenta.

Il problema nasce anche dal fatto che le dx9 sono pensate per il futuro, dovendo restare valide un botto di anni.
Con la generazione attuale, come hai detto te, nessuna delle due chede riesce ad andare alla massima qualità possibile (fp32), ma io penso che già dalla prossima generazione (nv40 & r420) quella precisione sarà lo standard.

yossarian

05-11-2003, 14:36

Originariamente inviato da david-1
Ora ti sparo una domanda allucinante..... :p
In poche parole riesci a spiegarmi cosa s'intende x precisione di calcolo?:eek:

il numero di bit utilizzati per rappresentare un qualunque tipo di segnale digitale (o analogico, dopo che questo è stato campionato).
Ad esempio, con un solo bit che può assumere due soli livelli di tensione (alto e basso) corrispondenti a 1 e 0 rispettivamente, ad un segnale si possono attribuire solo due valori. Di conseguenza, ad esempio, nel caso dei colori, questo corrisponderà a colore uniforme o assenza di colore (ad esempio o bianco o nero). Con 2 bit si hanno 4 livelli corrispondenti alle sequenze
00
01
10
11
ecc.
La rappresentazione può avvenire in virgola fissa (FX) o in virgola mobile (FP, da floating point); la seconda è più flessibile e permette una maggior precisione nell'approssimare il reale valore da rappresentare, rispetto alla virgola fissa. Qualora non si lavori con valori approssimati, ma con valori esatti, le due rappresentazioni sono del tutto equivalenti.

ciao

yossarian

05-11-2003, 14:44

Originariamente inviato da checo
scusa magari mi sbaglio, ma r300 renderizza in multitexture 16 texel 2 per pipe perchè ormai basarsi solo sul numero delle pipe è poco veritiero

avete ragione tutti e due; CS25 si riferisce alle operazioni per ciclo di clock, tu invece a quelle per singola passata.
E' vero che, ormai, parlare di valori teorici in multitexturing non ha alcun senso, perchè i chip DX possono applicare fino a 16 texture per pixel per single pass e la velocità di elaborazione dipende, non solo dal numero di TMU e di pipelines, ma anche dalla velocità con cui vengono eseguiti i cicli interni.
Ha ragione CS25 quando sostiene che, allo stato attuale, stanno acquistando sempre maggior importanza le unità logiche e i registri interni (soprattutto quelli temporanei, che sono quelli su cui si appoggiano operazioni come il multitexturing o tutte le multipass operations in genere).

ciao

ATi7500

05-11-2003, 14:58

Originariamente inviato da yossarian
avete ragione tutti e due; CS25 si riferisce alle operazioni per ciclo di clock, tu invece a quelle per singola passata.
E' vero che, ormai, parlare di valori teorici in multitexturing non ha alcun senso, perchè i chip DX possono applicare fino a 16 texture per pixel per single pass e la velocità di elaborazione dipende, non solo dal numero di TMU e di pipelines, ma anche dalla velocità con cui vengono eseguiti i cicli interni.
Ha ragione CS25 quando sostiene che, allo stato attuale, stanno acquistando sempre maggior importanza le unità logiche e i registri interni (soprattutto quelli temporanei, che sono quelli su cui si appoggiano operazioni come il multitexturing o tutte le multipass operations in genere).

ciao

il vantaggio di passare dai 128 ai 256 bit di bus memorie si sente di più con 4 pipeline o con 8?

bYeZ!

Fire Fox II

05-11-2003, 15:31

Perchè ATI è passata dai 4x2 della 8500 ai 4x1 della 9600?!? :what:

Redvex

05-11-2003, 15:43

posto xkè mi piace il 3d ;)

yossarian

05-11-2003, 15:54

Originariamente inviato da ATi7500
il vantaggio di passare dai 128 ai 256 bit di bus memorie si sente di più con 4 pipeline o con 8?

bYeZ!

la quantità di dati che viene trasferita per single pass è maggiore con la 8x1: se, ad esempio, si devono applicare 6 textures per pixel, con la 8x1, si avrà un totale di 6x8 texels trasferiti, contro i 6x4 della 4x2 (questo, ovviamente, semplificando al massimo e non tenendo conto di ulteriori buffer interni, in cui sono immagazzinati i dati intermedi di un'elaborazione multipass). In realtà, però, non sono solo i dati relativi alle textures applicate a dover passare per il canale di comunicazione ram-gpu, ma una moltitudine di altri dati, molti dei quali in contemporanea e viaggianti in direzioni opposte (il vantaggio di un'architettura crossbar sta tutto qui); perìò, anche per una 4x2, i 128 bit iniziano ad essere insufficienti, soprattutto se si considerano vga di fascia alta, per cui è prevedibile anche l'impiego dei filtri a risoluzioni medio/alte.
La scelta di nVIDIA di utilizzare un 128 per l'NV30 non è stata dettata dalla considerazione che, per una 4x2, i 128 bit potessero essere sufficienti, ma dalla considerazione che, con l'utilizzo di recirculating pipelines, il ricorso al frame buffer sarebbe stato ridotto. In realtà è così, ma non nella misura prevista da nVIDIA. Perciò si è resa necessaria la correzione apportata con NV35 (ampliamento del bus a 256 bit). Altro discorso, invece, è quello relativo alle ALU, a cui faceva cenno CS25 (anche li, nVIDIA è intervenuta, modificando l'architettura originaria dell'NV30, così come ha fatto nel passaggio da NV31 a NV36).

ciao

CS25

05-11-2003, 15:58

Originariamente inviato da david-1
Ora ti sparo una domanda allucinante..... :p
In poche parole riesci a spiegarmi cosa s'intende x precisione di calcolo?:eek:

Non e' una domanda allucinante, bensi' una domanda che ci sta tutta :)
Cerchiamo di farla molto semplice :)
Dunque fino ad oggi molti hanno creduto che bastassero i canonici 32 bit come profondita' di colore per fare tutto. In realta' non e' cosi', in quanto si vengono a creare situazioni nelle quali il calcolo del colore di un pixel diventa MOLTO complesso, in quanto al di la' del suo colore base vengono applicati una serie di effetti (illuminazione, bump...) che ovviamente variano quel valore.
Richiama alla mente ad esempio l'acqua del test 4 del 3dmark03, alla miriade di riflessi e di rifrazioni che si generano, causate dalle sorgenti di luce circostante, ed ai riflessi degli altri ogetti (erba, cielo...).
L'introduzione di effetti grafici sempre piu' complessi ha reso quindi necessario introdurre in hardware delle unita' di calcolo che invece di lavorare su valori integer (1, 2...), lavora su valori float (1.24342423, 1,24342424....) e permette quindi una resa incredibilmente precisa e realistica di quelle situazioni.
L'FP32 e' nientemeno che la profondita' di colore 128 bit (32+32+32+32), l'FP24 e' 96 bit (24+24+24+24) e l'FP16 e' 64 bit (16+16+16+16). Cio' che cambia pero' non e' il numero dei colori, che sono sempre 16 milioni, bensi' la precisione con cui la scheda video calcola il colore dei pixel, applica gli effetti e via dicendo.

Rispondo a Krinn.
Le dx9 hanno portato un vero e proprio balzo quantico, sebbene a molti sembrino solo una "evoluzione" delle dx8 (lasciandosi ingannare dal fatto che si continua a parlare di pixel e vertex shader con un semplice numerino di versione piu' grande...) in quanto e' l'architettura stessa delle schede ad essere profondamente mutata. Il futuro e' l'fp32 sempre e comunque, e richiedera' come minimo schede di seconda generazione dx9, cosi' come per le dx8 furono ideali schede quali il geforce4 e il radeon8500 rispetto al primo arrivato, il geforce3.

yossarian

05-11-2003, 16:01

Originariamente inviato da Fire Fox II
Perchè ATI è passata dai 4x2 della 8500 ai 4x1 della 9600?!? :what:

per avere più spazio interno per allocare un maggior numero di registri temporanei (le DX9 prevedono un numero minimo almeno quadruplo di registri temporanei, rispetto alle DX8.1 spec PS1.4) e per poter aumentare il numero di ALU, nonchè variarne la qualità (la 9600 contiene anche ALU che eseguono calcoli in FP, che sono più voluminose rispetto alle corrispondenti unità FX; anche nVIDIA si è trovata ad affrontare un problema simile, passando da NV30 a NV35 e da NV31 a NV36 e lo ha risolto diminuendo di qualche unità il numero di registri interni, per la verità già poco sufficiente, però eral'unica modifica possibile).

ciao

ATi7500

05-11-2003, 16:01

ottima spiegazione, anche se io mi riferivo ad un'ipotetica 9600XT con bus a 256 bit...pandyno aveva detto ke non si sarebbe assistito ad un raddoppio prestazionale perchè i 256 bit si sentono di più sulle architetture ad 8 pipe...

bYeZ!

yossarian

05-11-2003, 16:09

Originariamente inviato da ATi7500
ottima spiegazione, anche se io mi riferivo ad un'ipotetica 9600XT con bus a 256 bit...pandyno aveva detto ke non si sarebbe assistito ad un raddoppio prestazionale perchè i 256 bit si sentono di più sulle architetture ad 8 pipe...

bYeZ!

infatti non ci sarebbe raddoppio delle prestazioni, anche perchè, l'ipotetico raddoppio lo avresti solo alle risoluzioni più alte e con filtri attivati (situazioni d'impiego non sostenibili per la 9600 XT).
In realtà, nel test che fu fatto quando venne presentato l'NV35, si fece un bench con Q3, a 1600x1200 AA4x e aniso 4x, con i due chip a frequenze attorno ai 300 MHZ e si vide che, in quelle condizioni, l'NV35 faceva registrare prestazioni doppie rispetto all'NV30. Però, ti ripeto, si tratta di situazioni di impiego estreme. Indubbiamente, attivando i filtri e aumentando la risoluzione, i 256 bit permettono un bel boost prestazionale; però, nel caso specifico della serie 9600 c'è da registrare un comportamento anomalo con l'attivazione dell'AA4x; si ha un calo di prestazioni molto più brusco di quello fatto registrare dalla 9500 pro che ha stesso bus e minor bandwidth. Questo potrebbe far pensare all'impiego di registri interni meno capienti di quelli dell'R300, che incide negativamente sulla capacità di calcolo.

ciao

ATi7500

05-11-2003, 16:12

Originariamente inviato da yossarian
però, nel caso specifico della serie 9600 c'è da registrare un comportamento anomalo con l'attivazione dell'AA4x; si ha un calo di prestazioni molto più brusco di quello fatto registrare dalla 9500 pro che ha stesso bus e minor bandwidth. Questo potrebbe far pensare all'impiego di registri interni meno capienti di quelli dell'R300, che incide negativamente sulla capacità di calcolo.

ciao

mmm me ne ero accorto infatti, ed è stata la cosa ke mi ha impedito l'acquisto...cmq la 9500 pro ha 8 pipe...forse è per quello...cmq con i 256 bit di bus tu dici ke la situazione si capovolgerebbe o rimarrebbe uguale?

bYeZ!

Jedi_Master

05-11-2003, 16:41

Originariamente inviato da CS25
Le dx9 hanno portato un vero e proprio balzo quantico, sebbene a molti sembrino solo una "evoluzione" delle dx8 (lasciandosi ingannare dal fatto che si continua a parlare di pixel e vertex shader con un semplice numerino di versione piu' grande...) in quanto e' l'architettura stessa delle schede ad essere profondamente mutata.

Beh credo che balzo quantico sia forse un po' esagerato.
Oltre a pixel e vertex shader mi vengono in mente il continuous tesselation e l'hdr che vederli fa' piacere pero' non stravolge l'immagine cosi' drasticamente rispetto alla stessa con un buon uso delle possibilita' delle dx8!!
Poi magari mi sono perso qualcosa, tu o qualcun'altro saprebbe farmi un'esempio pratico del netto miglioramento visivo??
Grazie.
;)

yossarian

05-11-2003, 16:43

Originariamente inviato da ATi7500
mmm me ne ero accorto infatti, ed è stata la cosa ke mi ha impedito l'acquisto...cmq la 9500 pro ha 8 pipe...forse è per quello...cmq con i 256 bit di bus tu dici ke la situazione si capovolgerebbe o rimarrebbe uguale?

bYeZ!

sarebbe tutto da verificare; il bus a 256 bit favorirebbe lo scambio di dati con l'esterno, però un'insufficiente capienza dei registri interni rallenta l'elaborazione del chip, perchè costringe ad un maggior numero di accessi al frame buffer (quello che, in maniera amplificata, accade alla serie FX, soprattutto quando si elabora in FP32). Quindi sarebbe da vedere quanto l'aumento di ampiezza del canale esterno riesca a compensare le diminuita capacità di trasferimento dei dati all'interno del chip.
L'NV38 o l'NV35, pur avendo una bandwidth maggiore rispetto all'R360 o, ancor di più , rispetto all'R350 e all'R300, paradossalmente (almeno ad unìanalisi superficiale che tenga conto solo della bandwidth), perdono terreno proprio con i filtri, ad alta risoluzione (questo, sia con i PS2.0, con cui sappiamo che sono in difficoltà, ma anche con i PS1.x); questo a causa del maggior numero di accessi al frame buffer a cui sono obbligate anche dalla minor capacità dei registri interni.

yossarian

05-11-2003, 16:50

Originariamente inviato da Jedi_Master
Beh credo che balzo quantico sia forse un po' esagerato.
Oltre a pixel e vertex shader mi vengono in mente il continuous tesselation e l'hdr che vederli fa' piacere pero' non stravolge l'immagine cosi' drasticamente rispetto alla stessa con un buon uso delle possibilita' delle dx8!!
Poi magari mi sono perso qualcosa, tu o qualcun'altro saprebbe farmi un'esempio pratico del netto miglioramento visivo??
Grazie.
;)

non si tratta solo di miglioramento visivo; c'è anche quello e ci sarà soprattutto in futuro, quando si inizieranno ad utilizzare effettivamente le DX9; il problema è l'aumentata complessità dei calcoli. Quando saranno realmente (non come nei bench o nei giochi visti finora che hanno solo la presunzione di essere DX9), ci saranno pochissime istruzioni che non richiederanno un'elaborazioni in multipass, cosa che avviene molto più raramente con le DX8.1. Non è esagerato dire che la complessità teorica dei calcoli si è, come minimo, quadruplicata. Un effetto DX6 come l'EMBM richiede l'applicazione di 3 texels per pixel e apporta un discreto miglioramento all'immagine; pensa cosa si potrebbe fare applicando 12 o 16 textels per pixel

ATi7500

05-11-2003, 16:52

ti ringrazio! ;)

bYeZ!

ATi7500

05-11-2003, 16:57

forse è un po OT...

yossarian, mi sai dire quante texture per passata e quante per ciclo di clock può elaborare il 7500? e come mai ATi ha scelto di utilizzare ben TRE tmu e 2 pipe rinunciando a un più classico 4x2?

bYeZ!

Jedi_Master

05-11-2003, 17:04

Originariamente inviato da yossarian
non si tratta solo di miglioramento visivo; c'è anche quello...

Sinceramente spero ci sia soprattotto quello altrimenti tutti i soldini spesi nella mia skeduzza, dovro' condiderarli come buttati nel ce@@o.....e la cosa mi farebbe moooolto arrabbiare!!!!
:mad:

:sofico:

CS25

05-11-2003, 17:13

Originariamente inviato da Jedi_Master
Beh credo che balzo quantico sia forse un po' esagerato.
[/b]

Che franki mi perdoni se prendo in prestito il suo lavoro e linko un grafico che riassume bene la differenza solo numerica della precisione di calcolo :)

http://www.nvitalia.com/articoli/Floating_Point/nv30_fp_2.png

Al di la' delle feature, qui e' proprio un completamento e la messa in atto di un processo iniziato timidamente all'epoca delle dx7. Il tanto criticato transform & lighting e le prime istruzioni shader sono state una coraggiosa scommessa, le dx8 sono state il primo vero implementamento e le dx9 sono il coronamento del disegno.
Veder girare Half Life 2 e' qualcosa di incredibile, e se consideriamo che non sfrutta ancora appieno cio' che l'api puo' dare per via della limitatezza delle schede attuali... la prossima generazione di hw dx9.1 sara' qualcosa di incredibile :)

yossarian

05-11-2003, 17:21

Originariamente inviato da ATi7500
forse è un po OT...

yossarian, mi sai dire quante texture per passata e quante per ciclo di clock può elaborare il 7500? e come mai ATi ha scelto di utilizzare ben TRE tmu e 2 pipe rinunciando a un più classico 4x2?

bYeZ!

per la 7500, come per tutti i chip precedenti all'avvento delle DX8, tranne il Kyro2 e il Rage 128 GL, il calcolo è molto semplice, perchè il numero delle texture elaborate per passate corrisponde a quello di quelle elaborate per ciclo di clock, poichè questi chip non effettuano multipass rendering utilizzando buffer temporanei interni.
Di conseguenza, la 7500, ossia l'R100 avendo 2 pipelines con 3 TMU, può elaborare 2 pixel per ciclo di clock e per single pass, a cui può applicare fino a 3 textures per single pass. Diciamo che è l'unico chip, insieme alla Parhelia, a poter applicare un effetto come l'EMBM in un solo ciclo di clock.
Purtroppo però, per applicare un numero superiore di textures (4, 5, .....) è costretto a far ricorso al classico multipass rendering, in cui i risultati intermedi sono immagazzinati in una porzione del frame buffer.

yossarian

05-11-2003, 17:24

Originariamente inviato da Jedi_Master
Sinceramente spero ci sia soprattotto quello altrimenti tutti i soldini spesi nella mia skeduzza, dovro' condiderarli come buttati nel ce@@o.....e la cosa mi farebbe moooolto arrabbiare!!!!
:mad:

:sofico:

diciamo che ci potrai giocare, senza troppi compromessi, con giochi tipo HL2 e Doom3 che, anche se ancora non rappresentano al meglio le potenzialità dei PS2.0 e dei VS2.0 (e seguenti), però iniziano a dare un'idea di quello che ci si può fare.

checo

05-11-2003, 17:42

io penso che nemmeno la prossima generazione di skede sarà in grado di far girare bene giochi con magari 16 tex per passata in fp32 magari con aa ed aniso attivi

shodan

05-11-2003, 19:29

Originariamente inviato da yossarian
infatti non ci sarebbe raddoppio delle prestazioni, anche perchè, l'ipotetico raddoppio lo avresti solo alle risoluzioni più alte e con filtri attivati (situazioni d'impiego non sostenibili per la 9600 XT).
In realtà, nel test che fu fatto quando venne presentato l'NV35, si fece un bench con Q3, a 1600x1200 AA4x e aniso 4x, con i due chip a frequenze attorno ai 300 MHZ e si vide che, in quelle condizioni, l'NV35 faceva registrare prestazioni doppie rispetto all'NV30. Però, ti ripeto, si tratta di situazioni di impiego estreme. Indubbiamente, attivando i filtri e aumentando la risoluzione, i 256 bit permettono un bel boost prestazionale; però, nel caso specifico della serie 9600 c'è da registrare un comportamento anomalo con l'attivazione dell'AA4x; si ha un calo di prestazioni molto più brusco di quello fatto registrare dalla 9500 pro che ha stesso bus e minor bandwidth. Questo potrebbe far pensare all'impiego di registri interni meno capienti di quelli dell'R300, che incide negativamente sulla capacità di calcolo.

ciao

Azz mi fa piacere vedere che la discussione ha preso una piega così interessante.
Posso farti una domanda yossarian? La 9600PRO quando si trova in condizione di dover applicare un'antialiasing 4X non potrebbe semplicemente non avere abbasstanza fill-rate per offrire una velocità comparabile a quella della 9500PRO? E' vero che con l'AA conta sopratutto la banda verso la memoria e la 9600PRO in questo vince, però è anche vero che un pixel deve essere disegnato più volte e per questo anche la forza bruta delle pipeline potrebbe essere messa sotto sforzo, sopratutto tenendo conto che la 9600PRO ha solo 4 pipe e quindi potrebbe anche essere già discretamente soddisfatta da un bus verso la memoria di 128bit.

Anche una domanda per CS25 (non insultatemi :p):
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). E' anche vero che i motori vertex shader sono in genere "separati" dal resto (es: R300 ha 8 pipe ma 4 unità vertex shader). Addirittura l'NV30 ha il cosiddetto vertex shader array (potresti spiegarmi meglio che significa?). Qualcuno sa perchè si sceglie questo approccio (quello di separare dal resto delle pipe i motori vertex shader)?

Grazie. :)

yossarian

05-11-2003, 21:47

Originariamente inviato da shodan
Azz mi fa piacere vedere che la discussione ha preso una piega così interessante.
Posso farti una domanda yossarian? La 9600PRO quando si trova in condizione di dover applicare un'antialiasing 4X non potrebbe semplicemente non avere abbasstanza fill-rate per offrire una velocità comparabile a quella della 9500PRO? E' vero che con l'AA conta sopratutto la banda verso la memoria e la 9600PRO in questo vince, però è anche vero che un pixel deve essere disegnato più volte e per questo anche la forza bruta delle pipeline potrebbe essere messa sotto sforzo, sopratutto tenendo conto che la 9600PRO ha solo 4 pipe e quindi potrebbe anche essere già discretamente soddisfatta da un bus verso la memoria di 128bit.

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)

Originariamente inviato da shodan

Anche una domanda per CS25 (non insultatemi :p):
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). E' anche vero che i motori vertex shader sono in genere "separati" dal resto (es: R300 ha 8 pipe ma 4 unità vertex shader). Addirittura l'NV30 ha il cosiddetto vertex shader array (potresti spiegarmi meglio che significa?). Qualcuno sa perchè si sceglie questo approccio (quello di separare dal resto delle pipe i motori vertex shader)?

Grazie. :)

se rispondo anche alla seconda parte, non credo che il mio amico CS25 se la prenderà (almeno spero :D )
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.
La scelta di non includere le unità VS nelle pipelines di rendering eè dettata dal fatto che non è necessario un numero di VS pari a quello dei PS e, poichè il flusso di dati permette di farlo, si sceglie di tenere le unità VS separate. In realtà non + neppure giusto dire che sono separate, anche se il fatto che siano in numero inferiore potrebbe far pensare ciò; 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.
Veniamo alla vertex array. In realtà, pare proprio che le FX non abbiano alcuna vertex array (che invece si trova sul VP10 di 3DLabs), per un motivo molto semplice: un'unità vettoriale tradizionale è costituita da 4 unità scalari di tipo FP32 ognuna delle quali lavora su una coordinata (nello spazio ampliato si usano 4 ccordinate per definire un vettore se si usano coordinate cartesiane e 3 se si usano coordinate sferiche o cilindriche). Per cui, l'R3x0, con 4 unità vettoriali, ha di fatto 16 unità scalari raggruppate a 4 a 4. 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. Concettualmente è la stessa cosa:basta prendere un vettore e scomporlo nelle sua 4 coordinate, ognuna delle quali viene passata ad un'unità scalare dell'array; il problema è che questo passaggio costa in termini di prestazioni (al punto che, utilizzando vettori in input, l'array del VP10, a parità di unità scalari complessive, perde 1/3 circa in prestazioni, nei confronti dell'R3x0. L'array diventa vantaggioso con quelle applicazioni che non fanno largo uso di input in forma vettoriale classica (soprattutto programmi di grafica 3D pro, il cui input è piuttosto variegato), mentre è svantaggioso con i giochi. Perciò, valutando anche le prestazioni delle unità VS, e facendo questo tipo di considerazioni (la serie FX è destinata anche ai giocatori, mentre i chip di 3DLabs solo ad usi pro), diventa difficile ipotizzare la presenza di un array sull'NV3x, in luogo di unità vettoriali classiche.

david-1

05-11-2003, 22:54

Grazie a yossarian e CS25 per le spiegazioni sulla precisione di calcolo....... siete forti..!! :)

REPSOL

06-11-2003, 04:53

Miiiinchi@ questa discussione mi ha fatto perdere il sonno :D

Bella bella... erano mesi e mesi che non assistevo più ad una discussione dove avevo da imparare qualcosa di veramente importante :D

NICE ;)

Stà cosa del FP e dei registri interni mi intrippa :)

Ora però ninno.. bonanotte ;)

yossarian

06-11-2003, 09:47

Originariamente inviato da checo
io penso che nemmeno la prossima generazione di skede sarà in grado di far girare bene giochi con magari 16 tex per passata in fp32 magari con aa ed aniso attivi

è quello che penso anch'io, però non lo facciamo sapere in giro

;)

:D :D

ATi7500

06-11-2003, 09:55

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!

CS25

06-11-2003, 10:07

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

06-11-2003, 10:35

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

06-11-2003, 11:10

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

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 :D)
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! :muro:).

CIAO! :)

shodan

06-11-2003, 11:31

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 :sofico: ) 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

06-11-2003, 11:34

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

06-11-2003, 11:37

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

06-11-2003, 11:53

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 :sofico: ) 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

06-11-2003, 11:57

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

06-11-2003, 12:02

Originariamente inviato da fek
No, e' il contrario :)

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

yossarian

06-11-2003, 12:43

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

06-11-2003, 12:59

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

06-11-2003, 13:05

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

06-11-2003, 13:09

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

06-11-2003, 13:33

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

06-11-2003, 17:42

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

06-11-2003, 18:43

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

06-11-2003, 19:29

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

06-11-2003, 19:30

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 :D

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

06-11-2003, 19:57

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 €:rolleyes:

yossarian

06-11-2003, 20:56

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

REPSOL

07-11-2003, 03:50

Texture frattali? Mi spiegate che roba è?

THX

Ciaoz

yossarian

07-11-2003, 04:22

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

07-11-2003, 09:31

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

07-11-2003, 12:04

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

07-11-2003, 12:07

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

bYeZ!

fek

07-11-2003, 12:23

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

07-11-2003, 12:27

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

07-11-2003, 12:29

edit sorry

shodan

07-11-2003, 13:18

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

07-11-2003, 13:53

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

07-11-2003, 16:09

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... :huh:
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 :D).
Mi ci sono perlomeno avvicinato? :D

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... :sofico:

Grazie mille delle spiegazioni (passate e future ;)).

CIAO! :)

yossarian

07-11-2003, 16:15

Originariamente inviato da shodan
Allora vediamo se ho capito... :huh:
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 :D).
Mi ci sono perlomeno avvicinato? :D

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

18-12-2003, 16:16

Mi sono letto tutto il 3d e devo fare i miei complimenti ragazzi alla vostra preparazione. :eek:
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

18-12-2003, 16:31

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

ATi7500

18-12-2003, 18:02

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

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

bYeZ!

Norbrek™

18-12-2003, 21:07

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

19-12-2003, 23:54

Originariamente inviato da mg13
Mi sono letto tutto il 3d e devo fare i miei complimenti ragazzi alla vostra preparazione. :eek:
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

20-12-2003, 02:17

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:asd: :asd: :asd:

yossarian

20-12-2003, 03:31

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

20-12-2003, 14:52

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?

JENA PLISSKEN

20-12-2003, 15:20

X quanto ne so io , il PADELLA nn ha "problemi" di arkitettura , ma di una mancanza totale di HSR e ottimizzazzione x la banda, un po' ad es come l' Hyper-Z dell' ATI...;)

dario amd

20-12-2003, 16:50

bel post veramente utile ma un po complicato:bimbo: :bimbo: :bimbo:

shodan

20-12-2003, 17:44

Originariamente inviato da JENA PLISSKEN
X quanto ne so io , il PADELLA nn ha "problemi" di arkitettura , ma di una mancanza totale di HSR e ottimizzazzione x la banda, un po' ad es come l' Hyper-Z dell' ATI...;)

Infatti, anche questo incide molto pesantemente (in negativo) sulle performance della Parhelia... basti pensare che in giochi come UT (il primo!) o Quake III si possono raggiungere valori di sovrapposizione dei pixel (depth value o qualcosa del genere, non ricordo...) di 3 o 4: questo significa che per ogni pixel visualizzato, ce ne saranno 2 o 3 calcolati ma NON VISIBILI perchè coperti da altri pixel.

E' lampante che con un buon algoritmo di HSR il chip può risparmiarsi davvero tanto lavoro...

CIAO! :)

shodan

20-12-2003, 17:46

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

Azz... non sapevo che il Parhelia non avesse buffer interni dedicati all'imagazzinamento dello stato intermedio del pixel! Cavolo, far ricorso al framebuffer deve davvero uccidere le prestazioni del chip!
Comunque nei giochi attuali credo che non sia un grosso problema, visto che in genere si frutta il multitexture su 2 livelli (anche se le cose possono cambiare velocemente ;)).

CIAO! :)

yossarian

20-12-2003, 19:44

Originariamente inviato da shodan
Azz... non sapevo che il Parhelia non avesse buffer interni dedicati all'imagazzinamento dello stato intermedio del pixel! Cavolo, far ricorso al framebuffer deve davvero uccidere le prestazioni del chip!
Comunque nei giochi attuali credo che non sia un grosso problema, visto che in genere si frutta il multitexture su 2 livelli (anche se le cose possono cambiare velocemente ;)).

CIAO! :)

in realtà già oggi si usa multitexturing a più livelli; l'EMBM, ad esempio, richiede l'applicazione di 3 texel per pixel, le specifiche PS1.1 l'applicazione di fino a 4 texels per pixel e i PS1.4 fino a 6 texel per pixel (le DX9 arrivano a 16).

Il problema dell'overdraw (causato dalla mancanza di un algoritmo di HSR, è un altro dei problemi che contribuiscono ad abbattere le prestazioni della Parhelia).

Da qualche parte ho letto, inoltre, che la Parhelia è l'unico chip con 512 bit di bus. In realtà non è così; la Parhelia ha bus interno a 512 bit e memory bus controller a 256 bit (esattamente come R3x0 e NV35).

JENA PLISSKEN

20-12-2003, 20:30

Originariamente inviato da yossarian

Da qualche parte ho letto, inoltre, che la Parhelia è l'unico chip con 512 bit di bus. In realtà non è così; la Parhelia ha bus interno a 512 bit e memory bus controller a 256 bit (esattamente come R3x0 e NV35).

Infatti...si kiama Padella 512, ma l' mbc è @256;)

Inoltre ci sarebbe d' aggiungere un difetto visivo cronico se nn sbaglio su fondo bianco...ma sinc nn ne seguii + gli sviluppi;)

grey.fox

20-12-2003, 20:34

E' da tempo che non trovavo un thread così interessante!! Roba da fondersi il cevello! :muro:

JENA PLISSKEN

20-12-2003, 20:40

A questo punto quello ke mi kiedo è (Sempre se fosse vero!!!) cosa ha spinto ATI ad adottare il 12x1 ed NV l' 8x2....sicuramente uno dei 2 farà la scelta ke si rivelerà alla fine sbagliata( o quanto meno,< performante)...ma come faremo noi a capirlo in anticipo?? Spero ke almeno x quando usciranno sia pronto DOOM3....bah:muro: :muro: :muro:

MaBru

20-12-2003, 21:05

Originariamente inviato da fek
Direi un tempo infinito ;)

Sei proprio sicuro francesco?

Mi ricordo di un'intervista a John Carmack di qualche anno fa (mi pare addirittura pre-Q3) in cui il nostro diceva che per mettere fine in maniera definitiva allo "spixellamento" delle texture si sarebbe dovuti ricorrere alla compressione frattale.

Ciao

Zak84

21-12-2003, 18:08

x fek.

Hai PVT!!! ;)

shodan

21-12-2003, 20:02

Originariamente inviato da yossarian
in realtà già oggi si usa multitexturing a più livelli; l'EMBM, ad esempio, richiede l'applicazione di 3 texel per pixel, le specifiche PS1.1 l'applicazione di fino a 4 texels per pixel e i PS1.4 fino a 6 texel per pixel (le DX9 arrivano a 16).

Il problema dell'overdraw (causato dalla mancanza di un algoritmo di HSR, è un altro dei problemi che contribuiscono ad abbattere le prestazioni della Parhelia).

Da qualche parte ho letto, inoltre, che la Parhelia è l'unico chip con 512 bit di bus. In realtà non è così; la Parhelia ha bus interno a 512 bit e memory bus controller a 256 bit (esattamente come R3x0 e NV35).

Be in effetti come hai detto tu già oggi ci sono molti effetti che sfruttano il multitexture. Però se non ricordo male nei giochi attuali si fa largo uso anche del single-texturing (d'altronde se ad un oggetto basta una sola texture perchè applicarne di più?).

Una domanda: chip come l'R300 e l'NV30 hanno un bus interno largo quanti bit? E come viene calcolata quest'ampiezza (per esempio mi sembra di ricordare che il GeForce256 viene considerato un chip a 256 bit perchè ha 4 pipe ognuna da 64 bit l'una... giusto?)?

CIAO!

yossarian

22-12-2003, 02:00

Originariamente inviato da shodan
Be in effetti come hai detto tu già oggi ci sono molti effetti che sfruttano il multitexture. Però se non ricordo male nei giochi attuali si fa largo uso anche del single-texturing (d'altronde se ad un oggetto basta una sola texture perchè applicarne di più?).

Una domanda: chip come l'R300 e l'NV30 hanno un bus interno largo quanti bit? E come viene calcolata quest'ampiezza (per esempio mi sembra di ricordare che il GeForce256 viene considerato un chip a 256 bit perchè ha 4 pipe ognuna da 64 bit l'una... giusto?)?

CIAO!

R3x0 e NV3x hanno bus a 512 bit. Il bus dà la misura della quantità di bit che vengono elaborati per ciclo di clock; le cose non stanno in maniera tanto semplice come l'hai descritta. Molto dipende dal tipo di elaborazione richiesta e dall'architettura interna del chip. Ad esempio la Parhelia ha 4 pipeline con 4 TMU e 5 unità logiche ciascuna, però, all'occorrenza, ha la possibilità di conportarsi come un'architettura con 2 sole pipeline dotate, ognuna, di 4 TMU e ben 10 unità logiche; così facendo rinuncia all'uilizzo di 8 delle 16 TMU complessive, però guadagna molto in capacità di calcolo. Questo, ovviamente, se i dati da processare prevedono l'appliaczione di poche texture e l'esecuzione di molti calcoli logici.

mg13

22-12-2003, 10:16

Originariamente inviato da JENA PLISSKEN
Infatti...si kiama Padella 512, ma l' mbc è @256;)

Inoltre ci sarebbe d' aggiungere un difetto visivo cronico se nn sbaglio su fondo bianco...ma sinc nn ne seguii + gli sviluppi;)

Puoi essere un pò più preciso su questo difetto visivo?
Perchè io ho un problema che si amplifica con lo sfondo bianco anche se penso sia il monitor perchè me lo faceva anche con la ati 8500le.

mg13

22-12-2003, 10:18

Originariamente inviato da yossarian
R3x0 e NV3x hanno bus a 512 bit. Il bus dà la misura della quantità di bit che vengono elaborati per ciclo di clock; le cose non stanno in maniera tanto semplice come l'hai descritta. Molto dipende dal tipo di elaborazione richiesta e dall'architettura interna del chip. Ad esempio la Parhelia ha 4 pipeline con 4 TMU e 5 unità logiche ciascuna, però, all'occorrenza, ha la possibilità di conportarsi come un'architettura con 2 sole pipeline dotate, ognuna, di 4 TMU e ben 10 unità logiche; così facendo rinuncia all'uilizzo di 8 delle 16 TMU complessive, però guadagna molto in capacità di calcolo. Questo, ovviamente, se i dati da processare prevedono l'appliaczione di poche texture e l'esecuzione di molti calcoli logici.

Sei sicuro di quello che dici, perchè anch'io sapevo che la Parhelia era l'unica gpu a 512bit al mondo, anche se il bus verso la memoria è a 256bit.

yossarian

22-12-2003, 12:23

Originariamente inviato da mg13
Sei sicuro di quello che dici, perchè anch'io sapevo che la Parhelia era l'unica gpu a 512bit al mondo, anche se il bus verso la memoria è a 256bit.

la Parhelia è stata la prima, ma non è l'unica a 512 bit (è stata l'unica fino all'uscita dell'R300); anche il P10 ha bus interno a 512 bit e memory bus a 256 bit; l'unico su cui sono in dubbio, per svariati motivi, è l'NV3x (che potrebbe essere anche a 256 bit)

Inoltre la compatibilità della Parhelia con le DX8.1 si ferma ai PS1.3 (non include i PS1.4), al pari dell'NV25

shodan

22-12-2003, 18:37

Originariamente inviato da yossarian
R3x0 e NV3x hanno bus a 512 bit. Il bus dà la misura della quantità di bit che vengono elaborati per ciclo di clock; le cose non stanno in maniera tanto semplice come l'hai descritta. Molto dipende dal tipo di elaborazione richiesta e dall'architettura interna del chip. Ad esempio la Parhelia ha 4 pipeline con 4 TMU e 5 unità logiche ciascuna, però, all'occorrenza, ha la possibilità di conportarsi come un'architettura con 2 sole pipeline dotate, ognuna, di 4 TMU e ben 10 unità logiche; così facendo rinuncia all'uilizzo di 8 delle 16 TMU complessive, però guadagna molto in capacità di calcolo. Questo, ovviamente, se i dati da processare prevedono l'appliaczione di poche texture e l'esecuzione di molti calcoli logici.

Grazie yossarian.
Ma quindi la parhelia è un chip a 512 bit in base a quali calcoli?
Cioè... in base a cosa la Matrox (o ATI) dicono che i loro chip sono a x bit?
In base al numero di bit che possono muovere con un singolo colpo di clock?

Ciao grazie! :)

mg13

22-12-2003, 18:50

Originariamente inviato da yossarian
la Parhelia è stata la prima, ma non è l'unica a 512 bit (è stata l'unica fino all'uscita dell'R300); anche il P10 ha bus interno a 512 bit e memory bus a 256 bit; l'unico su cui sono in dubbio, per svariati motivi, è l'NV3x (che potrebbe essere anche a 256 bit)

Inoltre la compatibilità della Parhelia con le DX8.1 si ferma ai PS1.3 (non include i PS1.4), al pari dell'NV25

Leggendo PC PROFESSIONALE di dicembre 2003 ci sono delle recensioni delle nvidia fx5700 e fx5950 e radeon 9800xt e 9600xt, loro dicono nelle tabelle che i chip nv3x e il r3x0 sono a 256bit (errore di battitura?)
Ho visitato il sito di 3dlabs e non ho trovato nulla che dica che il p10 sia a 512bit.

Non voglio fare il difensore della skvideo che ho, ma vorrei sapere dove hai letto quello che tu sostieni.
Ciao.

yossarian

22-12-2003, 20:21

Originariamente inviato da mg13
Leggendo PC PROFESSIONALE di dicembre 2003 ci sono delle recensioni delle nvidia fx5700 e fx5950 e radeon 9800xt e 9600xt, loro dicono nelle tabelle che i chip nv3x e il r3x0 sono a 256bit (errore di battitura?)
Ho visitato il sito di 3dlabs e non ho trovato nulla che dica che il p10 sia a 512bit.

Non voglio fare il difensore della skvideo che ho, ma vorrei sapere dove hai letto quello che tu sostieni.
Ciao.

PC professionale ha anche detto che l'NV30 ha un'architettura 8x8, tanto per dirne una. SEcondo te qual è il senso di avere un'architettura interna a 256 bit e un memory bus a 512 bit effettivi (256 DDR equivale a 512 bit trasferiti per ciclo di clock)? Per avere un collo di bottiglia già in fase di progettazione, sulla carta?

yossarian

22-12-2003, 20:31

Originariamente inviato da shodan
Grazie yossarian.
Ma quindi la parhelia è un chip a 512 bit in base a quali calcoli?
Cioè... in base a cosa la Matrox (o ATI) dicono che i loro chip sono a x bit?
In base al numero di bit che possono muovere con un singolo colpo di clock?

Ciao grazie! :)

sono i bit trasferiti per ciclo di clock da un blocco all'altro all'interno del chip. Dire che un chip ha architettura interna a x bit equivale a dire che per ogni ciclo di clock, all'interno del chip vengono scambiate informazioni per un totale di x bit. Tieni conto che anche le interfacce tra unità di calcolo e registri interni sono di almeno 512 bit (in molti casi, le embedded ram utilizzano anche architettura a 1024 bit). Con l'utilizzo di ram di tipo GDDR2 o GDDR3, che aumentano, in realtà, proprio il bit rate, a parità di frequenza, è prevedibile che si assisterà, entro un paio di generazioni, ad un ulteriore aumento dell'ampiezza di bus delle architetture interne

shodan

22-12-2003, 20:42

Originariamente inviato da yossarian
sono i bit trasferiti per ciclo di clock da un blocco all'altro all'interno del chip. Dire che un chip ha architettura interna a x bit equivale a dire che per ogni ciclo di clock, all'interno del chip vengono scambiate informazioni per un totale di x bit. Tieni conto che anche le interfacce tra unità di calcolo e registri interni sono di almeno 512 bit (in molti casi, le embedded ram utilizzano anche architettura a 1024 bit). Con l'utilizzo di ram di tipo GDDR2 o GDDR3, che aumentano, in realtà, proprio il bit rate, a parità di frequenza, è prevedibile che si assisterà, entro un paio di generazioni, ad un ulteriore aumento dell'ampiezza di bus delle architetture interne

Ok yossarian!

Grazie mille! ;)

mg13

23-12-2003, 12:22

Originariamente inviato da yossarian
PC professionale ha anche detto che l'NV30 ha un'architettura 8x8, tanto per dirne una. SEcondo te qual è il senso di avere un'architettura interna a 256 bit e un memory bus a 512 bit effettivi (256 DDR equivale a 512 bit trasferiti per ciclo di clock)? Per avere un collo di bottiglia già in fase di progettazione, sulla carta?

Amesso che PC PRO abbia detto una castroneria, ma non menzioni il n. dove hai letto quello che dici, anche tu non ti sei tirato indietro dopo.

Mi sono girato i vari siti di: ATI, NVIDIA, MATROX E 3DLABS, e tutti confermano il bus verso la memoria locale ddr di 256bit.
NVIDIA conferma che il suo chip (nv3x) x le fx5900, fx5700 e fx5200 è di 256bit.
MATROX conferma che la Parhelia è 512bit.
Mentre gli altri due non specificano nulla.

Ora vorrei sapere le tue fonti di quello che hai scritto.
Altrimenti se vieni al workshop il 24 gennaio lo chiediamo direttamente a Paolo Corsini.

Ciao.

yossarian

23-12-2003, 13:16

Originariamente inviato da mg13
Amesso che PC PRO abbia detto una castroneria, ma non menzioni il n. dove hai letto quello che dici, anche tu non ti sei tirato indietro dopo.

Mi sono girato i vari siti di: ATI, NVIDIA, MATROX E 3DLABS, e tutti confermano il bus verso la memoria locale ddr di 256bit.
NVIDIA conferma che il suo chip (nv3x) x le fx5900, fx5700 e fx5200 è di 256bit.
MATROX conferma che la Parhelia è 512bit.
Mentre gli altri due non specificano nulla.

Ora vorrei sapere le tue fonti di quello che hai scritto.
Altrimenti se vieni al workshop il 24 gennaio lo chiediamo direttamente a Paolo Corsini.

Ciao.

NV35 è, in effetti, a 256 bit; infatti deriva da NV30 che ha l'interfaccia verso la memoria a 128 bit (non era possibile riprogettare tutto il chip per avere l'architettura interna a 512 bit; inoltre l'NV3x ha un'architettura delle pipeline piuttosto differente da quella degli altri, che gestisce il flusso di dati in maniera diversa).

R3x0 e P10 sono nate con interfaccia a 256 bit e architettura a 512 bit.

Il numero di PC Pro di cui parlo è quello di gennaio 2003 in cui fa un roundup delle vga in commercio e una preview della FX5800 (dicendo diverse castronerie, tra l'altro).

Per le fonti, per R300, accontentati di questo (che sicuramente è più attendibile di PC pro)

http://www.3dcenter.de/artikel/2002/07-14_english_a.php

poi ci sono sempre Topolino e il manuale delle giovani marmotte

A Corsini puoi chiederlo anche subito, perchè aspettare il 24 gennaio?

pandyno

23-12-2003, 13:38

Originariamente inviato da mg13
Ora vorrei sapere le tue fonti di quello che hai scritto.

Non ti conviene iniziare una diatriba del genere, dai retta ;)

yossarian

23-12-2003, 14:11

Originariamente inviato da pandyno
Non ti conviene iniziare una diatriba del genere, dai retta ;)

ciao pandy; non si tratta di iniziare una diatriba, anche perchè non avrebbe senso (e poi non ho né il tempo né la voglia per mettermi a discutere); mg13 ha ragione sul fatto che non si trovano informazioni chiare sui vari chip neppure sui siti dei produttori (Matrox, in questo, fa eccezione in positivo). Un esempio emblematico è stato quello dell'NV30 su cui nVIDIA non solo ha cercato di far trapelare il meno possibile, ma le informazioni che filtravano (a livello di voci di corridoio) erano, spesso, anche distorte e non veritiere.

pandyno

23-12-2003, 14:23

Si infatti anche per la questione FP24/32 di Rxx è un macello, non ci sono fonti chiare e trovi subito smentita da un' altra parte.

cmq, ti mando un PVT ;)

mg13

23-12-2003, 14:39

Non fraintendetemi, non volevo iniziare una diatriba ma sapere solo dove trovare quello che yossarian diceva, visto che i produttori non danno molte informazioni e anch'io non ho trovato nulla in merito.
La battuta del Topolino e del Manuale delle giovani marmotte, potevi anche risparmiartela visto che mi sembrava di discutere civilmente e seriamente.

yossarian

23-12-2003, 14:44

Originariamente inviato da pandyno
Si infatti anche per la questione FP24/32 di Rxx è un macello, non ci sono fonti chiare e trovi subito smentita da un' altra parte.

cmq, ti mando un PVT ;)

pvt letto.

Per la questione FP24/FP32 effettivamente c'è stata un po' di confusione, almeno a livello di notizie diffuse in giro (e bisogna ringraziare anche ATi per questo); le cose stanno in questi termini:
R3x0 lavora, a livello di unità di calcolo, a FP24 (qualunque sia la chiamata), salvo poi scalare a FP32 o a FP16 a livello di profondità di colore e utilizza, per le texture, indirizzi a 32 bit. Questo per le unità PS e relativamente ai calcoli in floating point (i VS lavorano in full fp32 ma questo vale già dalle DX8). Questo vale per tutta la gamma R3x0 (i chip sono praticamente identici a livelli di architettura interna: gli unici a differenziarsi, in minima parte, sono quelli con memory bus controller a 128 bit).

yossarian

23-12-2003, 14:45

Originariamente inviato da mg13
Non fraintendetemi, non volevo iniziare una diatriba ma sapere solo dove trovare quello che yossarian diceva, visto che i produttori non danno molte informazioni e anch'io non ho trovato nulla in merito.
La battuta del Topolino e del Manuale delle giovani marmotte, potevi anche risparmiartela visto che mi sembrava di discutere civilmente e seriamente.

ok, scusa ;)

hai un pvt

pandyno

23-12-2003, 14:47

Originariamente inviato da yossarian
pvt letto.

Per la questione FP24/FP32 effettivamente c'è stata un po' di confusione, almeno a livello di notizie diffuse in giro (e bisogna ringraziare anche ATi per questo); le cose stanno in questi termini:
R3x0 lavora, a livello di unità di calcolo, a FP24 (qualunque sia la chiamata), salvo poi scalare a FP32 o a FP16 a livello di profondità di colore e utilizza, per le texture, indirizzi a 32 bit. Questo per le unità PS e relativamente ai calcoli in floating point (i VS lavorano in full fp32 ma questo vale già dalle DX8). Questo vale per tutta la gamma R3x0 (i chip sono praticamente identici a livelli di architettura interna: gli unici a differenziarsi, in minima parte, sono quelli con memory bus controller a 128 bit).

yes, l' ho letto fino allo sfinimento :p

Tra l' altro ricordo che in una discussione avvenuta su nVitalia, postai un link dal sito ATI nel quale dichiarava FULL FP32, qualche giorno dopo svanito nel nulla....:D

yossarian

23-12-2003, 14:52

Originariamente inviato da pandyno
yes, l' ho letto fino allo sfinimento :p

Tra l' altro ricordo che in una discussione avvenuta su nVitalia, postai un link dal sito ATI nel quale dichiarava FULL FP32, qualche giorno dopo svanito nel nulla....:D

parli di quello all'uscita della 9800?
Ti dirò, per come la vedo (e per quello che so dell'R3x0), anche l'f-buffer non è una novità della 9800 (è una tecnica nota agli addetti ai lavori da circa due anni ed è di facile implementazione, soprattutto su un chip strutturalmemente nato per sfruttarla).
Una modifica delle ALU (nel caso di full FP32) e un aumento del numero dei registri temporanei (di circa il 25% per il passaggio da FP24 a FP32) e di una quantità imprecisata e dipendente dall'utilizzo che si vuole fare della funzionalità di f-buffer on chip, richiede la riprogettazione di gran parte delle pipeline di rendering (cosa del tutto impensabile nel passaggio da R300 a R350); molto più verosimile l'attivazione di alcune funzionalità fino ad allora tenute inattive o un diverso utilizzo di parte dei registri temporanei già presenti nel chip, nonchè di parte del frame buffer (gli f-buffer possono essere anche esterni al chip e allocati nel frame buffer o, addirittura, nella ram di sistema).

pandyno

23-12-2003, 15:02

Si, si parlava per R350 di FULL FP32, chiaramente smentito

Resta ancora un piccolo margine per 350 pero', si parla dell' 1% di distacco rispetto R300, ottimizzazione interna?

yossarian

23-12-2003, 15:11

Originariamente inviato da pandyno
Si, si parlava per R350 di FULL FP32, chiaramente smentito

Resta ancora un piccolo margine per 350 pro', si parla dell' 1% di distacco rispetto R300, ottimizzazione interna?

sicuramente; si può ottimizzzare anche semplicemente, ad esempio, modificando leggermente la logica di funzionamento di qualche unità di calcolo o lavorando sul compilatore o sul flusso di dati, per ottenere qualche piccolo margine di guadagno.
Di contro, in alcune applicazioni, il vantaggio che si avrebbe con l'f-buffer (qualora fosse presente su un chip e non sull'altro) sarebbe enorme, sia in termini di prestazioni che di qualità d'immagine (ad es. permette di renderizzare correttamente le superfici semitrasparenti, cosa che non sempre avviene con i metodi tradizionali).

pandyno

23-12-2003, 15:22

Spero di non vedere un' altra 9800Super XT in commercio ;)

D' altro canto cosi' l' HW attuale sarà sfruttato a dovere

mg13

23-12-2003, 19:14

Originariamente inviato da yossarian
ok, scusa ;)

hai un pvt

Sì ce l'ho e scuse accettate.

Ho anche letto il link che avevi postato prima, ma sul nv30 non aveva notizie precise, poi ho visto che della Parhelia diceva che ne applica solo 4 di texture x passata, mentre tu se non erro dicevi 16 come l'ATI.

yossarian

23-12-2003, 20:22

Originariamente inviato da mg13
Sì ce l'ho e scuse accettate.

Ho anche letto il link che avevi postato prima, ma sul nv30 non aveva notizie precise, poi ho visto che della Parhelia diceva che ne applica solo 4 di texture x passata, mentre tu se non erro dicevi 16 come l'ATI.

su NV30 non aveva notizie precise perchè nVIDIA non ha mai divulgato notizie sull'architettura del chip né prima né dopo l'uscita dell'NV30 (tanto che, per molto tempo, si era nell'incertezza se si trattasse di una 4x2, come sembrava dai test sintetici, o una 8x1 come aveva inizialmente lasciato trapelare NV).
La Parhelia può applicare solo 4 texture per passata (infatti è PS1.3 compliant, da questo punto di vista, anche se, per altri aspetti, è più avanzata rispetto alle specifiche suddette; questo perchè Matrox continua, in maniera inspiegabile, a rinunciare all'utilizzo di registri interni per l'immagazzinamento dei risultati intermedi dell'elaborazione: in tal modo, avendo 4 TMU riesce ad applicare fino a 4 texture sia per ciclo di clock che per single pass, mentre, ad esempio, l'R300, avendo una sola TMU ma utilizzando registri temporanei per le texture, riesce ad arrivare fino a 16 texture per single pass, pur applicando una sola texture per ciclo di clock).
La Parhelia ha introdotto una serie di novità (architettura a 512 bit, memory bus a 256 bit, 10 bit per colore nel frame buffer, tanto per dirne alcune); ha la migliore uscita 2D in assoluto, a livello di filtri, è l'unico chip ad applicare una funzione di AA anche in 2D ed è l'unico chip di tipo consumer a gestire fino a 3 monitor. Purtroppo, sul piamno delle prestazioni pure è penalizzata da alcune scelte, in parte obbligate: basse frequenze di funzionamento, ,ancanza di un algoritmo di HSR e, in caso di utilizzo massiccio di multitexturing, mancanza di registri temporanei e necessità di accedere al frame buffer quando si applicano più di 4 texel per pixel. Non teme confronti, invece, in termini di numero di unità logiche (5 per pipeline, per un totale di 20 contro, ad esempio, le 12 dell'NV35 e le 24 disposte, però su 8 pipeline, dell'R3x0). Inoltre, in caso di input contenente molti calcoli matematici e poche texture, la Parhelia può far lavorare in serie le ALU di 2 pipeline contigue, divenendo, a tutti gli effetti, una 2x4 (2 pipeline di rendering, ognuna con 4 TMU), con ciascuna pipeline dotata, però, di 10 ALU.

shodan

24-12-2003, 14:48

Originariamente inviato da yossarian
su NV30 non aveva notizie precise perchè nVIDIA non ha mai divulgato notizie sull'architettura del chip né prima né dopo l'uscita dell'NV30 (tanto che, per molto tempo, si era nell'incertezza se si trattasse di una 4x2, come sembrava dai test sintetici, o una 8x1 come aveva inizialmente lasciato trapelare NV).
La Parhelia può applicare solo 4 texture per passata (infatti è PS1.3 compliant, da questo punto di vista, anche se, per altri aspetti, è più avanzata rispetto alle specifiche suddette; questo perchè Matrox continua, in maniera inspiegabile, a rinunciare all'utilizzo di registri interni per l'immagazzinamento dei risultati intermedi dell'elaborazione: in tal modo, avendo 4 TMU riesce ad applicare fino a 4 texture sia per ciclo di clock che per single pass, mentre, ad esempio, l'R300, avendo una sola TMU ma utilizzando registri temporanei per le texture, riesce ad arrivare fino a 16 texture per single pass, pur applicando una sola texture per ciclo di clock).
La Parhelia ha introdotto una serie di novità (architettura a 512 bit, memory bus a 256 bit, 10 bit per colore nel frame buffer, tanto per dirne alcune); ha la migliore uscita 2D in assoluto, a livello di filtri, è l'unico chip ad applicare una funzione di AA anche in 2D ed è l'unico chip di tipo consumer a gestire fino a 3 monitor. Purtroppo, sul piamno delle prestazioni pure è penalizzata da alcune scelte, in parte obbligate: basse frequenze di funzionamento, ,ancanza di un algoritmo di HSR e, in caso di utilizzo massiccio di multitexturing, mancanza di registri temporanei e necessità di accedere al frame buffer quando si applicano più di 4 texel per pixel. Non teme confronti, invece, in termini di numero di unità logiche (5 per pipeline, per un totale di 20 contro, ad esempio, le 12 dell'NV35 e le 24 disposte, però su 8 pipeline, dell'R3x0). Inoltre, in caso di input contenente molti calcoli matematici e poche texture, la Parhelia può far lavorare in serie le ALU di 2 pipeline contigue, divenendo, a tutti gli effetti, una 2x4 (2 pipeline di rendering, ognuna con 4 TMU), con ciascuna pipeline dotata, però, di 10 ALU.

Mmm... moooolto interessante! ;)
Due domande yossarian:

1) Le Parhelia può utilizzare le sue complessive 16 TMU per applicare su un singolo pixel 16 texture per passata? Un po' come le GeForce256 che avevano un'architettura 4x1 ma all'occorrenza potevano anche far lavorare tutte le 4 pipe su un unico pixel, permettendo cos' di raggiungere il quad texturing in singola passata (naturalmene per singolo pixel).

2) Nel caso in cui la parhelia dovesse trovarsi in "assetto" di 2x4, molto potenza di calcolo delle TMU non andrebbe persa (a meno che non ci siano 4 texture per pixel, ma mi pare di aver capito che la parhelia "sceglie" questa modalità in caso di poche texture e molti calcoli). Inoltre quando parli di unità logiche parli degli stage delle unità pixel shader (mi pare proprio siano 5 per pipe).

Un'ultima cosa: mica tu o pandyno mi potete linkare le discussioni a cui facevate riferimento? :)

Ciao grazie! :)

yossarian

24-12-2003, 15:14

Originariamente inviato da shodan
Mmm... moooolto interessante! ;)
Due domande yossarian:

1) Le Parhelia può utilizzare le sue complessive 16 TMU per applicare su un singolo pixel 16 texture per passata? Un po' come le GeForce256 che avevano un'architettura 4x1 ma all'occorrenza potevano anche far lavorare tutte le 4 pipe su un unico pixel, permettendo cos' di raggiungere il quad texturing in singola passata (naturalmene per singolo pixel).

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).

Originariamente inviato da shodan

2) Nel caso in cui la parhelia dovesse trovarsi in "assetto" di 2x4, molto potenza di calcolo delle TMU non andrebbe persa (a meno che non ci siano 4 texture per pixel, ma mi pare di aver capito che la parhelia "sceglie" questa modalità in caso di poche texture e molti calcoli). Inoltre quando parli di unità logiche parli degli stage delle unità pixel shader (mi pare proprio siano 5 per pipe).

Ciao grazie! :)

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

Originariamente inviato da shodan

Un'ultima cosa: mica tu o pandyno mi potete linkare le discussioni a cui facevate riferimento? :)

Ciao grazie! :)

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

pandyno

24-12-2003, 15:22

Originariamente inviato da shodan

Un'ultima cosa: mica tu o pandyno mi potete linkare le discussioni a cui facevate riferimento? :)

A boh, fai un search, in pratica su nvitalia non si parlava di altro :D

yossarian

24-12-2003, 16:40

credo che il link sia questo

http://www.nvitalia.com/forum/showthread.php?threadid=22939

comunque, se sei interessato, ti consiglio di dare un'occhiata anche ad altre discussioni sul forum di nV Italia (ordinale per numero di risposte nell'ultimo anno e prendi buona parte di quelle delle prime due pagine in cui si fa cenno alle architetture di NV3x e R3x0).

ciao

pandyno

24-12-2003, 17:58

mmhh si il link ufficiale era questo

http://www.ati.com/technology/wp/directx9.html

e quanto si diceva era questo:

DirectX 9.0 is available as an update to Windows operating systems. To fully experience the benefits it provides, you will need one of the latest generation of high performance graphics accelerators that supports all the major new features, including 2.0 Vertex Shaders, 2.0 Pixel Shaders, and 128-bit floating point data formats. The first available products to support these features are the RADEON 9700 series and RADEON 9500 series VPUs from ATI. The demos described in this paper provide examples of how they can be used to achieve amazing new visual effects.

Chiaramente non si fa più menzione di quanto scritto sopra nel sito ATI, o per lo meno non ho trovato nulla di recente.

Ammetto pero' di non ricordare nello specifico di cosa si stava parlando e al momento non ho tempo per ''ripassare''

c' è sempre Yoass se volete :sofico:

shodan

25-12-2003, 13:14

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!! :D
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? :confused:
[FINE EDIT]

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

Ciao e grazie.

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

shodan

27-12-2003, 18:07

UP! :)

Redvex

27-12-2003, 18:16

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

checo

27-12-2003, 18:41

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? :confused:
[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

27-12-2003, 19:28

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!!! :eek:
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! :D).

CIAO! :)

checo

27-12-2003, 19:48

cosa intendi per oggi lavoriamo a 8 bit per canale?

shodan

27-12-2003, 20:10

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

27-12-2003, 20:13

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

27-12-2003, 20:40

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

27-12-2003, 21:17

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

28-12-2003, 23:59

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 :p): 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

06-01-2004, 14:08

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 :p): 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

06-01-2004, 18:03

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! :)