Una nuova dimostrazione della tecnologia Cell

[Banus]

Originariamente inviato da fek

Se non ho detto una scemenza, si', non hanno interfaccia verso la memoria centrale per prelevare dati e istruzioni, e questo fa parte del design, di modo da avere un modello di latenze costante per semplificare il progetto.

In bsa all'articolo di arstechnica (http://arstechnica.com/articles/paedia/cpu/cell-1.ars/2) le SPE hanno la possibilità di caricare dati direttamente dalla memoria centrale nella loro memoria locale. Il caricamento è esplicito (gestito a livello di codice).

[fantoibed]

Ora devo andare via e quindi purtroppo non leggerò la risposta prima di venerdì prossimo, comunque ho trovato un documento che sembra interessante sul sito della IBM. MPR-Cell-details-article-021405.pdf.

Purtroppo non ho avuto il tempo di leggerlo tutto, ma da un'occhiata veloce parrebbe che nè le SPU nè la PPU abbiano accesso diretto alla memoria, ma che tutto sia demandato all'EIB che a sua volta è collegato al MIC (che dovrebbe essere una specie di northbrige da quel che ho capito) che a sua volta accede alle XDR (...che al mercato mia madre comprò! )

Altro documento che sembrerebbe interessante è, secondo me, questo:
http://www.realworldtech.com/page.cf...WT021005084318

Saluti e alla prox settimana!

[fek]

Originariamente inviato da Banus

In bsa all'articolo di arstechnica (http://arstechnica.com/articles/paedia/cpu/cell-1.ars/2) le SPE hanno la possibilità di caricare dati direttamente dalla memoria centrale nella loro memoria locale. Il caricamento è esplicito (gestito a livello di codice).

Ok, allora ho detto una scemenza
Quindi e' possibile programmare il DMA direttamente dall'SPE in maniera esplicita senza passare dal controllore?
Vorrebbe dire che teoricamente e' possibile simulare qualcosa di simile ad un "texture fetch" direttamente dall'SPE.

Ecco il passo:

The SPE's ISA, which is not VMX/Altivec-derivative (more on this below), includes instructions for using the DMA controller to move data between main memory and local storage.

Grazie Banus.

[Banus]

Originariamente inviato da fek

Quindi e' possibile programmare il DMA direttamente dall'SPE in maniera esplicita senza passare dal controllore?

So che la IBM ha depositato un po' di brevetti relativi a metodi di accesso alla memoria, però non li ho letti per conservare la mia sanità mentale

Se non ricordo male l'idea è permettere di caricare blocchi di dati nella memoria locale delle SPE, in maniera simile a una cache, ma con istruzioni esplicite. In questo modo ad esempio per applicare una convoluzione ad un'immagine si carica la kernel con un'istruzione, poi con altre istruzioni si caricano i blocchi di pixel su cui il filtro sarà applicato. In questo modo il flusso di dati non deve passare per la PPE. Un'altra possibilità dovrebbe essere quella di copiare i dati nella memoria locale di un'altra SPE per eseguire istruizioni a catena (esempio, convoluzione + sogliatura).
D'altra parte la possibilità di "saltare" la PPE è uno dei motivi che dovrebbero rendere il Cell molto efficiente nei compiti facilmente vettorializzabili.

[Banus]

Originariamente inviato da fantoibed

Purtroppo non ho avuto il tempo di leggerlo tutto, ma da un'occhiata veloce parrebbe che nè le SPU nè la PPU abbiano accesso diretto alla memoria, ma che tutto sia demandato all'EIB che a sua volta è collegato al MIC

Il nostro era un discorso a livello logico
EIB dovrebbe fare le veci del bus interno del processore, permettendo il transito dei dati dal controller di memoria alle varie unità. Infatti, se vedi il layout del processore, EIB è in contatto fisico con le 8 SPE e con la PPE.

Originariamente inviato da fek

Vorrebbe dire che teoricamente e' possibile simulare qualcosa di simile ad un "texture fetch" direttamente dall'SPE.

Anche io avevo notato la somiglianza

[Criceto]

Originariamente inviato da Fx

criceto, sei un confusionario esagerato

core video e core image sono un framework che sfrutta la scheda video a far cosa? indovina un po'? a elaborare immagini. gli "effetti" che vengono applicati sono la stessa cosa di ciò che si vedeva da tempo in una serie di giochi, di bench, di demo ma portato su un uso completamente diverso.

Sorry, ma io non li avevo mai visti fare prima da qualsiasi altro software... (sarà che non gioco? E non ho una gpu programmabile? )

premesso questo non capisco:
a) perchè sono "predisposte" per il porting su cell? sono più "predisposte" per un porting su x86, se per quello, le gpu sono le stesse =)

Hanno realizzato un framework abbastanza generico da poterlo mappare su archietture diverse, come le GPU e le unità vettoriali. A questo punto nessuno vieta il loro adattamento al Cell. All'inizio sembrava una cosa per le sole GPU...

b) perchè mai dovrebbero usare il cell e non la gpu a fianco al cell?

Perchè in un computer di fascia bassa, come il MacMini, è più economico da tutti i punti di vista (costi, consumo, spazio) avere un solo processore complesso invece di 2.

[fek]

Originariamente inviato da Banus

So che la IBM ha depositato un po' di brevetti relativi a metodi di accesso alla memoria, però non li ho letti per conservare la mia sanità mentale

Se non ricordo male l'idea è permettere di caricare blocchi di dati nella memoria locale delle SPE, in maniera simile a una cache, ma con istruzioni esplicite. In questo modo ad esempio per applicare una convoluzione ad un'immagine si carica la kernel con un'istruzione, poi con altre istruzioni si caricano i blocchi di pixel su cui il filtro sarà applicato. In questo modo il flusso di dati non deve passare per la PPE. Un'altra possibilità dovrebbe essere quella di copiare i dati nella memoria locale di un'altra SPE per eseguire istruizioni a catena (esempio, convoluzione + sogliatura).
D'altra parte la possibilità di "saltare" la PPE è uno dei motivi che dovrebbero rendere il Cell molto efficiente nei compiti facilmente vettorializzabili.

Nella mia ignoranza sul Cell pensavo che il PPE caricasse i dati necessari nella memoria privata e poi "lanciasse" il programma.
In effetti cosi' e' decisamente piu' flessibile.

Il dubbio e': le istruzioni di caricamento sono bloccanti o no? Immagina un codice del tipo:

1) load kernel
2) load block_of_pixels
3) execute_kernel

Se le due load sono bloccanti, mi inchioda l'intero SPE fino a che il trasferimento dei due blocchi di memoria, le istruzioni 1 e 2, non sono completati?

Lo stesso "programma" su una GPU sarebbe eseguito su un certo numero di pipeline in contemporanea. quando la prima pipeline, ad esempio, manda il comando do fetch dalla memoria, invece di bloccarsi, ha della logica che parcheggia quel gruppo di pixel, e passa ad elaborare un altro gruppo di pixel. Quando il fetch e' completato, riesuma il primo blocco di pixel e lo elabora.

Va detto che nelle GPU odierne tutte le pipeline eseguono lo stesso programma (shader), mentre su un Cell ogni SPE puo' eseguire programmi diversi. E' un'interessante differenza che forse spiega bene quanto una GPU abbia difficiolta' ad eseguire i compiti di un Cell e viceversa.

[fek]

Originariamente inviato da Banus

Anche io avevo notato la somiglianza

Si', ma se i fetch dell'SPE sono bloccanti quanto andrebbe lento?
A meno che non ci si programmi esplicitamente il PPE per compiere il lavoro di threading per nascondere le latenze degli accessi alla memoria, tutto il lavoro che in una GPU e' hardwired.
Mi diventa sempre piu' chiaro il perche' abbiano affiancato una GPU al Cell nella PS3, un Cell si inchioderebbe al solo pensiero di dover processare pixel.

Questa considerazione vale nell'ipotesi che i fetch siano bloccanti.

[fek]

Originariamente inviato da Criceto

Perchè in un computer di fascia bassa, come il MacMini, è più economico da tutti i punti di vista (costi, consumo, spazio) avere un solo processore complesso invece di 2.

Dato un certo livello di prestazioni, e' molto piu' economico usare CPU e GPU, che usare il Cell che non e' in grado di fare nessuno dei due lavori allo stesso livello (general purpose e processare grafica) e dovrebbe essere sovradimensionato.

[Criceto]

Originariamente inviato da fek

Nella mia ignoranza sul Cell pensavo che il PPE caricasse i dati necessari nella memoria privata e poi "lanciasse" il programma.
In effetti cosi' e' decisamente piu' flessibile.

Il dubbio e': le istruzioni di caricamento sono bloccanti o no? Immagina un codice del tipo:

1) load kernel
2) load block_of_pixels
3) execute_kernel

Se le due load sono bloccanti, mi inchioda l'intero SPE fino a che il trasferimento dei due blocchi di memoria, le istruzioni 1 e 2, non sono completati?

Se ho capito la domanda, la risposta dovrebbe essere no.

Cioè la SPE esegue il suo bel codice nella memoria LOCALE (non può lavorare direttamente con la memoria centrale) e contemporanamente carica/scarica i dati elaborati con la memoria o le altre SPE.

Ricorda che il Cell ha una banda spaventosa, sia con la memoria che con le altre SPE per mezzo un un bus ad anello. Non ricordo però se la banda sia sufficiente in caso di contemporaneo accesso al bus da parte di tutte e 8 le SPE (non mi sembra, era qualcosa tipo la metà).

[Criceto]

Originariamente inviato da fek

Dato un certo livello di prestazioni, e' molto piu' economico usare CPU e GPU, che usare il Cell che non e' in grado di fare nessuno dei due lavori allo stesso livello (general purpose e processare grafica) e dovrebbe essere sovradimensionato.

Non sempre l'obbiettivo primario è avere il massimo delle prestazioni.
Il Cell è pensato come processore digitale multi-purpose ECONOMICO. Non va in competizioni con GPU da 500 Eur o processori da 1000 Eur.
Quindi un suo utilizzo "solitario" è auspicabile per il suo target, e quasi certo su macchine di fascia bassa.
Le GPU di cui parli sono processori estremamente complessi, spesso come e più del Cell in termini di transistor, quindi intrinsecamente costosi. Stai sicuro che se li possono eliminare pur mantenendo delle prestazioni "adeguate" lo faranno di certo. E il Cell dovrebbe garantire prestazioni onorevoli anche in ambiti ora di esclusiva pertinenza delle GPU.

[fek]

Originariamente inviato da Criceto

Se ho capito la domanda, la risposta dovrebbe essere no.

Non hai capito la domanda

Per quanto ampia si la banda passante, non accadra' mai che fatta la richiesta al DMA per trasferire da memoria centrare un dato, questo dato sia immediatamente disponibile all'istruzione dopo. Ci sara' sempre e comunque una certa latenza, perche' se questa latenza non esistesse non avrebbe senso avere la memoria locale.

Esempio:

fetch [addr0], mem1 # memoria centrale, NON locale
load r0, [addr0]
add r0, r0, 10

La prima istruzione richiede un dato da memoria centrale a memoria locale, la seconda istruzione lo carica in un registro da memoria locale. E' matematicamente impossibile che al momento della seconda istruzione il dato sia gia' presente in memoria locale per via delle latenze.

E' piu' probabile che accada una cosa del tipo:

fetch [addr0], mem1
# esegui qualcosa qui mentre attendi il fetch
wait [addr0]
load r0, [addr0]
add r0, r0, 10

Che esista una qualche istruzione di sincronizzazione che attende la fine del trasferimento e inchioda l'SPE. Il programmatore avrebbe sempre la possibilita' di eseguire un qualche lavoro utile fra il fetch e il wait. Se consideri che le GPU sono progettatr per nascondere automaticamente queste latenze quando processano i pixel (che accedono sempre alla memoria centrale per i fetch delle texture), hai un'ulteriore motivo per cui il Cell non potra' mai fare da GPU con prestazioni accettabile. Non e' costruito per questo lavoro.

[fek]

Originariamente inviato da Criceto

Non sempre l'obbiettivo primario è avere il massimo delle prestazioni.
Il Cell è pensato come processore digitale multi-purpose ECONOMICO. Non va in competizioni con GPU da 500 Eur o processori da 1000 Eur.
Quindi un suo utilizzo "solitario" è auspicabile per il suo target, e quasi certo su macchine di fascia bassa.
Le GPU di cui parli sono processori estremamente complessi, spesso come e più del Cell in termini di transistor, quindi intrinsecamente costosi. Stai sicuro che se li possono eliminare pur mantenendo delle prestazioni "adeguate" lo faranno di certo. E il Cell dovrebbe garantire prestazioni onorevoli anche in ambiti ora di esclusiva pertinenza delle GPU.

E' anche in grado di creare un milione di posti lavoro?

(Non hai letto nulla di quello che abbiamo scritto fin'ora, sembri un predicatore con la bibbia in mano che ripete la stessa filastrocca senza capire che vuol dire).

L'NV40 piu' economico viene venduto a meno di 50 dollari e sono stati ingegnerizzati sample con costi di produzione inferiori ai 10 dollari. Ci rinuncio, tu non sai di che stai parlando.

[Criceto]

Originariamente inviato da fek

Non hai capito la domanda

....

Esempio:

fetch [addr0], mem1 # memoria centrale, NON locale
load r0, [addr0]
add r0, r0, 10

Credo di averla capita. Ma come detto le SPE possono elaborare dati presenti solo nella memoria LOCALE, non in quella centrale.

Insomma si spezzettano i dati in blocchi da 256KB, si danno in pasto alla SPE che li elabora, e si copiano i risultati nella memoria centrale.
Credo sia questa la filosofia di funzionamento delle SPE del Cell...

[Banus]

Originariamente inviato da fek

Che esista una qualche istruzione di sincronizzazione che attende la fine del trasferimento e inchioda l'SPE. Il programmatore avrebbe sempre la possibilita' di eseguire un qualche lavoro utile fra il fetch e il wait.

Sto cercando info. Se funziona circa come Imagine, il Cell dovrebbe fare qualcosa del genere:

fetch [block 1] (startup)
fetch [block 2]
kernel [block 1]
fetch [block 3]
kernel [block 2]
...

e a regime quindi le SPE possono essere idealmente utilizzate al 100%.
Ovviamente non sempre sarà così, ad esempio quanto il rapporto operazioni/dati è molto piccolo ci saranno comunque latenze, oppure quando il flusso di dati non è coerente.

Vedo se riesco a trovare qualcosa di più preciso.

[Criceto]

Originariamente inviato da fek

E' anche in grado di creare un milione di posti lavoro?

Questa te la potevi risparmiare...

L'NV40 piu' economico viene venduto a meno di 50 dollari e sono stati ingegnerizzati sample con costi di produzione inferiori ai 10 dollari. Ci rinuncio, tu non sai di che stai parlando.

Cioè fammi capire: l'NV40 ha 220 milioni di transistor, più meno come il Cell. Quindi il costo industriali è paragobile. E viene prodotto con 10$?!
Ora ho capito perchè vogliono mettere i Cell anche nei televisori...
Comunque fidati, se mai la Apple farà un MacMini con il Cell NON avrà una GPU. Pur di risparmiare 10$ toglierebbero anche il mouse (ops, l'hanno già fatto!).

[fek]

Originariamente inviato da Criceto

Credo di averla capita. Ma come detto le SPE possono elaborare dati presenti solo nella memoria LOCALE, non in quella centrale.

Insomma si spezzettano i dati in blocchi da 256KB, si danno in pasto alla SPE che li elabora, e si copiano i risultati nella memoria centrale.
Credo sia questa la filosofia di funzionamento delle SPE del Cell...

Finalmente! Forse arriviamo a qualcosa.
Questa filosofia di funzionamento va benissimo per uno stream processor, ma e' l'esatto contrario di cio' che serve per una GPU.

I pixel possono accedere in maniera random e incoerente virtualmente qualunque locazione in memoria centrale all'interno di una o piu' texture che possono essere grandi fino a 16/32 mb. Non sarebbe possibile copiare tutte le texture in memoria locale di un SPE per poi accedere da li'.

Un pixel shader tipico e' una cosa di questo tipo:

tex2d r0, s0, t0 # equivalente di un fetch a memoria
tex2d r1, s1, t1
...
add r0, r0, r1
mov C0, r0

t0 e t1 sono gli indirizzi in memoria centrale (piu' o meno) e sono virtualmente ovunque.
Un Cell con quel modello computazionale non sarebbe in grado di eseguire uno shader di questo tipo con prestazioni accettabili, perche' si ritroverebbe continuamente a trasferire blocchi da memoria centrale a locale e ad attendere le latenze, oppure la PPU dovrebbe essere programmata esplicitamente per nascondere in qualche modo queste latenze, e non e' un compito banale per una CPU gia' per se' piuttosto lenta.

[fek]

Originariamente inviato da Criceto

Cioè fammi capire: l'NV40 ha 220 milioni di transistor, più meno come il Cell. Quindi il costo industriali è paragobile. E viene prodotto con 10$?!

Si', le versioni con meno pipeline sono prodotte a 10$ e sono enormemente piu' performanti di un Cell da 220 milioni di transistor (che non costa 10$ ma molto di piu') nel fare grafica 3d

Comunque fidati, se mai la Apple farà un MacMini con il Cell NON avrà una GPU. Pur di risparmiare 10$ toglierebbero anche il mouse (ops, l'hanno già fatto!).

Se il MacMini avesse solo un Cell a 10$ non sarebbe in grado di produrre grafica 3d in tempo reale per tutti i discorsi fatti fino ad ora. Infatti non lo avra'.

[Criceto]

Originariamente inviato da fek

Se il MacMini avesse solo un Cell a 10$ non sarebbe in grado di produrre grafica 3d in tempo reale per tutti i discorsi fatti fino ad ora. Infatti non lo avra'.

Bene, quindi secondo te il modello di programmazione del Cell non è adatto alla grafica 3D (o almeno ad alcuni suoi algoritmi, perchè penso che per altri, vada bene). Quindi la scelta di Sony di affiancargli una GPU è ancora più giustificata.

Però credo lo stesso che un eventuale MacMini col Cell non avrà un GPU, anche perchè una GeForce 6800 (NV40, giusto?) a Roma non si trova a meno di 300Eur, altro che 10$!!!

[fek]

Originariamente inviato da Criceto

Bene, quindi secondo te il modello di programmazione del Cell non è adatto alla grafica 3D (o almeno ad alcuni suoi algoritmi, perchè penso che per altri, vada bene). Quindi la scelta di Sony di affiancargli una GPU è ancora più giustificata.

Mi indichi quale algoritmo di grafica 3d pensi che andrebbe bene al Cell?

Però credo lo stesso che un eventuale MacMini col Cell non avrà un GPU, anche perchè una GeForce 6800 (NV40, giusto?) a Roma non si trova a meno di 300Eur, altro che 10$!!!

Quanto costa una 6200 Turbo Cache a Roma? NVIDIA produce il suo chip video spendendo attorno ai 10$, ed e' un signor chip video a basso costo, una cui pipeline e' in grado di eseguire tutte quelle operazioni per colpo di clock che avevo elencato in un altro post.