[3D tecnico]XBOX360 HW Vs PS3 HW

[Free Gordon]

Originariamente inviato da yossarian

appena ho un po' di tempo mi guardo in dettaglio le specifiche dell'x-chip; al momento non saprei cosa risponderti.
Se fossero relazionati tra loro, ci sarebbe dipendenza nell'elaborazione, in qiualche modo analoga a quella vista per il cell. Però per valutarne le implicazioni ho bisogno di un po' di tempo.

Non volevo pressarti sapevo che la cpu aveva un crossbar a 3 queue. Se così fosse sarebbero indipendenti no?

[Do85]

allora 24 o 48 pipeline per la 360???
se può essere interessante: http://forum.gamesradar.it/showthread.php?t=262328 (nn dico utile)

[PeK]

Originariamente inviato da Do85

allora 24 o 48 pipeline per la 360???
se può essere interessante: http://forum.gamesradar.it/showthread.php?t=262328 (nn dico utile)

bisogna registrarsi :\

non potresti copia/incollare le cose più interessanti? grazie

[yossarian]

Originariamente inviato da Free Gordon

Non volevo pressarti sapevo che la cpu aveva un crossbar a 3 queue. Se così fosse sarebbero indipendenti no?

dallo schema che ho potuto vedere, sembrerebbe che le 3 cpu siano indipendenti tra loro e ci sia solo la possibilità di uno scambio di dati attraverso il crossbar e la cache L2, in comune. Invece, pare sia possibile subordinare il lavoro delle cpu a quello della GPU che, in determinate situazioni, potrebbe fungere da master

[yossarian]

Originariamente inviato da Do85

allora 24 o 48 pipeline per la 360???
se può essere interessante: http://forum.gamesradar.it/showthread.php?t=262328 (nn dico utile)

48, ma non sono pipeline ma unità di calcolo del tipo full vect fp128 con in serie unità scalari fp32. Il che equivale a dire 96 unità complessive, accoppiate a due a due (una vettoriale con una scalare) e raggruppate in 3 blocchi da 16+16 ciascuno.
Inoltre ci sono 16 tmu per le operazioni di filtering e 16 in grado di eseguire solo point sampling e 16 vertex fetch

[ArtX]

scusa yossarian
potresti spiegarmi cosa sono esattamente le pipeline ,per me sono le unita di calcolo della gpu ma tu qui hai scritto

>>48, ma non sono pipeline ma unità di calcolo del tipo full vect fp128 con in serie unità scalari fp32. Il che equivale a dire 96 unità complessive, accoppiate a due a due (una vettoriale con una scalare) e raggruppate in 3 blocchi da 16+16 ciascuno.
Inoltre ci sono 16 tmu per le operazioni di filtering e 16 in grado di eseguire solo point sampling e 16 vertex fetch

io sono solo un neoappasionato di queste cose.

un'altra cosa, quante pipeline infine hanno rsx e r500 visto che qua non ci capisco più niente
e la gpu del revolution sarà uguale a quella del xbox2 solo con più mhz o caso? (anche se non centra niente con queste console)

[yossarian]

Originariamente inviato da ArtX

scusa yossarian
potresti spiegarmi cosa sono esattamente le pipeline ,per me sono le unita di calcolo della gpu ma tu qui hai scritto

>>48, ma non sono pipeline ma unità di calcolo del tipo full vect fp128 con in serie unità scalari fp32. Il che equivale a dire 96 unità complessive, accoppiate a due a due (una vettoriale con una scalare) e raggruppate in 3 blocchi da 16+16 ciascuno.
Inoltre ci sono 16 tmu per le operazioni di filtering e 16 in grado di eseguire solo point sampling e 16 vertex fetch

io sono solo un neoappasionato di queste cose.

un'altra cosa, quante pipeline infine hanno rsx e r500 visto che qua non ci capisco più niente
e la gpu del revolution sarà uguale a quella del xbox2 solo con più mhz o caso? (anche se non centra niente con queste console)

le pipeline sono semplicemente una sorta di catena di montaggio. Un dati in ingresso richiede un certo numero e una determinata tipologia di elaborazioni. Per fare questo si ricorre ad architetture che utilizzino unità di calcolo in serie o, in alcuni passaggi, strutturate come serie-parallelo-serie, in modo tale che ogni unità, dopo aver svolto il suo lavoro, passi il dato all'unità successiva. Quindi, una pipeline è, in realtà, una catena di unità di calcolo e non una singola unità. Nelle cpu e nelle gpu più recenti, poichè le elaborazioni sono diventate sempre più complesse, si è pensato di frazionare gli stadi che richiedevano tempi di elaborazione più lunghi, in tante sottounità, ognuna delle quali svolge parte del compito e affida l'elaborazione a quella successiva. In questo modo è possibile eseguire contemporaneamente più elaborazioni e di aumentare la frequenza di funzionamento (la velocità di elaborazione dell'intera pipeline è imposta dal suo stadio più lento; l'idea è quella di frazionare quest'ultimo in tanti stadi, ognuno dei quali svolga solo parte del compito e abbia tempi complessivi d'elaborazione di molto inferiori). Ad esempio, all'interno della pipeline di G70 possono circolare fino a una quindicina di pixel di cui fino a 8 elaborati contemporaneamente, con i dati di altri 56 immagazzinati all'interno dei registri di sola lettura, in attesa di entrare nelle pipeline.
Un chip come R5x0 o R500 si basa su un principio differente; ad esempio, su R520 è possibile caricare dati per oltre 16 mila dati da elaborare; però, complessivamente, ogni gruppo di unità di calcolo elabora solo 4 pixel per volta, per un totale di 16 (R520 ha 4 gruppi di 4 unità ciascuno), contro i 192 di G70 (8 per 24 pipeline). Però, a differenza di G70, le singole elaborazioni richiedono molto meno tempo perchè ogni unità compie poche operazioni piuttosto semplici e con tempi di esecuzione estremamente ridotti.
Su un principio analogo si basano lo SPE del Cell, che sono unità di calcolo vettoriali, con pochi stadi e in grado di compiere poche operazioni per ciclo ma molto velocemente. Quindi la differenza tra un'architettura pipelined e una non pipelined sta nel numero di operazioni per ciclo (molte in quella pipeline d poche nell'altra) e nella velocità con cui i dati escono dalle strutture preposte all'elaborazione (bassa velocità per le architetture pipelined, perchè ogni songolo dato deve attraversare molti stadi di calcolo e, spesso, si trova a dover attendere che l'elaborazione precedente sia terminata, alta velocità nelle altre).
R500 si basa sullo stesso principio di R520, con in aggiunta il fatto che le unità di calcolo sono in grado di eseguire sia calcoli geometrici che calcoli sui pixel (mentre in R520 e in G70 le due tipologie sono separate).

RSX ha un'architettura, almeno stando alle specifiche fornite, tipo quella di G70, ovvero con le classiche pipeline e, per l'esattezza, dovrebbe avere 8 vertex pipeline, 24 pixel pipeline e 16 rop's (che sono la parte terminale della pipeline di un chip grafico, quella che si occupa di "scrivere" i pixel, la cui elaborazione è stata completata, nel frame buffer. R500, invece, non un'architettura a pipeline, ma ha delle unità di calcolo disposte a matrice. Ognuna è in grado di compiere operazioni relative sia alle vertex che alle pixel pipeline. Le unità di calcolo di R500 sono in tutto 48, ognuna formata da un'unità vettoriale a 4 componenti e da una scalare in parallelo. Il blocco delle tmu, che in una architettura tradizionale è all'interno delle pixel pipeline, è posto al di fuori, anche questo con una struttura a matrice, il cui lavoro può essere coordinato in base alle esigenze della specifica elaborazione.

La gpu del Revolution dovrebbe essere della famiglia di R5x0, quindi dovrebbe derivare da R520 o, per essere più precisi, da R580 (non dovrebbe avere shader unificati come R500).

[Fiero]

A questo punto se le specifiche di RSX dovessero essere confermate sembra proprio debba essere parecchio inferiore a R500.
Praticamente hanno preso una 7800 e l'hanno pompata in frequenza...
Mentre in ATi hanno certamente fatto un progetto ben più complesso. Che (sempre sulla carta) sembra parecchio più efficiente.
E' plausibile pensare che Nvidia non abbia avuto sufficiente tempo per sviluppare qualcosa di specifico?
A questo punto è possibile pensare ad un 'adeguamento' dell'ultim'ora sull'architettura di RSX? O ormai è troppo tardi? O forse RSX ha ancora qualche asso nella manica da buttare sul tavolo?
Oppure ancora (io penso sia così) ormai la GPU è tratta e c'è poco da fare a questo punto?
Boh, basta attendere qualche news 'definitiva' su RSX...

ps. Ma 'sto topic sul Cell lo apriamo o no che tra un po' comincio gli esami e non posso passare i pomeriggi sul forum!

[Ren]

yoss cosa ne pensi della xcpu(xenos) ?

[yossarian]

Originariamente inviato da Ren

yoss cosa ne pensi della xcpu(xenos) ?

più informazioni prendo e più mi sembra non troppo dissimile dal cell (a parte il fatto che xenos è il chip grafico e xenon la cpu ).

Ognuno dei tre core ha, per buona parte, la stessa architettura del PPE con, in aggiunta, alcune pipeline dedicate a calcoli vettoriali simili alle SPE (con cui hanno in comune anche il numero di registri interni: 128). Hanno identiche unità di branching e implementano set di istruzioni VMX (con cui la PPE gestisce anche le SPE).
Quello che cambia è l'approccio: da un lato si ha una processore che gestisce, oltre alle sue pipeline interne, altre 8 unità di calcolo collegate ad esso tramite bus e tra loro in maniera tale che ognuna ha accesso diretto ai dati contenuti nei registri della precedente; dall'altro 3 processori che gestiscono, ognuno, qualcosa di simile a 2 SPE del cell, poste all'interno del core della cpu stessa. Il primo è l'esaltazione del calcolo parallelo, il secondo è un approccio intermedio tra architetture con parallelismo spinto e architetture di tipo pipelined (una PPE ha "solo"23 stadi contro i 40 di ciascun core dello xenon). Il Cell ha una maggior potenza complessiva e dovrebbe essere avvantaggiato nel funzionamento come steam processor (anche se il divario di potenza tra i due chip va notevolmente ridimensionato rispetto ai dati teorici forniti qualche tempo fa), lo Xenon è più flessibile e un po' meno complesso da programmare e si dovrebbe comportare meglio con i calcoli general pourpose, ma anche in questo caso, il vantaggio non è abissale.
Potrebbe essere interessante la possibilità di utilizzare R500 come master e lo Xenon come slave che potrebbe dare dei vantaggi non soltanto in termini di calcolo dei vertici da parte della cpu, come si è ipotizzato, ma anche in altri tipi di calcolo (in tal caso, la gestione di una scena sarebbe affidata ad un chip OoO con un chip IO a fare da coadiutore).

[Ren]

Nella porzione di cache dedicata alla gpu si ha una compressione dati d3d di 2x, questo mi fa pensare che la cpu possa gestire istruzioni direct3d nativamente...

tu che ne pensi ?

[OvErClOck82]

Originariamente inviato da Fiero

A questo punto se le specifiche di RSX dovessero essere confermate sembra proprio debba essere parecchio inferiore a R500.
Praticamente hanno preso una 7800 e l'hanno pompata in frequenza...
Mentre in ATi hanno certamente fatto un progetto ben più complesso. Che (sempre sulla carta) sembra parecchio più efficiente.
E' plausibile pensare che Nvidia non abbia avuto sufficiente tempo per sviluppare qualcosa di specifico?
A questo punto è possibile pensare ad un 'adeguamento' dell'ultim'ora sull'architettura di RSX? O ormai è troppo tardi? O forse RSX ha ancora qualche asso nella manica da buttare sul tavolo?
Oppure ancora (io penso sia così) ormai la GPU è tratta e c'è poco da fare a questo punto?
Boh, basta attendere qualche news 'definitiva' su RSX...

ps. Ma 'sto topic sul Cell lo apriamo o no che tra un po' comincio gli esami e non posso passare i pomeriggi sul forum!

per l' RSX io avevo sentito da varie interviste che si mangiava senza problemi due 6800ultra in sli, cosa che la 7800 nn fa, quindi, ammesso che sia vero; sono fiducioso

[yossarian]

Originariamente inviato da Ren

Nella porzione di cache dedicata alla gpu si ha una compressione dati d3d di 2x, questo mi fa pensare che la cpu possa gestire istruzioni direct3d nativamente...

tu che ne pensi ?

mi meraviglierei se non fosse così

[Coyote74]

Originariamente inviato da OvErClOck82

per l' RSX io avevo sentito da varie interviste che si mangiava senza problemi due 6800ultra in sli, cosa che la 7800 nn fa, quindi, ammesso che sia vero; sono fiducioso

Già si sapeva che l'RSX sarà più performante delle 7800, in quanto sfrutta la stessa tecnologia, ma ha una frequenza di lavoro molto superiore. Resta il fatto che da quello che ci è dato sapere l'R500 sembra migliore.

[Ren]

mi meraviglierei se non fosse così

Ma è una caratteristica speciale dello xenon o no ?
Il cell può gestire istruzioni opengl o direct3d ?

Per la gestione di istruzioni direttamente in D3d si è dovuto ricorrere ad un design speciale delle unità vettoriali ?

[yossarian]

Originariamente inviato da OvErClOck82

per l' RSX io avevo sentito da varie interviste che si mangiava senza problemi due 6800ultra in sli, cosa che la 7800 nn fa, quindi, ammesso che sia vero; sono fiducioso

è probabile che alcune affermazioni siano state ampiamente travisate.
Le istruzioni per clock, relative ai ps, in G70 sono 120 e in NV40 64; quelle relative ai vs sono 16 per G70, 12 per NV40; il numero massimo di operazioni sono 240 (648 flops) per i ps e 40 (80 flops) per i vs di G70, contro le 128 (304 flops) per i ps e 30 (60 flops) per i vs di NV40. Se porti la frequenza di G70 a 550Mhz hai una gpu che, in teoria, è più veloce di 2 6800 ultra.
E guarda caso, i numeri relativi alle istruzioni di RSX sono proprio 136 (120+16), esattamente come G70

[yossarian]

Originariamente inviato da Ren

Ma è una caratteristica speciale dello xenon o no ?
Il cell può gestire istruzioni opengl o direct3d ?

Per la gestione di istruzioni direttamente in D3d si è dovuto ricorrere ad un design speciale delle unità vettoriali ?

la PPE del Cell può gestire operazioni D3D e OpenGL. Le SPE hanno un set di operazioni altivec (esattamente come la unità vettoriali interne ai tre core dell'x-chip)

[fek]

Originariamente inviato da Ren

Ma è una caratteristica speciale dello xenon o no ?
Il cell può gestire istruzioni opengl o direct3d ?

Per la gestione di istruzioni direttamente in D3d si è dovuto ricorrere ad un design speciale delle unità vettoriali ?

Credo che si riferisca alla compressione DXTx che e' supportata da qualunque GPU da molti anni a questa parte.

D3D non e' un set di istruzioni, ma una API per pilotare le GPU. L'X360 usera' una versione customizzata di D3D per supportare le caratteristiche peculiari dell'R500..

[Ren]

cioè i dati elaborati verrano compressi nella porzione di cache e poi letti e decompressi dalla gpu ?

[Ren]

So said Jeff, an IBM chip developer, but as you know, the project is in conjunction with Microsoft. Add in a lot of work from Chartered, the company fabbing it. Microsoft definitely had input at all stages.

The chip itself is a three way SMP PPC with specialised function VMX extensions and two threads per core. It has 1MB of L2 cache, a FSB of 21.6GB/s. It has 165M transistors, and is built on IBM's 10KE 90nm SOI process.

The L1 Icache is 32K 2 way set associative, and has a 128 byte cache line size. It can issue 2 instructions per clock, in order, but can do delayed execution to cover load to use delays. The chip, still somewhat unnamed, has 2 fixed point units, and has a 2 cycle op latency. The Dcache is also 32K but is 4 way set associative, and is non-blocking. The FPU is combined with the VMX unit and can also handle two threads.

The full pipeline is 11 FO4 in length, and has a 10 cycle Scalar DP FPU latency, 2 cycle load latency, 4 cycles for simple VMX and 14 for dot product VMX. This is important because of the target for the chip, gaming. The VMX extensions are going to be heavily used here, and part of the MS mods were upping the number of VMX registers from 32 to 128. It also adds Direct3D pack and unpack instructions.

The 1MB L2 cache is shared by all three cores, and is 8-way set associtive. It is ECC protected, and supports the MESI coherency protocol. The FSB beyond that is specific to the Xbox360, and was designed for the machine itself. It connects to the ATI GPU at 10.8GBps in each direction, hence the 21.6GBps noted earlier. Interestingly, the IBM chip runs it's link layer at 1.35GHz with an 8 bit width, and ATI does it at 675MHz at 16 bits of width.

Despite the complexity of this chip, the first silicon was fully functional and running a test game a week after they got first power on. IBM and MS had an extensive testing program and it paid off. The chip was delivered on time and hit the quality targets. It is now in volume production, and you should be able to buy one in less than a month. They won't sell them to you without a console to wrap it in, but if they did, it would look like this.

Some last few tech rather miscellaneous specs. The project took about 24 months from signing on the dotted line to finish. 8 months of that was the time from tape out to volume production, meaning about 16 months was design and verification. The die is about 160 square mm, but they wouldn't talk about power. The work there is ongoing, so if you have a closed cabinet to keep them in, skip the first generation Xbox360s. To make matters worse, the mostly unnamed chip has a name, but they wouldn't give it out. Aaargh. The name on top of the chips will probably give Intel the shivers though. µ