La CPU di PlayStation 3 impiegata seriamente con Folding@home

La CPU di PlayStation 3 impiegata seriamente con Folding@home

Folding@home è un programma medico realizzato dall'Università di Stanford per lo studio del folding delle proteine.

di pubblicata il , alle 16:01 nel canale Videogames
PlaystationSony
 
195 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
jappilas19 Marzo 2007, 19:08 #161
Originariamente inviato da: bonzuccio
Non era assolutamente mia intenzione flammare
ottimo
Originariamente inviato da: yossarian
mi pare che il tutto sia partito dall'affermazione che il cell può fare rendering (che non è sicuramente mia ).
Se ti interessa, ci sono anche discussioni sul cell (ben più di una), dove, oltre al mio, potrai trovare anche altri pareri:
e dove sei sempre stato preciso e tecnico - come finora , d' altra parte

sul resto del post però ho l' impressione che tu mi abbia tolto le parole di bocca - nel senso che avrei dovuto, eventualmente, assumermi io la responsabilità di tacciarlo di fanboyismo (ma per adesso non ne ravvisavo la necessità

ammetto che stavo preoccupando per questo thread
bonzuccio19 Marzo 2007, 19:12 #162
edit
yossarian19 Marzo 2007, 19:33 #163
Originariamente inviato da: bonzuccio
" Originally Posted by Butta View Post
It makes me wonder if ports will fare a little better given these tools. The 2D crowds in Fight Night 3 were really hurting! Well if Spurs turns out to be as good as it sounds, perhaps Joker454 can stop bitching about PS3 being vertex limited... I wonder what happened to that guy, it seemed as if he had just begun working on a PS3 title. Wonder what his opinion is now given these new tools?

Risposta di joker454

Au contraire! Remember, my original beef was not that the PS3 was vertex limited, it was that the RSX was vertex limited, which I still stand by 100% today. In fact, I think the article quoted in this thread basically proves it. If you want a real world example, one of my code systems here at work can render ~1.2 million verticies on the 360's gpu faster than the rsx can render the same system with reduced lod models at ~700k verticies. This is all gpu, no cpu help. Yes, the difference is that lopsided in our game, even after I managed to bring that particular system down to two vertex inputs and optimize the heck out of the vertex shader and geometry layout ;( I don't wanna go through that whole thread again like last time, but needless to say to me, rsx still sucks. Your mileage may vary.

I never had a beef with cell though. It has a learning curve, and you need to pretty much rewrite all that code you've been saving over the years, but I think its worth it long term. The new tools and libraries that Sony has been putting out are awesome! I'll wait and see what real world performance we can get before I jump up and down for joy though. We only get 5 spu's full time, and the 6th is "most of the time" since Sony can use it if they need to (the 7th is theirs full time), and I assume with Home and all this other cool stuff they have coming out that they will indeed make use of the 6th.

We're currently fully using 2 spu's, and will most likely use all six by the time we are done since our goal is to hit 60fps on both platforms no matter what. As for how many we'll have free to handle geometry culling, I don't know just yet. I've been having fun with them so far though. I've moved all skinning off the gpu side to cpu side, since we get our biggest gains here on the PS3 by babying the RSX, ie, giving it as little to do as possible to get around its inadequacies. I actually tried it on the 360 as well and it gave back some fps, so the vmx units on the 360 will be fully worked also.

Doing geometry culling on the spu's is something I will do for sure, but I will also try it to a certain extent on the 360 as well, just to see what happens."

è uno dei post contenuti in uno dei th linkati..
http://forum.beyond3d.com/showthread.php?t=39185&page=3


ovvero hai riportato un post che non fa che confermare quanto è stato finora detto. Nessuno ha negato (ti invito a rileggerti tutti i post precedenti) che il cell possa fare calcoli geometrici. Il cell non è in grado di fare rendering (che non è composto solo da calcoli geometrici).
Ora, nell'ipotesi che il cell aiuti rsx, gli scenari possibili sono:
situazione in cui si è vs bounded: cell+rsx uguagliano (grosso modo) xenos
situazioni in cui colli di bottiglia sono altrove, rsx deve cavarsela da solo (e un chip a shader non unificati è molto meno efficiente di uno a shader unificati, anche su console e anche con codice ottimizzato; ne sa qualcosda NV che ha abbandonato l'architettura tradizionale di G7x, nonostante Kirk avesse più volte affermato, a ragione, che si poteva anche realizzare un chip sm4.0 senza l'unificazione fisica degli shader). In questo caso cell+rsx < xenos
Qualche parola sulle operazioni di texturing; rsx ha 24 tmu e xenos 16; però le tmu di rsx e una delle alu non sono indipendenti (quelle di xenos si). Questo significa che, nell'ipotesi di codice di tipo 1tex, 1 mad, 1 mad, se lavora a fp32, ogni pipeline di rsx perde qualcosa come 17 flops su 27 teoriche.

Infine, avere un'unità di vs etserna (come può essere un spe), non è la stessa cosa che averla interna, a livello di cicli persi per l'accesso ai dati (non è un caso che si tenda a integrare più core nello stesso die e all'interno di ogni core si aumenti il quantitativo di cache e registri; in quest'ottica, un grosso vantaggio è costituito dai 10 MB di eDRAM integrata nel die secondario di xenos: il suo vero limite è che ce ne sarebbe voluta di più ).
yossarian19 Marzo 2007, 19:33 #164
Originariamente inviato da: jappilas
ottimo
e dove sei sempre stato preciso e tecnico - come finora , d' altra parte

sul resto del post però ho l' impressione che tu mi abbia tolto le parole di bocca - nel senso che avrei dovuto, eventualmente, assumermi io la responsabilità di tacciarlo di fanboyismo (ma per adesso non ne ravvisavo la necessità

ammetto che stavo preoccupando per questo thread


tranquillo, al massimo evitavo di fare altri post
BTinside19 Marzo 2007, 21:43 #165
Originariamente inviato da: yossarian
(ti dice niente NV3x e Doom3?)

Io ricordo che l'unico modo per far andare veloce quei chip che di Pixel Sahder 2.0 avevano ben poco era quello di sfruttarne, oltre le open gl, l'unico punto forte, ovvero le stencil shadows (grazie all' ultrashadow anche). Inoltre, se non sbaglio, si scoprì anche che il gioco conteneva delle castrature per i chip Ati R3XX tanto che usci poi una patch (o forse c'era qualcosa da variare nel file di configurazione) in grado di eliminarle. Non ricordo in cosa consistesse questa "castratura", ma sdisattivava delle ottimizzazioni del R300.
Confermi?

Al tempo mi desti parecchie dritte...
BTinside19 Marzo 2007, 23:08 #166
Originariamente inviato da: ^TiGeRShArK^
Lo so
Partecipò lungamente anke lui alla discussione di diverso tempo fa sul Cell, insieme a me, Yossarian, Cdimauro, Fek (programmatore della LionHead) e tanti altri che non ti sto a nominare che non finiamo +

me la linkeresti?
yossarian19 Marzo 2007, 23:25 #167
Originariamente inviato da: BTinside
me la linkeresti?


http://www.hwupgrade.it/forum/showthread.php?t=1102887

questo è uno: tieniti forte perchè è lunghissimo

p.s. ho letto il pvt (appena ho un attimo di tempo ti rispondo (anche perchè è poco più breve dei primi tre capitoli dei promessi sposi
yossarian19 Marzo 2007, 23:31 #168
Originariamente inviato da: BTinside
Io ricordo che l'unico modo per far andare veloce quei chip che di Pixel Sahder 2.0 avevano ben poco era quello di sfruttarne, oltre le open gl, l'unico punto forte, ovvero le stencil shadows (grazie all' ultrashadow anche). Inoltre, se non sbaglio, si scoprì anche che il gioco conteneva delle castrature per i chip Ati R3XX tanto che usci poi una patch (o forse c'era qualcosa da variare nel file di configurazione) in grado di eliminarle. Non ricordo in cosa consistesse questa "castratura", ma sdisattivava delle ottimizzazioni del R300.
Confermi?

Al tempo mi desti parecchie dritte...


esatto: stencil shadow, prima passata solo con z-ops (con NV3x che raddoppiava l'output a livello di rop's, un misto di fixed function, shader 1.1 e 1.4 e molte dependent texture read (operazione in cui NV3x andava piuttosto bene e R3x0 aveva come limite quello di 4 istruzioni consecutive (la patch corresse proprio questo inconveniente, sostituiendo alcune operazioni di texturing in operazioni di pixel shading, oltre a riordinare parzialmente le istruzioni per rendere il codice più digeribile all'architettura ATi.
BTinside19 Marzo 2007, 23:42 #169
Originariamente inviato da: yossarian
http://www.hwupgrade.it/forum/showthread.php?t=1102887

questo è uno: tieniti forte perchè è lunghissimo

p.s. ho letto il pvt (appena ho un attimo di tempo ti rispondo (anche perchè è poco più breve dei primi tre capitoli dei promessi sposi


Ok, grazie.
BTinside19 Marzo 2007, 23:45 #170
Originariamente inviato da: yossarian
esatto: stencil shadow, prima passata solo con z-ops (con NV3x che raddoppiava l'output a livello di rop's, un misto di fixed function, shader 1.1 e 1.4 e molte dependent texture read (operazione in cui NV3x andava piuttosto bene e R3x0 aveva come limite quello di 4 istruzioni consecutive (la patch corresse proprio questo inconveniente, sostituiendo alcune operazioni di texturing in operazioni di pixel shading, oltre a riordinare parzialmente le istruzioni per rendere il codice più digeribile all'architettura ATi.


Davvero interessante...

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^