luckye
29-10-2005, 17:20
Io dico solo yoss e fek :ave:
Ne sanno...ma quante ne sanno! Il resto imho è :blah:
Ne sanno...ma quante ne sanno! Il resto imho è :blah:
View Full Version : [3D tecnico]XBOX360 HW Vs PS3 HW
vaio-man
29-10-2005, 17:22
quali spiegazioni?
ha detto l'R520 è ibrido, io ho detto no, se scondo te lo è porta le prove(di siti attendibili e non di inquirer),e lui per tutta risposta mi ha detto è così, se non convieni significa che nn capisci un ca**o (sintetizando)
se secondo te questo è competenza o è uno che da tutte le risposte documentando :doh:
ha detto l'R520 è ibrido, io ho detto no, se scondo te lo è porta le prove(di siti attendibili e non di inquirer),e lui per tutta risposta mi ha detto è così, se non convieni significa che nn capisci un ca**o (sintetizando)
se secondo te questo è competenza o è uno che da tutte le risposte documentando :doh:
Maury
29-10-2005, 17:24
significa che nn capisci un ca**o (sintetizando)
e cos'è che non ti torna in questa frase ? :confused: :rotfl:
e cos'è che non ti torna in questa frase ? :confused: :rotfl:
vaio-man
29-10-2005, 17:26
maury :mad: :fuck: :grrr: :ncomment: ok?
fek
29-10-2005, 17:32
quali spiegazioni?
ha detto l'R520 è ibrido, io ho detto no, se scondo te lo è porta le prove(di siti attendibili e non di inquirer),e lui per tutta risposta mi ha detto è così, se non convieni significa che nn capisci un ca**o (sintetizando)
se secondo te questo è competenza o è uno che da tutte le risposte documentando :doh:
Ecco qui le spiegazioni:
http://www.hwupgrade.it/forum/showthread.php?t=1036964
Divertiti, sono 900 e rotti post, molti di yoss, dove spiega per filo e per segno dove, come e perche' e' un'architettura ibrida. Il che non vuol dire che sia un'architettura unificata, perche' non lo e'. Sono due cose diverse.
Per altro, io prima di tutta quella spiegazione non avevo capito fino a quale livello l'architettura dell'R520 fosse stata cambiata rispetto all'R3x0, quindi e' stata una lettura almeno per me molto utile. Sono certo che lo sara' anche per te.
ha detto l'R520 è ibrido, io ho detto no, se scondo te lo è porta le prove(di siti attendibili e non di inquirer),e lui per tutta risposta mi ha detto è così, se non convieni significa che nn capisci un ca**o (sintetizando)
se secondo te questo è competenza o è uno che da tutte le risposte documentando :doh:
Ecco qui le spiegazioni:
http://www.hwupgrade.it/forum/showthread.php?t=1036964
Divertiti, sono 900 e rotti post, molti di yoss, dove spiega per filo e per segno dove, come e perche' e' un'architettura ibrida. Il che non vuol dire che sia un'architettura unificata, perche' non lo e'. Sono due cose diverse.
Per altro, io prima di tutta quella spiegazione non avevo capito fino a quale livello l'architettura dell'R520 fosse stata cambiata rispetto all'R3x0, quindi e' stata una lettura almeno per me molto utile. Sono certo che lo sara' anche per te.
vaio-man
29-10-2005, 17:36
non voglio cose dette da lui, voglio siti, gente neutrale e con la scheda in mano, insomma gente con le contro OO
grazie lo stesso fek, almeno tu dimostri di essere all'altezza del ruolo che occupi
grazie lo stesso fek, almeno tu dimostri di essere all'altezza del ruolo che occupi
luckye
29-10-2005, 17:39
non voglio cose dette da lui, voglio siti, gente neutrale e con la scheda in mano, insomma gente con le contro OO
grazie lo stesso fek, almeno tu dimostri di essere all'altezza del ruolo che occupi
Per quanto mi riguarda di palle yoss ne ha 3 :) :sofico:
Kmq più dei link in cui si scrive un pò quello che si vuole mi "fiderei" di spiegazioni di gente che porta a casa il pane grazie alle proprie conoscenze in tal campo ;)
Almeno imho
grazie lo stesso fek, almeno tu dimostri di essere all'altezza del ruolo che occupi
Per quanto mi riguarda di palle yoss ne ha 3 :) :sofico:
Kmq più dei link in cui si scrive un pò quello che si vuole mi "fiderei" di spiegazioni di gente che porta a casa il pane grazie alle proprie conoscenze in tal campo ;)
Almeno imho
fek
29-10-2005, 17:44
non voglio cose dette da lui, voglio siti, gente neutrale e con la scheda in mano, insomma gente con le contro OO
grazie lo stesso fek, almeno tu dimostri di essere all'altezza del ruolo che occupi
yoss e' uno di quelli con le contro OO :)
grazie lo stesso fek, almeno tu dimostri di essere all'altezza del ruolo che occupi
yoss e' uno di quelli con le contro OO :)
[Kendall]
29-10-2005, 17:44
non voglio cose dette da lui, voglio siti, gente neutrale e con la scheda in mano, insomma gente con le contro OO
grazie lo stesso fek, almeno tu dimostri di essere all'altezza del ruolo che occupi
:nono:
grazie lo stesso fek, almeno tu dimostri di essere all'altezza del ruolo che occupi
:nono:
yossarian
29-10-2005, 17:46
io non metto indubbio le loro conoscenze ma voglio prove, costa tanto dare un link attendibile (e con questo esludo the inquirer)?
fek non lo metto indubbio so chi è. e con questo chiudo
io un link dove non c'è scritto nè che la x1800 è ibrida nè che ha le pippe unificate l'ho portato e guarda il caso è propio in questo sito. :muro:
l'affermazione l'hai fatta, due per la precisione
1) la R520 è ibrida
2) lo sviluppo di r500 è iniziato nel 2002, e senza indicazioni su l'architettura da parte di M$
se vuoi ti posto il link anche per la seconda è sempre in questo sito
mi riferivo all'affermazione: l'R520 è più efficiente perchè raggiunge frequenze più alte. Cosa che non mi sono mai sognato di dire (se non nella tua immaginazione). Discorso molto diverso dal dire: l'R520 è stato progettato per lavorare ad alte frequenze e non è un chip o/c per raggiungere le prestazioni. Mi pare che siano due cose molto differenti. Non trovi? D'altra parte, sono anche quello che ha detto, subito dopo l'uscita di NV20, cjhe la successiva generazione di chip avrebbe avuto bus a 256 bit; ho anche detto, per primo sul web, con ben 2 mesi di anticipo sull'articolo di 3D Center, che ha fatto scoprire la cosa, che l'NV30 soffriva di carenza di registri temporanei interni (non lo sto dicendo per vantarmi, si tratta solo di, chiamiamole "referenze", semmai ce ne fosse bisogno su un forum); sono anche quello che ha detto, subito dopo l'uscita della X1800XT, che il chip era tutt'altro che o/c e che sarebbe salito ancora di molto, perchè era progettato per lavorare ad alte frequenze; e infatti, il v-core è a 1,3 V contro gli 1,4 della GTX in modalità 3D e il chip è arrivato, finora a circa 1 Ghz (se fai una ricerca su thread più o meno vecchi, su HWUpgrade e nV Italia, puoi trovare conferma a tutto).
Veniamo alle affermazioni che ti scandalizzano tanto, premettendo che le mie affermazioni si basano anche sulle recensioni, ma non solo su quelle (visto che alcune conoscenze le ho acquisite altrove :fagiano: ).
R520 è un chip ibrido, perchè ha conservato, di R4x0, solo l'architettura delle vsu (tranne il branch predictor) e, parzialmente, quella delle rop's. Il pixel processor è, al pari di quello di R500, un dispositivo con logica e architettura RISC (al contrario delle pixel pipeline di G70, R4x0 e tutto ciò che c'è stato prima). Ha, al pari di R500, un memory controller e un dispatch processor interamente programmabili. Utilizza, al pari di R500, un'array di registri di tipo R e R/W, fully associative e ad accessi multipli, invece di registri dedicati alla singola pipeline o alla singola unità di calcolo. Ha, al pari di R500, un array di tmu con texture buffer dedicato. La differenza rispetto a R500 sta solo nel fatto che gli shader non sono unificati. Nelle rop's, fa uso di un color buffer che, in parte, sostituisce, nelle funzionalità, l'eDRAM dell'R500, anche se non si tratta, in questo caso, di ram con unità di calcolo all'interno, ma di unità di calcolo che utilizzano un buffer. Ce n'è abbastanza per dire che si tratta di un chip ibrido? Quanti elementi comuni ha il pixel processor di R520 con quello di R500? E quanti con quello di G70 o di R4x0?
Questo, limitatamente alle differenze e alle similitudini architetturali. Volendo, si può proporre un'analisi analoga anche riguardo alla logica di funzionamento del chip, però non è questa la sede opportuna e non voglio continuare a contribuire a mandare il thread a pu@@ane.
Il progetto R400 risale al 2002 e prevedeva una serie di chip con architettura completamente nuova, da sviluppare in vista dell'adozione dello sm3.0 prima e dello sm4.0 in seguito (che propone l'unificazione degli shader, almeno a livello di logica). R5x0 e R500 sono due step successivi dello stesso progetto, che arriverà a proporre, con R600, il primo chip a shader unificati per pc.
Non è un caso che nel passaggio da sm2.0 a sm3.0, l'architettura di buona parte del chip, sia stata completamente ridisegnata, in maniera tale da poter funzionare, con qualche modifica, anche con logica a shader unificati (pur mantenendoli fisicamente separati).
Per chi ha lavorato, anche per poco tempo, nel campo alla progettazione di componenti elettronici, sa bene che un nuovo progetto (non un adattamento di qualcosa di esistente), fosse anche qualcosa di più semplice di un chip grafico, non si improvvisa in qualche mese su commissione. E, nel campo del 3D, ogni società ha i suoi piani di sviluppo che non possono essere variati perchè qualcuno ha bisogno di qualcosa di particolare (anche se questo qualcuno si chiama MS). ATi, o nVIDIA, o chi per essa, non si mette a progettare un chip, di sana pianta, su commissione. La dimostrazione l'avrai con RSX che non è altro che un G70 adattato ad una consolle. Oppure con il chip del revolution che sarà un adattamento di un chip della serie R5x0. Con R500 è semplicemente successo che ATi era abbastanza avanti nello sviluppo del chip, e l'idea di un chip wgf2.0 è piaciuta a MS. Certo è che se ATi non avesse avuto in progetto la realizzazione di chip a shader unificati anche per pc, non si sarebbe mai messa a progettare un chip così complesso solo per fare piacere a MS. Se la pensi così, è evidente che di quell'ambiente conosci meno di niente.
L'articolo di The Inquirer riporta una notizia vera; e cioè che il G70 non ha passato tutti i test proposti da MS per potersi fregiare del titolo di sm3.0 full compliant. In particolare, ha fallito i test di comparazione del campione con il prodotto della rasterizzazione. Ora, per quanto the inquirer sia la novella 2000 del 3D, un conto è una speculazione, un conto è una notizia riportata (anche su novella 2000 si trovano notizie attendibili).
fek non lo metto indubbio so chi è. e con questo chiudo
io un link dove non c'è scritto nè che la x1800 è ibrida nè che ha le pippe unificate l'ho portato e guarda il caso è propio in questo sito. :muro:
l'affermazione l'hai fatta, due per la precisione
1) la R520 è ibrida
2) lo sviluppo di r500 è iniziato nel 2002, e senza indicazioni su l'architettura da parte di M$
se vuoi ti posto il link anche per la seconda è sempre in questo sito
mi riferivo all'affermazione: l'R520 è più efficiente perchè raggiunge frequenze più alte. Cosa che non mi sono mai sognato di dire (se non nella tua immaginazione). Discorso molto diverso dal dire: l'R520 è stato progettato per lavorare ad alte frequenze e non è un chip o/c per raggiungere le prestazioni. Mi pare che siano due cose molto differenti. Non trovi? D'altra parte, sono anche quello che ha detto, subito dopo l'uscita di NV20, cjhe la successiva generazione di chip avrebbe avuto bus a 256 bit; ho anche detto, per primo sul web, con ben 2 mesi di anticipo sull'articolo di 3D Center, che ha fatto scoprire la cosa, che l'NV30 soffriva di carenza di registri temporanei interni (non lo sto dicendo per vantarmi, si tratta solo di, chiamiamole "referenze", semmai ce ne fosse bisogno su un forum); sono anche quello che ha detto, subito dopo l'uscita della X1800XT, che il chip era tutt'altro che o/c e che sarebbe salito ancora di molto, perchè era progettato per lavorare ad alte frequenze; e infatti, il v-core è a 1,3 V contro gli 1,4 della GTX in modalità 3D e il chip è arrivato, finora a circa 1 Ghz (se fai una ricerca su thread più o meno vecchi, su HWUpgrade e nV Italia, puoi trovare conferma a tutto).
Veniamo alle affermazioni che ti scandalizzano tanto, premettendo che le mie affermazioni si basano anche sulle recensioni, ma non solo su quelle (visto che alcune conoscenze le ho acquisite altrove :fagiano: ).
R520 è un chip ibrido, perchè ha conservato, di R4x0, solo l'architettura delle vsu (tranne il branch predictor) e, parzialmente, quella delle rop's. Il pixel processor è, al pari di quello di R500, un dispositivo con logica e architettura RISC (al contrario delle pixel pipeline di G70, R4x0 e tutto ciò che c'è stato prima). Ha, al pari di R500, un memory controller e un dispatch processor interamente programmabili. Utilizza, al pari di R500, un'array di registri di tipo R e R/W, fully associative e ad accessi multipli, invece di registri dedicati alla singola pipeline o alla singola unità di calcolo. Ha, al pari di R500, un array di tmu con texture buffer dedicato. La differenza rispetto a R500 sta solo nel fatto che gli shader non sono unificati. Nelle rop's, fa uso di un color buffer che, in parte, sostituisce, nelle funzionalità, l'eDRAM dell'R500, anche se non si tratta, in questo caso, di ram con unità di calcolo all'interno, ma di unità di calcolo che utilizzano un buffer. Ce n'è abbastanza per dire che si tratta di un chip ibrido? Quanti elementi comuni ha il pixel processor di R520 con quello di R500? E quanti con quello di G70 o di R4x0?
Questo, limitatamente alle differenze e alle similitudini architetturali. Volendo, si può proporre un'analisi analoga anche riguardo alla logica di funzionamento del chip, però non è questa la sede opportuna e non voglio continuare a contribuire a mandare il thread a pu@@ane.
Il progetto R400 risale al 2002 e prevedeva una serie di chip con architettura completamente nuova, da sviluppare in vista dell'adozione dello sm3.0 prima e dello sm4.0 in seguito (che propone l'unificazione degli shader, almeno a livello di logica). R5x0 e R500 sono due step successivi dello stesso progetto, che arriverà a proporre, con R600, il primo chip a shader unificati per pc.
Non è un caso che nel passaggio da sm2.0 a sm3.0, l'architettura di buona parte del chip, sia stata completamente ridisegnata, in maniera tale da poter funzionare, con qualche modifica, anche con logica a shader unificati (pur mantenendoli fisicamente separati).
Per chi ha lavorato, anche per poco tempo, nel campo alla progettazione di componenti elettronici, sa bene che un nuovo progetto (non un adattamento di qualcosa di esistente), fosse anche qualcosa di più semplice di un chip grafico, non si improvvisa in qualche mese su commissione. E, nel campo del 3D, ogni società ha i suoi piani di sviluppo che non possono essere variati perchè qualcuno ha bisogno di qualcosa di particolare (anche se questo qualcuno si chiama MS). ATi, o nVIDIA, o chi per essa, non si mette a progettare un chip, di sana pianta, su commissione. La dimostrazione l'avrai con RSX che non è altro che un G70 adattato ad una consolle. Oppure con il chip del revolution che sarà un adattamento di un chip della serie R5x0. Con R500 è semplicemente successo che ATi era abbastanza avanti nello sviluppo del chip, e l'idea di un chip wgf2.0 è piaciuta a MS. Certo è che se ATi non avesse avuto in progetto la realizzazione di chip a shader unificati anche per pc, non si sarebbe mai messa a progettare un chip così complesso solo per fare piacere a MS. Se la pensi così, è evidente che di quell'ambiente conosci meno di niente.
L'articolo di The Inquirer riporta una notizia vera; e cioè che il G70 non ha passato tutti i test proposti da MS per potersi fregiare del titolo di sm3.0 full compliant. In particolare, ha fallito i test di comparazione del campione con il prodotto della rasterizzazione. Ora, per quanto the inquirer sia la novella 2000 del 3D, un conto è una speculazione, un conto è una notizia riportata (anche su novella 2000 si trovano notizie attendibili).
Maury
29-10-2005, 17:50
non voglio cose dette da lui, voglio siti, gente neutrale e con la scheda in mano, insomma gente con le contro OO
grazie lo stesso fek, almeno tu dimostri di essere all'altezza del ruolo che occupi
Forse non ti è chiara una cosa... Yoss è uno che può mettersi tranquillamente al tavolo con ingegneri ATi ed nVidia facendo una figura della Madonna, hai denigrato le @@ sbagliate a questo giro ;)
e cmq intanto tu :banned: :fuck:
grazie lo stesso fek, almeno tu dimostri di essere all'altezza del ruolo che occupi
Forse non ti è chiara una cosa... Yoss è uno che può mettersi tranquillamente al tavolo con ingegneri ATi ed nVidia facendo una figura della Madonna, hai denigrato le @@ sbagliate a questo giro ;)
e cmq intanto tu :banned: :fuck:
fek
29-10-2005, 18:08
Forse non ti è chiara una cosa... Yoss è uno che può mettersi tranquillamente al tavolo con ingegneri ATi ed nVidia facendo una figura della Madonna, hai denigrato le @@ sbagliate a questo giro ;)
e cmq intanto tu :banned: :fuck:
Correzione: yoss non puo' mettersi tranquillamente al tavolo con ingegneri ATI, yoss si e' gia' messo al tavolo con ingegneri ATI :D
e cmq intanto tu :banned: :fuck:
Correzione: yoss non puo' mettersi tranquillamente al tavolo con ingegneri ATI, yoss si e' gia' messo al tavolo con ingegneri ATI :D
vaio-man
29-10-2005, 18:16
ci voleva tanto?
cmq la M$ ci ha messo del suo per forza ha controllato se il lavoro la soddisfava e ha dato la base di partenza, cioè ha detto come doveva a grandi linee essere l'architettura, cioè a shader unificati, che la ati ci stesse già lavorando è un altro discorso e ci può anche stare visto che da mondo è mondo, tutti presentano qualcosa di già pronto per poter partire da quello, per il g70 stessa questione nvidia lo aveva già pronto e la sony gli ha detto "ok, va bene, è un ottima base di partenza, ora mettiamoci a lavoro insieme e facciamo le migliorie del caso" e penso che lo stesso sia stato detto da M$ ad ati
per la questione perchè sia ibrida, finalmente mi hai spiegato la tua opinione, che , al contrario di quello che pensa qualcuno, ho capito alla perfezione :stordita: , e se mi dici che è ibrido perchè include caratteristiche di una architettura per console e di una desk sono d'accordo, se mi dici che include caratteristiche che gli permettono con piccoli accorgimenti e qualche modifica di diventare a shader unificati sono d'accordo.
ma devi ammetere che se tu non mi dici perchè secondo te è ibrido io non posso sapere che tu non ti stai riferendo a caratteristiche esclusive di una futura architettura a sheder unificati, perchè di quello non ha nulla.
sono d'accordo anche quando dici che non è + efficiente perchè raggiunge certe frequenze, ma perchè ha prestazioni altissime pur con un basso numero di pipeline (anche se di vere pipeline non di può parlare a causa della rivoluzionaria architettura).
in definitiva scusa se ti ho messo in bocca parole che non hai detto :stordita:
cmq la M$ ci ha messo del suo per forza ha controllato se il lavoro la soddisfava e ha dato la base di partenza, cioè ha detto come doveva a grandi linee essere l'architettura, cioè a shader unificati, che la ati ci stesse già lavorando è un altro discorso e ci può anche stare visto che da mondo è mondo, tutti presentano qualcosa di già pronto per poter partire da quello, per il g70 stessa questione nvidia lo aveva già pronto e la sony gli ha detto "ok, va bene, è un ottima base di partenza, ora mettiamoci a lavoro insieme e facciamo le migliorie del caso" e penso che lo stesso sia stato detto da M$ ad ati
per la questione perchè sia ibrida, finalmente mi hai spiegato la tua opinione, che , al contrario di quello che pensa qualcuno, ho capito alla perfezione :stordita: , e se mi dici che è ibrido perchè include caratteristiche di una architettura per console e di una desk sono d'accordo, se mi dici che include caratteristiche che gli permettono con piccoli accorgimenti e qualche modifica di diventare a shader unificati sono d'accordo.
ma devi ammetere che se tu non mi dici perchè secondo te è ibrido io non posso sapere che tu non ti stai riferendo a caratteristiche esclusive di una futura architettura a sheder unificati, perchè di quello non ha nulla.
sono d'accordo anche quando dici che non è + efficiente perchè raggiunge certe frequenze, ma perchè ha prestazioni altissime pur con un basso numero di pipeline (anche se di vere pipeline non di può parlare a causa della rivoluzionaria architettura).
in definitiva scusa se ti ho messo in bocca parole che non hai detto :stordita:
yossarian
29-10-2005, 18:36
ci voleva tanto?
cmq la M$ ci ha messo del suo per forza ha controllato se il lavoro la soddisfava e ha dato la base di partenza, cioè ha detto come doveva a grandi linee essere l'architettura, cioè a shader unificati, che la ati ci stesse già lavorando è un altro discorso e ci può anche stare visto che da mondo è mondo, tutti presentano qualcosa di già pronto per poter partire da quello, per il g70 stessa questione nvidia lo aveva già pronto e la sony gli ha detto "ok, va bene, è un ottima base di partenza, ora mettiamoci a lavoro insieme e facciamo le migliorie del caso" e penso che lo stesso sia stato detto da M$ ad ati
per la questione perchè sia ibrida, finalmente mi hai spiegato la tua opinione, che , al contrario di quello che pensa qualcuno, ho capito alla perfezione :stordita: , e se mi dici che è ibrido perchè include caratteristiche di una architettura per console e di una desk sono d'accordo, se mi dici che include caratteristiche che gli permettono con piccoli accorgimenti e qualche modifica di diventare a shader unificati sono d'accordo.
ma devi ammetere che se tu non mi dici perchè secondo te è ibrido io non posso sapere che tu non ti stai riferendo a caratteristiche esclusive di una futura architettura a sheder unificati, perchè di quello non ha nulla.
sono d'accordo anche quando dici che non è + efficiente perchè raggiunge certe frequenze, ma perchè ha prestazioni altissime pur con un basso numero di pipeline (anche se di vere pipeline non di può parlare a causa della rivoluzionaria architettura).
in definitiva scusa se ti ho messo in bocca parole che non hai detto :stordita:
scuse accettate :)
cmq la M$ ci ha messo del suo per forza ha controllato se il lavoro la soddisfava e ha dato la base di partenza, cioè ha detto come doveva a grandi linee essere l'architettura, cioè a shader unificati, che la ati ci stesse già lavorando è un altro discorso e ci può anche stare visto che da mondo è mondo, tutti presentano qualcosa di già pronto per poter partire da quello, per il g70 stessa questione nvidia lo aveva già pronto e la sony gli ha detto "ok, va bene, è un ottima base di partenza, ora mettiamoci a lavoro insieme e facciamo le migliorie del caso" e penso che lo stesso sia stato detto da M$ ad ati
per la questione perchè sia ibrida, finalmente mi hai spiegato la tua opinione, che , al contrario di quello che pensa qualcuno, ho capito alla perfezione :stordita: , e se mi dici che è ibrido perchè include caratteristiche di una architettura per console e di una desk sono d'accordo, se mi dici che include caratteristiche che gli permettono con piccoli accorgimenti e qualche modifica di diventare a shader unificati sono d'accordo.
ma devi ammetere che se tu non mi dici perchè secondo te è ibrido io non posso sapere che tu non ti stai riferendo a caratteristiche esclusive di una futura architettura a sheder unificati, perchè di quello non ha nulla.
sono d'accordo anche quando dici che non è + efficiente perchè raggiunge certe frequenze, ma perchè ha prestazioni altissime pur con un basso numero di pipeline (anche se di vere pipeline non di può parlare a causa della rivoluzionaria architettura).
in definitiva scusa se ti ho messo in bocca parole che non hai detto :stordita:
scuse accettate :)
Manp
29-10-2005, 18:40
ok ti do la risposta che tu non sei riuscito a darmi, F-A-N-B-O-Y
ecco ciò che sei ed ecco il motivo per cui nn porti prove
io dico cose sbagliate e tu cose giuste, ok!!
ma dimostramelo io sto qua aspetto te e non vedo perchè devo entrare in un thread tra g70 ed r520 visto che io sto parlando di M$, x-box,R500 (e non R520) e console :Prrr:
è la gente come te che rovina i forum, porta prove
significato del verbo provare(che non conosci): http://www.etimo.it/?term=provare&find=Cerca
tu sei simpatico e divertente, ma non hai ne il diritto ne tanto meno il titolo di dire certe cose di yossarin
lui ha ampiamente dimostrato negli anni di frequentazione di questo forum di avere conoscenze sulle architetture di GPU e CPU tali da essere quasi inimmaginabili per il resto degli utenti del forum (e non solo) e non si tratta di cazzate campate in aria, ma di una effettiva e precisa cultura al riguardo. una specifica cultura che tu devi ancora ampiamente dimostrare di avere
non credo che tu abbia idea di che contributo abbia dato yossarin alla crescita del forum spiegando con pazienza e nei dettagli, a chiunque lo chiedesse, argomenti per loro natura molto complessi. alrto che rovinare :rolleyes:
gli utenti che rovinano il forum sono altri... ... ...
:)
edit: ho visto che il disguido si è chiarito, meglio ;)
ecco ciò che sei ed ecco il motivo per cui nn porti prove
io dico cose sbagliate e tu cose giuste, ok!!
ma dimostramelo io sto qua aspetto te e non vedo perchè devo entrare in un thread tra g70 ed r520 visto che io sto parlando di M$, x-box,R500 (e non R520) e console :Prrr:
è la gente come te che rovina i forum, porta prove
significato del verbo provare(che non conosci): http://www.etimo.it/?term=provare&find=Cerca
tu sei simpatico e divertente, ma non hai ne il diritto ne tanto meno il titolo di dire certe cose di yossarin
lui ha ampiamente dimostrato negli anni di frequentazione di questo forum di avere conoscenze sulle architetture di GPU e CPU tali da essere quasi inimmaginabili per il resto degli utenti del forum (e non solo) e non si tratta di cazzate campate in aria, ma di una effettiva e precisa cultura al riguardo. una specifica cultura che tu devi ancora ampiamente dimostrare di avere
non credo che tu abbia idea di che contributo abbia dato yossarin alla crescita del forum spiegando con pazienza e nei dettagli, a chiunque lo chiedesse, argomenti per loro natura molto complessi. alrto che rovinare :rolleyes:
gli utenti che rovinano il forum sono altri... ... ...
:)
edit: ho visto che il disguido si è chiarito, meglio ;)
Manp
29-10-2005, 18:46
Correzione: yoss non puo' mettersi tranquillamente al tavolo con ingegneri ATI, yoss si e' gia' messo al tavolo con ingegneri ATI :D
:D
cmq, fek ho un favore da chiederti, mi diresti la tua su questa ipotesi:
http://www.hwupgrade.it/forum/showpost.php?p=10006577&postcount=6597
:)
:stordita:
:D
cmq, fek ho un favore da chiederti, mi diresti la tua su questa ipotesi:
http://www.hwupgrade.it/forum/showpost.php?p=10006577&postcount=6597
:)
:stordita:
yossarian
29-10-2005, 18:51
ringrazio tutti quanti per gli attestati di stima e per l'affetto dimostratomi; non pensavo di avere tanti amici :) e chiedo scusa per aver contribuito a portare OT il thread ;)
Ok, adesso che l'equivoco si è chiarito, prima che il thread diventi più melenso dell'ultima puntata di "vivere", cerchiamo di tornare IT (che non è il titolo di un noto romanzo di Stephen King da cui è stato tratto il film omonimo) :D
Ok, adesso che l'equivoco si è chiarito, prima che il thread diventi più melenso dell'ultima puntata di "vivere", cerchiamo di tornare IT (che non è il titolo di un noto romanzo di Stephen King da cui è stato tratto il film omonimo) :D
Maury
29-10-2005, 18:53
Correzione: yoss non puo' mettersi tranquillamente al tavolo con ingegneri ATI, yoss si e' gia' messo al tavolo con ingegneri ATI :D
si e immagino i loro bicchieri, pieno -> vuoto -> pieno -> vuoto -> pieno... alticci questi guru parlanoooooo di pipe, bus come se piovesse etc
:sofico:
si e immagino i loro bicchieri, pieno -> vuoto -> pieno -> vuoto -> pieno... alticci questi guru parlanoooooo di pipe, bus come se piovesse etc
:sofico:
Manp
29-10-2005, 18:55
ringrazio tutti quanti per gli attestati di stima e per l'affetto dimostratomi; non pensavo di avere tanti amici :) e chiedo scusa per aver contribuito a portare OT il thread ;)
forse perchè molti dei tuoi ammiratori si limitano a lurkare spaventati dalla complessità degli argomenti delle tue spiegazioni :stordita: :p (tra cui il sottoscritto :D )
anche se non per questo sono meno interessanti ;)
Ok, adesso che l'equivoco si è chiarito, prima che il thread diventi più melenso dell'ultima puntata di "vivere", cerchiamo di tornare IT (che non è il titolo di un noto romanzo di Stephen King da cui è stato tratto il film omonimo) :D
:asd:
forse perchè molti dei tuoi ammiratori si limitano a lurkare spaventati dalla complessità degli argomenti delle tue spiegazioni :stordita: :p (tra cui il sottoscritto :D )
anche se non per questo sono meno interessanti ;)
Ok, adesso che l'equivoco si è chiarito, prima che il thread diventi più melenso dell'ultima puntata di "vivere", cerchiamo di tornare IT (che non è il titolo di un noto romanzo di Stephen King da cui è stato tratto il film omonimo) :D
:asd:
Maury
29-10-2005, 18:57
(tra cui il sottoscritto :D )
:asd:
e io pure :sofico:
io ci trovo un nonchè di erotico in questi papiri teNNici :eek: :D
:asd:
e io pure :sofico:
io ci trovo un nonchè di erotico in questi papiri teNNici :eek: :D
luckye
29-10-2005, 19:08
Io ci trovo più o meno roba comprensibile :eek:
Come è possibile ?
Vabbè un minimo di informatica la conosco e pure un minimo di architettura.Gira e rigira sempre von neuman salta fuori :D
Come è possibile ?
Vabbè un minimo di informatica la conosco e pure un minimo di architettura.Gira e rigira sempre von neuman salta fuori :D
fek
29-10-2005, 19:09
si e immagino i loro bicchieri, pieno -> vuoto -> pieno -> vuoto -> pieno... alticci questi guru parlanoooooo di pipe, bus come se piovesse etc
:sofico:
Contribuisco all'OT :D
Perche' questa mi ricorda l'uscita a cena con ATI, alla quale fra gli altri ha partecipato il lead engineer dell'R520... un tipo pacioso e tranquillo, che alla seconda bottiglia in quattro di Bardolino non smetteva piu' di parlare :D
:sofico:
Contribuisco all'OT :D
Perche' questa mi ricorda l'uscita a cena con ATI, alla quale fra gli altri ha partecipato il lead engineer dell'R520... un tipo pacioso e tranquillo, che alla seconda bottiglia in quattro di Bardolino non smetteva piu' di parlare :D
yossarian
29-10-2005, 19:16
:D
:stordita:
per quanto riguarda il 5.1, si tratta della modalità minima prevista. Dal punto di vista HW non ci sono particolari problemi a gestire un 6.1 o un 7.1; dipenderà tutto da quello che decideranno di utilizzare gli sviluppatori
:stordita:
per quanto riguarda il 5.1, si tratta della modalità minima prevista. Dal punto di vista HW non ci sono particolari problemi a gestire un 6.1 o un 7.1; dipenderà tutto da quello che decideranno di utilizzare gli sviluppatori
yossarian
29-10-2005, 19:18
Contribuisco all'OT :D
Perche' questa mi ricorda l'uscita a cena con ATI, alla quale fra gli altri ha partecipato il lead engineer dell'R520... un tipo pacioso e tranquillo, che alla seconda bottiglia in quattro di Bardolino non smetteva piu' di parlare :D
pensavo lo reggesse meglio :D
Perche' questa mi ricorda l'uscita a cena con ATI, alla quale fra gli altri ha partecipato il lead engineer dell'R520... un tipo pacioso e tranquillo, che alla seconda bottiglia in quattro di Bardolino non smetteva piu' di parlare :D
pensavo lo reggesse meglio :D
Manp
29-10-2005, 20:08
per quanto riguarda il 5.1, si tratta della modalità minima prevista. Dal punto di vista HW non ci sono particolari problemi a gestire un 6.1 o un 7.1; dipenderà tutto da quello che decideranno di utilizzare gli sviluppatori
tnx ;)
avevo chiesto a fek perchè ho letto nel suo blog che in questi giorni stà smanettando col nuovo giocattolino (leggi devkit della xbox 360) :D
:)
tnx ;)
avevo chiesto a fek perchè ho letto nel suo blog che in questi giorni stà smanettando col nuovo giocattolino (leggi devkit della xbox 360) :D
:)
vaio-man
29-10-2005, 20:15
si 5.1 è il minimo, e viene tutto gestito da un singolo thread della cpu (xenon)
paura!!! :eek:
paura!!! :eek:
Free Gordon
29-10-2005, 22:32
Riguardo all'efficienza, tutte le recensioni hanno affermato che R520 è più efficiente di G70
Mi fai capire perchè R520 è più efficiente e mi linki una rece che lo dimostra? :stordita: (e tu mi dirai: e una fetta di culo no? :sofico: )
Mi fai capire perchè R520 è più efficiente e mi linki una rece che lo dimostra? :stordita: (e tu mi dirai: e una fetta di culo no? :sofico: )
Free Gordon
29-10-2005, 22:37
quando Xbox è stata annunciata ( e la conseguente partnership con Nvidia ufficializzata) per pc era l'era della gf2..
Ma poi hanno litigato per le royalties di Xbox... e Ms gliel'ha messa nel :ciapet: passando ad Ati. :D
Ma poi hanno litigato per le royalties di Xbox... e Ms gliel'ha messa nel :ciapet: passando ad Ati. :D
yossarian
29-10-2005, 23:41
Mi fai capire perchè R520 è più efficiente e mi linki una rece che lo dimostra? :stordita: (e tu mi dirai: e una fetta di culo no? :sofico: )
e una fetta di :ciapet: no? :sofico:
e una fetta di :ciapet: no? :sofico:
vaio-man
29-10-2005, 23:55
caro gordon, ecco qua: http://www.hwupgrade.it/articoli/skvideo/1361/index.html :D :cool:
Free Gordon
30-10-2005, 02:42
caro gordon, ecco qua: http://www.hwupgrade.it/articoli/skvideo/1361/index.html :D :cool:
Il fatto è proprio questo: quì http://www.hwupgrade.it/articoli/skvideo/1361/20.html mi pare che si affermi il contrario, o perlomeno ci sia un pareggio. ;)
Il fatto è proprio questo: quì http://www.hwupgrade.it/articoli/skvideo/1361/20.html mi pare che si affermi il contrario, o perlomeno ci sia un pareggio. ;)
vaio-man
30-10-2005, 09:18
l'architettura g70 in effeti è più efficiente nei calcoli semplici, ma questo nn è significativo in quanto una persona che compra questa scheda di sicuro non gioca con filtri disattivati, questo probabilmente dipende dall'architettura innovativa della scheda che non riesce a esprimere tutta la sua potenza in questo tipo di calcoli.
la cosa particolarmente interessante da notare è come la situazione si ribalta a favore di r520 nei calcoli con filtri attivi cioè la situazione + ricorrente con schede di questo tipo.
insomma ai progettisti ati interessava di + ottimizzare sia dal punto di vista hardware sia software la situazione solitamente + gravosa per la scheda video, i filtri
yossarian e fek se avete da fare precisazioni o correzioni, accomodatevi
la cosa particolarmente interessante da notare è come la situazione si ribalta a favore di r520 nei calcoli con filtri attivi cioè la situazione + ricorrente con schede di questo tipo.
insomma ai progettisti ati interessava di + ottimizzare sia dal punto di vista hardware sia software la situazione solitamente + gravosa per la scheda video, i filtri
yossarian e fek se avete da fare precisazioni o correzioni, accomodatevi
yossarian
30-10-2005, 11:24
Il fatto è proprio questo: quì http://www.hwupgrade.it/articoli/skvideo/1361/20.html mi pare che si affermi il contrario, o perlomeno ci sia un pareggio. ;)
http://www.digit-life.com/articles2/video/r520-part2.html
http://www.xbitlabs.com/articles/video/display/radeon-x1000_21.html
se guardi questi test sintetici, puoi renderti conto del fatto che, attualmente, la GTX sia in vantaggio solo nella gestione del calcolo matematico, in virtù della 48 unità MAD (contro le 16 MAD + 16 ADD) dell'R520. In tutti gli altri test, ad iniziare da quelli relativi a feature dello sm3.0 (come il dynamic branching) e, soprattutto, nei test che richiedono elaborazioni complesse (gestione di texture di grandi dimensioni, utilizzo di texture contemporaneamente a calcoli matematici, hsr, calcoli geometrici complessi), l'R520 è in vantaggio (anche nella versione XL), come è in vantaggio al crescere della risoluzione o quandi si iniziano ad utilizzare i filtri. Questo significa che la gestione delle varie funzionalità del chip è più efficiente rispetto a quella del G70. Al contrario, il G70 si avvantaggia nelle situazioni più semplici (dove può puntare sulla capacità di compiere un elevato numero di operazioni per ciclo, mentre il numero di operazioni per ciclo dell'R520 sono, volutamente, in numero molto minore) e nel puro calcolo matematico (grazie al maggior numero di unità di calcolo).
Non si tratta di situazioni "in game", ma sono, forse, ancora più indicativi, in quanto i giochi richiedono particolari ottimizzazioni che sull'R5x0 non possono ancora essere state fatte (tra l'altro, le possibilità di ottimizzare un chip con memory controller e dispatch processor completamente programmabili da driver, sono molto maggiori di quelle che si possono fare su un chip tradizionale, come mostrano gli incrementi ottenuti con una sola patch, che hanno portato R520 ad essere addirittura in vantaggio, rispetto a G70, in Doom3 e Quake4, soprattutto con filtri attivi e ad alte risoluzioni).
Altro appunto: il rapporto bandwidth/fillrate è vantaggioso per G70 (5,8 contro 4,8 della XT e 4 della XL); questo dovrebbe significare, a rigor di logica, che, al crescere della risoluzione e utilizzando i filtri, a dispetto della maggior banda passante assoluta, R520 dovrebbe essere maggiormente penalizzato rispetto a G70; invece accade l'esatto contrario. Questo può solo significare che l'architettura di r520 è meglio bilanciata, che l'accesso alla vram è più efficiente e che gli algoritmi di compressione dati utilizzati sono superiori (ma questo era già evidente con la precedente generazione).
Infine, facciamo il punto sul discorso efficienza/frequenza. Sulla base dell'efficienza a parità di frequenza ha senso comparare due chip con architettura e, soprattutto, logica di funzionamento uguale (ad esempio, ha senso il paragone athlon vs pentium o quello NV40 vs R4x0 vs G70). In questo caso, invece, ci si trova di fronte un chip, il G70, che utilizza istruzioni complesse, grandi batch di dati e fa circolare un gran numero di pixel all'interno delle pipeline, puntando sulla quantità di operazioni totali compiute (648 flops/clock per G70 contro 192 per R520, teoriche con, in più, in G70, altri pixel all'interno all'interno delle pipeline, messi in coda in attesa di elaborazione), dall'altro, un chip che compie un numero limitato di operazioni, puntando, però sull'efficenza massima delle stesse; mi spiego meglio: G70 è capace di un massimo di 648 flops/ciclo teoriche (escluse le operazioni di texture fetch); questo presuppone che tutte le unità di calcolo siano impegnate sempre a fare qualcosa; nella pratica, una pipeline lunga, articolata con registri dedicati alla singola unità, di tipo a mappatura diretta, raggiunge un'efficienza complessiva di circa il 50-55%; questo significa che, delle 648 operazioni complessive (27 per pipeline), se ne compiono, in realtà, tra le 324 e le 380 per ogni ciclo; al contrario, un'architettura come quella delle pixel pipeline di R520, può arrivare molto vicina al suo valore teorico massimo. Se poi, consideri che R520, al pari dei suoi predecessori, ha la possibilità di fare texture fetch senza rendere quasi del tutto inutilizzabile la prima delle due alu (cosa che accade in G70, dove alu e tmu dipendono l'una dall'altra), puoi renderti conto che, mentre in G70 si cala dalle 380 operazioni per ciclo a, circa 160 (considerando un 60% di efficacia per le operazioni di textre fetch), a cui vanno aggiunte le operazioni di texturing, su R520 il numero di operazioni complessive, al contrario, aumenta, anche grazie al fatto che le tmu non sono integrate nelle pipeline di rendering e la dipendenza nelle elaborazioni (attesa di dati in arrivo da un'altra unità) è molto minore. Non è un caso che, se guardi i test di digit life, relativi al pixel fillrate con texture, ti rendoi conto che la GTX è sempre sotto, anche rispetto alla XL (che pure ha frequenze di clock non troppo distanti), mentre il vantaggio della GTX nei soli calcoli matematici, è ben lontano dall'essere superiore di quasi il 240%, come, invece, lascerebbero supporre i dati teorici
p.s. stavolta, fine OT sul serio; ho aperto un thread su G70 e R520; quindi per qualunque cosa, iscrivetevi là
http://www.digit-life.com/articles2/video/r520-part2.html
http://www.xbitlabs.com/articles/video/display/radeon-x1000_21.html
se guardi questi test sintetici, puoi renderti conto del fatto che, attualmente, la GTX sia in vantaggio solo nella gestione del calcolo matematico, in virtù della 48 unità MAD (contro le 16 MAD + 16 ADD) dell'R520. In tutti gli altri test, ad iniziare da quelli relativi a feature dello sm3.0 (come il dynamic branching) e, soprattutto, nei test che richiedono elaborazioni complesse (gestione di texture di grandi dimensioni, utilizzo di texture contemporaneamente a calcoli matematici, hsr, calcoli geometrici complessi), l'R520 è in vantaggio (anche nella versione XL), come è in vantaggio al crescere della risoluzione o quandi si iniziano ad utilizzare i filtri. Questo significa che la gestione delle varie funzionalità del chip è più efficiente rispetto a quella del G70. Al contrario, il G70 si avvantaggia nelle situazioni più semplici (dove può puntare sulla capacità di compiere un elevato numero di operazioni per ciclo, mentre il numero di operazioni per ciclo dell'R520 sono, volutamente, in numero molto minore) e nel puro calcolo matematico (grazie al maggior numero di unità di calcolo).
Non si tratta di situazioni "in game", ma sono, forse, ancora più indicativi, in quanto i giochi richiedono particolari ottimizzazioni che sull'R5x0 non possono ancora essere state fatte (tra l'altro, le possibilità di ottimizzare un chip con memory controller e dispatch processor completamente programmabili da driver, sono molto maggiori di quelle che si possono fare su un chip tradizionale, come mostrano gli incrementi ottenuti con una sola patch, che hanno portato R520 ad essere addirittura in vantaggio, rispetto a G70, in Doom3 e Quake4, soprattutto con filtri attivi e ad alte risoluzioni).
Altro appunto: il rapporto bandwidth/fillrate è vantaggioso per G70 (5,8 contro 4,8 della XT e 4 della XL); questo dovrebbe significare, a rigor di logica, che, al crescere della risoluzione e utilizzando i filtri, a dispetto della maggior banda passante assoluta, R520 dovrebbe essere maggiormente penalizzato rispetto a G70; invece accade l'esatto contrario. Questo può solo significare che l'architettura di r520 è meglio bilanciata, che l'accesso alla vram è più efficiente e che gli algoritmi di compressione dati utilizzati sono superiori (ma questo era già evidente con la precedente generazione).
Infine, facciamo il punto sul discorso efficienza/frequenza. Sulla base dell'efficienza a parità di frequenza ha senso comparare due chip con architettura e, soprattutto, logica di funzionamento uguale (ad esempio, ha senso il paragone athlon vs pentium o quello NV40 vs R4x0 vs G70). In questo caso, invece, ci si trova di fronte un chip, il G70, che utilizza istruzioni complesse, grandi batch di dati e fa circolare un gran numero di pixel all'interno delle pipeline, puntando sulla quantità di operazioni totali compiute (648 flops/clock per G70 contro 192 per R520, teoriche con, in più, in G70, altri pixel all'interno all'interno delle pipeline, messi in coda in attesa di elaborazione), dall'altro, un chip che compie un numero limitato di operazioni, puntando, però sull'efficenza massima delle stesse; mi spiego meglio: G70 è capace di un massimo di 648 flops/ciclo teoriche (escluse le operazioni di texture fetch); questo presuppone che tutte le unità di calcolo siano impegnate sempre a fare qualcosa; nella pratica, una pipeline lunga, articolata con registri dedicati alla singola unità, di tipo a mappatura diretta, raggiunge un'efficienza complessiva di circa il 50-55%; questo significa che, delle 648 operazioni complessive (27 per pipeline), se ne compiono, in realtà, tra le 324 e le 380 per ogni ciclo; al contrario, un'architettura come quella delle pixel pipeline di R520, può arrivare molto vicina al suo valore teorico massimo. Se poi, consideri che R520, al pari dei suoi predecessori, ha la possibilità di fare texture fetch senza rendere quasi del tutto inutilizzabile la prima delle due alu (cosa che accade in G70, dove alu e tmu dipendono l'una dall'altra), puoi renderti conto che, mentre in G70 si cala dalle 380 operazioni per ciclo a, circa 160 (considerando un 60% di efficacia per le operazioni di textre fetch), a cui vanno aggiunte le operazioni di texturing, su R520 il numero di operazioni complessive, al contrario, aumenta, anche grazie al fatto che le tmu non sono integrate nelle pipeline di rendering e la dipendenza nelle elaborazioni (attesa di dati in arrivo da un'altra unità) è molto minore. Non è un caso che, se guardi i test di digit life, relativi al pixel fillrate con texture, ti rendoi conto che la GTX è sempre sotto, anche rispetto alla XL (che pure ha frequenze di clock non troppo distanti), mentre il vantaggio della GTX nei soli calcoli matematici, è ben lontano dall'essere superiore di quasi il 240%, come, invece, lascerebbero supporre i dati teorici
p.s. stavolta, fine OT sul serio; ho aperto un thread su G70 e R520; quindi per qualunque cosa, iscrivetevi là
Coyote74
30-10-2005, 11:43
Questo può solo significare che l'architettura di r520 è meglio bilanciata, che l'accesso alla vram è più efficiente e che gli algoritmi di compressione dati utilizzati sono superiori (ma questo era già evidente con la precedente generazione).
Però non sarebbe anche da dire che le schede basate su r520 utilizzano una memoria video molto più performante e costosa di quella implementata sulle G70? E da questo punto di vista nulla vieta alla nVidia di poter montare chip simili e recuperare così molto del gap lasciato per strada. O sbaglio?
Però non sarebbe anche da dire che le schede basate su r520 utilizzano una memoria video molto più performante e costosa di quella implementata sulle G70? E da questo punto di vista nulla vieta alla nVidia di poter montare chip simili e recuperare così molto del gap lasciato per strada. O sbaglio?
yossarian
30-10-2005, 11:56
Però non sarebbe anche da dire che le schede basate su r520 utilizzano una memoria video molto più performante e costosa di quella implementata sulle G70? E da questo punto di vista nulla vieta alla nVidia di poter montare chip simili e recuperare così molto del gap lasciato per strada. O sbaglio?
sbagli: allo stato attuale, il limite gel G70 non è la bandwidth (come dimostra CoR che è uno dei giochi più bandwidth limited); non almeno nella maggior parte dei casi. G70 ha 24 pp ma solo 16 rop's e ha, di conseguenza, un fillrate teorico (e anche pratico, nel caso del fillrate puro) uguale a quello della 6800 Ultra e molto vicino al suo limite teorico (6880 MPixel/sec è quello teorico, 64xx quello reale). Oltretutto, ha un rapporto banda/fillrate superiore a quello della XT (nonostante i 1500 Mhz), quindi il solo aumento del quantitativo e della frequenza della ram porterebbe, tranne che in rari casi, al solo aumento del prezzo della vga. Per recuperare il gap, deve aumentare anche la frequenza del chip e, quindi, il numero di operazioni al secondo e il fillrate massimo. Altrimenti, anche con ram da 6 Ghz, più di 6880 MPixel/sec il G70 non può fornire.
sbagli: allo stato attuale, il limite gel G70 non è la bandwidth (come dimostra CoR che è uno dei giochi più bandwidth limited); non almeno nella maggior parte dei casi. G70 ha 24 pp ma solo 16 rop's e ha, di conseguenza, un fillrate teorico (e anche pratico, nel caso del fillrate puro) uguale a quello della 6800 Ultra e molto vicino al suo limite teorico (6880 MPixel/sec è quello teorico, 64xx quello reale). Oltretutto, ha un rapporto banda/fillrate superiore a quello della XT (nonostante i 1500 Mhz), quindi il solo aumento del quantitativo e della frequenza della ram porterebbe, tranne che in rari casi, al solo aumento del prezzo della vga. Per recuperare il gap, deve aumentare anche la frequenza del chip e, quindi, il numero di operazioni al secondo e il fillrate massimo. Altrimenti, anche con ram da 6 Ghz, più di 6880 MPixel/sec il G70 non può fornire.
Coyote74
30-10-2005, 11:58
sbagli: allo stato attuale, il limite gel G70 non è la bandwidth; non almeno nella maggior parte dei casi. G70 ha 24 pp ma solo 16 rop's e ha, di conseguenza, un fillrate teorico (e anche pratico, nel caso del fillrate puro) uguale a quello della 6800 Ultra e molto vicino al suo limite teorico (6880 MPixel/sec è quello teorico, 64xx quello reale). Oltretutto, ha un rapporto banda/fillrate superiore a quello della XT (nonostante i 1500 Mhz), quindi il solo aumento del quantitativo e della frequenza della ram porterebbe, tranne che in rari casi, al solo aumento del prezzo della vga. Per recuperare il gap, deve aumentare anche la frequenza del chip e, quindi, il numero di operazioni al secondo e il fillrate massimo. Altrimenti, anche con ram da 6 Ghz, più di 6880 MPixel/sec il G70 non può fornire.
Thanks ;)
Thanks ;)
yossarian
30-10-2005, 12:04
Thanks ;)
aggiungo solo che il fillrate teorico della X1800XT è di 10000 e, di conseguenza, l'utilizzo di ram molto performati erano una scelta obbligata (per bene che si possano gestire gli accessi in memoria, una bandwidth adeguata, comunque serve e, con ram da 1200 Mhz, il rapporto banda/fillrate sarebbe stato pari a 3,8); inoltre, riguarda al G70, la rev2 sale in frequenza decisamente meglio nrispetto alla rev1; per cui è lecito aspettarsi un sostanzioso overclock del chip
aggiungo solo che il fillrate teorico della X1800XT è di 10000 e, di conseguenza, l'utilizzo di ram molto performati erano una scelta obbligata (per bene che si possano gestire gli accessi in memoria, una bandwidth adeguata, comunque serve e, con ram da 1200 Mhz, il rapporto banda/fillrate sarebbe stato pari a 3,8); inoltre, riguarda al G70, la rev2 sale in frequenza decisamente meglio nrispetto alla rev1; per cui è lecito aspettarsi un sostanzioso overclock del chip
Free Gordon
30-10-2005, 14:57
p.s. stavolta, fine OT sul serio; ho aperto un thread su G70 e R520; quindi per qualunque cosa, iscrivetevi là
Mi hai fatto comprendere meglio le motivazioni che stanno dietro alla maggiore efficienza di R520.
Grazie mille! :D
C'è ancora qualche parte oscura (come si realizza fiscamente il texture fetch? Perchè assorbe così tanta potenza?) ma il succo l'ho capito! ;)
Mi hai fatto comprendere meglio le motivazioni che stanno dietro alla maggiore efficienza di R520.
Grazie mille! :D
C'è ancora qualche parte oscura (come si realizza fiscamente il texture fetch? Perchè assorbe così tanta potenza?) ma il succo l'ho capito! ;)
yossarian
30-10-2005, 15:09
Mi hai fatto comprendere meglio le motivazioni che stanno dietro alla maggiore efficienza di R520.
Grazie mille! :D
C'è ancora qualche parte oscura (come si realizza fiscamente il texture fetch? Perchè assorbe così tanta potenza?) ma il succo l'ho capito! ;)
il texture fetch non assorbe potenza: è semplicemente il caricamento dei dati relativi ad una texture, all'interno della tmu. Il problema è che, da NV3x in poi (quindi anche G70), le architetture dei chip NV sono tali per cui la prima delle due alu funge anche da texture unit; per cui, in un cilco, o esegue calcoli matematici o si occupa delle texture (nel qual caso, la potenza nei calcoli matematici di G70 risulta pressochè dimezzata); al contrario, nei chip ATi tmu e alu sono, da sempre, indipendenti, per cui il chip può eseguire entrambe le operazioni nello stesso ciclo, senza perdere potenza di calcolo.
Grazie mille! :D
C'è ancora qualche parte oscura (come si realizza fiscamente il texture fetch? Perchè assorbe così tanta potenza?) ma il succo l'ho capito! ;)
il texture fetch non assorbe potenza: è semplicemente il caricamento dei dati relativi ad una texture, all'interno della tmu. Il problema è che, da NV3x in poi (quindi anche G70), le architetture dei chip NV sono tali per cui la prima delle due alu funge anche da texture unit; per cui, in un cilco, o esegue calcoli matematici o si occupa delle texture (nel qual caso, la potenza nei calcoli matematici di G70 risulta pressochè dimezzata); al contrario, nei chip ATi tmu e alu sono, da sempre, indipendenti, per cui il chip può eseguire entrambe le operazioni nello stesso ciclo, senza perdere potenza di calcolo.
Free Gordon
30-10-2005, 15:35
il texture fetch non assorbe potenza: è semplicemente il caricamento dei dati relativi ad una texture, all'interno della tmu. Il problema è che, da NV3x in poi (quindi anche G70), le architetture dei chip NV sono tali per cui la prima delle due alu funge anche da texture unit; per cui, in un cilco, o esegue calcoli matematici o si occupa delle texture (nel qual caso, la potenza nei calcoli matematici di G70 risulta pressochè dimezzata); al contrario, nei chip ATi tmu e alu sono, da sempre, indipendenti, per cui il chip può eseguire entrambe le operazioni nello stesso ciclo, senza perdere potenza di calcolo.
Ah, capito! ;)
Grazie dello spiegone ad un povero mortale! :D
Ora ti ho fatto una domanda di là, se vuoi rispondere... :sofico:
Ciauuu
Ah, capito! ;)
Grazie dello spiegone ad un povero mortale! :D
Ora ti ho fatto una domanda di là, se vuoi rispondere... :sofico:
Ciauuu
vaio-man
30-10-2005, 18:37
no yossarian, che io sappia e che sappia anche HWU ( http://www.hwupgrade.it/articoli/skvideo/1361/index.html ) il fillrate teorico della 7800 gtx è di 10320 Mtexel/s, è solo una precisazione, il tuo discorso non fa una piega, anche se io l'ho detto con parole + mortali :D
Manp
30-10-2005, 18:46
infatti la scheda della rece di HWUpgrade è canata :D
Reference card GeForce 7800 GTX specifications
* Core clock: 430 MHz
* Effective memory frequency: 1.2 GHz (2*600 MHz)
* Memory type: GDDR-3, 1.6ns
* Memory: 256 MB (there will be modifications with 512MB, because our sample provides seats for 512 MB of memory)
* Memory bandwidth: 38.4 GB/sec.
* Maximum theoretical fillrate: 6.9 gigapixel per second
* Theoretical texture sampling rate: 10.4 gigatexel per second
* 2 x DVI-I connectors
* SLI connector
* PCI-Express 16x bus
* TV-Out, HDTV-Out, HDCP support
* Power consumption: up to 110W (typical power consumption is below 100W, the card is equipped with one standard power connector for PCI Express, recommended PSUs should be 350W, 500W for SLI mode).
http://www.digit-life.com/articles2/video/g70-part1.html
credo, poi yoss ci dirà
:)
Reference card GeForce 7800 GTX specifications
* Core clock: 430 MHz
* Effective memory frequency: 1.2 GHz (2*600 MHz)
* Memory type: GDDR-3, 1.6ns
* Memory: 256 MB (there will be modifications with 512MB, because our sample provides seats for 512 MB of memory)
* Memory bandwidth: 38.4 GB/sec.
* Maximum theoretical fillrate: 6.9 gigapixel per second
* Theoretical texture sampling rate: 10.4 gigatexel per second
* 2 x DVI-I connectors
* SLI connector
* PCI-Express 16x bus
* TV-Out, HDTV-Out, HDCP support
* Power consumption: up to 110W (typical power consumption is below 100W, the card is equipped with one standard power connector for PCI Express, recommended PSUs should be 350W, 500W for SLI mode).
http://www.digit-life.com/articles2/video/g70-part1.html
credo, poi yoss ci dirà
:)
Ren
30-10-2005, 18:54
Texture fillrate e color fillrate sono due cose differenti.
Le rop's che si occupano di scrivere i pixel nel f-buffer sono le responsabili del MSAA.
Perciò alla fine le maggiori richieste di banda provengono dal color fillrate...
R520
16tu x 625 =10k
16rop x 325 =10k
G70
24pipe x 430 =10,6k
16rop x 430 =6,8k
Le rop's che si occupano di scrivere i pixel nel f-buffer sono le responsabili del MSAA.
Perciò alla fine le maggiori richieste di banda provengono dal color fillrate...
R520
16tu x 625 =10k
16rop x 325 =10k
G70
24pipe x 430 =10,6k
16rop x 430 =6,8k
vaio-man
30-10-2005, 18:55
no è giusto, comunque questo è un dato teorico eh :D
http://www.nvidia.com/page/specs_gf7800.html
http://www.nvidia.com/page/specs_gf7800.html
yossarian
30-10-2005, 19:15
no yossarian, che io sappia e che sappia anche HWU ( http://www.hwupgrade.it/articoli/skvideo/1361/index.html ) il fillrate teorico della 7800 gtx è di 10320 Mtexel/s, è solo una precisazione, il tuo discorso non fa una piega, anche se io l'ho detto con parole + mortali :D
conosco i dati riportati sulla rece di HWUpgrade e sul sito di nVIDIA; però ti assicuro che il pixel fillrate di G70 è 6880 MPixel/sec.
Bsasta guardare anche il dato sul fillrate reale (64xx) per rendersi conto di quanto si sia lontani dai 10320. Non solo, ma il pixel fillrate si misura partendo dal numero di rop's, con un conteggio analogo a quello mostrato da Ren.
questi sono i test della 7800 GTX relativi al fillrate
vi invito a guardare il primo grafico e, in particolare, i due test: pure fillrate e z-fillrate.
http://www.xbitlabs.com/articles/video/display/radeon-x1000_20.html
per chi conosce l'architettura dei chip NV sa che, fin dall'NV30, il fillrate, con sole z-ops, si raddoppia; bene, il pure fillrate è oari a 64xx e lo z fillrate è uguale a 128xx; inoltre, se si confrontano questi dati, con gli analoghi dell'NV40, si può vedere che questi due valori sono perfettamente sovrapposti. Quindi, la conclusioneè che il fillrate dipende dal numero di rop's (16 per G70 e NV40) e dalla frequenza.
Quindi, benchè i 10320 siano un dato teorico, sono comunque un dato teorico sbagliato e fuorviante per chi si aspetta veramente un simile fillrate
conosco i dati riportati sulla rece di HWUpgrade e sul sito di nVIDIA; però ti assicuro che il pixel fillrate di G70 è 6880 MPixel/sec.
Bsasta guardare anche il dato sul fillrate reale (64xx) per rendersi conto di quanto si sia lontani dai 10320. Non solo, ma il pixel fillrate si misura partendo dal numero di rop's, con un conteggio analogo a quello mostrato da Ren.
questi sono i test della 7800 GTX relativi al fillrate
vi invito a guardare il primo grafico e, in particolare, i due test: pure fillrate e z-fillrate.
http://www.xbitlabs.com/articles/video/display/radeon-x1000_20.html
per chi conosce l'architettura dei chip NV sa che, fin dall'NV30, il fillrate, con sole z-ops, si raddoppia; bene, il pure fillrate è oari a 64xx e lo z fillrate è uguale a 128xx; inoltre, se si confrontano questi dati, con gli analoghi dell'NV40, si può vedere che questi due valori sono perfettamente sovrapposti. Quindi, la conclusioneè che il fillrate dipende dal numero di rop's (16 per G70 e NV40) e dalla frequenza.
Quindi, benchè i 10320 siano un dato teorico, sono comunque un dato teorico sbagliato e fuorviante per chi si aspetta veramente un simile fillrate
vaio-man
30-10-2005, 19:19
si ma quello reale è di 64xx, io parlo di quello teorico
se così non fosse la g70 sarebbe la + grande in :ciapet: ata dalla serie fx, + pippe,+ frequenza e stesso fillrate teorico e reale? non penso
se così non fosse la g70 sarebbe la + grande in :ciapet: ata dalla serie fx, + pippe,+ frequenza e stesso fillrate teorico e reale? non penso
yossarian
30-10-2005, 19:29
si ma quello reale è di 64xx, io parlo di quello teorico
se così non fosse la g70 sarebbe la + grande in :ciapet: ata dalla serie fx, + pippe,+ frequenza e stesso fillrate teorico e reale? non penso
il fillrate teorico si calcola facendo il prodotto numero di rop's*frequenza del chip. Sono le rop's che "scrivono" i pixel nel fb; se anche hai 64 pixel pipeline, ma solo 16 rop's, avrai sempre lo stesso fillrate teorico di un chip 16/16 alla stessa frequenza.
la GF6800 Ultra è 425/1100 e ha 16 rop's; il suo valore teorico è 6800, il suo valore pratico è 64xx.
G70 è 430/1200 con 16 rop's; il suo valore teorico è 6880, quello reale è 64xx, perfettamente in linea con quanto avviene con la 6800 Ultra.
La 7800 si avvantaggia sulla 6800 quando si ha a che fare con calcoli più complessi, poichè, grazie al potenziamento delle unità matematiche e alle 8 pipeline in più, riesce a inviare dati alle rop's più velocemente (quindi le rop's restano inattive per meno tempo rispetto a quelle di NV40)
se così non fosse la g70 sarebbe la + grande in :ciapet: ata dalla serie fx, + pippe,+ frequenza e stesso fillrate teorico e reale? non penso
il fillrate teorico si calcola facendo il prodotto numero di rop's*frequenza del chip. Sono le rop's che "scrivono" i pixel nel fb; se anche hai 64 pixel pipeline, ma solo 16 rop's, avrai sempre lo stesso fillrate teorico di un chip 16/16 alla stessa frequenza.
la GF6800 Ultra è 425/1100 e ha 16 rop's; il suo valore teorico è 6800, il suo valore pratico è 64xx.
G70 è 430/1200 con 16 rop's; il suo valore teorico è 6880, quello reale è 64xx, perfettamente in linea con quanto avviene con la 6800 Ultra.
La 7800 si avvantaggia sulla 6800 quando si ha a che fare con calcoli più complessi, poichè, grazie al potenziamento delle unità matematiche e alle 8 pipeline in più, riesce a inviare dati alle rop's più velocemente (quindi le rop's restano inattive per meno tempo rispetto a quelle di NV40)
vaio-man
30-10-2005, 19:39
ok, capit, ma allora perchè ne danno un valore + alto?
e poi anche la x850xt ha 16 rops, così come tutte le altre schede di fascia alta della nuova e della vecchia generazione, non è che nel loro calcolo tengono conto anche di altro? perchè per assurdo la x850xt a parità di rops, dovrebbe avere un fillrate + alto anche della 7800 gtx avendo + Mhz :p
e poi anche la x850xt ha 16 rops, così come tutte le altre schede di fascia alta della nuova e della vecchia generazione, non è che nel loro calcolo tengono conto anche di altro? perchè per assurdo la x850xt a parità di rops, dovrebbe avere un fillrate + alto anche della 7800 gtx avendo + Mhz :p
*sasha ITALIA*
30-10-2005, 19:43
Posso dire una cosa? Vabbè che è un thread aperto appunto per discutere delle differenze tecniche ma sinceramente inutile scervellarsi così :D
Manp
30-10-2005, 19:46
Vabbè che è un thread aperto appunto per discutere delle differenze tecniche ma sinceramente inutile scervellarsi così :D
tu ragione :p
tu ragione :p
*sasha ITALIA*
30-10-2005, 19:49
cioè quando comincio a leggere fill rate e menate simili mi pare che raggiungiamo livelli inutili :D Sono entrambe console da gioco, simili per potenza e probabilmente per risultati. Stop, aspettiamo e divertiamoci senza contare i poligoni di differenza tra loro.. io la penso così
yossarian
30-10-2005, 19:53
ok, capit, ma allora perchè ne danno un valore + alto?
e poi anche la x850xt ha 16 rops, così come tutte le altre schede di fascia alta della nuova e della vecchia generazione, non è che nel loro calcolo tengono conto anche di altro? perchè per assurdo la x850xt a parità di rops, dovrebbe avere un fillrate + alto anche della 7800 gtx avendo + Mhz :p
infatti, questo è uno dei motivi per cui l'architettura di NV40/G70 può definirsi più efficiente di quella di R4x0. La X850XT ha un fillrate teorico più alto rispetto alla 7800 GTX ma, in pratica, fa segnare un valore inferiore perchè la sua architettura è meno efficiente (lo scostamento del valore reale da quello teorico è già un primo indice dell'efficienza di un chip, visto che pure fillrate e z-fillrate sono le operazioni più semplici da compiere)
e poi anche la x850xt ha 16 rops, così come tutte le altre schede di fascia alta della nuova e della vecchia generazione, non è che nel loro calcolo tengono conto anche di altro? perchè per assurdo la x850xt a parità di rops, dovrebbe avere un fillrate + alto anche della 7800 gtx avendo + Mhz :p
infatti, questo è uno dei motivi per cui l'architettura di NV40/G70 può definirsi più efficiente di quella di R4x0. La X850XT ha un fillrate teorico più alto rispetto alla 7800 GTX ma, in pratica, fa segnare un valore inferiore perchè la sua architettura è meno efficiente (lo scostamento del valore reale da quello teorico è già un primo indice dell'efficienza di un chip, visto che pure fillrate e z-fillrate sono le operazioni più semplici da compiere)
vaio-man
30-10-2005, 21:45
quindi mi stai confermando che per il calcolo del fillrate ati e nvidia non tengono conto solo di rops e frequenza, ma anche di altri fattori, e che il calgolo che hai fatto tu è la tecnica per noi poveri,comuni mortali
yossarian
30-10-2005, 21:54
quindi mi stai confermando che per il calcolo del fillrate ati e nvidia non tengono conto solo di rops e frequenza, ma anche di altri fattori, e che il calgolo che hai fatto tu è la tecnica per noi poveri,comuni mortali
no, è il contrario: il calcolo teorico tiene conto solo del numero di rop's e della frequenza del chip. Quindi la X850XT PE ha un fillrate teorico di 8640, mentre la GTX ha un fillrate teorico di 6880.
In pratica, la 7800GTX arriva a 64xx (molto vicina al suo valore teorico; la X850 arriva a circa 63xx (molto lontana dal suo valore teorico. Anche volendo tener conto del fatto che la X850 risulta maggiormente limitata in banda, ci sono sicuramente altri fattori che le impediscono di avvicinarsi al suo valore teorico, ostacolando un'efficace circolazione dei dati all'interno delle pipeline.
Però, per il calcolo teorico, si tiene conto solo di rop's e frequenze e niente altro. I valori reali sono quelli che si rilevano con i bench sintetici che testano il fillrate dei chip (e sono sempre inferiori a quelli teorici).
Le rop's sono come i caselli autostradali; da ogni rop's, in teoria, può uscire un solo pixel per ciclo. 16 rop's=16 pixel in un singolo ciclo. La frequenza è indice della velocità con cui i pixel escono dalle rop's. 430 Mhz significa che, in un secondo, da ogni rop's escono 430 milioni di pixel; se le rop's sono 16, si avrà che, in un secondo, usciranno 430 (milioni)*16 pixel. Al pari di un casello, se arrivano più macchine ne esce sempre una per volta. Le pixel pipeline, invece, mandano i pixel alle rop's, ma non sono abilitate a farli uscire dal chip. Quindi, se ho 48 pipeline che mandano, per ipotesi, 48 chip per ogni ciclo, ma ho solo 16 rop's, saranno, comunque, sempre 16 i pixel che usciranno in un ciclo (gli altri 32 si mettono in coda, come sull'autostrada quando tante macchine arrivano al casello).
no, è il contrario: il calcolo teorico tiene conto solo del numero di rop's e della frequenza del chip. Quindi la X850XT PE ha un fillrate teorico di 8640, mentre la GTX ha un fillrate teorico di 6880.
In pratica, la 7800GTX arriva a 64xx (molto vicina al suo valore teorico; la X850 arriva a circa 63xx (molto lontana dal suo valore teorico. Anche volendo tener conto del fatto che la X850 risulta maggiormente limitata in banda, ci sono sicuramente altri fattori che le impediscono di avvicinarsi al suo valore teorico, ostacolando un'efficace circolazione dei dati all'interno delle pipeline.
Però, per il calcolo teorico, si tiene conto solo di rop's e frequenze e niente altro. I valori reali sono quelli che si rilevano con i bench sintetici che testano il fillrate dei chip (e sono sempre inferiori a quelli teorici).
Le rop's sono come i caselli autostradali; da ogni rop's, in teoria, può uscire un solo pixel per ciclo. 16 rop's=16 pixel in un singolo ciclo. La frequenza è indice della velocità con cui i pixel escono dalle rop's. 430 Mhz significa che, in un secondo, da ogni rop's escono 430 milioni di pixel; se le rop's sono 16, si avrà che, in un secondo, usciranno 430 (milioni)*16 pixel. Al pari di un casello, se arrivano più macchine ne esce sempre una per volta. Le pixel pipeline, invece, mandano i pixel alle rop's, ma non sono abilitate a farli uscire dal chip. Quindi, se ho 48 pipeline che mandano, per ipotesi, 48 chip per ogni ciclo, ma ho solo 16 rop's, saranno, comunque, sempre 16 i pixel che usciranno in un ciclo (gli altri 32 si mettono in coda, come sull'autostrada quando tante macchine arrivano al casello).
vaio-man
30-10-2005, 22:43
ok, tutto giusto e tutta roba che sapevo
il mio dubbio è un altro,com'è che la nvidia ne dichiara teorici per il g70 10320 e invece per la nv40 ne dichiara 6800, se poi invece hanno entrambe 6800?
qua c'è qualcosa che contradice quello che dici: http://www.hwupgrade.it/articoli/skvideo/1311/17.html
l'ho esposto nel modo + semplice altrimenti poi non ci capiamo e si pensa che voglio scatenare casini per forza ;) :)
il mio dubbio è un altro,com'è che la nvidia ne dichiara teorici per il g70 10320 e invece per la nv40 ne dichiara 6800, se poi invece hanno entrambe 6800?
qua c'è qualcosa che contradice quello che dici: http://www.hwupgrade.it/articoli/skvideo/1311/17.html
l'ho esposto nel modo + semplice altrimenti poi non ci capiamo e si pensa che voglio scatenare casini per forza ;) :)
yossarian
30-10-2005, 22:51
ok, tutto giusto e tutta roba che sapevo
il mio dubbio è un altro,com'è che la nvidia ne dichiara teorici per il g70 10320 e invece per la nv40 ne dichiara 6800, se poi invece hanno entrambe 6800?
l'ho esposto nel modo + semplice altrimenti poi non ci capiamo e si pensa che voglio scatenare casini per forza ;) :)
questo dovresti chiederlo a quelli di nVIDIA; io mi sto limitando a dirti come si calcola il pixel fillrate (teorico). Il calcolo che fa nVIDIA si basa sul numero delle pixel pipeline: 24*430=10320; ma non è corretto, perchè l'output non è fornito dalle pixel pipeline ma dalle rop's.
il mio dubbio è un altro,com'è che la nvidia ne dichiara teorici per il g70 10320 e invece per la nv40 ne dichiara 6800, se poi invece hanno entrambe 6800?
l'ho esposto nel modo + semplice altrimenti poi non ci capiamo e si pensa che voglio scatenare casini per forza ;) :)
questo dovresti chiederlo a quelli di nVIDIA; io mi sto limitando a dirti come si calcola il pixel fillrate (teorico). Il calcolo che fa nVIDIA si basa sul numero delle pixel pipeline: 24*430=10320; ma non è corretto, perchè l'output non è fornito dalle pixel pipeline ma dalle rop's.
Manp
30-10-2005, 22:55
questo dovresti chiederlo a quelli di nVIDIA; io mi sto limitando a dirti come si calcola il pixel fillrate (teorico). Il calcolo che fa nVIDIA si basa sul numero delle pixel pipeline: 24*430=10320; ma non è corretto, perchè l'output non è fornito dalle pixel pipeline ma dalle rop's.
sarebbe questo:
Theoretical texture sampling rate: 10.4 gigatexel per second
?
si avvicina molto a quei 10k :stordita:
:)
sarebbe questo:
Theoretical texture sampling rate: 10.4 gigatexel per second
?
si avvicina molto a quei 10k :stordita:
:)
vaio-man
30-10-2005, 23:02
scusa me se non è correto, com'è che il 3d mark da 10100 in multitexturing?
sbaglia anche il 3d mark adesso? :mbe:
facendo due conti vedo che anche la ati usa quel calcolo, se sbagliano anche loro, di a entrambe di licenziare i loro ingegneri perchè si sono laureati alla cepu :D
a proposito l'output non viene dalle rops, loro caricano tutto nel frame buffer ;)
sbaglia anche il 3d mark adesso? :mbe:
facendo due conti vedo che anche la ati usa quel calcolo, se sbagliano anche loro, di a entrambe di licenziare i loro ingegneri perchè si sono laureati alla cepu :D
a proposito l'output non viene dalle rops, loro caricano tutto nel frame buffer ;)
yossarian
30-10-2005, 23:06
scusa me se non è correto, com'è che il 3d mark da 10100 in multitexturing?
sbaglia anche il 3d mark adesso? :mbe:
facendo due conti vedo che anche la ati usa quel calcolo, se sbagliano anche loro, di a entrambe di licenziare i loro ingegneri perchè si sono laureati alla cepu :D
a proposito l'output non viene dalle rops, loro caricano tutto nel frame buffer ;)
il 3DMark da 10k come texel fillrate e in multitexturing; ossia , applicando 8 texture per pixel, si arriva a 10k MTexel/sec (texel, non pixel e in multitexturing).
Già, e il frame buffer, chissà cosa è!!!!!!!!!!!!!!!!!!!!!!
Domanda: dal frame buffer, i pixel dove vanno?
sbaglia anche il 3d mark adesso? :mbe:
facendo due conti vedo che anche la ati usa quel calcolo, se sbagliano anche loro, di a entrambe di licenziare i loro ingegneri perchè si sono laureati alla cepu :D
a proposito l'output non viene dalle rops, loro caricano tutto nel frame buffer ;)
il 3DMark da 10k come texel fillrate e in multitexturing; ossia , applicando 8 texture per pixel, si arriva a 10k MTexel/sec (texel, non pixel e in multitexturing).
Già, e il frame buffer, chissà cosa è!!!!!!!!!!!!!!!!!!!!!!
Domanda: dal frame buffer, i pixel dove vanno?
vaio-man
30-10-2005, 23:12
bè nel frame buffer va tutto quello che esce dalle rops e da lì va al monitor, ma serve anche quello se no avrei a video l'uscita di una sola rops ;)
yossarian
30-10-2005, 23:18
bè nel frame buffer va tutto quello che esce dalle rops e da lì va al monitor, ma serve anche quello se no avrei a video l'uscita di una sola rops ;)
se quello che esce dalle rop's va al fb e dal fb al monitor, allora le rop's sono il punto di uscita dei pixel. Non ce ne sono altri. Le rop's sono 16, non una, e il fillrate è uguale a 16*430 (non 1*430).
Comunque, se volete continuare a illudervi che il valore giusto sia 10320 MPixel/sec, continuate pure a credere alle sparate dei pr; non ci guadagno niente a cercare di aprirvi gli occhi e non ho intenzione di continuare a ripetere sempre lo stesso discorso.
Anzi, mettiamola così: G70 ha un pixel fillrate teorico di 10320; in pratica l'output e di 64xx; questo significa il 40% in meno rispetto al valore teorico.
Hai ragione, dovrebbero licenziare tutti gli ingegneri di NV, perchè non hanno idea di come si progetti un chip :sofico:
se quello che esce dalle rop's va al fb e dal fb al monitor, allora le rop's sono il punto di uscita dei pixel. Non ce ne sono altri. Le rop's sono 16, non una, e il fillrate è uguale a 16*430 (non 1*430).
Comunque, se volete continuare a illudervi che il valore giusto sia 10320 MPixel/sec, continuate pure a credere alle sparate dei pr; non ci guadagno niente a cercare di aprirvi gli occhi e non ho intenzione di continuare a ripetere sempre lo stesso discorso.
Anzi, mettiamola così: G70 ha un pixel fillrate teorico di 10320; in pratica l'output e di 64xx; questo significa il 40% in meno rispetto al valore teorico.
Hai ragione, dovrebbero licenziare tutti gli ingegneri di NV, perchè non hanno idea di come si progetti un chip :sofico:
vaio-man
30-10-2005, 23:49
altro dubbio, e se il fillrate calcolato con le rops è ciò che noi vediamo effetivamente a schermo, mentre quello calcolato con le pipeline è quello che viene calcolato dal chip?
in questa maniera sarebbero giusti entrambi, ma da due punti di vista diversi, anche se in questa maniera sarebbe uno spreco assurdo di risorse, e dimostrerebbe che gli ingegneri ati e nvidia hanno studiato alla cepu, di conseguenza propongo di incendiare tutte le sedi cepu per avere schede video migliori :sofico:
in questa maniera sarebbero giusti entrambi, ma da due punti di vista diversi, anche se in questa maniera sarebbe uno spreco assurdo di risorse, e dimostrerebbe che gli ingegneri ati e nvidia hanno studiato alla cepu, di conseguenza propongo di incendiare tutte le sedi cepu per avere schede video migliori :sofico:
Vifani
31-10-2005, 14:10
Quanto dice yossarian è assolutamente vero, il discorso tuttavia è un altro. G70 può elaborare 24 texel per ciclo di clock, ma può scriverne solo 16 nel frame buffer. Se per fill rate intendiamo la capacità computazionale di G70, allora sono 24 texel per ciclo di clock, se intendiamo quanti ne può scrivere, allora dobbiamo parlare di 16 pixel per ciclo di clock.
In single texturing, teoricamente, G70 può elaborare 24 pixel per ciclo di clock e scriverne 16. La realtà tuttavia è che parlare di quanti ne può elaborare e non di quanti ne può scrivere probabilmente è una misura più significativa del fill rate perché come ben sappiamo basta applicare un semplice filtro trilineare per impedire ad ogni singola pipeline di elaborare un pixel per ciclo di clock (avendo una sola TMU) e in questi casi le 24 pipeline interne possono fare la differenza, fermo restando che alla fine più di 16 non ne potrà mai scrivere nel frame buffer.
Insomma, anche NV43 ha 4 ROPS e 8 pipeline, ma le sue prestazioni sono ben superiori a quelle di un chip come RV370 che ha 4 ROPS e 4 pipeline, anche a parità di frequenza di clock.
In single texturing, teoricamente, G70 può elaborare 24 pixel per ciclo di clock e scriverne 16. La realtà tuttavia è che parlare di quanti ne può elaborare e non di quanti ne può scrivere probabilmente è una misura più significativa del fill rate perché come ben sappiamo basta applicare un semplice filtro trilineare per impedire ad ogni singola pipeline di elaborare un pixel per ciclo di clock (avendo una sola TMU) e in questi casi le 24 pipeline interne possono fare la differenza, fermo restando che alla fine più di 16 non ne potrà mai scrivere nel frame buffer.
Insomma, anche NV43 ha 4 ROPS e 8 pipeline, ma le sue prestazioni sono ben superiori a quelle di un chip come RV370 che ha 4 ROPS e 4 pipeline, anche a parità di frequenza di clock.
yossarian
31-10-2005, 14:27
Quanto dice yossarian è assolutamente vero, il discorso tuttavia è un altro. G70 può elaborare 24 texel per ciclo di clock, ma può scriverne solo 16 nel frame buffer. Se per fill rate intendiamo la capacità computazionale di G70, allora sono 24 texel per ciclo di clock, se intendiamo quanti ne può scrivere, allora dobbiamo parlare di 16 pixel per ciclo di clock.
In single texturing, teoricamente, G70 può elaborare 24 pixel per ciclo di clock e scriverne 16. La realtà tuttavia è che parlare di quanti ne può elaborare e non di quanti ne può scrivere probabilmente è una misura più significativa del fill rate perché come ben sappiamo basta applicare un semplice filtro trilineare per impedire ad ogni singola pipeline di elaborare un pixel per ciclo di clock (avendo una sola TMU) e in questi casi le 24 pipeline interne possono fare la differenza, fermo restando che alla fine più di 16 non ne potrà mai scrivere nel frame buffer.
Insomma, anche NV43 ha 4 ROPS e 8 pipeline, ma le sue prestazioni sono ben superiori a quelle di un chip come RV370 che ha 4 ROPS e 4 pipeline, anche a parità di frequenza di clock.
infatti; tra l'altro, in uno dei post precedenti, ho anche fatto un distinguo tra la capacità di elaborazione eil fillrate, sottolineando il fatto che, se nel puro fillrate e nello z-fillrate, in cui il lavoro da parte del chip è minimo, tendente allo zero, non esistono differenze tra NV40 e G70; le differenze iniziano a vedersi quando l'elaborazione diventa più complessa e non è più possibile, per la singola pixel pipeline, di elaborare un pixel per ciclo (l'applicazione di un AF di tipo "brilinear", richiede 18 operazioni di interpolazione lineare che corrispondono ad applicare il bilinear 17 volte, mentre una singola tmu può fare un solo bilinear per ciclo).
Però, ciò non toglie che il calcolo del fillrate teorico, che corrisponde al valore massimo raggiungibile da un chip, si effettua nelle migliori condizioni possibili (ossia con elaborazioni molto "leggera") ed è condizionato dal numero di rop's. In condizioni di elaborazione pesante, tutti i chip sono ben lontani dal loro valore teorico.
Quindi, sono d'accordo con te sull'importanza della capacità d'elaborazione delle pixel pipeline, però, poichè il discorso verteva sul calcolo del fillrate teorico, non posso non sottolineare che gli unici parametri importanti, a tale fine, sono il numero di rop's e la frequenza del chip (poi, sappiamo bene che il G70 sarà quasi sempre ben lontano dai 6880 MPixel, ma lo sarà ancora di più rispetto ai 10320 MPixel/sec)
In single texturing, teoricamente, G70 può elaborare 24 pixel per ciclo di clock e scriverne 16. La realtà tuttavia è che parlare di quanti ne può elaborare e non di quanti ne può scrivere probabilmente è una misura più significativa del fill rate perché come ben sappiamo basta applicare un semplice filtro trilineare per impedire ad ogni singola pipeline di elaborare un pixel per ciclo di clock (avendo una sola TMU) e in questi casi le 24 pipeline interne possono fare la differenza, fermo restando che alla fine più di 16 non ne potrà mai scrivere nel frame buffer.
Insomma, anche NV43 ha 4 ROPS e 8 pipeline, ma le sue prestazioni sono ben superiori a quelle di un chip come RV370 che ha 4 ROPS e 4 pipeline, anche a parità di frequenza di clock.
infatti; tra l'altro, in uno dei post precedenti, ho anche fatto un distinguo tra la capacità di elaborazione eil fillrate, sottolineando il fatto che, se nel puro fillrate e nello z-fillrate, in cui il lavoro da parte del chip è minimo, tendente allo zero, non esistono differenze tra NV40 e G70; le differenze iniziano a vedersi quando l'elaborazione diventa più complessa e non è più possibile, per la singola pixel pipeline, di elaborare un pixel per ciclo (l'applicazione di un AF di tipo "brilinear", richiede 18 operazioni di interpolazione lineare che corrispondono ad applicare il bilinear 17 volte, mentre una singola tmu può fare un solo bilinear per ciclo).
Però, ciò non toglie che il calcolo del fillrate teorico, che corrisponde al valore massimo raggiungibile da un chip, si effettua nelle migliori condizioni possibili (ossia con elaborazioni molto "leggera") ed è condizionato dal numero di rop's. In condizioni di elaborazione pesante, tutti i chip sono ben lontani dal loro valore teorico.
Quindi, sono d'accordo con te sull'importanza della capacità d'elaborazione delle pixel pipeline, però, poichè il discorso verteva sul calcolo del fillrate teorico, non posso non sottolineare che gli unici parametri importanti, a tale fine, sono il numero di rop's e la frequenza del chip (poi, sappiamo bene che il G70 sarà quasi sempre ben lontano dai 6880 MPixel, ma lo sarà ancora di più rispetto ai 10320 MPixel/sec)
vaio-man
31-10-2005, 15:01
quindi è come ho supposto io due post fa? il valore nvidia è il valore di calcolo, mentre quello di yossarian è quello che effetivamente vediamo a schermo
yossarian
31-10-2005, 15:34
quindi è come ho supposto io due post fa? il valore nvidia è il valore di calcolo, mentre quello di yossarian è quello che effetivamente vediamo a schermo
il fillrate teorico è dato dall'output massimo teorico. Non ci sono altri valori di fillrate teorici, anche perchè, quello di nVIDIA non è neppure un valore reale, in quanto, nelle elaborazioni standard, non ci si avvicina neppure a quel valore e, per essere precisi, neppure ai 6880 Mpixel/sec.
Neanche nelle elaborazioni più semplici (pure fillrate) ci si avvicina al valore teorico di 10320 (anzi, si è poco sopra i 6400); quindi quel valore teorico è del tutto campato in aria.
Poi, se vuoi continuare a tenere per buoni i 10320 Mp/sec, sei libero di farlo; però ti invito a trovarmi un dato reale anche lontanamente paragonabile a quel valore teorico di pixel fillrate. In caso contrario, dovremmo èrendere per buone tutte la sparate da pr.
il fillrate teorico è dato dall'output massimo teorico. Non ci sono altri valori di fillrate teorici, anche perchè, quello di nVIDIA non è neppure un valore reale, in quanto, nelle elaborazioni standard, non ci si avvicina neppure a quel valore e, per essere precisi, neppure ai 6880 Mpixel/sec.
Neanche nelle elaborazioni più semplici (pure fillrate) ci si avvicina al valore teorico di 10320 (anzi, si è poco sopra i 6400); quindi quel valore teorico è del tutto campato in aria.
Poi, se vuoi continuare a tenere per buoni i 10320 Mp/sec, sei libero di farlo; però ti invito a trovarmi un dato reale anche lontanamente paragonabile a quel valore teorico di pixel fillrate. In caso contrario, dovremmo èrendere per buone tutte la sparate da pr.
vaio-man
31-10-2005, 15:44
non voglio dire che i valori ati e nvidia sono per forza giusti, ma almeno voglio capire da dove lo hanno tirato fuori, potrebbe essere il fillrate massimo in multitexturing,visto che in quella modalità il 3d mark segna valori vicini a quelli dichiarati?
yossarian
31-10-2005, 15:58
non voglio dire che i valori ati e nvidia sono per forza giusti, ma almeno voglio capire da dove lo hanno tirato fuori, potrebbe essere il fillrate massimo in multitexturing,visto che in quella modalità il 3d mark segna valori vicini a quelli dichiarati?
no; qui si parla di pixel non di texel; 10k texel, applicandone 8 per pixel equivalgono a 1250 pixel (molto lontani dai 10320 teorici, mi pare).
Il valore lo hanno tirato fuori moltiplicando il numero di pixel pipeline (24) per la frequenza (430); però è sbagliato, perchè il G70 non può, nel modo più assoluto, scrivere 24 pixel per ciclo, poichè ha solo 16 unità in grado di scrivere pixel (le rop's)
Fill Rate (billion pixels/sec.) 10.32
questa è la dicitura che appare sul sito NV relativa a G70; come vedi parla di pixel, non di texel o di multitexturing.
no; qui si parla di pixel non di texel; 10k texel, applicandone 8 per pixel equivalgono a 1250 pixel (molto lontani dai 10320 teorici, mi pare).
Il valore lo hanno tirato fuori moltiplicando il numero di pixel pipeline (24) per la frequenza (430); però è sbagliato, perchè il G70 non può, nel modo più assoluto, scrivere 24 pixel per ciclo, poichè ha solo 16 unità in grado di scrivere pixel (le rop's)
Fill Rate (billion pixels/sec.) 10.32
questa è la dicitura che appare sul sito NV relativa a G70; come vedi parla di pixel, non di texel o di multitexturing.
vaio-man
31-10-2005, 16:15
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
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
R@nda
02-11-2005, 15:29
Magari vi interessa :)
http://arstechnica.com/articles/paedia/hardware/revolution.ars
http://arstechnica.com/articles/paedia/hardware/revolution.ars
Manp
02-11-2005, 15:59
Magari vi interessa :)
http://arstechnica.com/articles/paedia/hardware/revolution.ars
l'avevo letto questa mattina... molto interessante, soprattutto l'ultima pagina ;)
:)
http://arstechnica.com/articles/paedia/hardware/revolution.ars
l'avevo letto questa mattina... molto interessante, soprattutto l'ultima pagina ;)
:)
Free Gordon
02-11-2005, 17:22
Bello! Finalmente qualcosa sul Broadway!
vaio-man
02-11-2005, 23:08
ma perchè la nintendo su quel chip non ha rilasciato nulla? :muro:
si è limitata solo a dire "noi non facciamo la sfida sul piano della potenza stavolta" :muro:
si è limitata solo a dire "noi non facciamo la sfida sul piano della potenza stavolta" :muro:
Ren
03-11-2005, 09:32
x yoss
Il nuovo memory controller(halo) e la cache full associative sono adottati da R500 ?
Quanto fa guadagnare HDR fp10 in performance rispetto ad un fp16 ?
Il nuovo memory controller(halo) e la cache full associative sono adottati da R500 ?
Quanto fa guadagnare HDR fp10 in performance rispetto ad un fp16 ?
fek
03-11-2005, 10:06
Quanto fa guadagnare HDR fp10 in performance rispetto ad un fp16 ?
A questa posso risponderti io: l'R500 renderizza su superfici a 64bit (fp16) alla meta' della velocita' rispetto a superfici a 32bit (fp10, con 2 bit per l'alpha). Questo non significa comunque la meta' del framerate, perche' il framerate dipende dai colli di bottiglia.
Secondo me, non saranno molti i titoli a usare full fp16.
A questa posso risponderti io: l'R500 renderizza su superfici a 64bit (fp16) alla meta' della velocita' rispetto a superfici a 32bit (fp10, con 2 bit per l'alpha). Questo non significa comunque la meta' del framerate, perche' il framerate dipende dai colli di bottiglia.
Secondo me, non saranno molti i titoli a usare full fp16.
selenio
03-11-2005, 10:22
A questa posso risponderti io: l'R500 renderizza su superfici a 64bit (fp16) alla meta' della velocita' rispetto a superfici a 32bit (fp10, con 2 bit per l'alpha). Questo non significa comunque la meta' del framerate, perche' il framerate dipende dai colli di bottiglia.
Secondo me, non saranno molti i titoli a usare full fp16.
Beato te che sei a smanettare, con il 360.
:D
Secondo me, non saranno molti i titoli a usare full fp16.
Beato te che sei a smanettare, con il 360.
:D
luckye
03-11-2005, 10:27
A questa posso risponderti io: l'R500 renderizza su superfici a 64bit (fp16) alla meta' della velocita' rispetto a superfici a 32bit (fp10, con 2 bit per l'alpha). Questo non significa comunque la meta' del framerate, perche' il framerate dipende dai colli di bottiglia.
Secondo me, non saranno molti i titoli a usare full fp16.
Beh facendo due conti fp10 e int. 32bit in si equivalgono.La qualità finale è sbilanciata a favore di fp10.
O sbaglio ?
Secondo me, non saranno molti i titoli a usare full fp16.
Beh facendo due conti fp10 e int. 32bit in si equivalgono.La qualità finale è sbilanciata a favore di fp10.
O sbaglio ?
Ren
03-11-2005, 10:28
A questa posso risponderti io: l'R500 renderizza su superfici a 64bit (fp16) alla meta' della velocita' rispetto a superfici a 32bit (fp10, con 2 bit per l'alpha). Questo non significa comunque la meta' del framerate, perche' il framerate dipende dai colli di bottiglia. Secondo me, non saranno molti i titoli a usare full fp16.
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 :D
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 :D
Ren
03-11-2005, 10:32
Beh facendo due conti fp10 e int. 32bit in si equivalgono.La qualità finale è sbilanciata a favore di fp10. O sbaglio ?
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...
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...
yossarian
03-11-2005, 13:50
x yoss
Il nuovo memory controller(halo) e la cache full associative sono adottati da R500 ?
Quanto fa guadagnare HDR fp10 in performance rispetto ad un fp16 ?
è molto probabile; almeno stando ai brevetti depositati per le architetture dei nuovi chip (R5x0, R500 e R6x0). Anzi, a dirla tutta, ci soo anche brevetti che prevedono più di uno o due arbiter (che potrebbero essere assimilati al dispatch processor e al memory controller, ovvero, a tutti quei dispositivi "attivi" che si occupano della gestione del flusso di dati).
Il nuovo memory controller(halo) e la cache full associative sono adottati da R500 ?
Quanto fa guadagnare HDR fp10 in performance rispetto ad un fp16 ?
è molto probabile; almeno stando ai brevetti depositati per le architetture dei nuovi chip (R5x0, R500 e R6x0). Anzi, a dirla tutta, ci soo anche brevetti che prevedono più di uno o due arbiter (che potrebbero essere assimilati al dispatch processor e al memory controller, ovvero, a tutti quei dispositivi "attivi" che si occupano della gestione del flusso di dati).
yossarian
03-11-2005, 14:37
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 :D
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)
Sei stato un pò vago, specifica i colli di bottiglia e quantifica in percentuale l'aumento di performance.
ps. scusa se rompo le balls :D
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
03-11-2005, 14:44
halo? arbiter? ma state parlando di halo 2? :D
:p
:p
Free Gordon
03-11-2005, 17:22
halo? arbiter? ma state parlando di halo 2? :D
:p
:sofico: Vero!
:p
:sofico: Vero!
fek
03-11-2005, 19:16
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.
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
03-11-2005, 19:21
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 :D
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.
Sei stato un pò vago, specifica i colli di bottiglia e quantifica in percentuale l'aumento di performance.
ps. scusa se rompo le balls :D
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
03-11-2005, 19:36
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)
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
03-11-2005, 19:38
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) ?
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
03-11-2005, 19:54
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 :)
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
03-11-2005, 20:10
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)
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
03-11-2005, 20:19
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).
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
03-11-2005, 20:36
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...
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
03-11-2005, 21:37
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 :D
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 :D
luckye
03-11-2005, 21:46
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...
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
03-11-2005, 22:33
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 :D
Appena ci provo te lo dico :D
Appena ci provo te lo dico :D
luckye
03-11-2005, 22:49
Appena ci provo te lo dico :D
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.
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
04-11-2005, 00:18
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? :D
Perchè 3 core a doppio thread allora? :D
luckye
04-11-2005, 00:36
Perchè 3 core a doppio thread allora? :D
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... :D
Ottimo davvero questo XENON
P.s io sono economista non informatico magari ne sparo di banzane :)
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... :D
Ottimo davvero questo XENON
P.s io sono economista non informatico magari ne sparo di banzane :)
yossarian
04-11-2005, 01:39
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 :D
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 :D
Free Gordon
04-11-2005, 02:00
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... :D
Ottimo davvero questo XENON
P.s io sono economista non informatico magari ne sparo di banzane :)
E il sonoro dove lo metti? :sofico:
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! :D Ma il die sarebbe stato troppo grosso probabilmente..
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... :D
Ottimo davvero questo XENON
P.s io sono economista non informatico magari ne sparo di banzane :)
E il sonoro dove lo metti? :sofico:
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! :D Ma il die sarebbe stato troppo grosso probabilmente..
fek
04-11-2005, 08:38
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 :D
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 :D
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 :D
Diciamo che è solo un'idea di cui tu potresti confermarmi o meno la fattibilità.
Nel caso funzionasse, però, voglio l'esclusiva :D
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 :D
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 :D
fek
04-11-2005, 08:43
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... :D
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 :D
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.
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... :D
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 :D
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
04-11-2005, 09:49
E il sonoro dove lo metti? :sofico:
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! :D Ma il die sarebbe stato troppo grosso probabilmente..
Vabbè dai l'ho buttato lì alle due di notte...sonoro ? thread virtuale in un core :D
Kmq sta xbox mi piace sempre più :D
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! :D Ma il die sarebbe stato troppo grosso probabilmente..
Vabbè dai l'ho buttato lì alle due di notte...sonoro ? thread virtuale in un core :D
Kmq sta xbox mi piace sempre più :D
fek
04-11-2005, 10:27
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.
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
04-11-2005, 10:48
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??? :D
Alla fine è una 7800 pompata o c'è qualche sorpresa grossa...? :sofico:
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??? :D
Alla fine è una 7800 pompata o c'è qualche sorpresa grossa...? :sofico:
yossarian
04-11-2005, 11:15
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 :D
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 :D
beh, effettivamente a 1280x720 con AA4x tutto il frame non ci sta (ti servirebbero almeno 30 MB a 32 bit + 32 di z estencil) :D
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
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 :D
beh, effettivamente a 1280x720 con AA4x tutto il frame non ci sta (ti servirebbero almeno 30 MB a 32 bit + 32 di z estencil) :D
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
04-11-2005, 11:22
beh, effettivamente a 1280x720 con AA4x tutto il frame non ci sta (ti servirebbero almeno 30 MB a 32 bit + 32 di z estencil) :D
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.
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
04-11-2005, 11:31
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
:)
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
04-11-2005, 13:01
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 :)
EDIT: come non detto; ho trovato le informazioni che cercavo
:)
Comporta non usarlo o tornare a 8 bit :)
yossarian
04-11-2005, 13:08
Comporta non usarlo o tornare a 8 bit :)
anche se in ritardo, ci ero arrivato
comunque, grazie lo stesso :)
anche se in ritardo, ci ero arrivato
comunque, grazie lo stesso :)
Do85
04-11-2005, 17:21
inizio a credere che la microsoft abbia raggiunto le stesse prestazioni con un minor costo... :sofico:
luckye
04-11-2005, 17:32
inizio a credere che la microsoft abbia raggiunto le stesse prestazioni con un minor costo... :sofico:
No è probabile che sarà il nintendo revolution a quanto mi è dato sapere :oink:
No è probabile che sarà il nintendo revolution a quanto mi è dato sapere :oink:
yossarian
09-11-2005, 01:41
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=
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
09-11-2005, 12:52
Beh questo è un chiarimento significativo :)
Lakitu
09-11-2005, 13:18
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.
:)
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
09-11-2005, 16:16
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 :D
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. :sofico:
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 :D
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. :sofico:
Lakitu
09-11-2005, 20:04
stai cercando di farmi perdere tutte le amicizie :D
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. :sofico:
Intanto grazie per questo primo "indizio"... ;) ...rimango in fiduciosa attesa di aggiornamenti... chi sa qualcosa, parli! :D
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. :sofico:
Intanto grazie per questo primo "indizio"... ;) ...rimango in fiduciosa attesa di aggiornamenti... chi sa qualcosa, parli! :D
cangia
09-11-2005, 22:18
No è probabile che sarà il nintendo revolution a quanto mi è dato sapere :oink:
qualcuno dei nostri due esperti ha notizie in merito riguardo l'hw eo/ prestazioni e/o comportamento del chip-chop del Revolution ? :D
qualcuno dei nostri due esperti ha notizie in merito riguardo l'hw eo/ prestazioni e/o comportamento del chip-chop del Revolution ? :D
cangia
09-11-2005, 22:21
stai cercando di farmi perdere tutte le amicizie :D
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. :sofico:
se non fa parte della prima :D .. o è un chip serie r5x0 adattato alla console .. oppure è qualcosa di totalmente diverso ... si, ma cosa ? :D
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. :sofico:
se non fa parte della prima :D .. o è un chip serie r5x0 adattato alla console .. oppure è qualcosa di totalmente diverso ... si, ma cosa ? :D
Free Gordon
09-11-2005, 23:36
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. ;)
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
09-11-2005, 23:41
di sicuro dovrà scaldar poco e consumare poco...
che non sia magari un derivato di RV530? :fagiano:
:)
che non sia magari un derivato di RV530? :fagiano:
:)
yossarian
09-11-2005, 23:50
se non fa parte della prima :D .. o è un chip serie r5x0 adattato alla console .. oppure è qualcosa di totalmente diverso ... si, ma cosa ? :D
non è che ci siano molte alternative (2 e ne hai già scartata una) :D
vi do un altro indizio: potrebbe non essere a 0,09
non è che ci siano molte alternative (2 e ne hai già scartata una) :D
vi do un altro indizio: potrebbe non essere a 0,09
luckye
10-11-2005, 00:29
qualcuno dei nostri due esperti ha notizie in merito riguardo l'hw eo/ prestazioni e/o comportamento del chip-chop del Revolution ? :D
Che cpu avrà il revo ? (di chip video yoss ne sa troppo sparo qualche cacchiata sulla cpu và....magari non si accorge :-) )
Beh speculando rapidamente visto che ibm progetta due linee di chip e ha dimostrato di attingere sempre dalla propria tecnologia e customizzarla al bisogno...
O è un derivato del cell
O è un derivato Powerpc
Visto che il cell è improbabile per via delle dimensioni della consolle (piccola) e per quanto dichiarato dalla nintendo (non facciamo la guerra dei numeri...) e (intendiamo sviluppare rapidamente e velocemente giochi...) è probabile che sarà derivato powerpc.
Quasi sicuramente mi aspetto un powerpc stile x-box ma non tricore dual thread ma piuttosto un monocore-mono/dual thread con cache aumentata.
Sarebbe l'unico modo di appunto tentare di contenere i consumi per infilarlo in quello scatolino (già un dualcore la vedo molto,troppo dura) senza sacrificare troppo le prestazioni grazie alla cache maggiorata.
Inoltre si farebbe vita facile ai programmatori che si troverebbe con tool di sviluppo e architetture che conoscono già sopratutto monocore che evita di dover far bilanciare il carico.
Ovviamente sono solo mie speculazioni nulla di attendibile ma verosimilmente sarà quella la strada...
Che cpu avrà il revo ? (di chip video yoss ne sa troppo sparo qualche cacchiata sulla cpu và....magari non si accorge :-) )
Beh speculando rapidamente visto che ibm progetta due linee di chip e ha dimostrato di attingere sempre dalla propria tecnologia e customizzarla al bisogno...
O è un derivato del cell
O è un derivato Powerpc
Visto che il cell è improbabile per via delle dimensioni della consolle (piccola) e per quanto dichiarato dalla nintendo (non facciamo la guerra dei numeri...) e (intendiamo sviluppare rapidamente e velocemente giochi...) è probabile che sarà derivato powerpc.
Quasi sicuramente mi aspetto un powerpc stile x-box ma non tricore dual thread ma piuttosto un monocore-mono/dual thread con cache aumentata.
Sarebbe l'unico modo di appunto tentare di contenere i consumi per infilarlo in quello scatolino (già un dualcore la vedo molto,troppo dura) senza sacrificare troppo le prestazioni grazie alla cache maggiorata.
Inoltre si farebbe vita facile ai programmatori che si troverebbe con tool di sviluppo e architetture che conoscono già sopratutto monocore che evita di dover far bilanciare il carico.
Ovviamente sono solo mie speculazioni nulla di attendibile ma verosimilmente sarà quella la strada...
yossarian
10-11-2005, 00:41
Che cpu avrà il revo ? (di chip video yoss ne sa troppo sparo qualche cacchiata sulla cpu và....magari non si accorge :-) )
Beh speculando rapidamente visto che ibm progetta due linee di chip e ha dimostrato di attingere sempre dalla propria tecnologia e customizzarla al bisogno...
O è un derivato del cell
O è un derivato Powerpc
Visto che il cell è improbabile per via delle dimensioni della consolle (piccola) e per quanto dichiarato dalla nintendo (non facciamo la guerra dei numeri...) e (intendiamo sviluppare rapidamente e velocemente giochi...) è probabile che sarà derivato powerpc.
Quasi sicuramente mi aspetto un powerpc stile x-box ma non tricore dual thread ma piuttosto un monocore-mono/dual thread con cache aumentata.
Sarebbe l'unico modo di appunto tentare di contenere i consumi per infilarlo in quello scatolino (già un dualcore la vedo molto,troppo dura) senza sacrificare troppo le prestazioni grazie alla cache maggiorata.
Inoltre si farebbe vita facile ai programmatori che si troverebbe con tool di sviluppo e architetture che conoscono già sopratutto monocore che evita di dover far bilanciare il carico.
Ovviamente sono solo mie speculazioni nulla di attendibile ma verosimilmente sarà quella la strada...
non credo che tu sia andato molto distante dalla verità ;)
Beh speculando rapidamente visto che ibm progetta due linee di chip e ha dimostrato di attingere sempre dalla propria tecnologia e customizzarla al bisogno...
O è un derivato del cell
O è un derivato Powerpc
Visto che il cell è improbabile per via delle dimensioni della consolle (piccola) e per quanto dichiarato dalla nintendo (non facciamo la guerra dei numeri...) e (intendiamo sviluppare rapidamente e velocemente giochi...) è probabile che sarà derivato powerpc.
Quasi sicuramente mi aspetto un powerpc stile x-box ma non tricore dual thread ma piuttosto un monocore-mono/dual thread con cache aumentata.
Sarebbe l'unico modo di appunto tentare di contenere i consumi per infilarlo in quello scatolino (già un dualcore la vedo molto,troppo dura) senza sacrificare troppo le prestazioni grazie alla cache maggiorata.
Inoltre si farebbe vita facile ai programmatori che si troverebbe con tool di sviluppo e architetture che conoscono già sopratutto monocore che evita di dover far bilanciare il carico.
Ovviamente sono solo mie speculazioni nulla di attendibile ma verosimilmente sarà quella la strada...
non credo che tu sia andato molto distante dalla verità ;)
luckye
10-11-2005, 01:07
non credo che tu sia andato molto distante dalla verità ;)
Beh detto da te è un complimentone :sofico:
Visto che sei quì e di là quanti texture sample e arithmetic instructions macina una singola pipe di r520 e di r500 ?
Sono rimasto fermo a 1texture + 4 math dell'nv40 :D
E sopratutto (come esposto anche nell'altro 3d g70 e r520) prima che per le pipe si faccia come per i mhz delle cpu perchè nessuna recensione spiega che non conta tanto il loro numero quanto la loro potenza ?
Quì già la gente sparava su r520 perchè ne aveva solo 16.... :rolleyes: :D
Beh detto da te è un complimentone :sofico:
Visto che sei quì e di là quanti texture sample e arithmetic instructions macina una singola pipe di r520 e di r500 ?
Sono rimasto fermo a 1texture + 4 math dell'nv40 :D
E sopratutto (come esposto anche nell'altro 3d g70 e r520) prima che per le pipe si faccia come per i mhz delle cpu perchè nessuna recensione spiega che non conta tanto il loro numero quanto la loro potenza ?
Quì già la gente sparava su r520 perchè ne aveva solo 16.... :rolleyes: :D
Speed399
10-11-2005, 01:39
aveva scritto qualcosina anche arstechnica sul broadway (cpu del revo)
http://arstechnica.com/articles/paedia/hardware/revolution.ars/2
grossomodo quello che hai ipotizzato tu e che anche io penso si avvicini abbastanza alla realtà
http://arstechnica.com/articles/paedia/hardware/revolution.ars/2
grossomodo quello che hai ipotizzato tu e che anche io penso si avvicini abbastanza alla realtà
yossarian
10-11-2005, 02:20
Beh detto da te è un complimentone :sofico:
Visto che sei quì e di là quanti texture sample e arithmetic instructions macina una singola pipe di r520 e di r500 ?
Sono rimasto fermo a 1texture + 4 math dell'nv40 :D
E sopratutto (come esposto anche nell'altro 3d g70 e r520) prima che per le pipe si faccia come per i mhz delle cpu perchè nessuna recensione spiega che non conta tanto il loro numero quanto la loro potenza ?
Quì già la gente sparava su r520 perchè ne aveva solo 16.... :rolleyes: :D
ci sono vari modi per contare le istruzioni e le operazioni di un chip.
Ad esempio NV40, in assenza di operazioni di texturing, per ogni alu (in realtà si parla di pixel pipeline, ma uso la definizione che da nVIDIA), gestisce tre istruzioni a fp16 (una MAD, una ADD e una normalizzazione vettoriale) e, in più, un'istruzione di branching; in fp32, invece, si ha un'istruzione in meno (perchè la normalizzazione non è supportata). Tenuto conto che: una MAD conta per due operazioni, e la normalizzazione per 3, escludendo le operazioni di branching e limitandosi a quelle matematiche, in un singolo ciclo abbiamo 6 operazioni vettoriali che diventano 19 flops (8 per la MAD, 4 per la ADD e 7 per la NORM) a fp16 e 12 a fp32.
G70, che ha due MAD vettoriali e 2 scalari, invece, vanta 5 istruzioni a fp16 (e 4 a fp32, sempre per la normalizzazione che funziona solo a fp16), 10 operazioni (su vettori o scalari), 10 istruzioni e 27 flops per ciclo per ogni alu; a fp32, ovviamente, si scende a 4 istruzioni, 8 operazioni e 20 flops.
Per ogni alu di R520 si hanno: 4 istruzioni, 6 operazioni e 12 flops (le alu di R520 sono del tipo vect3+scalar, mentre quelle di G70 sono vect4+scalar), tutto a fp32. Le operazioni di texture sono separate e gestite in modo tale che, ad ogni quad di ps sia assegnato un quad di tmu (che possono lavorare separatamente o tutte o in parte insieme su uno stesso thread.
Se per R520 è difficile parlare di piepline, per R500 è quasi impossibile; a meno che non si voglia consoderare il fatto che le alu sono raggruppate in 3 gruppi da 16 ciascuna. Comunque, ogni alu di R500 è di tipo vect4+scalar, per un totale di 2 istruzioni, 4 operazioni e 10 flops tutto a fp32 8però sono 48 contro le 16 di R520 e le 24 di G70).
In più, i chip ATi possono gestire texture ops e math ops contemporaneamente.
Veniamo al discorso potenza e frequenza. La potenza teorica non è un dato indicativo delle reali potenzialità del chip. Facendo due calcoli, si vede che il G70 ha un output teorico in Gflops, pari a circa 5 volte e mezza quello di r520; questo farebbe pensare a distacchi dello stesso ordine di grandezza nei test sul pixel processor (che non coinvolgono altri elementi del chip, ma che testano solo la potenza di calcolo dei pixel shader); invece, notiamo che il vantaggio massimo si attesta attorno ad una volta e mezza e nella maggior parte dei casi sono molto più vicini. Addirittura, nei test con HDR o con dynamic branching, la situazione si ribalta, con un netto vantaggio per l'R520 (con db siamo sull'ordine di circa 2 volte più veloce). Questo significa che il rendimento di G70 è nettamente inferiore a quello teorico (e infatti si attesta sulle 2,2 istruzioni per ciclo in fp16 e sulle 1,6 in fp32, contro le 5 teoriche), mentre quello di r520 è molto più vicino alla teoria. E bada bene, qui parlo di istruzioni per ciclo, quindi la frequenza di funzionamento del chip non c'entra assolutamente niente. Questo dimostra che il pixel processor di R520 è molto più effiicente di quello di G70; altra prova si ha con risoluzioni elevate e filtri attivi: il rendimento di G70 crolla a picco, mentre il calo di quello di R520 è graduale. Anche questo dimostra che, nelle situazioni complesse, R520 mantiene un rendimento elevato, mentre G70 cala in maniera drastica.
Ora considera che su R520 le ottimizzazioni spinte riguardano solo il pixel processor e l'interfaccia con la ram (con qualche aggiustamento nelle rop's e nei vs); al contrario, in R500, le ottimizzazioni riguardano tutto il chip.
Visto che sei quì e di là quanti texture sample e arithmetic instructions macina una singola pipe di r520 e di r500 ?
Sono rimasto fermo a 1texture + 4 math dell'nv40 :D
E sopratutto (come esposto anche nell'altro 3d g70 e r520) prima che per le pipe si faccia come per i mhz delle cpu perchè nessuna recensione spiega che non conta tanto il loro numero quanto la loro potenza ?
Quì già la gente sparava su r520 perchè ne aveva solo 16.... :rolleyes: :D
ci sono vari modi per contare le istruzioni e le operazioni di un chip.
Ad esempio NV40, in assenza di operazioni di texturing, per ogni alu (in realtà si parla di pixel pipeline, ma uso la definizione che da nVIDIA), gestisce tre istruzioni a fp16 (una MAD, una ADD e una normalizzazione vettoriale) e, in più, un'istruzione di branching; in fp32, invece, si ha un'istruzione in meno (perchè la normalizzazione non è supportata). Tenuto conto che: una MAD conta per due operazioni, e la normalizzazione per 3, escludendo le operazioni di branching e limitandosi a quelle matematiche, in un singolo ciclo abbiamo 6 operazioni vettoriali che diventano 19 flops (8 per la MAD, 4 per la ADD e 7 per la NORM) a fp16 e 12 a fp32.
G70, che ha due MAD vettoriali e 2 scalari, invece, vanta 5 istruzioni a fp16 (e 4 a fp32, sempre per la normalizzazione che funziona solo a fp16), 10 operazioni (su vettori o scalari), 10 istruzioni e 27 flops per ciclo per ogni alu; a fp32, ovviamente, si scende a 4 istruzioni, 8 operazioni e 20 flops.
Per ogni alu di R520 si hanno: 4 istruzioni, 6 operazioni e 12 flops (le alu di R520 sono del tipo vect3+scalar, mentre quelle di G70 sono vect4+scalar), tutto a fp32. Le operazioni di texture sono separate e gestite in modo tale che, ad ogni quad di ps sia assegnato un quad di tmu (che possono lavorare separatamente o tutte o in parte insieme su uno stesso thread.
Se per R520 è difficile parlare di piepline, per R500 è quasi impossibile; a meno che non si voglia consoderare il fatto che le alu sono raggruppate in 3 gruppi da 16 ciascuna. Comunque, ogni alu di R500 è di tipo vect4+scalar, per un totale di 2 istruzioni, 4 operazioni e 10 flops tutto a fp32 8però sono 48 contro le 16 di R520 e le 24 di G70).
In più, i chip ATi possono gestire texture ops e math ops contemporaneamente.
Veniamo al discorso potenza e frequenza. La potenza teorica non è un dato indicativo delle reali potenzialità del chip. Facendo due calcoli, si vede che il G70 ha un output teorico in Gflops, pari a circa 5 volte e mezza quello di r520; questo farebbe pensare a distacchi dello stesso ordine di grandezza nei test sul pixel processor (che non coinvolgono altri elementi del chip, ma che testano solo la potenza di calcolo dei pixel shader); invece, notiamo che il vantaggio massimo si attesta attorno ad una volta e mezza e nella maggior parte dei casi sono molto più vicini. Addirittura, nei test con HDR o con dynamic branching, la situazione si ribalta, con un netto vantaggio per l'R520 (con db siamo sull'ordine di circa 2 volte più veloce). Questo significa che il rendimento di G70 è nettamente inferiore a quello teorico (e infatti si attesta sulle 2,2 istruzioni per ciclo in fp16 e sulle 1,6 in fp32, contro le 5 teoriche), mentre quello di r520 è molto più vicino alla teoria. E bada bene, qui parlo di istruzioni per ciclo, quindi la frequenza di funzionamento del chip non c'entra assolutamente niente. Questo dimostra che il pixel processor di R520 è molto più effiicente di quello di G70; altra prova si ha con risoluzioni elevate e filtri attivi: il rendimento di G70 crolla a picco, mentre il calo di quello di R520 è graduale. Anche questo dimostra che, nelle situazioni complesse, R520 mantiene un rendimento elevato, mentre G70 cala in maniera drastica.
Ora considera che su R520 le ottimizzazioni spinte riguardano solo il pixel processor e l'interfaccia con la ram (con qualche aggiustamento nelle rop's e nei vs); al contrario, in R500, le ottimizzazioni riguardano tutto il chip.
luckye
10-11-2005, 11:04
aveva scritto qualcosina anche arstechnica sul broadway (cpu del revo)
http://arstechnica.com/articles/paedia/hardware/revolution.ars/2
grossomodo quello che hai ipotizzato tu e che anche io penso si avvicini abbastanza alla realtà
Già è vero il discorso è analogo. Beh alla fine è abbastanza palese cioè 1 +2 fa tre.
Se su 3 cpu per consolle tutte ibm 2 sono derivate da architetture esistenti e non ex novo... insomma tanto mistero sul revolution ma poi basta ragionarci un'attimo.
P.s non lo sconoscevo quel sito :eek: figo :eek: ha tutti argomenti semplici semplici :sofico:
http://arstechnica.com/articles/paedia/hardware/revolution.ars/2
grossomodo quello che hai ipotizzato tu e che anche io penso si avvicini abbastanza alla realtà
Già è vero il discorso è analogo. Beh alla fine è abbastanza palese cioè 1 +2 fa tre.
Se su 3 cpu per consolle tutte ibm 2 sono derivate da architetture esistenti e non ex novo... insomma tanto mistero sul revolution ma poi basta ragionarci un'attimo.
P.s non lo sconoscevo quel sito :eek: figo :eek: ha tutti argomenti semplici semplici :sofico:
Ren
10-11-2005, 11:22
Domandine : :sofico:
1.Perchè i chip nvidia calano a picco quando utilizzano un numero di texture elevato ?
2.Perchè il setup di R500 è limitato a 500M di poligoni ? Teoricamente non potrebbe calcolarne 6 miliardi ?
3.Quanto risparmia in termini di risorse revolution con un rendering a soli 640x480 ?
1.Perchè i chip nvidia calano a picco quando utilizzano un numero di texture elevato ?
2.Perchè il setup di R500 è limitato a 500M di poligoni ? Teoricamente non potrebbe calcolarne 6 miliardi ?
3.Quanto risparmia in termini di risorse revolution con un rendering a soli 640x480 ?
fek
10-11-2005, 11:46
Se per R520 è difficile parlare di piepline, per R500 è quasi impossibile; a meno che non si voglia consoderare il fatto che le alu sono raggruppate in 3 gruppi da 16 ciascuna. Comunque, ogni alu di R500 è di tipo vect4+scalar, per un totale di 2 istruzioni, 4 operazioni e 10 flops tutto a fp32 8però sono 48 contro le 16 di R520 e le 24 di G70).
Mi togli un dubbio? Le ALU dell'R500 sono raggruppate in 3 gruppi da 16, in confiurazione MIMD. Quindi ogni gruppo di ALU puo' lavorare su un flusso di istruzioni differente, giusto?
Non lo controllo io (almeno non ho trovato alcuna API per controllarlo), ma posso assumere che un gruppo possa lavorare su vertici e un altro gruppo su frammenti?
Mi togli un dubbio? Le ALU dell'R500 sono raggruppate in 3 gruppi da 16, in confiurazione MIMD. Quindi ogni gruppo di ALU puo' lavorare su un flusso di istruzioni differente, giusto?
Non lo controllo io (almeno non ho trovato alcuna API per controllarlo), ma posso assumere che un gruppo possa lavorare su vertici e un altro gruppo su frammenti?
yossarian
10-11-2005, 12:06
Domandine : :sofico:
1.Perchè i chip nvidia calano a picco quando utilizzano un numero di texture elevato ?
2.Perchè il setup di R500 è limitato a 500M di poligoni ? Teoricamente non potrebbe calcolarne 6 miliardi ?
3.Quanto risparmia in termini di risorse revolution con un rendering a soli 640x480 ?
1) non sono solo i chip NV a calare a picco e non succede solo con le texture, ma con qualunque tipo di calcolo complesso. Dipende dal livello di efficienza complessiva di un chip: più è alta l'efficienza, minore è il calo in situazioni complesse. In un chip a shader separati succede raramente che tutte le unità lavorino in contemporanea; questo perchè è praticamente impossibile bilanciare la velocità di esecuzione di tutti i blocchi di unità, in modo che le operazioni siano perfettamente sincronizzate. Quindi si verifica che lavorano i vs e i ps restano in idle, in attesa che arrivino i dati; lavorano i ps e i vs sono in attesa di potre inviare i dati perchè il blocco successivo non ha disponibilità ad accoglierne di nuovi. Quando il lavoro dei ps è particolarmente pesante si creano situazioni di attesa sia per i vs che per le rop's. Lo stesso memory controller, di tipo crossbar, non è particolarmente indicato per gestire accessi multipli agli stessi banchi di ram e per lavorare con ram ad elevato bit rate. Ovviamente, all'aumentare della pesantezza dei calcoli, tutti questi problemi si acuiscono. In particolare, relativamente ai chip NV, la loro logica di funzionamento prevede la circolazione di un gran numero di pixel all'interno delle pipeline: questo, se da un lato comporta la possibilità di gestire flussi dinamici di dati (cosa che la serie R4x0 non era in grado di fare), dall'altro fa aumentare l'inefficienza in situazioni di rendering complesso (pensa solo alla situazione in cui si hanno più pixel in attesa dello stesso texel, all'interno della pixel pipeline, soprattutto se quel texel non è contenuto nella texture cache interna alla pipeline) e non permette una gestione ottimale dei registri interni.
2) perchè per il setup dei triangoli le cifre sono più o meno distribuite in maniera casuale. R500 ha 16 vertex fetch unit quindi contro le 8 di G70 e di r520. Per G70 i triangoli dichiarati sono 860, per R520 1250. Diciamo che in pratica, i 500 milioni di R500 sono molto più verosimili dei1250 di r520 e degli 860 di G70, che in pratica nei test sintetici sul processore geometrico (quindi solo vs impegnati) variano dal centinaio a poche decine di milioni.
3) non lo so; comunque non aspettarti vantaggi analoghi a quelli di R500, perchè il chip del Revo non dovrebbe avere 10 MB di eDRAM nelle rop's
1.Perchè i chip nvidia calano a picco quando utilizzano un numero di texture elevato ?
2.Perchè il setup di R500 è limitato a 500M di poligoni ? Teoricamente non potrebbe calcolarne 6 miliardi ?
3.Quanto risparmia in termini di risorse revolution con un rendering a soli 640x480 ?
1) non sono solo i chip NV a calare a picco e non succede solo con le texture, ma con qualunque tipo di calcolo complesso. Dipende dal livello di efficienza complessiva di un chip: più è alta l'efficienza, minore è il calo in situazioni complesse. In un chip a shader separati succede raramente che tutte le unità lavorino in contemporanea; questo perchè è praticamente impossibile bilanciare la velocità di esecuzione di tutti i blocchi di unità, in modo che le operazioni siano perfettamente sincronizzate. Quindi si verifica che lavorano i vs e i ps restano in idle, in attesa che arrivino i dati; lavorano i ps e i vs sono in attesa di potre inviare i dati perchè il blocco successivo non ha disponibilità ad accoglierne di nuovi. Quando il lavoro dei ps è particolarmente pesante si creano situazioni di attesa sia per i vs che per le rop's. Lo stesso memory controller, di tipo crossbar, non è particolarmente indicato per gestire accessi multipli agli stessi banchi di ram e per lavorare con ram ad elevato bit rate. Ovviamente, all'aumentare della pesantezza dei calcoli, tutti questi problemi si acuiscono. In particolare, relativamente ai chip NV, la loro logica di funzionamento prevede la circolazione di un gran numero di pixel all'interno delle pipeline: questo, se da un lato comporta la possibilità di gestire flussi dinamici di dati (cosa che la serie R4x0 non era in grado di fare), dall'altro fa aumentare l'inefficienza in situazioni di rendering complesso (pensa solo alla situazione in cui si hanno più pixel in attesa dello stesso texel, all'interno della pixel pipeline, soprattutto se quel texel non è contenuto nella texture cache interna alla pipeline) e non permette una gestione ottimale dei registri interni.
2) perchè per il setup dei triangoli le cifre sono più o meno distribuite in maniera casuale. R500 ha 16 vertex fetch unit quindi contro le 8 di G70 e di r520. Per G70 i triangoli dichiarati sono 860, per R520 1250. Diciamo che in pratica, i 500 milioni di R500 sono molto più verosimili dei1250 di r520 e degli 860 di G70, che in pratica nei test sintetici sul processore geometrico (quindi solo vs impegnati) variano dal centinaio a poche decine di milioni.
3) non lo so; comunque non aspettarti vantaggi analoghi a quelli di R500, perchè il chip del Revo non dovrebbe avere 10 MB di eDRAM nelle rop's
yossarian
10-11-2005, 12:12
Mi togli un dubbio? Le ALU dell'R500 sono raggruppate in 3 gruppi da 16, in confiurazione MIMD. Quindi ogni gruppo di ALU puo' lavorare su un flusso di istruzioni differente, giusto?
Non lo controllo io (almeno non ho trovato alcuna API per controllarlo), ma posso assumere che un gruppo possa lavorare su vertici e un altro gruppo su frammenti?
si; hai 16 vertex fetch unit; guarda caso, 16, come le alu di ogni gruppo :D
Supponiamo che tu abbia in input 4 gruppi di vertici e il restante sono pixel, il chip funaziona in questo modo: l'arbiter analizza l'input e attiva i vertex fetch di 4 gruppi di 3 alu ciascuno, inviando loro i dati relativi. In tal modo dovresti avere 4 gruppi di 3 alu ciascuno che lavora sui vertici e il restante sui pixel
Non lo controllo io (almeno non ho trovato alcuna API per controllarlo), ma posso assumere che un gruppo possa lavorare su vertici e un altro gruppo su frammenti?
si; hai 16 vertex fetch unit; guarda caso, 16, come le alu di ogni gruppo :D
Supponiamo che tu abbia in input 4 gruppi di vertici e il restante sono pixel, il chip funaziona in questo modo: l'arbiter analizza l'input e attiva i vertex fetch di 4 gruppi di 3 alu ciascuno, inviando loro i dati relativi. In tal modo dovresti avere 4 gruppi di 3 alu ciascuno che lavora sui vertici e il restante sui pixel
Ren
10-11-2005, 13:06
Più so al riguardo di r500 + rsx sembra una caccola.... :D
BTinside
17-11-2006, 16:28
io mi baso sugli shot e IMHo PS3 spacca di brutto 360!!! Senza contare che i giochi di 360 sono 720p mentre quelli PS3 sono 1080p!!!!!!
ahaha, quante ne abbiamo sparate ragazzi, nei primi post ci sono io che dico che la eDRAM del 360 è di 16mb :asd:
Però ci siamo divertiti. :p
P.s. chiedo scusa per l'apertura di un thread omonimo, ma questo è datato 2005 e il tasto ricerca non me l'ha mostrato, se l'avessi saputo prima avrei usato questo. :)
ahaha, quante ne abbiamo sparate ragazzi, nei primi post ci sono io che dico che la eDRAM del 360 è di 16mb :asd:
Però ci siamo divertiti. :p
P.s. chiedo scusa per l'apertura di un thread omonimo, ma questo è datato 2005 e il tasto ricerca non me l'ha mostrato, se l'avessi saputo prima avrei usato questo. :)
kenjcj2000
17-11-2006, 21:00
Allora letto tutto al volo (saluti a FEK e YOS) anche grazie alla presenza dei nostri espertoni....
Come vado dicendo da tempo credo che fra le due macchine esiste una sostanziale parità... e di conseguenza la differenza la farà chi ci programma sopra
Come vado dicendo da tempo credo che fra le due macchine esiste una sostanziale parità... e di conseguenza la differenza la farà chi ci programma sopra
BTinside
18-11-2006, 11:04
:asd:
PS3 presa a martellate :
http://img83.imageshack.us/img83/9409/ps3smahsi5.jpg
Xbox 360 di un camionista dopo un gravissimo incidente con il camion :
http://img93.imageshack.us/img93/194/360grfo6.jpg
PS3 presa a martellate :
http://img83.imageshack.us/img83/9409/ps3smahsi5.jpg
Xbox 360 di un camionista dopo un gravissimo incidente con il camion :
http://img93.imageshack.us/img93/194/360grfo6.jpg
PeK
19-11-2006, 20:14
rotfl :asd:
leggere i primi commenti :asd:
5 mesi di ritardo, doppia uscita hdmi, 3 schede di rete :sofico:
leggere i primi commenti :asd:
5 mesi di ritardo, doppia uscita hdmi, 3 schede di rete :sofico:
dididj
21-11-2006, 08:27
As long as consoles have existed, discussions, debates, arguments, fights, and all out WARS have taken place over who makes the best video game units. Growing up, I was always a Nintendo fan boy; I didn't want to hear anything about Sega Genesis... In my mind, Nintendo had Mario, Zelda, and other great first-party titles. Sega had Sonic, and red blood.
Things are slightly more complicated these days however. Console makers are taking different approaches to designing their products; some go for hardcore processing power, others focus more on online gaming. We already have a heated debate going on in our forum about which console is better, PS3 or XBOX 360.
I thought it would be a good idea to ask my friend, who is a lead programmer for a large gaming company that produces games for both PS3 and XBOX 360. He has also worked on PS2, XBOX 1, and PC games in the past 6-or-so years. Obviously, considering his position working with both consoles and both Sony and Microsoft, he doesn't want to step on any toes, so wishes to remain anonymous at this time. Here are his thoughts on the subject:
Being a video game developer (I develop for both, Playstation 3 and XBOX 360) people ask me almost daily which platform I think is better. These are my personal feelings, in no way does this reflect my employer.
Short answer: XBOX 360.
Long answer: Price, performance, visual quality, game selection and online support. I think the XBOX 360 wins in every category.
Price: This is obvious; the XBOX 360 core is only $299. The PS3 is around $499 for the 20GB version. It comes with a hard drive, but you don’t need a hard drive to enjoy a lot of great games on the 360 so I think it’s fair to compare both core systems.
Performance: On paper, the PS3 is more powerful. In reality, it’s quite inferior to the 360. Without getting into too many details, the three general-purpose CPU’s the xbox360 has are currently FAR easier to take advantage of than the SPU’s on the PS3. I suspect a few years down the road some high budget, first party PS3 exclusive titles will come out that really take advantage of the SPU’s and do things the XBOX 360 can’t, but I don’t think the console is worth buying based on this speculation (for some it will be though, we'll have to wait and see how these games turn out).
Graphics: The XBOX 360 is a clear winner. The GPU is more powerful. It has more powerful fillrate, and far more pixel and vertex processing horsepower. Part of the reason is their choice of memory, and architecture of pixel and vertex procesing. I can’t get into details but the same vertex shader will run much slower on the PS3 than the XBOX 360. The 360 also has a clever new way rendering high definition anti aliased back buffers. To accomplish the same effect on PS3 is prohibitively expensive. For this reason I think many games will have no choice but to run in non-HD resolutions on the PS3 version, use a lower quality anti aliasing technique, or do back buffer upscaling. The end result in all cases is going to be noticeably worse image quality.
Game Selection: The XBOX 360 has a huge head start here. 1 year is an eternity in gaming. Almost all multi-platform developers have made the XBOX 360 their primary platform due to timing of release-to-market, this means the games will look and perform better on the 360. The PS3 versions will be ports of the 360 versions. (The opposite was true for XBOX 1 vs. PS2). The XBOX 360 is also far faster to develop for due to better development tools (massively popular Visual Studio .NET vs. proprietary, buggy PS3 compiler and debugger), better documentation, and easier architecture (3 general purpose CPU’s vs. 8 specialized processors that require DMA). Timing has also caused all next-gen middleware developers to make XBOX 360 their primary platform, and they will ‘add ps3 support’ as needed. This support will probably be inferior to the XBOX 360’s due to manpower and more importantly, demand. It’s this catch-22 now that will continue to drive the 360 forward and hold PS3 back.
The other obvious point here is that right now the Xbox360 already has a very impressive line-up of titles on store shelves; the ps3 just launched, and has virtually nothing of interest. Also, many 360 games are already discounted ($35 for Fight Night 3 on Amazon). PS3 games are all full price since it just launched.
Live: Microsoft’s online support with XBOX1 was phenomenal. They built in-house experience, user base, facilities, $$ commitment from executive level (since it proved successful), and most importantly, feedback from 100,000s of XBOX Live subscribers. Playstation 2’s online support sucked. They are now playing catch-up, trying to emulate Xbox’s model. But they had their hands tied just trying to make the PS3 work, it was incredibly ambitious (blu-ray etc.). I haven’t seen it yet, but I seriously doubt the quality will be anywhere to the level of XBOX 360.
HD Content: The PS3 comes with one built in (blu-ray). The XBOX 360 offers HD-DVD as an add-on for $200. You probably don’t care about HD-DVD right now. But you will soon (The quality between DVD and HD is comparable to VHS vs DVD, if you have the right TV) so I suggest paying attention to the war that’s begun. There are two formats: HD-DVD and BLU-RAY. Basically if you rent a BLU-RAY DVD from Bockbuster, it won’t play in your XBOX 360 HD-DVD, and vice versa with the PS3. The implications of this format war would require another article on its own. But as far as the consoles are concerned, the XBOX 360 wins because the DVD player is a separate unit. Playing movies is very taxing on the DVD reader, and let’s face it. In 3 years when your PS3 DVD drive goes out due to playing lots of movies (PS2 was notoriously bad about this) you will have to go buy another PS3. With the 360, you’ll just chuck your HD-DVD player, and go buy another one at the store. In 3 years standalone units wlil probably only cost about $99-150. Another point for the XBOX 360, is that I don’t know who will win the format-war, so I would rather wait with purchase of a HD player. The PS3 doesn’t give you this option.
Things are slightly more complicated these days however. Console makers are taking different approaches to designing their products; some go for hardcore processing power, others focus more on online gaming. We already have a heated debate going on in our forum about which console is better, PS3 or XBOX 360.
I thought it would be a good idea to ask my friend, who is a lead programmer for a large gaming company that produces games for both PS3 and XBOX 360. He has also worked on PS2, XBOX 1, and PC games in the past 6-or-so years. Obviously, considering his position working with both consoles and both Sony and Microsoft, he doesn't want to step on any toes, so wishes to remain anonymous at this time. Here are his thoughts on the subject:
Being a video game developer (I develop for both, Playstation 3 and XBOX 360) people ask me almost daily which platform I think is better. These are my personal feelings, in no way does this reflect my employer.
Short answer: XBOX 360.
Long answer: Price, performance, visual quality, game selection and online support. I think the XBOX 360 wins in every category.
Price: This is obvious; the XBOX 360 core is only $299. The PS3 is around $499 for the 20GB version. It comes with a hard drive, but you don’t need a hard drive to enjoy a lot of great games on the 360 so I think it’s fair to compare both core systems.
Performance: On paper, the PS3 is more powerful. In reality, it’s quite inferior to the 360. Without getting into too many details, the three general-purpose CPU’s the xbox360 has are currently FAR easier to take advantage of than the SPU’s on the PS3. I suspect a few years down the road some high budget, first party PS3 exclusive titles will come out that really take advantage of the SPU’s and do things the XBOX 360 can’t, but I don’t think the console is worth buying based on this speculation (for some it will be though, we'll have to wait and see how these games turn out).
Graphics: The XBOX 360 is a clear winner. The GPU is more powerful. It has more powerful fillrate, and far more pixel and vertex processing horsepower. Part of the reason is their choice of memory, and architecture of pixel and vertex procesing. I can’t get into details but the same vertex shader will run much slower on the PS3 than the XBOX 360. The 360 also has a clever new way rendering high definition anti aliased back buffers. To accomplish the same effect on PS3 is prohibitively expensive. For this reason I think many games will have no choice but to run in non-HD resolutions on the PS3 version, use a lower quality anti aliasing technique, or do back buffer upscaling. The end result in all cases is going to be noticeably worse image quality.
Game Selection: The XBOX 360 has a huge head start here. 1 year is an eternity in gaming. Almost all multi-platform developers have made the XBOX 360 their primary platform due to timing of release-to-market, this means the games will look and perform better on the 360. The PS3 versions will be ports of the 360 versions. (The opposite was true for XBOX 1 vs. PS2). The XBOX 360 is also far faster to develop for due to better development tools (massively popular Visual Studio .NET vs. proprietary, buggy PS3 compiler and debugger), better documentation, and easier architecture (3 general purpose CPU’s vs. 8 specialized processors that require DMA). Timing has also caused all next-gen middleware developers to make XBOX 360 their primary platform, and they will ‘add ps3 support’ as needed. This support will probably be inferior to the XBOX 360’s due to manpower and more importantly, demand. It’s this catch-22 now that will continue to drive the 360 forward and hold PS3 back.
The other obvious point here is that right now the Xbox360 already has a very impressive line-up of titles on store shelves; the ps3 just launched, and has virtually nothing of interest. Also, many 360 games are already discounted ($35 for Fight Night 3 on Amazon). PS3 games are all full price since it just launched.
Live: Microsoft’s online support with XBOX1 was phenomenal. They built in-house experience, user base, facilities, $$ commitment from executive level (since it proved successful), and most importantly, feedback from 100,000s of XBOX Live subscribers. Playstation 2’s online support sucked. They are now playing catch-up, trying to emulate Xbox’s model. But they had their hands tied just trying to make the PS3 work, it was incredibly ambitious (blu-ray etc.). I haven’t seen it yet, but I seriously doubt the quality will be anywhere to the level of XBOX 360.
HD Content: The PS3 comes with one built in (blu-ray). The XBOX 360 offers HD-DVD as an add-on for $200. You probably don’t care about HD-DVD right now. But you will soon (The quality between DVD and HD is comparable to VHS vs DVD, if you have the right TV) so I suggest paying attention to the war that’s begun. There are two formats: HD-DVD and BLU-RAY. Basically if you rent a BLU-RAY DVD from Bockbuster, it won’t play in your XBOX 360 HD-DVD, and vice versa with the PS3. The implications of this format war would require another article on its own. But as far as the consoles are concerned, the XBOX 360 wins because the DVD player is a separate unit. Playing movies is very taxing on the DVD reader, and let’s face it. In 3 years when your PS3 DVD drive goes out due to playing lots of movies (PS2 was notoriously bad about this) you will have to go buy another PS3. With the 360, you’ll just chuck your HD-DVD player, and go buy another one at the store. In 3 years standalone units wlil probably only cost about $99-150. Another point for the XBOX 360, is that I don’t know who will win the format-war, so I would rather wait with purchase of a HD player. The PS3 doesn’t give you this option.
Window Vista
22-11-2006, 14:40
Il sito HardCoreWare.net ha pubblicato recentemente un'analisi svolta da uno sviluppatore anonimo sulle caratteristiche tecniche e pratiche delle due console di nuova generazione targate Sony e Microsoft.
Lo sviluppatore ha preferito mantenere l'anonimato per non creare attriti con l'azienda per cui lavora, sottolineando di avere all'attivo 6 anni di sviluppo con videogiochi per PC, Xbox e PlayStation 2 ed essere al lavoro su nuovi progetti per Xbox 360 e PlayStation 3.
Partendo dal prezzo naturalmente la vincitrice è Xbox 360 che nella versione Core offre uno scorcio next-gen partendo da 299 Euro, pur ammettendo che PlayStation 3 con 20 GB di Hard Disk possa offrire qualcosa di più che però non vale i 200 Euro di differenza.
Ma le prestazioni? Secondo lo sviluppatore la chiara vincitrice del confronto è Xbox 360 in quanto pur avendo un processore che sulla carta è meno potente, offre una maggiore semplicità di sviluppo. I tre core del processore PowerPC incluso in Xbox 360 sono assolutamente più immediati da controllare rispetto al processore Cell di PlayStation 3 e, secondo lo sviluppatore, solamente software house ad alto budget o interne a Sony riusciranno a sfruttare adeguatamente l'SPU della nuova console.
La grafica è un altro punto a favore di Xbox 360, oltre che sulla carta anche nella realtà. Il fillrate (ovvero la velocità di movimento dei punti sullo schermo) e la potenza di calcolo per pixel e vertex shader è superiore a quella del chip grafico RSX di PlayStation 3. Sembra inoltre che nell'uso della console in schermi non-HD la qualità video di Xbox 360 sia avvantaggiata da un sistema migliore di Anti-Aliasing.
Anche lo sviluppo di videogiochi su Xbox 360 è più semplice che su PlayStation 3, grazie a una piattaforma Visual Studio .NET già collaudata che è alla base della piattaforma XNA.
Viene messa anche in dubbio la piattaforma online di PlayStation 3, ma lo stesso sviluppatore ammette di averla rpovata poco e non può esprimersi più di tanto.
Infine, l'alta definizione nei film. Se da un lato PlayStation 3 integra un lettore Blu-ray ed è pronta all'uso, Xbox 360 riesce a diventare un ottimo lettore HD-DVD acquistando un accessorio. La differenza tra un film in alta definizione e uno tradizionale, secondo lo sviluppatore, è la stessa che c'è stata dal momento del passaggio dai film in VHS a quelli in DVD, con l'aggiunta di parecchie novità dal punto di vista interattivo. Si tratta comunque di una guerra di formati che interesserà solo in parte il successo di queste due piattaforme.
Qualche dubbio su quanto indicato da questo "anonimo" sviluppatore sorge sicuramente, anche se soprattutto la parte relativa alla semplicità di sviluppo combacia con quanto recentemente dichiarato da John Carmack, presidente di Id Software, che ha definito "Xbox 360 più semplice da programmare di un PC".
Agli appassionati interesserà tutta questa storia prima di acquistare la console di Microsoft o di Sony?
LINK:http://www.gamestar.it/showPage.php?template=News&id=8867&argomento=Xbox%20360
Lo sviluppatore ha preferito mantenere l'anonimato per non creare attriti con l'azienda per cui lavora, sottolineando di avere all'attivo 6 anni di sviluppo con videogiochi per PC, Xbox e PlayStation 2 ed essere al lavoro su nuovi progetti per Xbox 360 e PlayStation 3.
Partendo dal prezzo naturalmente la vincitrice è Xbox 360 che nella versione Core offre uno scorcio next-gen partendo da 299 Euro, pur ammettendo che PlayStation 3 con 20 GB di Hard Disk possa offrire qualcosa di più che però non vale i 200 Euro di differenza.
Ma le prestazioni? Secondo lo sviluppatore la chiara vincitrice del confronto è Xbox 360 in quanto pur avendo un processore che sulla carta è meno potente, offre una maggiore semplicità di sviluppo. I tre core del processore PowerPC incluso in Xbox 360 sono assolutamente più immediati da controllare rispetto al processore Cell di PlayStation 3 e, secondo lo sviluppatore, solamente software house ad alto budget o interne a Sony riusciranno a sfruttare adeguatamente l'SPU della nuova console.
La grafica è un altro punto a favore di Xbox 360, oltre che sulla carta anche nella realtà. Il fillrate (ovvero la velocità di movimento dei punti sullo schermo) e la potenza di calcolo per pixel e vertex shader è superiore a quella del chip grafico RSX di PlayStation 3. Sembra inoltre che nell'uso della console in schermi non-HD la qualità video di Xbox 360 sia avvantaggiata da un sistema migliore di Anti-Aliasing.
Anche lo sviluppo di videogiochi su Xbox 360 è più semplice che su PlayStation 3, grazie a una piattaforma Visual Studio .NET già collaudata che è alla base della piattaforma XNA.
Viene messa anche in dubbio la piattaforma online di PlayStation 3, ma lo stesso sviluppatore ammette di averla rpovata poco e non può esprimersi più di tanto.
Infine, l'alta definizione nei film. Se da un lato PlayStation 3 integra un lettore Blu-ray ed è pronta all'uso, Xbox 360 riesce a diventare un ottimo lettore HD-DVD acquistando un accessorio. La differenza tra un film in alta definizione e uno tradizionale, secondo lo sviluppatore, è la stessa che c'è stata dal momento del passaggio dai film in VHS a quelli in DVD, con l'aggiunta di parecchie novità dal punto di vista interattivo. Si tratta comunque di una guerra di formati che interesserà solo in parte il successo di queste due piattaforme.
Qualche dubbio su quanto indicato da questo "anonimo" sviluppatore sorge sicuramente, anche se soprattutto la parte relativa alla semplicità di sviluppo combacia con quanto recentemente dichiarato da John Carmack, presidente di Id Software, che ha definito "Xbox 360 più semplice da programmare di un PC".
Agli appassionati interesserà tutta questa storia prima di acquistare la console di Microsoft o di Sony?
LINK:http://www.gamestar.it/showPage.php?template=News&id=8867&argomento=Xbox%20360
dididj
22-11-2006, 14:44
è la versione ridotta di quello che avevo riportato pocanzi.
javaboy
22-11-2006, 15:12
Ma su xbox 360 è possibile programmare in c#?
Ci sono dei giochi scritti in questo linguaggio per xbox360?
Ci sono dei giochi scritti in questo linguaggio per xbox360?
dossier
22-11-2006, 18:10
Il sito HardCoreWare.net ha pubblicato recentemente un'analisi svolta da uno sviluppatore anonimo sulle caratteristiche tecniche e pratiche delle due console di nuova generazione targate Sony e Microsoft.
Lo sviluppatore ha preferito mantenere l'anonimato per non creare attriti con l'azienda per cui lavora, sottolineando di avere all'attivo 6 anni di sviluppo con videogiochi per PC, Xbox e PlayStation 2 ed essere al lavoro su nuovi progetti per Xbox 360 e PlayStation 3.
Partendo dal prezzo naturalmente la vincitrice è Xbox 360 che nella versione Core offre uno scorcio next-gen partendo da 299 Euro, pur ammettendo che PlayStation 3 con 20 GB di Hard Disk possa offrire qualcosa di più che però non vale i 200 Euro di differenza.
Ma le prestazioni? Secondo lo sviluppatore la chiara vincitrice del confronto è Xbox 360 in quanto pur avendo un processore che sulla carta è meno potente, offre una maggiore semplicità di sviluppo. I tre core del processore PowerPC incluso in Xbox 360 sono assolutamente più immediati da controllare rispetto al processore Cell di PlayStation 3 e, secondo lo sviluppatore, solamente software house ad alto budget o interne a Sony riusciranno a sfruttare adeguatamente l'SPU della nuova console.
La grafica è un altro punto a favore di Xbox 360, oltre che sulla carta anche nella realtà. Il fillrate (ovvero la velocità di movimento dei punti sullo schermo) e la potenza di calcolo per pixel e vertex shader è superiore a quella del chip grafico RSX di PlayStation 3. Sembra inoltre che nell'uso della console in schermi non-HD la qualità video di Xbox 360 sia avvantaggiata da un sistema migliore di Anti-Aliasing.
Anche lo sviluppo di videogiochi su Xbox 360 è più semplice che su PlayStation 3, grazie a una piattaforma Visual Studio .NET già collaudata che è alla base della piattaforma XNA.
Viene messa anche in dubbio la piattaforma online di PlayStation 3, ma lo stesso sviluppatore ammette di averla rpovata poco e non può esprimersi più di tanto.
Infine, l'alta definizione nei film. Se da un lato PlayStation 3 integra un lettore Blu-ray ed è pronta all'uso, Xbox 360 riesce a diventare un ottimo lettore HD-DVD acquistando un accessorio. La differenza tra un film in alta definizione e uno tradizionale, secondo lo sviluppatore, è la stessa che c'è stata dal momento del passaggio dai film in VHS a quelli in DVD, con l'aggiunta di parecchie novità dal punto di vista interattivo. Si tratta comunque di una guerra di formati che interesserà solo in parte il successo di queste due piattaforme.
Qualche dubbio su quanto indicato da questo "anonimo" sviluppatore sorge sicuramente, anche se soprattutto la parte relativa alla semplicità di sviluppo combacia con quanto recentemente dichiarato da John Carmack, presidente di Id Software, che ha definito "Xbox 360 più semplice da programmare di un PC".
Agli appassionati interesserà tutta questa storia prima di acquistare la console di Microsoft o di Sony?
LINK:http://www.gamestar.it/showPage.php?template=News&id=8867&argomento=Xbox%20360
:) ste cose hanno valenza zero il mondo è pieno di perosne che si improvvisano sviluppatori anonimi :asd:
Lo sviluppatore ha preferito mantenere l'anonimato per non creare attriti con l'azienda per cui lavora, sottolineando di avere all'attivo 6 anni di sviluppo con videogiochi per PC, Xbox e PlayStation 2 ed essere al lavoro su nuovi progetti per Xbox 360 e PlayStation 3.
Partendo dal prezzo naturalmente la vincitrice è Xbox 360 che nella versione Core offre uno scorcio next-gen partendo da 299 Euro, pur ammettendo che PlayStation 3 con 20 GB di Hard Disk possa offrire qualcosa di più che però non vale i 200 Euro di differenza.
Ma le prestazioni? Secondo lo sviluppatore la chiara vincitrice del confronto è Xbox 360 in quanto pur avendo un processore che sulla carta è meno potente, offre una maggiore semplicità di sviluppo. I tre core del processore PowerPC incluso in Xbox 360 sono assolutamente più immediati da controllare rispetto al processore Cell di PlayStation 3 e, secondo lo sviluppatore, solamente software house ad alto budget o interne a Sony riusciranno a sfruttare adeguatamente l'SPU della nuova console.
La grafica è un altro punto a favore di Xbox 360, oltre che sulla carta anche nella realtà. Il fillrate (ovvero la velocità di movimento dei punti sullo schermo) e la potenza di calcolo per pixel e vertex shader è superiore a quella del chip grafico RSX di PlayStation 3. Sembra inoltre che nell'uso della console in schermi non-HD la qualità video di Xbox 360 sia avvantaggiata da un sistema migliore di Anti-Aliasing.
Anche lo sviluppo di videogiochi su Xbox 360 è più semplice che su PlayStation 3, grazie a una piattaforma Visual Studio .NET già collaudata che è alla base della piattaforma XNA.
Viene messa anche in dubbio la piattaforma online di PlayStation 3, ma lo stesso sviluppatore ammette di averla rpovata poco e non può esprimersi più di tanto.
Infine, l'alta definizione nei film. Se da un lato PlayStation 3 integra un lettore Blu-ray ed è pronta all'uso, Xbox 360 riesce a diventare un ottimo lettore HD-DVD acquistando un accessorio. La differenza tra un film in alta definizione e uno tradizionale, secondo lo sviluppatore, è la stessa che c'è stata dal momento del passaggio dai film in VHS a quelli in DVD, con l'aggiunta di parecchie novità dal punto di vista interattivo. Si tratta comunque di una guerra di formati che interesserà solo in parte il successo di queste due piattaforme.
Qualche dubbio su quanto indicato da questo "anonimo" sviluppatore sorge sicuramente, anche se soprattutto la parte relativa alla semplicità di sviluppo combacia con quanto recentemente dichiarato da John Carmack, presidente di Id Software, che ha definito "Xbox 360 più semplice da programmare di un PC".
Agli appassionati interesserà tutta questa storia prima di acquistare la console di Microsoft o di Sony?
LINK:http://www.gamestar.it/showPage.php?template=News&id=8867&argomento=Xbox%20360
:) ste cose hanno valenza zero il mondo è pieno di perosne che si improvvisano sviluppatori anonimi :asd:
*sasha ITALIA*
22-11-2006, 18:41
:cry: la Sony aveva ancora la mia stima :cry:
dididj
23-11-2006, 15:16
posto anche qua perchè mi pare stia morendo il thread :(
ppu ps3 vs g5
pare che l'unità powerpc del cell sia un pò più lenta di un g5 a 1.6ghz
http://www.geekpatrol.ca/2006/11/playstation-3-performance/
ppu ps3 vs g5
pare che l'unità powerpc del cell sia un pò più lenta di un g5 a 1.6ghz
http://www.geekpatrol.ca/2006/11/playstation-3-performance/
sslazio
23-11-2006, 15:24
posto anche qua perchè mi pare stia morendo il thread :(
ppu ps3 vs g5
pare che l'unità powerpc del cell sia un pò più lenta di un g5 a 1.6ghz
http://www.geekpatrol.ca/2006/11/playstation-3-performance/
bhè non mi sembra sia proprio così, in alcuni casi scoperchia letteralmente il G5 anche di 4 volte.
Inoltre c'è sicuramente bisogno si ottimizzare il codice della cpu meglio per linux, non appena lo faranno non escludo di vedere numeri triplicati se non quintuplicati.
E poi non dimentichiamoci che la PS2 ha solo 256 mega che sono veramente ma veramente pochi.
ppu ps3 vs g5
pare che l'unità powerpc del cell sia un pò più lenta di un g5 a 1.6ghz
http://www.geekpatrol.ca/2006/11/playstation-3-performance/
bhè non mi sembra sia proprio così, in alcuni casi scoperchia letteralmente il G5 anche di 4 volte.
Inoltre c'è sicuramente bisogno si ottimizzare il codice della cpu meglio per linux, non appena lo faranno non escludo di vedere numeri triplicati se non quintuplicati.
E poi non dimentichiamoci che la PS2 ha solo 256 mega che sono veramente ma veramente pochi.
dididj
23-11-2006, 15:43
i casi in cui scoperchia il g5 sono quelli di scrittura intensiva dove si fa decisamente sentire la bandwidth delle xdr.
per il discorso ram "Geekbench results don’t vary with the amount of physical RAM installed provided the amount of free RAM is over 100MB when Geekbench runs."
motivi per cui la ppu del cell è più lenta del corrispettivo g5:
1.) PPE has 32 KB L1 I-Cache while the PowerPC 970 has 64 KB of L1 I-Cache.
2.) The PowerPC 970 is a dynamically scheduled (Out Of Order execution) core, albeit tracking instruction groups and not individual instructions. The PPE is a statically scheduled (In program Order execution) core. The G5 can cover L1 cache misses and mitigate a bit L2 cache misses, CELL’s PPE just stalls.
3.) CELL’s PPE execution units: 1 Load/Store Unit (or LSU) and 1 FXU (arithmetic integer and fixed-point instructions as well as shifts and rotates, etc…) that are fed from the main instruction queue and 1 VSU (Vector/Scalar Unit: it has its own instruction queue that feeds the VMX unit and the FPU) so the very best case scenario would be four decoded instructions executed per clock cycle with the right mix of FP heavy and Integer heavy threads.
http://researchweb.watson.ibm.com/journal/rd/494/kahle.pdf (and also
the CELL BE Programming handbook
http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/9F820A5FFA3ECE8C8725716A0062585F/$file/BEHandbookv1.0_10May2006.pdf
at page 751 details the valid dual-issue possibilities, but note that the main Issue Queue can issue two instructions like 1 LSU and 1 FXU while the Vector/Scalar Issue Queue issues two instructions to the VMX unit and to the FPU block in theory).
To make a long story short, the PowerPC 970 has 2x the number of FXU’s and 2x the LSU’s compared to the PPE and in the very best case scenario it can execute 8 decoded instructions (IOP’s) in parallel when all the issue queues have something to deliver (do not count the Branch Unit and the Condition Register Unit):
http://arstechnica.com/cpu/02q2/ppc970/images/ppc-970-large-diagram.png
http://arstechnica.com/cpu/02q2/ppc970/screenshot-1.html
per il discorso ram "Geekbench results don’t vary with the amount of physical RAM installed provided the amount of free RAM is over 100MB when Geekbench runs."
motivi per cui la ppu del cell è più lenta del corrispettivo g5:
1.) PPE has 32 KB L1 I-Cache while the PowerPC 970 has 64 KB of L1 I-Cache.
2.) The PowerPC 970 is a dynamically scheduled (Out Of Order execution) core, albeit tracking instruction groups and not individual instructions. The PPE is a statically scheduled (In program Order execution) core. The G5 can cover L1 cache misses and mitigate a bit L2 cache misses, CELL’s PPE just stalls.
3.) CELL’s PPE execution units: 1 Load/Store Unit (or LSU) and 1 FXU (arithmetic integer and fixed-point instructions as well as shifts and rotates, etc…) that are fed from the main instruction queue and 1 VSU (Vector/Scalar Unit: it has its own instruction queue that feeds the VMX unit and the FPU) so the very best case scenario would be four decoded instructions executed per clock cycle with the right mix of FP heavy and Integer heavy threads.
http://researchweb.watson.ibm.com/journal/rd/494/kahle.pdf (and also
the CELL BE Programming handbook
http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/9F820A5FFA3ECE8C8725716A0062585F/$file/BEHandbookv1.0_10May2006.pdf
at page 751 details the valid dual-issue possibilities, but note that the main Issue Queue can issue two instructions like 1 LSU and 1 FXU while the Vector/Scalar Issue Queue issues two instructions to the VMX unit and to the FPU block in theory).
To make a long story short, the PowerPC 970 has 2x the number of FXU’s and 2x the LSU’s compared to the PPE and in the very best case scenario it can execute 8 decoded instructions (IOP’s) in parallel when all the issue queues have something to deliver (do not count the Branch Unit and the Condition Register Unit):
http://arstechnica.com/cpu/02q2/ppc970/images/ppc-970-large-diagram.png
http://arstechnica.com/cpu/02q2/ppc970/screenshot-1.html
Free Gordon
23-11-2006, 18:23
bhè non mi sembra sia proprio così, in alcuni casi scoperchia letteralmente il G5 anche di 4 volte.
Inoltre c'è sicuramente bisogno si ottimizzare il codice della cpu meglio per linux, non appena lo faranno non escludo di vedere numeri triplicati se non quintuplicati.
E poi non dimentichiamoci che la PS2 ha solo 256 mega che sono veramente ma veramente pochi.
C'è la risposta di panjev sotto all'articolo, che spiega i motivi di queste povere perfomance.
La PPU servirà al cell per coordinare le spe, l'uso del cell, ottimizzato nei giochi PS3, sarà tutto un altro.
Inoltre c'è sicuramente bisogno si ottimizzare il codice della cpu meglio per linux, non appena lo faranno non escludo di vedere numeri triplicati se non quintuplicati.
E poi non dimentichiamoci che la PS2 ha solo 256 mega che sono veramente ma veramente pochi.
C'è la risposta di panjev sotto all'articolo, che spiega i motivi di queste povere perfomance.
La PPU servirà al cell per coordinare le spe, l'uso del cell, ottimizzato nei giochi PS3, sarà tutto un altro.
dididj
25-11-2006, 10:02
test della sola ppu del cell:
Dhrystone v2.1
PS3 Cell 3.2GHz: 1879.630
PowerPC G4 1.25GHz: 2202.600
PentiumIII 866MHz: 1124.311
Pentium4 2.0AGHz: 1694.717
Pentium4 3.2GHz: 3258.068
Linpack 100x100 Benchmark In C/C++ (Rolled Double Precision)
PS3 Cell 3.2GHz: 315.71
PentiumIII 866MHz: 313.05
Pentium4 2.0AGHz: 683.91
Pentium4 3.2GHz: 770.66
Athlon64 X2 4400+ (2.2GHz): 781.58
Linpack 100x100 Benchmark In C/C++ (Rolled Single Precision)
PS3 Cell 3.2GHz: 312.64
PentiumIII 866MHz: 198.7
Pentium4 2.0AGHz: 82.57
Pentium4 3.2GHz: 276.14
Athlon64 X2 4400+ (2.2GHz): 538.05
Dhrystone v2.1
PS3 Cell 3.2GHz: 1879.630
PowerPC G4 1.25GHz: 2202.600
PentiumIII 866MHz: 1124.311
Pentium4 2.0AGHz: 1694.717
Pentium4 3.2GHz: 3258.068
Linpack 100x100 Benchmark In C/C++ (Rolled Double Precision)
PS3 Cell 3.2GHz: 315.71
PentiumIII 866MHz: 313.05
Pentium4 2.0AGHz: 683.91
Pentium4 3.2GHz: 770.66
Athlon64 X2 4400+ (2.2GHz): 781.58
Linpack 100x100 Benchmark In C/C++ (Rolled Single Precision)
PS3 Cell 3.2GHz: 312.64
PentiumIII 866MHz: 198.7
Pentium4 2.0AGHz: 82.57
Pentium4 3.2GHz: 276.14
Athlon64 X2 4400+ (2.2GHz): 538.05
Pecio
29-11-2006, 16:51
be ma effettivamente voi quale comprereste?
!!xbox 360 o ps3!!a me sinceramente dopo aver letto tutto prenderei 360..costa meno..più facile da programmare..più sfruttabile quindi...x vedere giochi più belli di 360 su ps3 bisognerà aspettare almeno 3 4 anni...
!!xbox 360 o ps3!!a me sinceramente dopo aver letto tutto prenderei 360..costa meno..più facile da programmare..più sfruttabile quindi...x vedere giochi più belli di 360 su ps3 bisognerà aspettare almeno 3 4 anni...
pippomostarda
29-11-2006, 19:17
entrambe ovviamente.Il box già ce l'ho e la play sarà mia al day1... :D
aceto876
29-11-2006, 19:34
be ma effettivamente voi quale comprereste?
!!xbox 360 o ps3!!a me sinceramente dopo aver letto tutto prenderei 360..costa meno..più facile da programmare..più sfruttabile quindi...x vedere giochi più belli di 360 su ps3 bisognerà aspettare almeno 3 4 anni...
L'xbox l'ho presa per gears of war e cod3. In teoria avrei anche MOTOGP06 se mi mandassero la copia in sostituzione. Ma campa cavallo...in pratica pare che me lo devono stampare apposta...
!!xbox 360 o ps3!!a me sinceramente dopo aver letto tutto prenderei 360..costa meno..più facile da programmare..più sfruttabile quindi...x vedere giochi più belli di 360 su ps3 bisognerà aspettare almeno 3 4 anni...
L'xbox l'ho presa per gears of war e cod3. In teoria avrei anche MOTOGP06 se mi mandassero la copia in sostituzione. Ma campa cavallo...in pratica pare che me lo devono stampare apposta...
BTinside
01-12-2006, 19:10
http://www.1up.com/do/feature?pager.offset=0&cId=3155393
Vorrei dare un mio parere sui video e sulle immagini :
Tiger Woods 07
La versione PS3 appare più dettagliata nei colori e nelle foglie degli alberi, ma ha un lod leggermente inferiore, ovvero nello stesso screenshot, alle spalle del giocatore di golf mancano un tronco d'albero e vi è la metà degli spettatori rispetto la versione 360, per il resto sembrano identici.
http://media.1up.com/media?id=3106455&type=lg
Call of Duty 3
La versione 360 ha dei colori più saturi, il dettaglio invece mi sembra identico ma con qualche texture un pelo più definita, ma proprio di poco. Poi, a detta delle recensioni, vi sono cali di framerate che la versione 360 non ha.
http://media.1up.com/media?id=3105431&type=lg
Madden NFL 07
Per Madden vale lo stesso discorso di Cod 3.
http://media.1up.com/media?id=3106436&type=lg
Ridge Racer 6 e 7
Personalmente, trovo più realistica la versione PS3, mi piace di più perchè gode di textures migliori, mentre la versione 360, ha effetti d'illuminazione un pò irrealistici e sparati.
http://media.1up.com/media?id=3106427&type=lg
http://media.1up.com/media?id=3106603&type=lg
Toni Hawk P.8
Colori lievemente migliori su PS3, textures pressocchè identiche in entrambe le versioni ed un effetto blooming molto più accentuato su X360, lo si vede all'inizio del video e sugli stecciati. Preferisco la versione PS3, quella 360 è troppo carica di blooming.
http://media.1up.com/media?id=3106450&type=lg
NBA 2K7
Stesso discorso di Cod 3, con in più il fatto che le textures del pavimento del campo di gioco sono più sgranate su PS3.
http://media.1up.com/media?id=3106453&type=lg
NFS Carbon
Textures un pelo più sgranate per la versione PS3 ma colori lievemente più vividi.
http://media.1up.com/media?id=3106452&type=lg
Marvel Ultimate Allianceù
Nella versione PS3 le fiamme nello shot sono più complesse, così come gli effetti particellari della bolla di fumo.
Superiore e maggiormente complessa su PS3 è anche l'illuminazione, basta guardare il riflesso del fuoco sulle tubature di sinistra e sul pavimento sottostante, è evidentemente più realistica e complessa.
http://media.1up.com/media?id=3106439&type=lg
Blazing Angels
La versione PS3 è molto superiore, sembra un altro gioco, a partire dall'aereo, in complessità e textures e l'ombra che riflette sull'asfalto (assente su 360), i dettagli ambientali e gli edifici, la qualità del cielo e la quantità di nuvole. Tutto migliore.
Infine, a parte tutto, la solita esagerazione di effetti e blooming nella versione 360, la irrealisticità dell'effetto sole, che nella versione PS3 è di gran lunga più realistico e sobrio.
Forse solo l'acqua è superiore nella versione 360.
http://media.1up.com/media?id=3106443&type=lg
http://media.1up.com/media?id=3106444&type=lg
In conclusione, le versioni PS3 hanno un effetto più "sobrio", quasi voluto, come se lo standard PS3 è avere giochi non troppo esagerati e "sparati" dal punto di vista colori/effetti, ed è lo stile che preferisco personalmente (a parte Cod 3 in cui apprezzo i colori più accesi). Anche se, in alcuni casi le textures sono meno nitide. Su 360 invece spesso gli effetti sono troppo esagerati, un esempio rozzo di prima next generation.
Apprezzo però la maggior definizione delle textures su 360.
In pratica il massimo sarebbe la sobrietà delle versioni PS3 e il dettaglio textures delle versioni 360.
I colori meno accesi credo siano un effetto voluto.
Considerando che questi sono i titoli PS3 di primissima generazione (come quello 360 d'altronde), alla luce della maggior difficoltà di programmazione dell'hardware della console Sony, direi che sono risultati ottimi, ovviamente imho.
:)
Vorrei dare un mio parere sui video e sulle immagini :
Tiger Woods 07
La versione PS3 appare più dettagliata nei colori e nelle foglie degli alberi, ma ha un lod leggermente inferiore, ovvero nello stesso screenshot, alle spalle del giocatore di golf mancano un tronco d'albero e vi è la metà degli spettatori rispetto la versione 360, per il resto sembrano identici.
http://media.1up.com/media?id=3106455&type=lg
Call of Duty 3
La versione 360 ha dei colori più saturi, il dettaglio invece mi sembra identico ma con qualche texture un pelo più definita, ma proprio di poco. Poi, a detta delle recensioni, vi sono cali di framerate che la versione 360 non ha.
http://media.1up.com/media?id=3105431&type=lg
Madden NFL 07
Per Madden vale lo stesso discorso di Cod 3.
http://media.1up.com/media?id=3106436&type=lg
Ridge Racer 6 e 7
Personalmente, trovo più realistica la versione PS3, mi piace di più perchè gode di textures migliori, mentre la versione 360, ha effetti d'illuminazione un pò irrealistici e sparati.
http://media.1up.com/media?id=3106427&type=lg
http://media.1up.com/media?id=3106603&type=lg
Toni Hawk P.8
Colori lievemente migliori su PS3, textures pressocchè identiche in entrambe le versioni ed un effetto blooming molto più accentuato su X360, lo si vede all'inizio del video e sugli stecciati. Preferisco la versione PS3, quella 360 è troppo carica di blooming.
http://media.1up.com/media?id=3106450&type=lg
NBA 2K7
Stesso discorso di Cod 3, con in più il fatto che le textures del pavimento del campo di gioco sono più sgranate su PS3.
http://media.1up.com/media?id=3106453&type=lg
NFS Carbon
Textures un pelo più sgranate per la versione PS3 ma colori lievemente più vividi.
http://media.1up.com/media?id=3106452&type=lg
Marvel Ultimate Allianceù
Nella versione PS3 le fiamme nello shot sono più complesse, così come gli effetti particellari della bolla di fumo.
Superiore e maggiormente complessa su PS3 è anche l'illuminazione, basta guardare il riflesso del fuoco sulle tubature di sinistra e sul pavimento sottostante, è evidentemente più realistica e complessa.
http://media.1up.com/media?id=3106439&type=lg
Blazing Angels
La versione PS3 è molto superiore, sembra un altro gioco, a partire dall'aereo, in complessità e textures e l'ombra che riflette sull'asfalto (assente su 360), i dettagli ambientali e gli edifici, la qualità del cielo e la quantità di nuvole. Tutto migliore.
Infine, a parte tutto, la solita esagerazione di effetti e blooming nella versione 360, la irrealisticità dell'effetto sole, che nella versione PS3 è di gran lunga più realistico e sobrio.
Forse solo l'acqua è superiore nella versione 360.
http://media.1up.com/media?id=3106443&type=lg
http://media.1up.com/media?id=3106444&type=lg
In conclusione, le versioni PS3 hanno un effetto più "sobrio", quasi voluto, come se lo standard PS3 è avere giochi non troppo esagerati e "sparati" dal punto di vista colori/effetti, ed è lo stile che preferisco personalmente (a parte Cod 3 in cui apprezzo i colori più accesi). Anche se, in alcuni casi le textures sono meno nitide. Su 360 invece spesso gli effetti sono troppo esagerati, un esempio rozzo di prima next generation.
Apprezzo però la maggior definizione delle textures su 360.
In pratica il massimo sarebbe la sobrietà delle versioni PS3 e il dettaglio textures delle versioni 360.
I colori meno accesi credo siano un effetto voluto.
Considerando che questi sono i titoli PS3 di primissima generazione (come quello 360 d'altronde), alla luce della maggior difficoltà di programmazione dell'hardware della console Sony, direi che sono risultati ottimi, ovviamente imho.
:)
Marko91
04-12-2006, 07:18
Considerando che questi sono i titoli PS3 di primissima generazione (come quello 360 d'altronde), alla luce della maggior difficoltà di programmazione dell'hardware della console Sony, direi che sono risultati ottimi, ovviamente imho.
:)
Sicuramente è un ottimo risultato ma penso sia dovuto anche per il grande tempo che hanno avuto gli sviluppatori (quasi un'anno) e che in molti titoli multipiattaforma, il motore grafico della versione 360 è stato adattato a quella ps3.
Posto un'altra interessante analisi:
http://www.itvidya.com/playstation_3_vs_xbox_360
DETAILED ANALYSIS OF PERFORMANCE SPECIFICATIONS
CPU
The Xbox 360 processor was designed to give game developers the power that they actually need, in an easy to use form. The Cell processor has impressive streaming floating-point power that is of limited use for games.
The majority of game code is a mixture of integer, floating-point, and vector math, with lots of branches and random memory accesses. This code is best handled by a general purpose CPU with a cache, branch predictor, and vector unit.
The Cell's seven DSPs (what Sony calls SPEs) have no cache, no direct access to memory, no branch predictor, and a different instruction set from the PS3's main CPU. They are not designed for or efficient at general purpose computing. DSPs are not appropriate for game programming.
Xbox 360 has three general purpose CPU cores. The Cell processor has only one.
Xbox 360's CPUs has vector processing power on each CPU core. Each Xbox 360 core has 128 vector registers per hardware thread, with a dot product instruction, and a shared 1-MB L2 cache. The Cell processor's vector processing power is mostly on the seven DSPs.
Dot products are critical to games because they are used in 3D math to calculate vector lengths, projections, transformations, and more. The Xbox 360 CPU has a dot product instruction, where other CPUs such as Cell must emulate dot product using multiple instructions.
Cell's streaming floating-point work is done on its seven DSP processors. Since geometry processing is moved to the GPU, the need for streaming floating-point work and other DSP style programming in games has dropped dramatically.
Just like with the PS2's Emotion Engine, with its missing L2 cache, the Cell is designed for a type of game programming that accounts for a minor percentage of processing time.
Sony's CPU is ideal for an environment where 12.5% of the work is general-purpose computing and 87.5% of the work is DSP calculations. That sort of mix makes sense for video playback or networked waveform analysis, but not for games. In fact, when analyzing real games one finds almost the opposite distribution of general purpose computing and DSP calculation requirements. A relatively small percentage of instructions are actually floating point. Of those instructions which are floating-point, very few involve processing continuous streams of numbers. Instead they are used in tasks like AI and path-finding, which require random access to memory and frequent branches, which the DSPs are ill-suited to.
Based on measurements of running next generation games, only ~10-30% of the instructions executed are floating point. The remainders of the instructions are load, store, integer, branch, etc. Even fewer of the instructions executed are streaming floating point—probably ~5-10%. Cell is optimized for streaming floating-point, with 87.5% of its cores good for streaming floating-point and nothing else.
Game programmers do not want to spread their code over eight processors, especially when seven of the processors are poorly suited for general purpose programming. Evenly distributing game code across eight processors is extremely difficult.
Game programmers do not want to spread their code over eight processors, especially when seven of the processors are poorly suited for general purpose programming. Evenly distributing game code across eight processors is extremely difficult.
GPU
Even ignoring the bandwidth limitations the PS3's GPU is not as powerful as the Xbox 360's GPU.
Below are the specs from Sony's press release regarding the PS3's GPU.
RSX GPU
550 MHz
Independent vertex/pixel shaders
51 billion dot products per second (total system performance)
300M transistors
136 "shader operations" per clock
The interesting ALU performance numbers are 51 billion dot products per second (total system performance), 300M transistors, and more than twice as powerful as the 6800 Ultra.
The 51 billions dot products per cycle were listed on a summary slide of total graphics system performance and are assumed to include the Cell processor. Sony's calculations seem to assume that the Cell can do a dot product per cycle per DSP, despite not having a dot product instruction.
However, using Sony's claim, 7 dot products per cycle * 3.2 GHz = 22.4 billion dot products per second for the CPU. That leaves 51 - 22.4 = 28.6 billion dot products per second that are left over for the GPU. That leaves 28.6 billion dot products per second / 550 MHz = 52 GPU ALU ops per clock.
It is important to note that if the RSX ALUs are similar to the GeForce 6800 ALUs then they work on vector4s, while the Xbox 360 GPU ALUs work on vector5s. The total programmable GPU floating point performance for the PS3 would be 52 ALU ops * 4 floats per op *2 (madd) * 550 MHz = 228.8 GFLOPS which is less than the Xbox 360's 48 ALU ops * 5 floats per op * 2 (madd) * 500 MHz= 240 GFLOPS.
With the number of transistors being slightly larger on the Xbox 360 GPU (330M) it's not surprising that the total programmable GFLOPs number is very close.
The PS3 does have the additional 7 DSPs on the Cell to add more floating point ops for graphics rendering, but the Xbox 360's three general purpose cores with custom D3D and dot product instructions are more customized for true graphics related calculations.
The 6800 Ultra has 16 pixel pipes, 6 vertex pipes, and runs at 400 MHz. Given the RSX's 2x better than a 6800 Ultra number and the higher frequency of the RSX, one can roughly estimate that it will have 24 pixel shading pipes and 4 vertex shading pipes (fewer vertex shading pipes since the Cell DSPs will do some vertex shading). If the PS3 GPU keeps the 6800 pixel shader pipe co-issue architecture which is hinted at in Sony's press release, this again gives it 24 pixel pipes* 2 issued per pipe + 4 vertex pipes = 52 dot products per clock in the GPU.
If the RSX follows the 6800 Ultra route, it will have 24 texture samplers, but when in use they take up an ALU slot, making the PS3 GPU in practice even less impressive. Even if it does manage to decouple texture fetching from ALU co-issue, it won't have enough bandwidth to fetch the textures anyways.
For shader operations per clock, Sony is most likely counting each pixel pipe as four ALU operations (co-issued vector+scalar) and a texture operation per pixel pipe and 4 scalar operations for each vector pipe, for a total of 24 * (4 + 1) + (4*4) = 136 operations per cycle or 136 * 550 = 74.8 GOps per second.
Given the Xbox 360 GPU's multithreading and balanced design, you really can't compare the two systems in terms of shading operations per clock. However, the Xbox 360's GPU can do 48 ALU operations (each can do a vector4 and scalar op per clock), 16 texture fetches, 32 control flow operations, and 16 programmable vertex fetch operations with tessellation per clock for a total of 48*2 + 16 + 32 + 16 = 160 operations per cycle or 160 * 500 = 80 GOps per second.
Overall, the automatic shader load balancing, memory export features, programmable vertex fetching, programmable triangle tesselator, full rate texture fetching in the vertex shader, and other "well beyond shader model 3.0" features of the Xbox 360 GPU should also contribute to overall rendering performance.
Bandwidth
The PS3 has 22.4 GB/s of GDDR3 bandwidth and 25.6 GB/s of RDRAM bandwidth for a total system bandwidth of 48 GB/s.
The Xbox 360 has 22.4 GB/s of GDDR3 bandwidth and a 256 GB/s of EDRAM bandwidth for a total of 278.4 GB/s total system bandwidth.
Why does the Xbox 360 have such an extreme amount of bandwidth? Even the simplest calculations show that a large amount of bandwidth is consumed by the frame buffer. For example, with simple color rendering and Z testing at 550 MHz the frame buffer alone requires 52.8 GB/s at 8 pixels per clock. The PS3's memory bandwidth is insufficient to maintain its GPU's peak rendering speed, even without texture and vertex fetches.
The PS3 uses Z and color compression to try to compensate for the lack of memory bandwidth. The problem with Z and color compression is that the compression breaks down quickly when rendering complex next-generation 3D scenes.
HDR, alpha-blending, and anti-aliasing require even more memory bandwidth. This is why Xbox 360 has 256 GB/s bandwidth reserved just for the frame buffer. This allows the Xbox 360 GPU to do Z testing, HDR, and alpha blended color rendering with 4X MSAA at full rate and still have the entire main bus bandwidth of 22.4 GB/s left over for textures and vertices.
CONCLUSION
When you break down the numbers, Xbox 360 has provably more performance than PS3. Keep in mind that Sony has a track record of over promising and under delivering on technical performance. The truth is that both systems pack a lot of power for high definition games and entertainment.
However, hardware performance, while important, is only a third of the puzzle. Xbox 360 is a fusion of hardware, software and services. Without the software and services to power it, even the most powerful hardware becomes inconsequential. Xbox 360 games—by leveraging cutting-edge hardware, software, and services—will outperform the PlayStation 3.
C'è un imprecisione presente. RSX è stato downgradato a 500Mhz e quasi tutti i numeri riferiti a questa GPU sono più alti del 10%.
:)
Sicuramente è un ottimo risultato ma penso sia dovuto anche per il grande tempo che hanno avuto gli sviluppatori (quasi un'anno) e che in molti titoli multipiattaforma, il motore grafico della versione 360 è stato adattato a quella ps3.
Posto un'altra interessante analisi:
http://www.itvidya.com/playstation_3_vs_xbox_360
DETAILED ANALYSIS OF PERFORMANCE SPECIFICATIONS
CPU
The Xbox 360 processor was designed to give game developers the power that they actually need, in an easy to use form. The Cell processor has impressive streaming floating-point power that is of limited use for games.
The majority of game code is a mixture of integer, floating-point, and vector math, with lots of branches and random memory accesses. This code is best handled by a general purpose CPU with a cache, branch predictor, and vector unit.
The Cell's seven DSPs (what Sony calls SPEs) have no cache, no direct access to memory, no branch predictor, and a different instruction set from the PS3's main CPU. They are not designed for or efficient at general purpose computing. DSPs are not appropriate for game programming.
Xbox 360 has three general purpose CPU cores. The Cell processor has only one.
Xbox 360's CPUs has vector processing power on each CPU core. Each Xbox 360 core has 128 vector registers per hardware thread, with a dot product instruction, and a shared 1-MB L2 cache. The Cell processor's vector processing power is mostly on the seven DSPs.
Dot products are critical to games because they are used in 3D math to calculate vector lengths, projections, transformations, and more. The Xbox 360 CPU has a dot product instruction, where other CPUs such as Cell must emulate dot product using multiple instructions.
Cell's streaming floating-point work is done on its seven DSP processors. Since geometry processing is moved to the GPU, the need for streaming floating-point work and other DSP style programming in games has dropped dramatically.
Just like with the PS2's Emotion Engine, with its missing L2 cache, the Cell is designed for a type of game programming that accounts for a minor percentage of processing time.
Sony's CPU is ideal for an environment where 12.5% of the work is general-purpose computing and 87.5% of the work is DSP calculations. That sort of mix makes sense for video playback or networked waveform analysis, but not for games. In fact, when analyzing real games one finds almost the opposite distribution of general purpose computing and DSP calculation requirements. A relatively small percentage of instructions are actually floating point. Of those instructions which are floating-point, very few involve processing continuous streams of numbers. Instead they are used in tasks like AI and path-finding, which require random access to memory and frequent branches, which the DSPs are ill-suited to.
Based on measurements of running next generation games, only ~10-30% of the instructions executed are floating point. The remainders of the instructions are load, store, integer, branch, etc. Even fewer of the instructions executed are streaming floating point—probably ~5-10%. Cell is optimized for streaming floating-point, with 87.5% of its cores good for streaming floating-point and nothing else.
Game programmers do not want to spread their code over eight processors, especially when seven of the processors are poorly suited for general purpose programming. Evenly distributing game code across eight processors is extremely difficult.
Game programmers do not want to spread their code over eight processors, especially when seven of the processors are poorly suited for general purpose programming. Evenly distributing game code across eight processors is extremely difficult.
GPU
Even ignoring the bandwidth limitations the PS3's GPU is not as powerful as the Xbox 360's GPU.
Below are the specs from Sony's press release regarding the PS3's GPU.
RSX GPU
550 MHz
Independent vertex/pixel shaders
51 billion dot products per second (total system performance)
300M transistors
136 "shader operations" per clock
The interesting ALU performance numbers are 51 billion dot products per second (total system performance), 300M transistors, and more than twice as powerful as the 6800 Ultra.
The 51 billions dot products per cycle were listed on a summary slide of total graphics system performance and are assumed to include the Cell processor. Sony's calculations seem to assume that the Cell can do a dot product per cycle per DSP, despite not having a dot product instruction.
However, using Sony's claim, 7 dot products per cycle * 3.2 GHz = 22.4 billion dot products per second for the CPU. That leaves 51 - 22.4 = 28.6 billion dot products per second that are left over for the GPU. That leaves 28.6 billion dot products per second / 550 MHz = 52 GPU ALU ops per clock.
It is important to note that if the RSX ALUs are similar to the GeForce 6800 ALUs then they work on vector4s, while the Xbox 360 GPU ALUs work on vector5s. The total programmable GPU floating point performance for the PS3 would be 52 ALU ops * 4 floats per op *2 (madd) * 550 MHz = 228.8 GFLOPS which is less than the Xbox 360's 48 ALU ops * 5 floats per op * 2 (madd) * 500 MHz= 240 GFLOPS.
With the number of transistors being slightly larger on the Xbox 360 GPU (330M) it's not surprising that the total programmable GFLOPs number is very close.
The PS3 does have the additional 7 DSPs on the Cell to add more floating point ops for graphics rendering, but the Xbox 360's three general purpose cores with custom D3D and dot product instructions are more customized for true graphics related calculations.
The 6800 Ultra has 16 pixel pipes, 6 vertex pipes, and runs at 400 MHz. Given the RSX's 2x better than a 6800 Ultra number and the higher frequency of the RSX, one can roughly estimate that it will have 24 pixel shading pipes and 4 vertex shading pipes (fewer vertex shading pipes since the Cell DSPs will do some vertex shading). If the PS3 GPU keeps the 6800 pixel shader pipe co-issue architecture which is hinted at in Sony's press release, this again gives it 24 pixel pipes* 2 issued per pipe + 4 vertex pipes = 52 dot products per clock in the GPU.
If the RSX follows the 6800 Ultra route, it will have 24 texture samplers, but when in use they take up an ALU slot, making the PS3 GPU in practice even less impressive. Even if it does manage to decouple texture fetching from ALU co-issue, it won't have enough bandwidth to fetch the textures anyways.
For shader operations per clock, Sony is most likely counting each pixel pipe as four ALU operations (co-issued vector+scalar) and a texture operation per pixel pipe and 4 scalar operations for each vector pipe, for a total of 24 * (4 + 1) + (4*4) = 136 operations per cycle or 136 * 550 = 74.8 GOps per second.
Given the Xbox 360 GPU's multithreading and balanced design, you really can't compare the two systems in terms of shading operations per clock. However, the Xbox 360's GPU can do 48 ALU operations (each can do a vector4 and scalar op per clock), 16 texture fetches, 32 control flow operations, and 16 programmable vertex fetch operations with tessellation per clock for a total of 48*2 + 16 + 32 + 16 = 160 operations per cycle or 160 * 500 = 80 GOps per second.
Overall, the automatic shader load balancing, memory export features, programmable vertex fetching, programmable triangle tesselator, full rate texture fetching in the vertex shader, and other "well beyond shader model 3.0" features of the Xbox 360 GPU should also contribute to overall rendering performance.
Bandwidth
The PS3 has 22.4 GB/s of GDDR3 bandwidth and 25.6 GB/s of RDRAM bandwidth for a total system bandwidth of 48 GB/s.
The Xbox 360 has 22.4 GB/s of GDDR3 bandwidth and a 256 GB/s of EDRAM bandwidth for a total of 278.4 GB/s total system bandwidth.
Why does the Xbox 360 have such an extreme amount of bandwidth? Even the simplest calculations show that a large amount of bandwidth is consumed by the frame buffer. For example, with simple color rendering and Z testing at 550 MHz the frame buffer alone requires 52.8 GB/s at 8 pixels per clock. The PS3's memory bandwidth is insufficient to maintain its GPU's peak rendering speed, even without texture and vertex fetches.
The PS3 uses Z and color compression to try to compensate for the lack of memory bandwidth. The problem with Z and color compression is that the compression breaks down quickly when rendering complex next-generation 3D scenes.
HDR, alpha-blending, and anti-aliasing require even more memory bandwidth. This is why Xbox 360 has 256 GB/s bandwidth reserved just for the frame buffer. This allows the Xbox 360 GPU to do Z testing, HDR, and alpha blended color rendering with 4X MSAA at full rate and still have the entire main bus bandwidth of 22.4 GB/s left over for textures and vertices.
CONCLUSION
When you break down the numbers, Xbox 360 has provably more performance than PS3. Keep in mind that Sony has a track record of over promising and under delivering on technical performance. The truth is that both systems pack a lot of power for high definition games and entertainment.
However, hardware performance, while important, is only a third of the puzzle. Xbox 360 is a fusion of hardware, software and services. Without the software and services to power it, even the most powerful hardware becomes inconsequential. Xbox 360 games—by leveraging cutting-edge hardware, software, and services—will outperform the PlayStation 3.
C'è un imprecisione presente. RSX è stato downgradato a 500Mhz e quasi tutti i numeri riferiti a questa GPU sono più alti del 10%.
evildevil
04-12-2006, 10:05
http://www.1up.com/do/feature?pager.offset=0&cId=3155393
Vorrei dare un mio parere sui video e sulle immagini :
[cut]
In conclusione, le versioni PS3 hanno un effetto più "sobrio", quasi voluto, come se lo standard PS3 è avere giochi non troppo esagerati e "sparati" dal punto di vista colori/effetti, ed è lo stile che preferisco personalmente (a parte Cod 3 in cui apprezzo i colori più accesi). Anche se, in alcuni casi le textures sono meno nitide. Su 360 invece spesso gli effetti sono troppo esagerati, un esempio rozzo di prima next generation.
Apprezzo però la maggior definizione delle textures su 360.
In pratica il massimo sarebbe la sobrietà delle versioni PS3 e il dettaglio textures delle versioni 360.
I colori meno accesi credo siano un effetto voluto.
Considerando che questi sono i titoli PS3 di primissima generazione (come quello 360 d'altronde), alla luce della maggior difficoltà di programmazione dell'hardware della console Sony, direi che sono risultati ottimi, ovviamente imho.
:)
quoto su tutto, l'xbox ha hdr ultra pompato, perfino fastidioso a volte... ma non parlerei di effetti "troppo esagerati"
le console sono la piattaforma, chi ci mette i livelli di luci ecc sono i programmatori del gioco, non penso ke nel caso di blazing angels su xbox non si siano potuti diminuire i livelli di luci e mettere 2 ombre... bho
Vorrei dare un mio parere sui video e sulle immagini :
[cut]
In conclusione, le versioni PS3 hanno un effetto più "sobrio", quasi voluto, come se lo standard PS3 è avere giochi non troppo esagerati e "sparati" dal punto di vista colori/effetti, ed è lo stile che preferisco personalmente (a parte Cod 3 in cui apprezzo i colori più accesi). Anche se, in alcuni casi le textures sono meno nitide. Su 360 invece spesso gli effetti sono troppo esagerati, un esempio rozzo di prima next generation.
Apprezzo però la maggior definizione delle textures su 360.
In pratica il massimo sarebbe la sobrietà delle versioni PS3 e il dettaglio textures delle versioni 360.
I colori meno accesi credo siano un effetto voluto.
Considerando che questi sono i titoli PS3 di primissima generazione (come quello 360 d'altronde), alla luce della maggior difficoltà di programmazione dell'hardware della console Sony, direi che sono risultati ottimi, ovviamente imho.
:)
quoto su tutto, l'xbox ha hdr ultra pompato, perfino fastidioso a volte... ma non parlerei di effetti "troppo esagerati"
le console sono la piattaforma, chi ci mette i livelli di luci ecc sono i programmatori del gioco, non penso ke nel caso di blazing angels su xbox non si siano potuti diminuire i livelli di luci e mettere 2 ombre... bho
BTinside
08-12-2006, 15:31
Parla un programmatore indipendente, quindi in teoria non di parte.
UK's Guardian talked to Richard Hackett a head of technology at Blitz regarding the technology in the PS3 and Xbox 360. Hackett states tha they are very both similar in terms of performance and we won't see the optimal potential of each machine being achieved for quite some time yet.
I:
The debate over graphics on Xbox 360 and PS3 is still raging online, with developers coming out on both sides to claim superiority. As an independent developer how do you compare the two formats in terms of visuals?
D:
In essence the two systems are actually fairly closely matched in terms of graphics. The jump to HD is a major step up in visual quality and that is delivered by both systems. The difference between 720p and 1080i will be fairly academic for some time as there are very few mass market TVs out there at the moment that support native 1080 resolution, and I'm not sure the average consumer sees the difference between them anyway.
At Blitz our cross platform technology enables us to develop simultaneously for both systems and spend our time playing to the strengths of each. Of course developers have had longer to get to grips with the X360 bu[B]t you can be sure we won't see the full potential of the either system and especially the PS3 for some time yet.
I:
One developer has publicly (although anonymously) stated that Xbox 360 - in games programming terms - is the better machine as the GPU is more powerful, providing greater pixel and vertex processing horsepower. Do you concur at all? Is this really what it all comes down to?
D:
The X360 GPU is slightly more flexible due to the subtle differences between the respective architectures of the nVidia and ATI chipset. Certain shader restrictions are lifted or easier to work around on X360. The bandwidth of the X360 GPU is pretty massive too, though partly this is balanced out by the differences in VRAM layout of the two systems that means the Xbox needs to move graphics data around the system more than the PS3 does. While the GPUs are fast and have a big impact on the visual quality and level of game effects, other factors such as general processing power and memory architecture also come into play.
maxconsole
UK's Guardian talked to Richard Hackett a head of technology at Blitz regarding the technology in the PS3 and Xbox 360. Hackett states tha they are very both similar in terms of performance and we won't see the optimal potential of each machine being achieved for quite some time yet.
I:
The debate over graphics on Xbox 360 and PS3 is still raging online, with developers coming out on both sides to claim superiority. As an independent developer how do you compare the two formats in terms of visuals?
D:
In essence the two systems are actually fairly closely matched in terms of graphics. The jump to HD is a major step up in visual quality and that is delivered by both systems. The difference between 720p and 1080i will be fairly academic for some time as there are very few mass market TVs out there at the moment that support native 1080 resolution, and I'm not sure the average consumer sees the difference between them anyway.
At Blitz our cross platform technology enables us to develop simultaneously for both systems and spend our time playing to the strengths of each. Of course developers have had longer to get to grips with the X360 bu[B]t you can be sure we won't see the full potential of the either system and especially the PS3 for some time yet.
I:
One developer has publicly (although anonymously) stated that Xbox 360 - in games programming terms - is the better machine as the GPU is more powerful, providing greater pixel and vertex processing horsepower. Do you concur at all? Is this really what it all comes down to?
D:
The X360 GPU is slightly more flexible due to the subtle differences between the respective architectures of the nVidia and ATI chipset. Certain shader restrictions are lifted or easier to work around on X360. The bandwidth of the X360 GPU is pretty massive too, though partly this is balanced out by the differences in VRAM layout of the two systems that means the Xbox needs to move graphics data around the system more than the PS3 does. While the GPUs are fast and have a big impact on the visual quality and level of game effects, other factors such as general processing power and memory architecture also come into play.
maxconsole
Murakami
08-12-2006, 21:44
Parla un programmatore indipendente, quindi in teoria non di parte.
maxconsole
Praticamente, non ha detto nulla, se non che sono più o meno pari... :D
maxconsole
Praticamente, non ha detto nulla, se non che sono più o meno pari... :D
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.