[PS3 Engine] CELL + nVIDIA RSX

[torgianf]

Originariamente inviato da Legolas84

Ciao, e grazie per il tuo intervento

Quindi accontoniamo pure il discorso delle directX che in effetti con le console hanno poco a che vedere...

Concentrandoci invece su CELL+RSX, tu che puoi lavorarci sopra, pensi che veramente ottimizzando il codice e delegando parte del lavoro a CELL (la parte che sa fare bene) si avrebbe un notevole incremento di prestazioni rispetto a quello che può fare ora? La curva di miglioramento (pur partendo da un livello buono in senso assoluto in cui ci troviamo ora) sarà alta come quella che abbiamo visto tutti su PS2?

Alla fine è vero che PS3 è difficile da programmare, ma se programmata bene potrebbe dare veramente tanto....

se ricordo bene gia heavenly sword delega parte del carico poligonale al cell.

[nAo]

No, in HS la grafica e' fatta tutta su RSX.
Ceramente CELL puo' affianche RSX in alcune cose e migliorare quindi le prestazioni, ci sono gia' alcuni titoli che usano CELL per eliminare qualsiasi poligono non visibile prima che venga mandato a RSX, o che implementano parte dei vertex shader (ad esempio lo skinning) per alleggerire RSX di parte dei calcoli in quei casi in cui si puo' essere vertex limited.
Sospetto che molti dei modi con i quali CELL in futuro aiutera' RSX non sono stati ancora inventati!

[Legolas84]

Sembra la conferma del fatto che c'è ancora molto da scoprire in questa architettura...

[Cobalto]

Originariamente inviato da Legolas84

Sembra la conferma del fatto che c'è ancora molto da scoprire in questa architettura...

Tempo al tempo, come per la ps2 hanno creato capolavori come God of war, così per la ps3 ne creeranno altrettanti.

La differenza sostanziale tra ieri e oggi è che fino a poco tempo fa c'era un monopolio sony, quindi tutte le sh sviluppavano per ps2 e/o pc e fine della storia, adesso invece si dividono tra 360/wii/pc/ps3 (e ce ne sono ancora tante che lavorano su ps2) quindi la situazione è profondamente cambiata, quello che un tempo poteva essere per una piccola sh un investimento sicuro (puntare sulla sony) al giorno d'oggi diventa un'incognita totale.

Della serie per lavorare su ps3 devi avere le spalle larghe, altrimenti meglio rinunciare in partenza altrimenti poi ti fai male.

[Legolas84]

Sicuramente una volta che sarà stata sviscerata questa architettura anche le software house più piccole potranno programmare spendendo meno... (ora non è così) perchè avranno a disposizione kit più sviluppati.

Ad esempio Insomniac ha aperto una sezione del suo sito dove condivide le sue esperienze di programmazione su PS3...

Originariamente inviato da Legolas84

Sicuramente una volta che sarà stata sviscerata questa architettura anche le software house più piccole potranno programmare spendendo meno... (ora non è così) perchè avranno a disposizione kit più sviluppati.

Ad esempio Insomniac ha aperto una sezione del suo sito dove condivide le sue esperienze di programmazione su PS3...

che poi scusate, ma programmare giochi per ps3 non dovrebbe essere "più facile" rispetto ad altre console in quanto ps3 sfrutta i BR e quindi i programmatori hanno 50gb di spazio su cui lavorare?

[Cobalto]

Originariamente inviato da Nerocielo

che poi scusate, ma programmare giochi per ps3 non dovrebbe essere "più facile" rispetto ad altre console in quanto ps3 sfrutta i BR e quindi i programmatori hanno 50gb di spazio su cui lavorare?

Guarda che lo spazio non c'entra nulla, non è che il bluray miracolosamente ti rende capace di programmare...



Poi non è che si "programma su bluray", il supporto è l'ultimo stadio.

Originariamente inviato da Cobalto

Guarda che lo spazio non c'entra nulla, non è che il bluray miracolosamente ti rende capace di programmare...

sempre a capire quello che vuoi capire.

intendo dire che dovrebbe (CONDIZIONALE!!) essere più facile in quanto hai più spazio e quindi non sei costretto a scegliere tra grafica o motion o altro, ma puoi mettere tutto quanto.

capito?

[Marko91]

un algoritmo grafico che su di un processore a 3.4 Ghz genera 24 milioni di vertici al secondo su Cell lo stesso identico algoritmo non ottimizzato per cell genera 589 milioni di vertici ... quindi general purpose o no S-FPU o D-FPU cambia molto poco poichè cell se ottimizzato a dovere raggiungerebbe oltre 4 miliardi di vertici al secondo ... ricerce condotte dal M.I.T. e non da gente che fa hotdog...

Parole senza senso. E' normale che la particolare architettura del Cell lo avvantaggi nei calcoli in FP, come i vertici. Si noti già l'elevata preparazione del nostro utente!

Non si può non riconoscere le difficoltà che una nuova tecnologia come questa "architettura PS3 / cell+RSX / purtroppo comporta ma in progettazione lo hanno capito senz'altro bisogna vedere quanto ci mettono i developer "e quanti siano disposti parlando di developer di terze parti fatta eccezione per il team NINJA di tecmo" a intraprendere una strada davvero difficile perchè insomma comporta tantissimi workaround "raggiri" per fare cose che magari sono di una estrema semplicità .. Microsoft in questo ha sia enormi e smisurati meriti ma anche demeriti in egual misura o forse ancora maggiore poichè ha abituato le community di developer ad avere la pappa pronta e cosi facendo li ha si "figurativamente" permesso di esprimere i propri progetti con una semplicità estrema ma dall'altro lato ha anche limitato in maniera paurosa lo sfruttamento degli hardware...

Avere degli eccellenti tool di sviluppo limitata lo sfruttamento dell'hardware? Vicerversa, con eccellenti tool di sviluppo si risparmia tempo e con quel tempo risparmiato si possono produrre più contenuti e migliorare l'engine.

Cell può essere utilizzato in 3 modi differenti per grafica "e chi più ne a ne metta"
1: Può accelerare in maniera spaventosa i calcoli delle geometrie e i calcoli volumetrici
2: può accelerare codice che normalmente grava troppo su GPU perchè bisogna compilare con troppa roba per ottimizzarla in modo tale che non si sprechi troppa potenza di calcolo per fare cose che cell farebbe a occhi chiusi
3: può tramite specifici kit essere integrato come processore o pipeline all'interno di RSX "detto semplicisticamente, molto semplicisticamente"

Aria fritta.
Il Cell è un processore con elevate capacità in calcolo FP: qualunque algoritmo usi FP verrà eseguito dalle SPU molto velocemente.
Ci sono molti modi di utilizzare le SPU, ma non sono infinite. Al momento ne sono disponibili "circa 6" su 7. (Una è riservata al DMR dell'Os, l'altra in parte all'audio e alle operazioni di streaming/compressione/decompressione dati).

Il discorso purtroppo e che fino ad oggi il metodo di sviluppo convenzionale su architetture Multicore era avere un compilatore e alcuni algoritmi che "SOLI" ottimizzavano il workflow "La distribuzione dei dati" tra i vari core... ed una logica di prefetch si occupava di "correggere" gli errori e il parallelismo...
questa cosa su Cell invece "deve essere gestita e preventivamente imposta dal developer" ecco la loro difficoltà,in verità non sanno fare il loro lavoro.. e Sony ha implementato Playstation EDGE per permettere "la simulazione di COME" il developer "DOVREBBE" programmare la distribuzione dei dati ai vari processori "SPE" all'interno di cell ed ovviamente altre cose come monitorare il residuo sfruttabile dell'architettura

Falso.
Ci sono 2 modi di utilizzare il Cell: modalità PPE-Centric, modalità SPE-Centric.
Nella prima modalità, il PPE del Cell viene utilizzato per coordinare e amministrare il lavoro delle SPE. Nella seconda modalità, il codice per ogni SPE viene scritto direttamente dallo sviluppatore permettendo di liberare il PPE dal compito di coordinare il tutto. La differenza tra le 2 modalità di lavoro è sopratutto nella tempistica e nel costo: sviluppare attualmente software SPE-Centric è improponibile. Su Beyond3D, DeanA del team dei Ninja Theory, ha parlato della programmazione SPE-Centric: per lui sarà utilizzata con la terza generazione di software di Ps3, presumibilmente nel 2009.
E' assolutamente sbagliato accusare gli sviluppatori di incapacità, poichè sono costretti a rimanere nel budget e nei tempi stabiliti.

Purtroppo se da un lato è vero che è possibile sviluppare con semplicità estrema nel modo convenzionale "cioè come in passato o cmq su processori non come Cell" dall'altro arrivano i limiti poichè non è possibile per un processore convenzionale l'utilizzo al 100% . Cell cambia questa cosa ma purtroppo si deve capire come utilizzarlo "più che altro si deve lavorarci e non lamentarsi" visto che la logica e la filosofia di programmazione e completamente e radicalmente cambiata... i tool e le piattaforme come Playstation EDGE daranno un incredibile boost alle performance e alle ottimizzazioni per la piattaforma PS3 .

Bullshit.
Questa frase non significa assolutamente nulla. Il Cell è un processore particolare, ma non ha senso parlare di utilizzo al 100% rispetto ad un processore convenzionale.

Cell ha la possibilita di rendersi componente integrata di RSX...


Io credo che Cell avrà il compito di "elaborare e accelerare" preventivamente i dati fornendoli ad RSX già pronti , cosi facendo RSX sgraverà il suo workflow di oltre il 40% il che vuol dire una potenza ineguagliabile perchè i calcoli che davvero inpegnano verranno già elaborati da cell

Lo scopo è permettere il rendering direttamente da XDR che alla velocità di carico / elaborazione / scarico di cell vuol dire avere sempre a disposizione questi 256 Mb in qualsiasi momento , senza contare le unità ACU in ogni SPE
che sono 512Kb con blocchi indipendenti di 128KB x 4 e canali bi-direzionali tra ogni SPE e da ogni SPE quindi ogni SPE puo "prelevare" i dati già elaborati e "ri-elaborarli" .. teoricamente bisognerebbe prendere come esempio una pipeline a 8 stadi indipendendi formata da veri e propri processori con DMA , Cache, Bus indipendenti e supporto Multithreading a 64bit... "detto sempre molto semplicemente"

La LS di ogni SPE è 256Kb, non 512KB. Quella è la dimensione della Cache L2 del PPE del Cell. Le SPE non hanno interfaccia DMA e non si possono chiamare processori. Anche un DSP lo sarebbe allora.
Per quanto riguarda la XDR, in realtà attualmente sono disponibili solo 192 Mb (64 occupati dal S.O e dal DMR).

i 256 Mb della GDDR3 verranno utilizzati come "semplice deposito ad elevata banda" poichè potrebbe essere necessario ricalcolare alcuni elementi della scena che magari non richedono un canale cosi veloce...

Ridicolo. Le texture e l'fb dove andrebbero? Sulla luna?

In definitiva cell non è un processore che ha una data funzione e quindi usi quella e basta Cell è davvero quello che si dice "programmare" un processore


se non sei capace Cell vale quanto un 486 fermo restando la sua straordinaria potenza ...
considera che un codice ottimizzato per cell permette oltre 4 miliardi di vertici...

Ma dai? E io che pensavo che i processori si potessero mangiare.

Veniamo ad un confronto diretto...

Quanto segue l'ho già ripreso e riscritto in altri forum dove era successa la stessa identica cosa cioè gli utenti "casual" non riuscivano a spiegarsi il XKè 360 fosse "apparentemente" migliore graficamente..

Metterò a confronto l'hardware PS3 con quello 360 soprattutto dal punto di vista architetturale e prestazionale... ci vorra esperienza per poter comprendere quanto segue quindi buona rilettura.

Preparo i pop-corn.

Il processore CELL:
Il processore "CELL" dispone di 1 unità centrale chiamata PPE "Power Processing Element" Questo singolo componente "core" puo calcolare da solo
12 valori in floating point per ciclo di clock ad una velocità di 3.2Ghz quindi
:12x3.2=38.4 Gflops al secondo

Il processore XENON "cpu centrale di 360" dispone di 3 elementi PPE "ANCHE Sè NON SONO IDENTICI" quindi il solo processore centrale di 360 è in grado di calcolare: 12x3x3.2=115.2 Gflops al secondo

Ora veniamo all'elemento che in CELL è più importante ed innovativo cioè parliamo degli SPE "Sinergistyc Processing Element"

Cell disponde di 8 di questi "SPE" 1 di questi è dedicato alla decodifica AUDIO ed 1 altro è "riservato a ridondanza e sistema operativo" ne rimangono quindi 6 per l'elaborazione. Ogni SPE è in grado di calcolare 8 valori in floating point per ciclo di clock quindi : 8x3.2=25.6
25.6 Gflops x 7 spe= 179.2 Gflops

Le SPE sono 7, una è disattivata via hardware per iniziali problemi di resa produttiva.

ora non dimentichiamo che abbiamo a disposizione anche la potenza di elaborazione del "PPE" che è pari a 38.4 gflops quindi ne ricaviamo un totale di : 217.6Gflops Ora sè è vero che questo calcolo viene fatto tenendo conto dell'utilizzo al 100% di questi elementi è anche vero che questo discorso è più fruibile su PS3 che su 360 quindi già qui siano in netto vantaggio a favore di PS3..

In netto vantaggio sui calcoli floating-point.

Passiamo ad RSX e XENOS le "Graphics processing Unit" delle 2 console rispettivamente Playstation3 ed Xbox 360 .

PS3 > Nvidia RSX:
Capace di un elaborazione pari a 1882 Gflops al secondo .....
contro i 742 Gflops di XENOS...

Come esempio prendiamo in considerazione il numero degli shader
che nel processore RSX sono pari a 56 , mentre nello XENOS sono 48

Molti non sanno che già in questo caso questi shader non possono essere confrontati, poiche' compiono operazioni differenti, sia nella tipologia che nella quantita' neanche le ROP possono essere paragonate perchè è vero che quelle dell'RSX sono piu' lente ma devono svolgere un lavoro molto meno pesante sè confrontate con la "pessima" architettura da volgare PC con qui è stata realizzata xbox360 ed il processore XENOS

Oddio rotolo!

RSX possiede 8 unità vertex unit ognuna capace di 10 flops/ciclo di clock e 24 Pixel Shader ognuno capace di 27 flops/ciclo di clock. Il Chip è cloccato a 500 Mhz. In totale può elaborare 364 Gigaflops: 6 volte meno della tua sparata. Xenos ha 192 unità Maad cloccate a 500 Mhz. Ogni Maad equivale a 2 flops, in totale quindi 192 Gigaflops. Anche qui, i tuoi numeri solo "leggermente" poco precisi...

Rsx:
24 pixel shader
8 vertex shader
128 bit di bus
22,4 Gb/s di banda passante "che poi non è nemmeno corretto dichiararlo cosi"
8 rops "invece che 16 nella versione NV50, più avanti verrà spiegato il xkè"
550 Mhz Core clock
256mb di GDDR3 a 700Mhz, possibilità di accesso ai 256 Mb del Cell, non so con che velocità la ram del CELL è a 3.2Ghz
Classe g70/71. Supporto totale alle Dx 9.0c/L e SM 3.0 , SM3.0+/4

Bullshit.
RSX è un G71 (o NV47) e supporta gli SM3 e le Dx 9.0c, non gli SM4.0.

L'RSX, deriva dall'NV50 castomizzato appositamente, dunque possiede 48 P-Shader raggruppati a coppie in 24 P-Pipeline. Possiede inoltre 8 VertexShader.
Il totale delle ALU e' di 96 (ogni shader e' fisicamente composto da due ALU, viste come una sola logica) e una mini-ALU per shader. Dunque sono 96(P-Shader)+8(Vshader)=104+48(mini-Alu).

Dispone di 8 ROP (rasterizzatori, ovvero, unita' che operano sull'immagine finita, gli applicano eventuali forme di post-processing, tipo AA ed in alcuni casi HDR e li "disegnano" a schermo), le quali non si occupano dell'HDR (nella PS3), che e' deputato alla P-Pipline. Avere piu' ROP con quella RAM video, non servirebbe a nulla, in quanto non possono lavorare con la XDR.

L'RSX puo' fare ogni tipo di operazione anche dalla XDR (volendo anche il rendering), questa porta altri 25,6GB/s (64bit*3,2Ghz/8bit=25,6GB/s), lavorare con questa memoria richiede piu' cicli, dunque e' probabile che nVidia/Sony, abbia inserito un maggior quantitativo di cache, (196KB, molte di più dell'NV50), proprio per compensare le latenze maggiori. Questo giustificherebbe anche il numero di transistor, che dovrebbe essere inferiore a quello dell'NV50, dato che non include le logiche dedite al pure-video ed 8 ROP (che sono integrate nel DIE).

WoW! Hai imparato a copiare i messaggi di MadCat!!! Incredibile!

I 48 Shader generici di XENOS sono appunto "unificati", il che significa che sono tutti uguali ed Il loro compito mutera' (ogni 4 clicli di clock), a seconda delle richieste, tra vertici e pixel.

Dunque XENOS dispone di 48 shader (anche in questo caso, 96 ALU, perche' fisicamente doppie), in luogo dei 56 dell'RSX (152ALU e mini).

Xenos ha 48 ALU, ognuna capace di 4 Maad. Ogni Alu è considerato uno Shader.

Ovviamente, il paragone, se pur numericamente ora corretto, resta COMPLETAMENTE inutile. Non e' il numero di Shader che fornisce la potenza d'elabolrazione, ma la capacita' specifica delle unita' di calcolo, che li rendera' migliori o peggiori a seconda del compito che gli sara' richiesto.

Ad esempio:

il caricamento di una texture, sull'RSX occupera' parte delle risorse dalla P-Pipeline, ma potra farne fino a 24 per ciclo,

nello XENOS, sono gratuite (gestite da uan logica indipendente), ma limitatamente al numero di 16 contro le 24 di RSX

Quanto alla banda di memoria tanto cantada dalla ATI per la loro EdRam, i 256GB/s, riguardano solo la comunicazione delle ROP con l'eDRAM, entrambi contenuti nel daughter DIE, che e' separato dal resto della VPU ed e' connesso ad essa tramite un canale molto piu' lento, ma pur sempre rapido (32GB/s) "dove RSX in questo caso copre oltre 35GB/s sia in entrata che contemporaneamente in uscita"


L'eDRAM implementata nello XENOS e' molto piccola, non puo' contenere un FrameBuffer medio (una 720p AA4X, occupa 28MB), dunque non puo' fare da memoria d'immagazzinamento, non potra' contenere il Vbuffer, né le texture o qualunque altro dato che non sia prettamente relativo al FrameBuffer stesso, questo errore fù fatto nella progettazione di Playstation2 "difatti avevano solo 4mb" solo che si parlava del 1999 solo che al tempo di PS2 proprio errore non lo era viste le risoluzione di quel tempo...

L'edram di 360 non è piccola per un errore di progettazione ma per scelta economica. L'edram costa moltissimo.

nel caso di 360 "XENOS" tutto i dati provengono dalla DDR, che deve soddisfare sia le richieste dello XENOS che dello XENON (questo e' solo uno dei maggiori limiti della console xbox360).

Falso. L'UMA non è un limite, è un uso diverso delle risorse. In certi casi permette di utilizzare al meglio le memoria disponibile.

Non disponendo di un'eDRAM abbastanza grande "cioe 10MB", lo XENOS ha bisogno di svuotarla in continuazione (cio'è trasferire nella memoria principale i dati) e riempirla piu' volte per ogni frame, dunque, dividerla in tessere, ma questo comporta un piccolo scotto da pagare, ovvero, tutti i poligoni compresi in piu' di una tessera, dovranno essere ricalcolati ad ogni frame, il che comporta un aggravio del peso delle geometrie sia per XENOS che per XENON, mediamente compreso tra il 20 e l'80% nel caso di sole 3 tessere (vi sono metodi alternativi, con il memexport ed il predicated tilling che pero', richiedono molte più risorse e quindi XENON avrà difficoltà xkè non eccelle per nulla in questo senso). Nel caso dell'accoppiata RSX / CELL questo non avviene assolutamente poichè il framebuffer puo anche essere di 512mb e non solo di 10mb... senza nessun aggravio , senza contare che CELL potrebbe decidere in alcune circostanze di programmazione di "chiedere ad RSX" ulteriore potenza di calcolo per renderizzare un immagine... General Purpose Graphics Processing Unit

Il PRT è proprio la possibilità di dividere il più parti l'Fb, e il suo peso sulle risorse è molto variabile, può essere lo 0% come il 20% ma finora non avevo mai letto nessuno che l'aveva quantificato. L'80% è un'altra delle tua bullshit vero?
Nel cso di RSX/Cell se il FrameBuffer fosse di 512 Mb, vedresti lo schermo nero
L'ultima frase non vuol dire un cacchio.

Esempio:
lo XENOS e' DX9+, gli SM sono praticamente dei 4.0, ma non e' DX10, manca totalmente di una tipologia di shader detta (Geometry) che RSX grazie al processore CELL puo generare tranquillamente prendendosene carico ... e quindi arrivare ad essere DX10..
Sorvolando sui numeri errati "di cui ormai in rete è pieno per screditare Sony che dovremmo ringraziare per aver prodotto tale hardware"

Rotolo!!! Sony Vittima!!

c'e' da aggiungere una cosa.

L'RSX non sara' utilizzato come una VPU da PC cioe come si fà su XENOS in 360, i giochi dedicati alla PS3, utilizzeranno molto meglio le risorse e le distribuiranno maggiormente. un esempio puo essere un AA che fa parte dell'engine, non richiedera' assolutamente tutta quella banda di memoria che richiede su 360 (ove e' una cosa aggiunta e forzata in un secondo momento), né pesera' cosi' tanto (calcolera' solo il necessario).

Un HDR fatto nella P-Pipeline di RSX, sara' molto piu' bello come risultato (32 bit, contro i soli 10 dello XENOS) e potra' gravare sui P-Shader, che sono decisamente il punto di forza di RSX e il punto più debole di XENOS

Un HDR fatto nella P-Pipeline utilizzando NAO32 consuma delle risorse, e attualmente non ci sono pannelli televisivi in grado di visualizzare più di 10 bit di totalità.

Dunque non e' corretto parlare di flessibilita' maggiore o minore, ma di utilizzi differenti dove RSX e stralargamente superiore a quel rottame di XENOS e dove cell è nettamente superiore a quel rottame di XENON

LOL!

[Marko91]

Originariamente inviato da Nerocielo

sempre a capire quello che vuoi capire.

intendo dire che dovrebbe (CONDIZIONALE!!) essere più facile in quanto hai più spazio e quindi non sei costretto a scegliere tra grafica o motion o altro, ma puoi mettere tutto quanto.

capito?

Non è esatto. In realtà per ora un dvd9 dovrebbe bastare per qualunque genere di utilizzo, al massimo se ne usano 2. Lo spazio del supporto è irrilevante, e non è in alcun modo correlato con la facilità /difficoltà nella programmazione.

[Cobalto]

Originariamente inviato da Nerocielo

sempre a capire quello che vuoi capire.

intendo dire che dovrebbe (CONDIZIONALE!!) essere più facile in quanto hai più spazio e quindi non sei costretto a scegliere tra grafica o motion o altro, ma puoi mettere tutto quanto.

capito?

Non funziona esattamente così, perché ogni scelta anche la minima comporta per una SH tempo e denaro, indipendentemente dal supporto.

La vedi troppo semplice, se fosse facile sviluppare un videogioco perché "si ha più spazio" a quest'ora ci sarebbero gli hd-dvd da 200gb invece dei dvd9, ma non è così, è molto più complicato di quello che può sembrare.

...O pensi che per ps3 impiegano ANNI in sviluppo perché non sanno programmare, pur avendo il bluray?

[Legolas84]

Il fatto di avere il Blu Ray ti permette semplicemente di avere più spazio nel supporto... puoi metterci più roba.... ma la cosa si ferma li....

[naoto84]

Originariamente inviato da Marko91

Un HDR fatto nella P-Pipeline utilizzando NAO32 consuma delle risorse, e attualmente non ci sono pannelli televisivi in grado di visualizzare più di 10 bit di totalità.

Ma i 32 bit dell'HDR non servono per avere una codifica lineare e in un ampio intervallo dei valori di luminanza... per poi finire comunque ad una immagine "visibile" tradizionale con profondità di colore per canale anche molto inferiore?

Voglio dire: il fatto che il mio display possa arrivare a 10 bit per canale rende inutile i 32 bit del formato HDR oppure no? Non dovrebbero essere così automatica la cosa... quei 32 bit e 10 bit non vengono usati per misurare la stessa cosa nella stessa maniera e la fase finale di tone mapping ha modi raffinati di mappare il range dell'immagine HDR a quello dell'immagine che va mostrata su schermo.

Che so, faccio un parallelo con la tradizionale elaborazione delle immagini: se prendo una immagine con 8 bit per canale e rimappo i livelli prendendo il valore di mezzo come livello basso a quel punto mi ritrovo una immagine quantizzata in modo più grossolano di quanto potrebbe rendere il monitor. Quindi un bit in più mi avrebbe fatto comodo all'inizio, se pure non immediatamente utile.

[nAo]

Originariamente inviato da Marko91

Aria fritta.
Il Cell è un processore con elevate capacità in calcolo FP: qualunque algoritmo usi FP verrà eseguito dalle SPU molto velocemente.

Magari! Purtroppo non e' cosi', non tutte gli algoritmi che necessitano di elevate capacita' di calcolo in virgola mobile mappano bene su CELL, un esempio pratico e' il texture mapping.

La LS di ogni SPE è 256Kb, non 512KB. Quella è la dimensione della Cache L2 del PPE del Cell. Le SPE non hanno interfaccia DMA e non si possono chiamare processori. Anche un DSP lo sarebbe allora.

Ancora con sta storia degli SPE che non sarebbero processori, basta per favore
E cmq documentarsi non farebbe male..OGNI SPE ha una interfaccia DMA che si chiama MFC (Memory Flow Controller), che e' in pratica un processorino presente su ogni SPE che si occupa di gestire il DMA mentre l'SPE fa altro.
Per ogni SPE puoi avere 16 transfer DMA in contemporanea senza stallare l'SPE perche' l'MFC si fa carico di gestire il tutto i maniera trasparente.

Per quanto riguarda la XDR, in realtà attualmente sono disponibili solo 192 Mb (64 occupati dal S.O e dal DMR).

DRM, non DMR, e cmq l'OS non occopua piu' 64 mega..

In netto vantaggio sui calcoli floating-point.

La gente se lo dimentica ma ogni SPE puo' lavorare su calcoli in FP o su calcoli interi, con lo stesso rate (se si escludono moltiplicazioni e divisioni),
quindi gli SPE sono anche potentissimi processori per il calcolo su numeri interi.

RSX possiede 8 unità vertex unit ognuna capace di 10 flops/ciclo di clock e 24 Pixel Shader ognuno capace di 27 flops/ciclo di clock. Il Chip è cloccato a 500 Mhz. In totale può elaborare 364 Gigaflops: 6 volte meno della tua sparata. Xenos ha 192 unità Maad cloccate a 500 Mhz. Ogni Maad equivale a 2 flops, in totale quindi 192 Gigaflops. Anche qui, i tuoi numeri solo "leggermente" poco precisi...

Tutti questi numeri non hanno molto senso perche' sono stati sommati uno con l'altro operazioni su tipi di dati differenti, con precisione differente, etc..
Lasciamo perdere i flops per favore come misura di performance, non avevano senso 10 anni fa, ne hanno pure meno ora.

Bullshit.
RSX è un G71 (o NV47) e supporta gli SM3 e le Dx 9.0c, non gli SM4.0.

RSX non e' G71.

Un HDR fatto nella P-Pipeline utilizzando NAO32 consuma delle risorse, e attualmente non ci sono pannelli televisivi in grado di visualizzare più di 10 bit di totalità.

Ci sono ci sono, ma sono ancora molto costosi (toccati con mano al siggraph dello scorso anno)

Marco

[nAo]

Originariamente inviato da naoto84

Voglio dire: il fatto che il mio display possa arrivare a 10 bit per canale rende inutile i 32 bit del formato HDR oppure no? Non dovrebbero essere così automatica la cosa... quei 32 bit e 10 bit non vengono usati per misurare la stessa cosa nella stessa maniera e la fase finale di tone mapping ha modi raffinati di mappare il range dell'immagine HDR a quello dell'immagine che va mostrata su schermo.

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

[me]

da felicissimo possessore di 360 e non di ps3,semplicemente perche' mi manca il denaro,credo che la 360 sia un ottima macchina e che ps3,col tempo,diventera' anch'essa un ottima piattaforma..semplicemente questo...e spero di poter giocare su play 3 quando avro' le finanze,gli stessi titoli che su 360 mi tengono compagnia..e' quello che penso,ci auguriamo tutti esseri ludici dotati di un minimo di cervello.

[Legolas84]

Originariamente inviato da nAo

Magari! Purtroppo non e' cosi', non tutte gli algoritmi che necessitano di elevate capacita' di calcolo in virgola mobile mappano bene su CELL, un esempio pratico e' il texture mapping.


Ancora con sta storia degli SPE che non sarebbero processori, basta per favore
E cmq documentarsi non farebbe male..OGNI SPE ha una interfaccia DMA che si chiama MFC (Memory Flow Controller), che e' in pratica un processorino presente su ogni SPE che si occupa di gestire il DMA mentre l'SPE fa altro.
Per ogni SPE puoi avere 16 transfer DMA in contemporanea senza stallare l'SPE perche' l'MFC si fa carico di gestire il tutto i maniera trasparente.




DRM, non DMR, e cmq l'OS non occopua piu' 64 mega..


La gente se lo dimentica ma ogni SPE puo' lavorare su calcoli in FP o su calcoli interi, con lo stesso rate (se si escludono moltiplicazioni e divisioni),
quindi gli SPE sono anche potentissimi processori per il calcolo su numeri interi.



Tutti questi numeri non hanno molto senso perche' sono stati sommati uno con l'altro operazioni su tipi di dati differenti, con precisione differente, etc..
Lasciamo perdere i flops per favore come misura di performance, non avevano senso 10 anni fa, ne hanno pure meno ora.

RSX non e' G71.

Ci sono ci sono, ma sono ancora molto costosi (toccati con mano al siggraph dello scorso anno)

Marco

chiaro e coinciso... soprattutto perchè sono fermamente convinto anche io che RSX non sia uguale a G71

[Max(IT)]

per me l' articolo si commenta da solo da questa frase:

Dunque non e' corretto parlare di flessibilita' maggiore o minore, ma di utilizzi differenti dove RSX e stralargamente superiore a quel rottame di XENOS e dove cell è nettamente superiore a quel rottame di XENON

mi sembra il delirio di qualcuno che ha cercato di imbastire un discorso sensato su basi a dir poco approssimative (pur condividendo una parte di quanto dice)

[Max(IT)]

Originariamente inviato da nAo

Ancora con sta storia degli SPE che non sarebbero processori, basta per favore

sono senza dubbio processori.
NON sono processori GP, e questo è un' altro discorso ...

La gente se lo dimentica ma ogni SPE puo' lavorare su calcoli in FP o su calcoli interi, con lo stesso rate (se si escludono moltiplicazioni e divisioni),
quindi gli SPE sono anche potentissimi processori per il calcolo su numeri interi.

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

Tutti questi numeri non hanno molto senso perche' sono stati sommati uno con l'altro operazioni su tipi di dati differenti, con precisione differente, etc..
Lasciamo perdere i flops per favore come misura di performance, non avevano senso 10 anni fa, ne hanno pure meno ora.

concordo in pieno.
La cosa che mi fa più ridere di quell' analisi è la somma dei flops, che dimostrano quanto poco ne sappia in materia la persona in questione.
Chiaramente un professionista come te sa bene quanto inutili siano certi paragoni.

RSX non e' G71.

questa è potenzialmente la cosa più interessante di questo thread.
Partendo dal presupposto che RSX non è identico a G71, senza dubbio deriva molto strettamente da G70.
Dici "RSX non è G71". In cosa differisce a parte numero di ROPS e bus ?

[PESCEDIMARZO]

Originariamente inviato da Nerocielo

che poi scusate, ma programmare giochi per ps3 non dovrebbe essere "più facile" rispetto ad altre console in quanto ps3 sfrutta i BR e quindi i programmatori hanno 50gb di spazio su cui lavorare?

Che arcidiavolo c'entra?E' come dire che un furgone tiene meglio la strada di un auto perchè ha il bagagliaio piu' capiente!