• Als Spam markieren
• Beitrag melden

• 
  Diese Gruppe Alles

• Archiv
• RSS-Feeds

• Kontakt
• Hilfe
• Impressum
• Datenschutz

Re: PS3 .. ma come, una GPU ?!?

marcotti@gmail.com wrote:
> Davide Pasca wrote:

> Non sei obbligato ad avere un flusso ben definito di dati in uscita ed
> in entrata ma e' ovviamente meglio fare in modo che sia cosi' se vuoi
> sfruttare le SPUs come si deve.

Non sei neanche obbligato a guidare la macchina sulla strada
asfaltata.. 8)

> Non sono d'accordo, i videogiochi sono strapieni di strutture alla
> quale puoi accedere in maniera regolare, e anche quando non e'
> cosi' e' sposso possibile regolarizzarle, almeno entro certi limiti.

Da come la vedo io, i calcoli vettoriali nei giochi servono a tre cose:
la grafica e la fisica, e l'audio.
L'audio pesa poco. La fisica e la grafica (che potrebbero essere
accomunate), tendono ad essere ottimizzate tramite strutture
gerarchiche, matrici sparse, alberi, etc.
Il problema maggiore nella grafica 3D e' l'illuminazione globale, un
problema con complessita' quadratica, che mette in relazione ogni
elemento con gli altri elementi.
Nel caso dell'audio o dell'image processing, essendo 2D, si puo'
tranquillamente lavorare con elementi discreti e processare tipo DSP,
nel caso del 3D, l'eventuale voxel richiederebbe troppa memoria, per
cui si ottimizza utilizzando primitive geometriche.. non si tratta piu'
di DSP puro e il processore che cruncha numeri comincia a sentire il
peso il peso dell'accesso random.

..questo volevo dire.

> Non vedo dove sia il problema: l'esempio che hai fatto e' esattamente
> una di quelle cose che girano in maniera estremamente efficiente
> su SPUs. Puoi tranquillamente usare la CPU per decidere cosa e'
> visibile

E l'idea di batchare cose con la CPU, di dati spezzettati che va contro
al concetto di processore indipendente.

> e cosa e no e per costruire una lista di jobs per le SPUs: una volta
> che la lista del lavoro da fare e' pronta si parte.. (anzi, non devi
> manco
> aspettare che sia completa.. :) )

I risultati pero' spero che li aspetti 8P

> anche questo non vedo che particolare problema sia, nessuno ti obbliga
> a scrivere il codice piu' ottimizzato dell'universo.

..vabbe' allora diamo per assunto che gli SPU sono programmati alla
meno peggio e facciamo finta che sono 3 e mezzo anziche' 7 8)

> Programmare su SPU equivale a saper programme in C/C++ con qualche
> restrizione sui dati, tutto qui. Ovviamente c'e' sempre il problema del
> MT,
> ma quello ce l'hai comunque..pure su 360 :)

Yeah, ma su 360 mando in MT un pezzo di codice qualsiasi. Un
sottosistema intero con dei locks molto generici.

> Esattamente l'opposto, su CUDA e' compito dello sviluppatore
> decidere come distribuire il lavoro, in quanti task, gruppi di task,
> thread, etc..
> Nun ze po' 'dddi de piu' perche' c'e' l'NDA..ma quando l'SDK
> sara' pubblico mi sa che non ti piacera' tanto.. ;)

L'SDK ce l'ho, ma come ho detto ho letto comunque poco..
In generale mi piace il concetto di "highly multithreaded coprocessor".

Notare che personalmente so poco di calcolo parallelo, sicuramente il
Cell ha potenziale, ma la questione e' quanto sia facile usarlo
decentemente nei giochi piuttosto che nelle ricerche dalla IBM.

baubau
Davide

Antworten