[3D tecnico]XBOX360 HW Vs PS3 HW

[yossarian]

Originariamente inviato da Ren

Parli del blending eseguito nelle rop's vero ?
Sei stato un pò vago, specifica i colli di bottiglia e quantifica in percentuale l'aumento di performance.

ps. scusa se rompo le balls

si, parla di quello; le operazioni nello shader processor avvengono a fp32 e il texture blending a fp16.

Il principale collo di bottiglia, se si usa fp16 nelle rop's, è dato dalle dimensioni del buffer (eDRAM); con AA4x si può caricare un intero frame solo a 640x480, se si usa i8; senza utilizzo di AA si può operare in single pass, a fp16, solo con risoluzioni non superiori a 1280x720 (in formato HDTV)

[Manp]

halo? arbiter? ma state parlando di halo 2?

[Free Gordon]

Originariamente inviato da Manp

halo? arbiter? ma state parlando di halo 2?

Vero!

[fek]

Originariamente inviato da luckye

Beh facendo due conti fp10 e int. 32bit in si equivalgono.La qualità finale è sbilanciata a favore di fp10.
O sbaglio ?

Non sbagli, ma si guadagnano solo due bit in fondo, che vanno praticamente dritti nella mantissa. Alla fine il guadagno in termini qualitativi e' tutto da stimare. Ti sapro' dire qualcosa di piu' preciso in un paio di mesi quando passo al post processing.

[fek]

Originariamente inviato da Ren

Parli del blending eseguito nelle rop's vero ?
Sei stato un pò vago, specifica i colli di bottiglia e quantifica in percentuale l'aumento di performance.

ps. scusa se rompo le balls

Si', sono stato vago, scusa

Parlavo del lavoro eseguto nelle rop: blending e MSAA. MS dichiara che ogni rop ha bisogno di due cicli per processare un frammento a 64 bit, rispetto al ciclo necessario per un frammento a 32bit.

Le rop sono solo uno dei colli di bottiglia nella pipeline grafica. Un collo di bottiglia puo' essere ad esempio nello shader engine, se gli shader sono troppo complessi, oppure nella fase geometrica, se la scena da processare ha troppi poligoni (raro), oppure nella CPU stessa se i calcoli che svolge sono troppo pesanti. Le prestazioni finali dipendono fortemente dallo stadio piu' appesantito e lento, il collo di bottiglia.

[yossarian]

Originariamente inviato da fek

Si', sono stato vago, scusa

Parlavo del lavoro eseguto nelle rop: blending e MSAA. MS dichiara che ogni rop ha bisogno di due cicli per processare un frammento a 64 bit, rispetto al ciclo necessario per un frammento a 32bit.

Le rop sono solo uno dei colli di bottiglia nella pipeline grafica. Un collo di bottiglia puo' essere ad esempio nello shader engine, se gli shader sono troppo complessi, oppure nella fase geometrica, se la scena da processare ha troppi poligoni (raro), oppure nella CPU stessa se i calcoli che svolge sono troppo pesanti. Le prestazioni finali dipendono fortemente dallo stadio piu' appesantito e lento, il collo di bottiglia.

dovrebbe essere così: blending a fp16, tone mapping e MSAA da un lato e blending a i8 e MSAA dall'altro. Considerando che le unità che si occupano di blending e tone mapping sono le stesse, i conti dovrebbero tornare (un ciclo per fare blending e uno per fare tone mapping+MSAA con fp16 e un ciclo per fare blending+MSAA con i8)

[Ren]

si, parla di quello; le operazioni nello shader processor avvengono a fp32 e il texture blending a fp16. Il principale collo di bottiglia, se si usa fp16 nelle rop's, è dato dalle dimensioni del buffer (eDRAM); con AA4x si può caricare un intero frame solo a 640x480, se si usa i8; senza utilizzo di AA si può operare in single pass, a fp16, solo con risoluzioni non superiori a 1280x720 (in formato HDTV)

Quindi le rop's rimangono in attesa finche la memoria non è disponibile.(quanto si perde se la memoria è metà di quella utile?)
Ho visto che nel design del chip hanno deciso di utilizzare un display controller esterno x diminuire la complessità del chip.
Quanto influisce in termini di transistor un controller integrato di stampo PC,(quindi che può gestire svariate risoluzioni) ?

[fek]

Originariamente inviato da yossarian

dovrebbe essere così: blending a fp16, tone mapping e MSAA da un lato e blending a i8 e MSAA dall'altro. Considerando che le unità che si occupano di blending e tone mapping sono le stesse, i conti dovrebbero tornare (un ciclo per fare blending e uno per fare tone mapping+MSAA con fp16 e un ciclo per fare blending+MSAA con i8)

yoss, per capirci, che cosa intendi per tonemapping di preciso?

Io quando parlo di tonemapping intendo una qualche funzione eseguita in post processing da un pixel shader che prende il framebuffer in ingresso come texture e restituisce il framebuffer i8 con eventuali effetti di blooming e depth of field.

Giusto per chiarire il discorso

[yossarian]

Originariamente inviato da Ren

Quindi le rop's rimangono in attesa finche la memoria non è disponibile.(quanto si perde se la memoria è metà di quella utile?)
Ho visto che nel design del chip hanno deciso di utilizzare un display controller esterno x diminuire la complessità del chip.
Quanto influisce in termini di transistor un controller integrato di stampo PC,(quindi che può gestire svariate risoluzioni) ?

no; hai ragione, non sono stato molto preciso. Mi riferivo alle operazioni di post processing. La spiegazione relativa alle operazioni in real time è quella che ti ha dato fek poco più in basso (due cicli in fp16 contro uno in i8)

[yossarian]

Originariamente inviato da fek

yoss, per capirci, che cosa intendi per tonemapping di preciso?

Io quando parlo di tonemapping intendo una qualche funzione eseguita in post processing da un pixel shader che prende il framebuffer in ingresso come texture e restituisce il framebuffer i8 con eventuali effetti di blooming e depth of field.

Giusto per chiarire il discorso

la stessa cosa; si tratta semplicemente di un'operazione di compressione dei dati da hdr (o half hdr) a ldr, prima dell'invio definitivo degli stessi nel fb; ma non è detto che debba avvenire in post processing con accesso al frame buffer. Ad esempio, disponendo di una color cache nelle rop's, si può effettuare, come lo stesso blending, all'interno delle rop's stesse, prima di inviare il risultato finale al fb. In questo caso non è del tutto lecito parlare di operazione di post processing (se con post processing si intendono quelle operazioni eseguite ripescando texture dal fb).
Le rop's in grado di eseguire blending a fp16 hanno parte delle funzionalità dei ps e l'algoritmo di compressione comunemente adoperato e di tipo log (in base 2).

[fek]

Ok, ma io come programmerei un tale tonemapping hardwired nelle ROP?

Per il mio algoritmo di compressione del range dinamico (nulla di che, una funzione logaritmica relativamente banale), ho in input alcuni parametri che mi regolano l'esposizione ad esempio.

Quando renderizzo su un target fp16, lascio il blending lineare (invece di usare l'sRGB), e poi faccio il tonemapping a manina alla fine. Anche perche' alla conclusione del processo passo il tutto attraverso una cubemap per rimappare i colori, aggiungo blooming, dof e altre cosette varie.

Pero' mi hai dato un'idea, magari riesco a risparmiare qualche istruzione nello shader usando la gamma correction nelle ROP.... hmmm... ci penso su...

[luckye]

Originariamente inviato da fek

yoss, per capirci, che cosa intendi per tonemapping di preciso?

Io quando parlo di tonemapping intendo una qualche funzione eseguita in post processing da un pixel shader che prende il framebuffer in ingresso come texture e restituisce il framebuffer i8 con eventuali effetti di blooming e depth of field.

Giusto per chiarire il discorso

Visto che stai smanettando con una cosina che hai lì narraci di cosa può fare il procedural synthesis di zio bill o di che fig@t@ e lockare la l2

[luckye]

Originariamente inviato da Ren

Sono i monitor che rendono inutile un hdr superiore a 8bit x canale.
L'unico vantaggio risiede nelle operazioni svolte in virgola mobile che avendo un andamento logaritmico danno un maggiore senso di realtà al nostro occhio...

Beh a voler vedere oltre che si sa sta cosa degli 8bit ripetuta mille volte vorrei kmq far notare che l'occhio è sensibile alle sfumature di verde.
Quindi con tutte le altre sfumature di colore vengono compensate dal nostro occhio.
Kmq nulla toglie che fp16 porti a un minor degrado...

[fek]

Originariamente inviato da luckye

Visto che stai smanettando con una cosina che hai lì narraci di cosa può fare il procedural synthesis di zio bill o di che fig@t@ e lockare la l2

Appena ci provo te lo dico

[luckye]

Originariamente inviato da fek

Appena ci provo te lo dico

E' una feature importante secondo me alla quale non è stato dato il giusto rilievo.Non penso di sbagliare parlando di "rivoluzione" oltre che a rendere chiaro il perchè di 3 core a doppio thread.

[Free Gordon]

Originariamente inviato da luckye

E' una feature importante secondo me alla quale non è stato dato il giusto rilievo.Non penso di sbagliare parlando di "rivoluzione" oltre che a rendere chiaro il perchè di 3 core a doppio thread.

Perchè 3 core a doppio thread allora?

[luckye]

Originariamente inviato da Free Gordon

Perchè 3 core a doppio thread allora?

Un core per procedural synthesis e magari Real-time skinning

Un core per gestire il thread main del gioco le parti ad alto livello del 3D engine e controllare il data generation thread

Un core per fisica, imput del giocatore,intelligenza artificiale.

Nulla vieta di aver due thread nello stesso core...
Ottimo davvero questo XENON

P.s io sono economista non informatico magari ne sparo di banzane

[yossarian]

Originariamente inviato da fek

Ok, ma io come programmerei un tale tonemapping hardwired nelle ROP?

Per il mio algoritmo di compressione del range dinamico (nulla di che, una funzione logaritmica relativamente banale), ho in input alcuni parametri che mi regolano l'esposizione ad esempio.

Quando renderizzo su un target fp16, lascio il blending lineare (invece di usare l'sRGB), e poi faccio il tonemapping a manina alla fine. Anche perche' alla conclusione del processo passo il tutto attraverso una cubemap per rimappare i colori, aggiungo blooming, dof e altre cosette varie.

Pero' mi hai dato un'idea, magari riesco a risparmiare qualche istruzione nello shader usando la gamma correction nelle ROP.... hmmm... ci penso su...

Sai che non sono la persona più indicata a darti suggerimenti su come programmare le operazioni di rendering . L'unica cosa che posso dirti è che hai 10 MB dentro al chip da usare alla stregua di un fb. l'idea è quella di accodare il tone mapping al blending a fp16. Quindi puoi fare gamma correction nelle rop's, oppure lavorare, per ciò che rimane, in post processing, ma caricando l'intero frame all'interno dellle eDRAM.
Diciamo che è solo un'idea di cui tu potresti confermarmi o meno la fattibilità.
Nel caso funzionasse, però, voglio l'esclusiva

[Free Gordon]

Originariamente inviato da luckye

Un core per procedural synthesis e magari Real-time skinning

Un core per gestire il thread main del gioco le parti ad alto livello del 3D engine e controllare il data generation thread

Un core per fisica, imput del giocatore,intelligenza artificiale.

Nulla vieta di aver due thread nello stesso core...
Ottimo davvero questo XENON

P.s io sono economista non informatico magari ne sparo di banzane

E il sonoro dove lo metti?

Cmq ho capito cosa volei dire..

Calcola però che i 3 core avranno solo 340Kb di L2 a testa.. non molta in fondo.
Da questo lato sarebbe stato molto meglio averne almeno 2Mb in totale! Ma il die sarebbe stato troppo grosso probabilmente..

[fek]

Originariamente inviato da yossarian

Sai che non sono la persona più indicata a darti suggerimenti su come programmare le operazioni di rendering . L'unica cosa che posso dirti è che hai 10 MB dentro al chip da usare alla stregua di un fb. l'idea è quella di accodare il tone mapping al blending a fp16. Quindi puoi fare gamma correction nelle rop's, oppure lavorare, per ciò che rimane, in post processing, ma caricando l'intero frame all'interno dellle eDRAM.
Diciamo che è solo un'idea di cui tu potresti confermarmi o meno la fattibilità.
Nel caso funzionasse, però, voglio l'esclusiva

Sicuramente non posso caricare l'intero frame in EDRAM, devo comunque passare per il predicated tiling (1280x720 MSAA4x), e' un TCR Microsoft, in altre parole c'e' la scelta fra farlo, oppure invece farlo

L'idea per ora e' di usare un fp10, perche' non penso di potermi permettere un fill rate ridotto alla meta', risolvere il backbuffer in memoria centrale dall'EDRAM e poi riusarlo come texture in ingresso per il tonemapping (+ goodies). Pero' mi hai suggerito che potrei usare le rop per risparmiare magari qualche istruzione del tonemapper. Se funziona, l'esclusiva e il ringraziamento nei crediti sono tutti tuoi