[Official Thread] Xbox360 e Ps3: Hardware

[BTinside]

Originariamente inviato da bonzuccio

Alla fine arriverai anche tu ALLA DOMANDA

Se ti riferisci alla domanda a yoss l'ho appena fatta

[Window Vista]

Ma perchè invece di utilizzare bump a manetta, non facessero le macchine a mano e colorate a mano con palette diverse, invece di tutto quel plastico???

[Yngwie74]

Originariamente inviato da BTinside

Eh ragazzi, se parla yoss, ne vale la pena leggere i suoi post come oro colato, è molto preparato (oltre ad essere abbastanza grande) ed è totalmente imparziale.

Yoss non si discute. Sono contento ogni volta che lo vedo postare.

[bonzuccio]

Si ho capito ma a me mi ha fatto un po incaxxare

[Yngwie74]

Originariamente inviato da bonzuccio

Si ho capito ma a me mi ha fatto un po incaxxare

Non te la prendere bonzuccio, pero' non ti puoi mettere a discutere con uno che ne sa millemila volte piu' di te in cio' che e' il suo pane quotidiano.

E come se io da inge che sono mi mettessi a discutere con un cardiochirurgo su come si fa un'operazione al cuore.

[bonzuccio]

Originariamente inviato da Yngwie74

Non te la prendere bonzuccio, pero' non ti puoi mettere a discutere con uno che ne sa millemila volte piu' di te in cio' che e' il suo pane quotidiano.

E come se io da inge che sono mi mettessi a discutere con un cardiochirurgo su come si fa un'operazione al cuore.

Ho capito ho capito ma non mi ha convinto cacchio.. mi ha lasciato con l'amarognolo in bocca e con nessuna convinzione e adesso devo rompermi la testa coi th in inglese.. maporc

[R@nda]

Originariamente inviato da bonzuccio

Ho capito ho capito ma non mi ha convinto cacchio.. mi ha lasciato con l'amarognolo in bocca e con nessuna convinzione e adesso devo rompermi la testa coi th in inglese.. maporc

Le risposte Yoss te le ha date tutte.
Per il resto ti consiglio di leggerteli si i thread su By3d, perchè lì posta gente che sulle architetture ci sta sviluppando.
Non riesco a capire cosa non ti convince....

[bonzuccio]

Non mi convince perchè dica che cell non può fare calcoli poligonali al posto di rsx quando su beyond lo stanno facendo usando le spe per i poligoni e la vga per il resto

[R@nda]

Originariamente inviato da bonzuccio

Non mi convince perchè dica che cell non può fare calcoli poligonali al posto di rsx quando su beyond lo stanno facendo usando le spe per i poligoni e la vga per il resto

No lui ti ha detto che non può renderizzare...o meglio, che non ha senso perchè non è un architettura specilazzata come lo è una Gpu.
Ed è la stessa cosa che stanno dicendo anche su By3d.

[BTinside]

O meglio ancora, contestava il fatto che si insinuasse che Il Cell fosse in grado di svolgere i compiti di una gpu e sostituirla. E' daccordo sul fatto che possa gestire piligoni, ma non può di certo sostituire una gpu.

[bonzuccio]

Allora devo leggermi un po di forum..
mi stavo studiando queste slide
http://www.gfdata.de/archiv03-2007-gamefront/2881.html

[R@nda]

Originariamente inviato da BTinside

O meglio ancora, contestava il fatto che si insinuasse che Il Cell fosse in grado di svolgere i compiti di una gpu e sostituirla. E' daccordo sul fatto che possa gestire piligoni, ma non può di certo sostituire una gpu.

Sennò Sony non spendeva soldi per un RSX....visto quello che gli costa la PS3 non ci avrebbero pensato due volte.

[bonzuccio]

E' chiaro, giustamente il calcolo di poligoni non è rendering
ma insomma non è rendering ma su quello che non è poligoni rsx se la cava molto bene e con edge si aprono nuovi scenari

[Yngwie74]

Imho Yoss ha fatto un riassunto della situazione in questo passo:

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ù ).

[Crashman]

Originariamente inviato da bonzuccio

Non ho capito..
da profano se questa è la situazione


RSX
- 550 MHz
- 8 unità di vertex
- 24 pixel pipelines
- 24 unità di texture
- 48 pixel ALU (che fanno pure texturing) + 48mini ALU (che si caricano delle texture facendo piccoli calcoli specializzati per le pixel alu)

Xenos
- 500 MHz
- 48 pixel ALU's (che fanno anche lavoro di vertex)
- 16 unità di texture separate

se il collo di bottglia sono i vertex rsx per il resto mi pare leggermente meglio..
se le coordinate di alcuni frammenti possono essere dati in pasto a rsx da cell e poi rsx li "riempie" sarebbe meglio no?

Stavo per rispondere, ma ho visto che il quote di yoss è già abbastanza esaustivo.
Il fatto è che le 24 texture unit dell' RSX non sono indipendenti, ciò vuol dire che usarle vuol dire occupare una pixel pipe. Nello xenos invece tutte le alu sono sempre disponibili, visto che le texture unit sono completamente indipendenti. In oltre si tratta le unità di shading sono generiche quindi è più semplice occuparle sempre al 100% (o quasi). L'edram aiuta nell'applicazione di filtri o in operazioni come l'alpha blending.
Nel comparto video, personalmente vedo la GPU di ati in vntaggio su tutti, ma proprio tutti i fronti

[Max(IT)]

Originariamente inviato da ripsk

Xeon, il confronto era con un p4 non con la x360

scusami, lapsus freudiano

Certo che è anacronistica, mi riferivo al passato , dei cisc è rimasta traccia solo per la retrocompatibilità in poche famiglie di processori come gli x86, qualunque nuova architettura nasce come risc (processori della ibm, renesas, texas, freescale, stm, fujitsu, atmel, infineon, microchip ecc... )

il set di istruzioni delle moderne cpu, ad esempio, hanno ben poco di RISC, anche se RISC è l' approccio dell' architettura. Come ho detto la definizione CISC/RISC è del tutto anacronistica ormai.

[Max(IT)]

Originariamente inviato da Marko91

Perchè sono compiti che il Cell può svolgere in maniera facile e veloce, aiutando la GPU. Se ho una scena molto complessa (4+ milioni di poligoni) e i VS di RSX non riescono a gestirla, il Cell può renderizzare i poligoni che mi servono. Il suo compito non si ferma solo qui: può eseguire culling, cioè alleggerire la scena per RSX, si possono usare le SPE come geometry shader, fare tessellation e molte altre funzioni che peserebbero sulla GPU.

se il Cell si mette a "fare la gpu" non può fare la cpu. L' implementazione dell' RSX nella PS3 è la dimostrazione che neppure SOny pensa che il Cell possa sostituirsi alla gpu. Che poi le sue caratteristiche gli permettano di coadiuvare la gpu in una serie di compiti è indubbio, ma quello che contesto è proprio questo: meglio a questo punto una cpu più "semplice" (come approccio alla programmazione) affiancato da una gpu più sofisticata, piuttosto che ricorrere ad una cpu così complessa e trovarsi ad affiancarla con una gpu che sembra "aggiunta postuma".
Magari i risulatti finali sono equivalenti, ma lo sforzo richiesto per sfruttare il tutto mi sembra eccessivo.

Su wikipedia non è scritto, ma ci sono due modi di usare il Cell:
-modalità PPE-Centric
-modalità SPE-Centric
Nella prima, che è quella che si sta usando attualmente, il codice viene passato alla PPE che gestisce le varie SPE ed è quindi quasi sempre occupata.
Nella seconda, ogni SPE ha un suo codice differente e la PPE è quasi totalmente libera.
Lo svantaggio della seconda modalità sta nel tempo necessario a scrivere codice per ogni specifica SPE. Su Beyond3D, DeanC (che è uno sviluppatore dei Ninja Theory) ha detto che secondo lui questo tipo di utilizzo del Cell si avrà nella terza generazione di titoli next-gen. Quindi a novembre 2008 circa.

la mia cultura sul Cell non è "wikipedia based"
C' è altro materiale, molto by IBM, ben più completo.
Le SPE non hanno accesso diretto alla ram, da quanto mi risulta, se non via DMA (il che richiede una programmazione diversa ed assai meno "diretta"). Inoltre è limitato anche il quantitativo di ram contigua a cui possono accedere.
Il tutto senza contare l' assoluta impossibilità di eseguire codice out of order.
Utilizzare con piena efficienza le SPE secondo me sarà davvero difficile (sempre che sia effettivamente fattibile in un gioco). Seguo con interesse i thread su B3D, ma leggo le dichiarazioni entusiastiche di "certi sviluppatori" con un briciolo di scetticismo
Sono intimamente convinto che il Cell non sia la "cpu definitiva" per l' impiego videoludico, anche se chiaramente posso essere smentito dai fatti.

Originariamente inviato da Murakami

Mah, questa idea mi convince poco: le SPE dovrebbero essere usate per fare altro, non renderizzare poligoni (compito per il quale i VS sono più efficienti).

questa è anche la mia idea.
Chiaro che poi gli sviluppatori cerchino di sfruttare al massimo l' hw che hanno a disposizione, specialmente se la console non permette un approccio "user friendly".

Originariamente inviato da R@nda

Sennò Sony non spendeva soldi per un RSX....visto quello che gli costa la PS3 non ci avrebbero pensato due volte.

le voci, anche abbastanza attendibili, dicono che effettivamente ci hanno pensato inizialmente, poi hanno deciso che non sarebbe bastato.