[PS3 Engine] CELL + nVIDIA RSX

[Max(IT)]

Originariamente inviato da nAo

1) quell'articolo non ha ne' capo ne' coda, non basta scrivere 3 paginate di roba piene di termini presi a casaccio qua e la e infilarci dentro 2 numeri senza senso per scrivere un articolo serio, insomma e' fuffa
2) la traduzione della fuff e' abominevole e l'ha resa ancora peggiore!
3) ogni CPU, data abbastanza memoria, puo' praticamente eseguire qualsiasi algoritmo, quindi pure il commodore 64 col quale ho iniziato a programmare (con abbastanza memoria..) potrebbe implementare DX10 da cima a fondo, il problema e' che non sarebbe molto veloce (eufemismo!)
Stessa cosa vale per una cpu moderna, installate vista, installate DX10 SDK e lanciate una demo dall'SDK con emulazione software..se osservate un frame al minuto vi e' andata bene, pure col vostro quad core a 3 ghz nuovo fiammante.
Quindi e' ovvio che una CPU moderna puo' eseguire l'intera pipeline di rendering di DX10 (o DX11, o DX9 etc..), anche se a una velocita' non esaltante.
Ma una pipeline di rendering moderna e' suddivisa in molti task, alcuni dei quali mappano bene su una CPU (cioe' possono esssere implementati in maniera efficiente), mentre altri mappano molto male.
Ad esempio una CPU si trova, in generale, molto piu' a suo agio mentre fa vertex shading o geometry shading ( a patto che gli shader eseguiti non vogliano samplare delle texture..) che pixel shading.
Quindi non c'e' dubbio che CELL possa implementare in maniera efficiente vertex e geometry shader (con meno successo se in questi shader si devono samplare textures..) , come lo puo' fare anche la cpu di Xbox360, anche se mi aspetterei implementazioni molto piu' veloci su CELL che su 360.
MEntre se usassimo CELL per implementare tutta la pipeline di rendering i risultati sarebbero..penosi
Questo e' il motivo per il quale PS3 ha una GPU, e per il quale la storiella che PS3 fosse stata originariamente penstata per avere 2 CELL e nessuna GPU e' una baggianata: se spendi mezzo miliardo di dollari per sviluppare una CPU (cell in questo caso) e il design viene fatto per essere efficiente in alcune cose e non in altre e' ovvio che l'idea di usare CELL per eseguire task per i quali NON e' stato progettato, se mai e' stata presa in considerazione, non lo e' stata per piu' di 3 secondi.
4) Tenete presente che a entrambe Xenos e RSX mancano molte moltissime features (non solo geometry shaders) per essere DX10 compliant, e allo stesso tempo entrambe hanno features che NON sono presenti in DX10, infatti non ha molto senso dir questa GPU supporta DX9 o DX10 su una console, in quanto le varie versioni di direct X sono sviluppate per supportare una vasta gamma di GPU attraversio una interfaccia software astratta, che non ti permette di vedere cosa fa verameente l'hw, come lo fa e cosa potrebbe fare, mentre su console abbiamo un accesso molto piu' diretto all'hw. Ci sono tantissime features specifiche di ogni GPU che non sono esposte in DX9, DX10, etc.. e semplicemente non vengono usate (spesso nvidia e ati espongono queste feature in opengl attraverso delle estensioni proprietarie e non compatibili tra loro) su PC.

Marco

chiaramente non posso che concordare in pieno con quanto hai scritto qui sopra

[nAo]

Originariamente inviato da Max(IT)

beh, se si ESCLUDE moltiplicazioni ...
In calcoli di tipo vettoriale non mi pare una cosa da poco.

Beh..di solito quando lavori su interi o su vettori di interi non fai le stesse
identiche operazioni che fai quando lavori su dati in virgola mobile, altrimenti non vi sarebbe ragione di supportare entrambi i tipi di dati.
Lavorare vettorialmente su interi su CELL significa avere la possibilita' di fare operaioni logiche su vettori di interi, contare il numero di bit a 1 su un vettore,ruotare i bit su un vettore, etc..
Cmq gli SPE supportano le moltiplicazioni su interi a full speed, ma solo su operandi a 16 bit, le divisioni invece non sono supportate per niente,ma se a uno proprio serve fare divisioni su interi puo' sempre convertire da intero a fp, dividere e convertire a interi (il che e' molto veloce su SPE..)

Dici "RSX non è G71". In cosa differisce a parte numero di ROPS e bus ?

Nun ze po di'

[Max(IT)]

Originariamente inviato da -=Krynn=-

Eccomi Se tutto va bene mi laureo a ottobre, va bene uguale?


Passiamo all'articolo va.

Sono riuscito a leggerlo fino in fondo, e non mi sembra tanto campato per aria, anzi... e non è nemmeno di parte, dato che fin dall'inizio dice che per un programmatore medio è più facile programmare su X360, che il risultato viene meglio ed in minor tempo, quindi non mi pare denigri la console microsoft.

mio caro "laureando" , guarda, l' articolo è a dir poco approssimativo e, come già detto, non ha capo ne coda.
Non è sulle conclusioni che non si può concordare (potenzialità del Cell e difficoltà ad ottenere risultati nell' immediato), ma sul modo in cui l' autore ci è giunto.
Io non so quanto tu mastichi di architettura dei processori e di grafica in generale (io molto più della prima che della seconda, per preparazione professionale), ma sulla sua analisi ho davvero poco da condividere.

[naoto84]

Originariamente inviato da nAo

Esatto, tipicamente si prende l'immagine HDR (in qualsiasi formato sia stata renderizzata, l'importante e' che codifichi in qualche modo una immagine con un range piu' ampio del classico 0..1), e da questa si puo' determinare qual e' l'espozione piu' o meno necessaria per convertirla a un range che e' displayable dai monitor attuali (generalmente si fa la media del logaritmo della luminanza di un parte rilevante dell'immagine), poi si fa 'tone mapping' usando il valore dell'esposizione calcolato predentemente se i porta l'immagine nel range 0..1

Approfitto ancora della tua disponibilità...

- Il tone mapping è una trasformazione globale? Questo non sono riuscito a capirlo da me...

- La finezza della grandezza misurata nell'HDR è costante: radianza misurata in maniera lineare. Tuttavia, a valle di trasformazioni che debbano simulare il comportamento logaritmico di un sensore, questa finezza diventa non costante. Enorme per i valori alti e scarsa per quelli bassi (spero di non stare dicendo una stupidaggine).
Se faccio tone mapping con un'esposizione molto bassa potrebbe succedere che i livelli di luminanza di output (ipotizziamo 10 bit) corrispondano ai livelli di radianza nell'HDR con una finezza superiore a quella dell'immagine HDR (che diventa quindi insufficiente)?
Come dire: i bit dell'HDR non sono mai abbastanza? Ci vorrebbe una misura di radianza continua (come nella realtà), con quantizzazione fatta solamente dal sensore (come nelle fotografie)?

[Legolas84]

Originariamente inviato da Max(IT)

mio caro "laureando" , guarda, l' articolo è a dir poco approssimativo e, come già detto, non ha capo ne coda.
Non è sulle conclusioni che non si può concordare (potenzialità del Cell e difficoltà ad ottenere risultati nell' immediato), ma sul modo in cui l' autore ci è giunto.
Io non so quanto tu mastichi di architettura dei processori e di grafica in generale (io molto più della prima che della seconda, per preparazione professionale), ma sulla sua analisi ho davvero poco da condividere.

nAo è la persona più preparata, quindi se l'ha detto lui è evidente che sia così...

[Max(IT)]

Originariamente inviato da nAo

Beh..di solito quando lavori su interi o su vettori di interi non fai le stesse
identiche operazioni che fai quando lavori su dati in virgola mobile, altrimenti non vi sarebbe ragione di supportare entrambi i tipi di dati.
Lavorare vettorialmente su interi su CELL significa avere la possibilita' di fare operaioni logiche su vettori di interi, contare il numero di bit a 1 su un vettore,ruotare i bit su un vettore, etc..
Cmq gli SPE supportano le moltiplicazioni su interi a full speed, ma solo su operandi a 16 bit, le divisioni invece non sono supportate per niente,ma se a uno proprio serve fare divisioni su interi puo' sempre convertire da intero a fp, dividere e convertire a interi (il che e' molto veloce su SPE..)

perfetto, detto così è più chiaro.
Io immagino che cmq si converta sempre in fp per comodità (sono fuori dal settore da un pò, ma io farei così)

Nun ze po di'

eh, lo immaginavo, ma speravo che su questo potessi sbottonarti un pò.
Da quanto leggo in giro, pensavo non fosse troppo diverso da un G73 (numero di pipes leggermente differente).
G73 non è coperto da NDA: non puoi parlare neppure di questo ? Insomma, affrontare l' argomento "al contrario"

[Max(IT)]

Originariamente inviato da Legolas84

nAo è la persona più preparata, quindi se l'ha detto lui è evidente che sia così...

lo stesso Nao ha giustamente detto che l' articolo è in gran parte "spazzatura", eh

[nAo]

Originariamente inviato da naoto84

- Il tone mapping è una trasformazione globale? Questo non sono riuscito a capirlo da me...

Ci sono tone mapping globali e locali, non so molto su i secondi se che non sono molto piu' complessi.
Anche se una idea per fare uno locale e semplice ce l'ho,ma e' talmente idiota che sicuramente non funziona, altrimenti qualche ricercatore ci avrebbe gia' pensato.

- La finezza della grandezza misurata nell'HDR è costante: radianza misurata in maniera lineare. Tuttavia, a valle di trasformazioni che debbano simulare il comportamento logaritmico di un sensore, questa finezza diventa non costante. Enorme per i valori alti e scarsa per quelli bassi (spero di non stare dicendo una stupidaggine)..

Nessuna stupidaggine, stai parlando della curva gamma tipica dei display CRT e che viene 'simulata' anche su LCD per espandere il range da 8 bit a circa 10.

Se faccio tone mapping con un'esposizione molto bassa potrebbe succedere che i livelli di luminanza di output (ipotizziamo 10 bit) corrispondano ai livelli di radianza nell'HDR con una finezza superiore a quella dell'immagine HDR (che diventa quindi insufficiente)?

Non lo puoi sapere a priori, dipende dal tone mapping che fai, ci sono letteralmente decine e decine di algoritmi differenti, con curve di tone mapping differenti.

Come dire: i bit dell'HDR non sono mai abbastanza? Ci vorrebbe una misura di radianza continua (come nella realtà), con quantizzazione fatta solamente dal sensore (come nelle fotografie)?

In teoria non sono mai abbastanza, in pratica si in quanto non siamo in grado di percepire variazione continue di luminanza e cromaticita' (uso la terminologia dello spazio CIE) sotto una determinata soglia.

[nAo]

Originariamente inviato da Max(IT)

perfetto, detto così è più chiaro.
Io immagino che cmq si converta sempre in fp per comodità (sono fuori dal settore da un pò, ma io farei così)

Ci sono algoritmi che richiedono estrema accuratezza e precisione nei calcoli che non mappano bene su calcoli in virgola mobile per vari motivi (ad esempio a*(b*c) puo' essere diverso da (a*b)*c se fai calcoli con lo standard IEEE per singola e doppia precisione), un esempio pratico e' la rasterizzazione di un triangolo: per far si che sia perfetta (watertight rasterization) in modo che non ci siano mai buchi tra un edge di un triangolo e un'altro edge di un altro triangolo che sono perfettamente sovrapponibili ma che sono genenrati da coordinate diverse/coordinate identiche che arrivano da direzioni diverse si usano calcoli in virgola fissa (cioe' su interi ma tenendo conto di una parte frazionaria) in modo da controllare in maniera perfetta l'errore nei calcoli e fare in modo che non sia mai visivamente significativo.
Non conosco nessuna GPU che implementa la rasterizzazione con calcoli in virgola mobile, ma siccome non e' una parte programmabile esposta agli sviluppatori e' una cosa poco conosciuta.

eh, lo immaginavo, ma speravo che su questo potessi sbottonarti un pò.
Da quanto leggo in giro, pensavo non fosse troppo diverso da un G73 (numero di pipes leggermente differente).
G73 non è coperto da NDA: non puoi parlare neppure di questo ? Insomma, affrontare l' argomento "al contrario"

NOn e' cosi' semplice, non pensare che Sony ti venga a dire che RSX e' differente qui qui e qua.. RSX e' RSX, non G71, NV47 o quant'altro, e' un processore a parte che le sue specificita', e non sono poche..e spesso non sono apparenti, neanche dalla documentazione.
Ma non tutti sono maniaci dell'hw come me..

[darkfear]

sono estasiato da ognuno dei vostri commenti sto leggendo tutto

vi prego continuate

[Legolas84]

Originariamente inviato da Max(IT)

lo stesso Nao ha giustamente detto che l' articolo è in gran parte "spazzatura", eh

Guarda che se lo dice lui sono perfettamente daccordo, mica ho detto il contrario, e nel postarlo non l'ho mai preso come assoluta verità eh!

[naoto84]

Grazie Nao, troppo gentile... andrò a documentarmi per altri dettagli.
Anche se qui a documentarsi su tutto quello che c'è scritto nel topic mi sa che ci vogliono anni.

[-=Krynn=-]

Originariamente inviato da nAo

RSX non e' G71.

Cosa è di preciso allora?

[nAo]

Originariamente inviato da -=Krynn=-

Cosa è di preciso allora?

RSX

[-=Krynn=-]

uff vabbè, ho letto nella pagina dopo che non potevi sbottonarti sull'argomento, ma ormai avevo già postato...

[Max(IT)]

Originariamente inviato da Legolas84

Guarda che se lo dice lui sono perfettamente daccordo, mica ho detto il contrario, e nel postarlo non l'ho mai preso come assoluta verità eh!

si, infatti il tuo post di qualche pagina fa era chiaro in tal senso.
Solo che, per quanto concordi completamente sulla preparazione di Nao (presenza che vorrei vedere più assiduamente sul forum), tieni conto che c' è gente qui dentro che magari adesso fa altro ma MAGARI ha iniziato a programmare anche prima di lui e che senza scomodare la preparazione di un illustre professionista del settore può accorgersi del pressapochismo dell' articolo

Originariamente inviato da nAo

Ci sono algoritmi che richiedono estrema accuratezza e precisione nei calcoli che non mappano bene su calcoli in virgola mobile per vari motivi (ad esempio a*(b*c) puo' essere diverso da (a*b)*c se fai calcoli con lo standard IEEE per singola e doppia precisione), un esempio pratico e' la rasterizzazione di un triangolo: per far si che sia perfetta (watertight rasterization) in modo che non ci siano mai buchi tra un edge di un triangolo e un'altro edge di un altro triangolo che sono perfettamente sovrapponibili ma che sono genenrati da coordinate diverse/coordinate identiche che arrivano da direzioni diverse si usano calcoli in virgola fissa (cioe' su interi ma tenendo conto di una parte frazionaria) in modo da controllare in maniera perfetta l'errore nei calcoli e fare in modo che non sia mai visivamente significativo.
Non conosco nessuna GPU che implementa la rasterizzazione con calcoli in virgola mobile, ma siccome non e' una parte programmabile esposta agli sviluppatori e' una cosa poco conosciuta.

ti ringrazio, spiegazione esemplare.

NOn e' cosi' semplice, non pensare che Sony ti venga a dire che RSX e' differente qui qui e qua.. RSX e' RSX, non G71, NV47 o quant'altro, e' un processore a parte che le sue specificita', e non sono poche..e spesso non sono apparenti, neanche dalla documentazione.

non è così semplice ma forse neppure così complesso. RSX è comunque una soluzione tutto sommato sviluppata "in fretta", quindi è verosimile pensare ad un' adattamento di quanto già avevano in casa all' epoca, più che ad uno sviluppo ex-novo (e lo dimostra la mancanza di architettura di tipo shared).
Per quanto mi riguarda credo che RSX non sia lontano da un G73, con pesanti modifiche al controller della memoria.
Mi spiace che tu non possa addentrarti nel discorso.

Ma non tutti sono maniaci dell'hw come me..

per come hanno insegnato a me, e per come la penso effettivamente io, la passione per l' hw è FONDAMENTALE per un programmatore, specie se "a basso livello".
Del resto tu, da quanto leggo, hai iniziato dal C64 (io dallo Z80, non troppo lontano), quindi sai benissimo come fosse necessario conoscerne BENE l' hw per sfruttarlo davvero. Oggi ci sono SDK che magari permettono di programmare senza conoscere UNA VIRGOLA dell' hw su cui gira il codice, ma per come la penso io questo approccio non porta lontano e restituisce solo giochi tutti uguali tra loro (dal punto di vista tecnico) e tutt' altro che ottimizzati.
Spero vivamente che come te la pensino nello stesso modo tutti i maggiori programmatori.

[Mason]

Ciao Marco

Una delucidazione:
2 pool di memoria differente, ho sempre pensato che le texture per rsx fossero pescate direttamente da gddr3, mentre ho letto che tramite un bridge tra rsx e xdram puo' accedere anche a questo pool, e possibile e vantaggioso farlo? si fa?

Cosa ne pensi 2 due vantaggi di x360 rispetto all arch 360: 512 ram (text piu definite), edram da 10mb (operazioni su color apha e altro praticamente a gratis), saranno colmabili da ps3? Mi rendo conto che la domanda fa perno sulle caratteristiche delle 2 macchine, ma sopratutto per la prima, mi piacerebbe sapere come la vedi tu

[nAo]

Originariamente inviato da Mason

Ciao Marco

Una delucidazione:
2 pool di memoria differente, ho sempre pensato che le texture per rsx fossero pescate direttamente da gddr3, mentre ho letto che tramite un bridge tra rsx e xdram puo' accedere anche a questo pool, e possibile e vantaggioso farlo? si fa?

Si, si e si.

Cosa ne pensi 2 due vantaggi di x360 rispetto all arch 360: 512 ram (text piu definite), edram da 10mb (operazioni su color apha e altro praticamente a gratis), saranno colmabili da ps3? Mi rendo conto che la domanda fa perno sulle caratteristiche delle 2 macchine, ma sopratutto per la prima, mi piacerebbe sapere come la vedi tu

Non sapevo 360 avesse texture piu' definite! A parte gli scherzi entrambe le console hanno a disposizione piu' o meno lo stesso quantitativo di memoria per le texture, non credo ci sia nessun gap dal colmare, anche se probabilmente su PS3 usare tutta la memoria disponibile per le texture e' piu' complicato che su 360.
Per quanto rigaurda l'edram e' vantaggiosa per alcune cose, meno vantaggiosa per altre (per fare AA devi renderizzare parti della scena N volte e per usare come texture qualcosa che hai generato con la GPU devi dumpare il contenuto dell'edram sulla memoria esterna, che per quanto veloce sia puo' essere un costo aggiuntivo.
Ci sono titoli per PS3 gia' usciti da tempo che usano tonnellate di particelle a tutto schermo senza colpo ferire (motostorm), il che vuol dire che la mancanza di edram e quindi di fillrate puo' essere sopperita in altri modi, basta usare quella cosa che abbiamo in mezzo alle orecchie

[ivano444]

ok...ma alla fine....tanto per sapere...chi la spunta?

[nAo]

Originariamente inviato da ivano444

ok...ma alla fine....tanto per sapere...chi la spunta?

deve per forza spuntarla qualcuno o qualcosa?