4x2 = 8x1?

[yossarian]

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

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]

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]

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]

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]

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]

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]

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]

ti ringrazio!


bYeZ!

[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!

[Jedi_Master]

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

[CS25]

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



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]

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]

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

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]

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]

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

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

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

[REPSOL]

Miiiinchi@ questa discussione mi ha fatto perdere il sonno

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

NICE

Stà cosa del FP e dei registri interni mi intrippa

Ora però ninno.. bonanotte

[yossarian]

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

[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!