[THREAD UFFICIALE] Aspettando R700

[Foglia Morta]

Originariamente inviato da yossarian

grandi e grossi non direi, visto che ciascuno richiede 1/3 circa dei registri rispetto a quanto fanno quelli di G80, fregnoni, magari, si; ma la colpa non è tutta loro; anche il compiler ci ha messo del suo

ecco grazie... sono certo che con questa risposta hai ridato sonni tranquilli a molti forumisti

[Mercuri0]

Originariamente inviato da yossarian

perchè un'emulazione via SW è sempre più lenta e meno affidabile. Le difficoltà incontrate nella parallelizzazione delle operazioni, con codice generico, nelle architetture vliw (che si affidano al compiler per questo task), sono emblematiche. Il bilanciamento dei carichi di lavoro via SW non è destinato ad ottenere risultati migliori)

Non capisco però perché "meno affidabile". Un bilanciamento del carico di lavoro via hardware dovrebbe avere la stessa "affidabilità" di uno via software, con la differenza che l'hardware non lo puoi scaricare da internet.

Certo, il mio discorso vale a parità di architettura: è ovvio che un chip "magico" e ultracompatibile che facesse la ripartizione del carico tra due GPU sarebbe preferibile ai driver di oggi che lo fanno, ma se questo chip potesse esistere, esisterebbe anche un driver in grado di farlo, magari non alla stessa velocità.

Il discorso dell'architettura vliw non mi sembra molto attinente alla ripartizione del carico tra GPU.

[HackaB321]

Originariamente inviato da Foglia Morta

Riguardo gli shader processor di R600 e derivati cosa ti viene in mente se ti dico che sono Grandi Grossi & Fregnoni ? ( nessuno qui l'ha mai capito ed è un dubbio che mi angoscia , magari tu lo sai )

Originariamente inviato da yossarian

un miglior accesso alla ram migliora anche le prestazioni dello shader core e delle tmu (latenze più basse e ti ricordo che tra le operazioni a maggiori latenze ci sono quelle di texture fetch, motivo per cui ATi fa uso di texture cache fully associative); c'è stata anche qualche ottimizzazione a livello di parallelizzazione delle operazioni matematiche. Il vero problema di R6x0 e derivati è stato propio la difficoltà a sfruttare al massimo il parallelismo teorico possibile; le cose sarebbero migliorate se si fosse fatto AA via shader come previsto con il defferred rendering e se si fosse sfruttato maggiormente il vertex texturing (la qual cosa avrebbe permesso di mascherare l'altro punto debole di R600 e, cioè, la capacità di fare texture filtering).

Il problema del parallelismo mi fa venire in mente un' altra domanda, anche se prima vorrei leggere qualche recensione tecnica di Rv770.
R600 è dotato di 4 cluster, questo implica che il compiler dovrebbe riuscire in una situazione ottimale, in ogni ciclo (anzi ogni 4 cicli, credo, avendo R600 branching granularity di 64 threads), ad assemblare 4 macroistruzioni da "dare in pasto" ad ognuno dei 4 cluster (ognuna delle quali, in un mondo perfetto, sarebbe composta da 5 istruzioni scalari). Ora abbiamo visto che il compilatore
già così fa una fatica immane perchè deve comunque evitare le dipendenze tra istruzioni nell'assemblare le VLIW.
Ora, in Rv770 invece di incrementare il numero di sp per cluster (come molti si aspettavano) , hanno incrementato il numero dei cluster da 4 a 10 (penso per migliorare le prestazioni nel dynamic branching): questo dovrebbe aver reso il lavoro di parallelizzazione del compiler molto più difficile, eppure le prestazioni non sembrano risentirne minimamente. Hai qualche informazione a riguardo?

Un'altra cosa: cos'è il vertex texturing?

Originariamente inviato da Marko91

Secondo me pochissime.

Ho la sensazione che sarà R8x0 a passare al multicore. Magari non sullo stesso die, ma nel medesimo package. Forse ogni core potrebbe essere costituito da una versione ottimizzata e a 40nm di RV770 (con ogni MC a 128bit?).

Anche per me pochissime. Anche perchè dalle prime foto R700 sembra comunque composto da due package.

[yossarian]

Originariamente inviato da Mercuri0

Non capisco però perché "meno affidabile". Un bilanciamento del carico di lavoro via hardware dovrebbe avere la stessa "affidabilità" di uno via software, con la differenza che l'hardware non lo puoi scaricare da internet.

Certo, il mio discorso vale a parità di architettura: è ovvio che un chip "magico" e ultracompatibile che facesse la ripartizione del carico tra due GPU sarebbe preferibile ai driver di oggi che lo fanno, ma se questo chip potesse esistere, esisterebbe anche un driver in grado di farlo, magari non alla stessa velocità.

Il discorso dell'architettura vliw non mi sembra molto attinente alla ripartizione del carico tra GPU.

un controller che gestisce automaticamente il bilanciamento di carico tra i vari gruppi di alu di una gpu già esiste (è presente in tutti i chip ATi, e NV a shader unificati) ed è programmato a basso livello. Un chip analogo può gestire il bilanciamento dei carichi di lavoro tra 2 o più processori o unità di calcolo complesse. Basta solo creare una struttura di controller a più livelli (di fatto è già presente all'interno delle gpu dove esistono più controller che comunicano tra di loro).
Il driver è più lento e, poichè quanti livelli di logica ci sono, tanto più aumentano i cicli sottratti ad operazioni non finalizzate al calcolo puro e semplice, avere operazioni gestite da HW preposto a quel compito, anzichè da SW che deve essere ottimizzato per farlo velocizza le cose. Inoltre un HW programmato a basso livello è trasparente al codice a livello più alto, il che significa che non può essere influenzato da errori nella programmazione o da eventuali conflitti. Infine, l'ottimizzazione via driver di architetture sempre più complesse comporta notevole dispendio di energie con risultati non sempre all'altezza.

L'esempio dell'architettura vliw serviva a richiamare l'attenzione sui problemi di R6x0 che è parzialmente vliw; il bilanciamento dei carichi tra gruppi di unità e gli accessi alla ram, gestiti da controller HW non hanno dato nessun problema. La gestione del parallelismo delle alu di tipo vliw, invece, che doveva essere affidata ad un compilatore (e quindi doveva avvenire via SW) ha creato notevoli problemi)

[Mercuri0]

Originariamente inviato da yossarian

un controller che gestisce automaticamente il bilanciamento di carico tra i vari gruppi di alu di una gpu già esiste (è presente in tutti i chip ATi, e NV a shader unificati) ed è programmato a basso livello. Un chip analogo può gestire il bilanciamento dei carichi di lavoro tra 2 o più processori o unità di calcolo complesse. Basta solo creare una struttura di controller a più livelli (di fatto è già presente all'interno delle gpu dove esistono più controller che comunicano tra di loro).

Però il problema della ripartizione del carico nel multi GPU mi sembra più legato a problemi di texturing/rendering/ e sopratutto accesso alla memoria che non di ALU in sé. Altrimenti perché bisognerebbe ricorrere a soluzioni tipo l'AFR?

A differenza delle CPU, per cui il multi-core è l'unico modo per poter progredire oggigiorno a causa di vincoli tecnologici, il "multi gpu" è una scelta solo per contenere i costi di progettazione. Non capisco molto il discorso di "multi-gpu on-die", non è più efficiente un'architettura modulare che si possa ingrandire a piacere con il copia&incolla nel CAD, piuttosto che livelli di controller in cascata?

L'esempio dell'architettura vliw serviva a richiamare l'attenzione sui problemi di R6x0 che è parzialmente vliw; il bilanciamento dei carichi tra gruppi di unità e gli accessi alla ram, gestiti da controller HW non hanno dato nessun problema. La gestione del parallelismo delle alu di tipo vliw, invece, che doveva essere affidata ad un compilatore (e quindi doveva avvenire via SW) ha creato notevoli problemi)

Sull'ottica hardware/software abbiamo proprio visioni diverse .

Non credo che un compilatore VLIW hardware (o accelerato via hardware) sarebbe più efficace di uno software.

L'idea delle architetture VLIW è di spostare il lavoro sul software (lavoro che tra l'altro non ha vincoli di velocità, visto che la compilazione non avviene in tempo reale) per semplificare l'hardware. Io non riesco a vedere questo come prova che "software è inerentemente peggio - o meno affidabile - di hardware" anzi, il compilatore software puoi aggiornarlo...

[NicKonsumaru]

edit

[Foglia Morta]

yoss quale limite di RV670 bisogna superare per far si che una scheda con 2 gpu in 2 distinti package sullo stesso pcb non sia più un crossfire su singola scheda come lo è ora la 3870X2 ?

[yossarian]

Originariamente inviato da HackaB321

Il problema del parallelismo mi fa venire in mente un' altra domanda, anche se prima vorrei leggere qualche recensione tecnica di Rv770.
R600 è dotato di 4 cluster, questo implica che il compiler dovrebbe riuscire in una situazione ottimale, in ogni ciclo (anzi ogni 4 cicli, credo, avendo R600 branching granularity di 64 threads), ad assemblare 4 macroistruzioni da "dare in pasto" ad ognuno dei 4 cluster (ognuna delle quali, in un mondo perfetto, sarebbe composta da 5 istruzioni scalari). Ora abbiamo visto che il compilatore
già così fa una fatica immane perchè deve comunque evitare le dipendenze tra istruzioni nell'assemblare le VLIW.
Ora, in Rv770 invece di incrementare il numero di sp per cluster (come molti si aspettavano) , hanno incrementato il numero dei cluster da 4 a 10 (penso per migliorare le prestazioni nel dynamic branching): questo dovrebbe aver reso il lavoro di parallelizzazione del compiler molto più difficile, eppure le prestazioni non sembrano risentirne minimamente. Hai qualche informazione a riguardo?

R6x0 ha un'architettura che si può riassumere come 4-16-5, con 4 macro gruppi, ognuno con 16 cluster ciascuno con 5 unità scalari. Il bilanciamento dei carichi di lavoro avviene a livello di macroarchitettura (tra i 4 gruppi principali e, all'interno di ciascun gruppo, tra i 16 sottogruppi) ed è automatico. Il compiler deve fare in modo che le 5 unità scalari di ogni gruppo da 16 siano il più possibile impegnate; quindi deve riorganizzare le microistruzioni in una macroistruzione da dare in pasto a ciascun gruppo di 5 unità scalari di ogni gruppo. Il fatto di avere 4 gruppi o 10 non cambia nulla all'atto pratico (se non il fatto che gli vengono date in pasto più microistruzioni); posso solo dire che è stato organizzato meglio il lavoro complessivo del chip (ma non posso aggiungere dettagli sull'architettura).
Per quanto riguarda il branching l'avere 10 gruppi da 80 alu (16*5) avrebbe aumentato le dimensioni delle batch se si fosse mantenuto lo stesso algoritmo usato per R600 (16*10 invece di 16*4).

Originariamente inviato da HackaB321

Un'altra cosa: cos'è il vertex texturing?

il vertex texturing è la possibilità di fare texture fetch anche da parte deille unità di vertex shading (con le architetture unificate questa distinzione non ha più senso), introdotta con lo sm3.0

Originariamente inviato da HackaB321

Anche per me pochissime. Anche perchè dalle prime foto R700 sembra comunque composto da due package.

con R700 nessuna

[gianni1879]

Originariamente inviato da Foglia Morta

Riguardo gli shader processor di R600 e derivati cosa ti viene in mente se ti dico che sono Grandi Grossi & Fregnoni ? ( nessuno qui l'ha mai capito ed è un dubbio che mi angoscia , magari tu lo sai )

oddio noooooo

[The_SaN]

Originariamente inviato da gianni1879

oddio noooooo

Si, l' ha detto
Sono quasi crepato all'istante

[-noxius-]

Originariamente inviato da The_SaN

Si, l' ha detto
Sono quasi crepato all'istante

Vi dico solo che noto con piacere che mi ha messo sulla ignore list ... hehe ..
La lezione non gli è servita a nulla e continua a fare il veggente

Battuta davvero splendida tra l'altro

[Maury]

Un saluto a Yoss è sempre un piacere leggere le sue disamine

E grande ATI

[yossarian]

Originariamente inviato da Mercuri0

Però il problema della ripartizione del carico nel multi GPU mi sembra più legato a problemi di texturing/rendering/ e sopratutto accesso alla memoria che non di ALU in sé. Altrimenti perché bisognerebbe ricorrere a soluzioni tipo l'AFR?

le operazioni di texture fetch sono indubbiamente tra quelle a latenze più elevate, ma i modi per mascherare queste latenze sono molti: più thread in circolo contemporaneamente (il gran numero di registri temporanei e le cache interne ai chip lo stanno a testimoniare, texture cache di tipo set associative o fully associative, un numero di unità di texture fetch e texture address maggiore rispetto a quello di texture filtering. Il bilanciamento dei carichi di lavoro tra unità di calcolo, però, non è problematico solo per quello; si deve tener conto di un gran numero di elementi (istruzioni dipendenti da altre, priorità di alcune operazioni rispetto ad altre, possibilità di trovare alu immediatamente disponibili, ecc); non è un caso che la stragrande maggioranza dello spazio all'interno di una gpu è ormai occupato da dispositivi di controllo, da registri, da buffer e da cache e molti cicli sono impiegati per operazioni non propriamente matematiche

Originariamente inviato da Mercuri0

A differenza delle CPU, per cui il multi-core è l'unico modo per poter progredire oggigiorno a causa di vincoli tecnologici, il "multi gpu" è una scelta solo per contenere i costi di progettazione. Non capisco molto il discorso di "multi-gpu on-die", non è più efficiente un'architettura modulare che si possa ingrandire a piacere con il copia&incolla nel CAD, piuttosto che livelli di controller in cascata?

anche nelle gpu le architetture modulari sono l'unico modo per poter progredire, a mano che non si voglia accettare l'idea di chip sempre più grandi che, magari, in futuro, integreranno anche la ram all'interno. O, se vogliamo, anche per le cpu si può progredire ricorrendo ad un'architettura di tipo monolitico; basta ricreare su un'unico core la struttura di due o più core. Anche li, però, è antieconomico farlo.
Un'architettura modulare è più efficiente fino ad un certo livello di complessità, a patto di non rendere troppo macchinose le comunicazioni tra le varie gpu; e comunque, anche un'architettura multigpu o multicore che dir si voglia, da un certo livello di complessità in poi non può più essere gestita via SW (vedi, ad esempio, il cell, la cui gestione interna non avviene via SW ed è un controller HW a gestire i dma dei spe e gli stessi dma sono inizializzati dal ppe: il tutto in maniera trasparente rispetto al SW).

Originariamente inviato da Mercuri0

Sull'ottica hardware/software abbiamo proprio visioni diverse .

Non credo che un compilatore VLIW hardware (o accelerato via hardware) sarebbe più efficace di uno software.

L'idea delle architetture VLIW è di spostare il lavoro sul software (lavoro che tra l'altro non ha vincoli di velocità, visto che la compilazione non avviene in tempo reale) per semplificare l'hardware. Io non riesco a vedere questo come prova che "software è inerentemente peggio - o meno affidabile - di hardware" anzi, il compilatore software puoi aggiornarlo...

ho fatto l'esempio di un'architettura vliw (e il riferimento in ambito gpu è evidentemente a R600), perchè in quella particolare architettura è stata proprio la parte gestita via SW a creare i problemi maggiori. Poi, che le architetture vliw spostino la complessità di organizzazione a livello sw è evidente; grazie al vliw in R600 si è riusciti ad infilare 320 sp (che hanno richiesto uno spazio più che dimezzato rispetto ad una corrispondente architettura completamente gestita in HW).

Anche i controller HW possono essere "aggiornati" se sono programmabili; però, se permetti, non si può accettare l'idea che un dispositivo "critico" per il funzionamento di un chip, come un controller, possa essere programmato ad alto livello via driver, magari da persone che neppure conoscono alla perfezione l'architettura del chip

[yossarian]

Originariamente inviato da Foglia Morta

yoss quale limite di RV670 bisogna superare per far si che una scheda con 2 gpu in 2 distinti package sullo stesso pcb non sia più un crossfire su singola scheda come lo è ora la 3870X2 ?

stai innocentemente girando attorno alla domanda: come sarà gestito il dual gpu su R700, per caso?

[Foglia Morta]

Originariamente inviato da yossarian

stai innocentemente girando attorno alla domanda: come sarà gestito il dual gpu su R700, per caso?

malizioso

Kyle Bennett di HardOcp a Dicembre 2007 aveva detto che ingegneri ATi gli avevano detto che R700 non sarebbe stato un crossfire... ce lo spiegherai tra un po

[Milotto]

Originariamente inviato da Foglia Morta

yoss quale limite di RV670 bisogna superare per far si che una scheda con 2 gpu in 2 distinti package sullo stesso pcb non sia più un crossfire su singola scheda come lo è ora la 3870X2 ?

Originariamente inviato da yossarian

stai innocentemente girando attorno alla domanda: come sarà gestito il dual gpu su R700, per caso?

Sono sicuro della sua innocenza...



Cmq sono felice che questo 3d abbia preso una piega più "tech" e didattica...

[Marko91]

Oddio, RV770 è vivo!
E' consapevole di essere una chip grafico XD

[LCol84]

Originariamente inviato da Marko91

Oddio, RV770 è vivo!
E' consapevole di essere una chip grafico XD

Questa si che è la vera rivoluzione di rv770

[Marko91]

Originariamente inviato da yossarian

stai innocentemente girando attorno alla domanda: come sarà gestito il dual gpu su R700, per caso?

Non so quanto ne sappia w0mbat ma dice che saranno collegati tramite il nuovo MC.

http://forum.beyond3d.com/showpost.p...postcount=4284

[Marko91]

Originariamente inviato da LCol84

Questa si che è la vera rivoluzione di rv770

Noo... ora ho capito quali sono i malvagi piani di Ati! Stanno creando Skynet con queste chip coscienti e poi scateneranno il giorno del giudizio!! Nvidia salvaci tu!