[3D tecnico]XBOX360 HW Vs PS3 HW

[fek]

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

Bene, cosi' mi puoi dare qualche dritta di economia che sono a quasi zero

Il discorso sui thread e' un po' piu' complesso. E' vero che la XCPU puo' usare per ogni core i tempi morti di esecuzione per eseguire un altro thread, ma questo non vuol dire avere due thread in parallelo che viaggiano a piena velocita'. Il massimo ottenibile e' circa il 30% in meno, ovvero ogni thread viaggia al 30% in meno che se fosse eseguito da solo. Quindi associare due thread ad una CPU ha un costo non nullo, che influisce sulla decisione.

Riguardo all'XPS, non si sposa benissimo con il predicated tiling: per fare una lunga storia breve, un oggetto generato proceduralmente dev'essere rigenerato per ogni tile (potenzialmente tre/quattro volte a frame!) se non viene predicato manualmente. Quindi richiede un po' di accortezza. Ma qui siamo sul teorico, perche' in pratica ancora non ho fatto nulla a riguardo.

[luckye]

Originariamente inviato da Free Gordon

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

Vabbè dai l'ho buttato lì alle due di notte...sonoro ? thread virtuale in un core
Kmq sta xbox mi piace sempre più

[fek]

Queste due console sono due belle macchinette

E' impressionante come siano architetturalmente molto differenti eppure sembrano vicinissime in termini di prestazioni. Scrivere un simulatore di fluidodinamica sul Cell dev'essere un gran divertimento, ad esempio.

[Free Gordon]

Originariamente inviato da fek

Queste due console sono due belle macchinette

E' impressionante come siano architetturalmente molto differenti eppure sembrano vicinissime in termini di prestazioni. Scrivere un simulatore di fluidodinamica sul Cell dev'essere un gran divertimento, ad esempio.

Ma sto RSX benedetto, è finito o no???

Alla fine è una 7800 pompata o c'è qualche sorpresa grossa...?

[yossarian]

Originariamente inviato da fek

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

beh, effettivamente a 1280x720 con AA4x tutto il frame non ci sta (ti servirebbero almeno 30 MB a 32 bit + 32 di z estencil)

Una cosa che mi chiedo è questa; adoperando la notazione 10+10+10+2, non si ha un range troppo ridotto per il canale alpha? So che ci sono delle tecniche per cercare di ovviare a questo inconveniente, ma quanto sono realmente efficaci? In fondo, l'alpha channel porta anche i dati relativi alla luminanza che trasporta, in un certo qual modo, i valori relativi alle funzioni peso delle 3 componenti RGB e quindi un suo range ridotto riduce, di conseguenza, le possiblità di scelta di queste funzioni

[fek]

Originariamente inviato da yossarian

beh, effettivamente a 1280x720 con AA4x tutto il frame non ci sta (ti servirebbero almeno 30 MB a 32 bit + 32 di z estencil)

Una cosa che mi chiedo è questa; adoperando la notazione 10+10+10+2, non si ha un range troppo ridotto per il canale alpha? So che ci sono delle tecniche per cercare di ovviare a questo inconveniente, ma quanto sono realmente efficaci? In fondo, l'alpha channel porta anche i dati relativi alla luminanza che trasporta, in un certo qual modo, i valori relativi alle funzioni peso delle 3 componenti RGB e quindi un suo range ridotto riduce, di conseguenza, le possiblità di scelta di queste funzioni

Il destination alpha e' usato rarissimamente. Non lo vedo come un grosso problema.

[yossarian]

Originariamente inviato da fek

Il destination alpha e' usato rarissimamente. Non lo vedo come un grosso problema.

e in quelle rare volte che viene usato, cosa comporta l'avere a disposizione solo 2 bit?

EDIT: come non detto; ho trovato le informazioni che cercavo

[fek]

Originariamente inviato da yossarian

e in quelle rare volte che viene usato, cosa comporta l'avere a disposizione solo 2 bit?

EDIT: come non detto; ho trovato le informazioni che cercavo

Comporta non usarlo o tornare a 8 bit

[yossarian]

Originariamente inviato da fek

Comporta non usarlo o tornare a 8 bit

anche se in ritardo, ci ero arrivato

comunque, grazie lo stesso

[Do85]

inizio a credere che la microsoft abbia raggiunto le stesse prestazioni con un minor costo...

[luckye]

Originariamente inviato da Do85

inizio a credere che la microsoft abbia raggiunto le stesse prestazioni con un minor costo...

No è probabile che sarà il nintendo revolution a quanto mi è dato sapere

[yossarian]

Originariamente inviato da vaio-man

quindi è come dico io, loro calcolano il valore di pixel che il chip può calcolare, mentre tu quello dei pixel che può visualizzare, di conseguenza la nvidia lo prende come valore della velocità del chip, mentre tu come valore dei pixel che fa muovere a schermo, questo significa che la nvidia dice "si sullo schermo abbiamo ancora 6400Mpixel/s ma il chip ne calcola molti di +, di conseguenza la nuova scheda raggiunge framerate + altri a parità di pixel in movimento sullo schermo"
quel valore deve uscire per forza da qualche parte, anche perchè se no come potrebbe essere che nei calcoli semplici (forza bruta) vince il g70, mentre nei calcoli + complessi (ottimizazzioni,efficienza) vince R520

*Update 6/29/05*

We have an update from NVIDIA on how fillrate is calculated on the GeForce 7800 GTX in lieu of the difference between pixel (fragment) pipelines and ROP numbers.

In an early draft of the reviewers guide I also listed pixel fill rate as 10.3G Pixels/sec (thinking 24 pixel pipes x 430MHz core). While that's certainly the bilinear-filtered texel fill rate, Tony corrected me stating that for peak pixel fill rate, we'd multiply number of ROPs x core clock rate, since "pixels" are output from the ROPs, so it's really 16x430MHz = 6.88GB/sec. Given the number of times fragments might cycle through pixel pipes, we really didn't need to increase # of ROPs to maintain a balanced architecture.

Thank you Nick and Tony. Our corrected statement is that the texel fillrate is indeed 10.3 GigaPixels/Sec but the peak pixel fillrate, since pixels are output through the ROPs, is 6.88 GigaPixels/Sec. You can think of this as the "effective" fillrate. Certainly you do not need to get caught up in these details as the real test of this video card is how it performs in games, which you will see later on this review. The gameplay evaluation speaks for itself.


da hardocp

http://www.hardocp.com/article.html?art=Nzg0LDM=

[Vifani]

Beh questo è un chiarimento significativo

[Lakitu]

X fek, yossarian e chiunque altro conosce ciò di cui scrive...

potreste "allargare" il thread anche su quel che sapete riguardo all'HW del Revolution, spiegandone un po' i possibili pregi e difetti e paragonandolo a quelli di Xbox360 e PS3?

Grazie.

[yossarian]

Originariamente inviato da Lakitu

X fek, yossarian e chiunque altro conosce ciò di cui scrive...

potreste "allargare" il thread anche su quel che sapete riguardo all'HW del Revolution, spiegandone un po' i possibili pregi e difetti e paragonandolo a quelli di Xbox360 e PS3?

Grazie.

stai cercando di farmi perdere tutte le amicizie

ti dico solo che ATi ha in cantiere due linee di produzione: una relativa a chip con shader unificati (tipo R500) e una relativa alla famiglia R5x0 e RV5x0 e che il chip del revo non fa parte della prima.

[Lakitu]

Originariamente inviato da yossarian

stai cercando di farmi perdere tutte le amicizie

ti dico solo che ATi ha in cantiere due linee di produzione: una relativa a chip con shader unificati (tipo R500) e una relativa alla famiglia R5x0 e RV5x0 e che il chip del revo non fa parte della prima.

Intanto grazie per questo primo "indizio"... ...rimango in fiduciosa attesa di aggiornamenti... chi sa qualcosa, parli!

[cangia]

Originariamente inviato da luckye

No è probabile che sarà il nintendo revolution a quanto mi è dato sapere

qualcuno dei nostri due esperti ha notizie in merito riguardo l'hw eo/ prestazioni e/o comportamento del chip-chop del Revolution ?

[cangia]

Originariamente inviato da yossarian

stai cercando di farmi perdere tutte le amicizie

ti dico solo che ATi ha in cantiere due linee di produzione: una relativa a chip con shader unificati (tipo R500) e una relativa alla famiglia R5x0 e RV5x0 e che il chip del revo non fa parte della prima.

se non fa parte della prima .. o è un chip serie r5x0 adattato alla console .. oppure è qualcosa di totalmente diverso ... si, ma cosa ?

[Free Gordon]

Da più parti ho letto che è un chip derivato da R520, a basso consumo energetico.

Non credo che in potenza sarà al livello delle altre due GPU (RSX e C1) ma sarà cmq abbastanza veloce per ciò che interssa a Nintendo..

Come del resto è sempre stato, per questa casa.

Calcola che deve stare in un case piccolissimo (spessore di 3dvd), per cui sarà qualcosa di estremamente parsimonioso, in consumi.

[Manp]

di sicuro dovrà scaldar poco e consumare poco...

che non sia magari un derivato di RV530?