Beh, anche questo è in real-time, così dice lo speaker, se è vero questa PS3 è davvero incredibile...
http://files.m00ki.de/bliz/Videos/sonycon_demos_getaway_wmvlow.wmv

Quest'altro era il video delle paperelle:
http://files.m00ki.de/bliz/Videos/sonycon_demos_duckies2_wmvlow.wmv

Ma forse quello che appare più incredibile è il realismo delle simulazioni fisiche e d'ambiente. Ma come fanno?!?


4 stelline 4 paperelle ... io voglio i giochi non le papere :sofico:

era scritto su tutti i portali di vg e non solo, vai un pò a spulciarli :p

ci sn rimasto troppo male, ero gasatissimo per Kill Zone 2, loro hanno detto... "questa è la previsione di come vogliamo fare il gioco", io ci credo che verrà così, anzi meglio, ma quello era cmq un FMV :(

Azz, gran peccato

ciao ragazzi io volevo sapere perche insistete con la faccenda che il processore della xbox 360 e meglio di quello della play3

Quali sono i particolari che ti fanno pensare che non siano applicazioni in real-time ma dei video?

Ciao

L'intervista al CEO di Guerrilla che dice che il loro e' un video prerenderizzato mi ha fatto sospettare qualcosa :p

il processore grafico della xbox 360 a 10 mega di tipo gdd3 da 700 mhz di memoria vram incastonata nel processore graficio che gli permette di aplicare aa x4 in hdtv e fin li ci siamo (come il processore video della ps2).
invece la play3 ha una memoria principale da 256mb xdr da 3.2ghz
e in piu ha 256mb vram di tipo gdd3 da 700mhz dedicata per il processore grafico percio non vedo perche implementare una memoria incastonata nel processore grafico se ne ha gia 256mega e poi nel caso ne servisse di piu puo usare i 256 di tipo xdr di quella centrale in questo caso salirebbe a 512mb. peresempio la scheda grafica del pc che ha 256mb questi 256mb sono di tipo vram. a mio parere e meglio il la soluzione ps3 perche facilita i programmatori

il processore grafico della xbox 360 a 10 mega di tipo gdd3 da 700 mhz di memoria vram incastonata nel processore graficio che gli permette di aplicare aa x4 in hdtv e fin li ci siamo (come il processore video della ps2).
invece la play3 ha una memoria principale da 256mb xdr da 3.2ghz
e in piu ha 256mb vram di tipo gdd3 da 700mhz dedicata per il processore grafico percio non vedo perche implementare una memoria incastonata nel processore grafico se ne ha gia 256mega e poi nel caso ne servisse di piu puo usare i 256 di tipo xdr di quella centrale in questo caso salirebbe a 512mb. peresempio la scheda grafica del pc che ha 256mb questi 256mb sono di tipo vram. a mio parere e meglio il la soluzione ps3 perche facilita i programmatori

No ti sbagli... è l'esatto contrario.
La PS3 ha 256 Mb di RAM GDD3(22.4 Gb/s) dedicata alla CPU e 256 Mb di RAM dedicata alla scheda video. Quindi la scheda video può usare SOLO quei 256 per se stessa, non può prendere quelli del processore.
La 360 ha 512 Mb di RAM GDD3(22.4 Gb/s) da utilizzare per il processore e per la scheda video. Nel sistema della 360 si può fare quello che dici tu, ovvero condividere a seconda di chi ne ha bisogno 516 Mb di RAM. E in + la scheda video dela 360 avrà 10 Mb di ERAM per se stessa che andrà a 256 Gb/s. Ecco la differenza fra una soluzione e l'altra.

Io a quanto ho capito il Cell andrà bene per la grafica(calcoli in virgola mobile) mentre il multi-core per l'IA e la fisica(calcoli in intero). Almeno così si dice.
Spiegatemi meglio il fatto che il multi-core va meglio in general purpose mentre il cell in streaming... cosa vuol dire.

Cmq se è come penso io, ovvero che la 360 ha una scheda video + potente e quindi può permettersi di affidare la grafica alla scheda video, mentre il cell deve pensarci lui, le 2 macchine sarebbero molto simili.

Cmq in molti siti si fa riferimento ad una scheda di comparazione
http://xbox360.ign.com/articles/617/617951p3.html
che dimostra addirittura che la 360 sarebbe + performante della PS3.

Se qualkuno può commentarla, facendoci capire qualkosa non sarebbe male.

COncordo, troppa roba tecnica e io non sono del campo.

O qualcuno me lo spiega (e mi dice se le argomentazioni ci sono o sono solo fuffa) oppure ho imparato a non credere cecamente alle cose solo perchè viene usato un linguaggio tecnico :)

Ciao

l' RSX della playstation 3 PUO' usare anche i 256mb di XDR principalmente riservati al cell con una tecnologia presumibilmente simile a quella turbocache

i 10mb di edram della xbox360 sono ON DIE assieme a R500 e non sono a 700mhz :| vanno alla velocità della GPU e ci comunicano a 256gb/s infatti

prima di tutto i grafici di ign sono delle cazzate assurde forse anche pagate dallo zio bil come fanno a fare dei grafici delle due console che sono ancora in fase di rifinitura e addirittura la play e ancora in un avanzato stato di progettazione almeno per quanto riguarda la gpu rsx
ti posso dire soltanto che la GPU gestisce 136 operzioni di shader per ciclo di clock. nel grafico progliettato alla presentazione della play si legge chiaramente che la gpu nvidia gestisce 100bilioni di shader al secondo contro i 48bilioni di shader al secondo di xbox360 e poi se ti dico che la memoria di sistema e 256mb XDR A 3,2GHZ non puoi dirmi che e di tipo gdd3 a 700mhz perche le gdd3 sono quelle della vram capito vai a vedrti le caratteristiche .guarda quahttp://www.anandtech.com/tradeshows/showdoc.aspx?i=2417&p=4


guarda attentamente come e collegato il cell con la gpu e leggi attentamente . poi se mi vengono altre cose in mente ti faro sapere

penso che prenderò una delle 2 console, penso la ps3. ho saltato la 2 e quindi prendo la 3 :D


cmq nn oso immaginare che cavolo di simulazioni metereologiche riesce a fare quella bestia del cell, se è vero quanto dichiarato ne bastanto 10-15 in parallelo per fare il culo a gran parte dei supercomputer di fascia bassa

http://www.anandtech.com/tradeshows/showdoc.aspx?i=2417&p=5

prima di tutto i grafici di ign sono delle cazzate assurde forse anche pagate dallo zio bil come fanno a fare dei grafici delle due console che sono ancora in fase di rifinitura e addirittura la play e ancora in un avanzato stato di progettazione almeno per quanto riguarda la gpu rsx
ti posso dire soltanto che la GPU gestisce 136 operzioni di shader per ciclo di clock. nel grafico progliettato alla presentazione della play si legge chiaramente che la gpu nvidia gestisce 100bilioni di shader al secondo contro i 48bilioni di shader al secondo di xbox360 e poi se ti dico che la memoria di sistema e 256mb XDR A 3,2GHZ non puoi dirmi che e di tipo gdd3 a 700mhz perche le gdd3 sono quelle della vram capito vai a vedrti le caratteristiche .guarda qua

http://www.anandtech.com/tradeshows/showdoc.aspx?i=2417&p=4


guarda attentamente come e collegato il cell con la gpu e leggi attentamente . poi se mi vengono altre cose in mente ti faro sapere

:spam:

in un articolo scritto da nvidia dopo le3 ,ce scriito che la play 3
in verita non ha una solo gpu ma volendo 8 cioe rsx e le sette spe (Synergistic Processing Element).ognuna da 3,2 ghz 36 gflops.
e poi dai viene di logico che play 3 e piu potente riesce ha gestire due uscite video a 1080p

prima di tutto i grafici di ign sono delle cazzate assurde forse anche pagate dallo zio bil

Hai delle prove di quanto affermi? E' un'accusa piuttosto pesante.


ti posso dire soltanto che la GPU gestisce 136 operzioni di shader per ciclo di clock. nel grafico progliettato alla presentazione della play si legge chiaramente che la gpu nvidia gestisce 100bilioni di shader al secondo contro i 48bilioni di shader al secondo di xbox360

Sai che cosa vogliono dire quei numeri? Non si parla di shader gestibili al secondo ma di "shader op" (operazioni di shader, somme, addizioni, moltiplicazioni, divisioni).
Perche' dai numeri che hai citato, sapendo che cosa significano, si ricava che l'R500 potrebbe processare piu' float dell'RSX, non il contrario.

in un articolo scritto da nvidia dopo le3 ,ce scriito che la play 3
in verita non ha una solo gpu ma volendo 8 cioe rsx e le sette spe (Synergistic Processing Element).ognuna da 3,2 ghz 36 gflops.
e poi dai viene di logico che play 3 e piu potente riesce ha gestire due uscite video a 1080p

Le SPE non sono delle GPU e non ci si avvicinano neppure. Sono dei semplici streaming processor che non sono in grado di fare il lavoro di una GPU in maniera accettabile. Un uso dell'SPE potrebbe in ambito grafico puo' essere infatti l'applicazione del kernel di un filtro (ad esempio di blooming) al risultato della rasterizzazione dell'RSX, oppure il processamento della geometria (simile ai vertex shader) prima di passare i dati all'RSX per il rendering. La prima soluzione comunque, oltre ad essere piuttosto complicata, potrebbe avere delle ripercussioni sulla banda passante, perche' lo stesso dato (il framebuffer) andrebbe trasportato avanti e indietro sul bus di sistema, dove nell'R500, al contrario, risiederebbe sempre nella memoria eDRAM e sarebbe filtrato in loco.

Le due uscite video sono una conseguenza del fatto che tutte le GPU per PC hanno due uscite video, e l'RSX e' parente strettissimo del G70 di NVIDIA. Avere due uscite video significa avere due DAC, non dice nulla sulla potenza della GPU.
Infine, il supporto alla risoluzione 1080p e' uno svantaggio, perche' ha costretto NVIDIA a non usare eDRAM (ne sarebbe servita troppa ed e' troppo costosa) per il framebuffer, ma appoggiarsi alla VRAM di 256mb.

OT. Prima di fare il submit dei tuoi post puoi usare questo link per cortesia?
http://www.google.co.uk/language_tools?hl=en
Grazie.

Potrebbe essere interessante.
Comunque i bench ci sono. Ce ne sono tanti che dicono una cosa, e tanti che dicono il contrario...
Quelli di Apple, in particolare, si smentiscono da soli... :asd:
In FP doppia precisione non dovrebbe essere affatto scarso (anzi). Diversi super-cluster al top sono basati su PPC 970 per questo motivo.
Come ho già detto su un thread nella sezione Processori, la classifica dei super computer è basata su UN SOLO BENCHMARK: il LINKPAK. Direi è TROPPO POCO per valutare la bontà di processore / sistema, non credi?
D'altra parte è quello il mercato principale di Apple, e se il PPC970 va bene per quelle cose tanto basta... E i bench SPEC poi, l'ultima volta che ho visto non erano nemmeno multi-threading, quindi le macchine top di Apple (che sono tutte dual) ne escono per forza male...
Come ti ho già detto, se non sai niente di quello di cui parli, faresti bene a restartene zitto... :rolleyes:
Non lo trovo...
Non saprei dirti perchè non c'è, ma quando sono usciti i PowerMac Apple pubblicava dei bench SPEC confrontandoli con gli equivalenti Intel (a pari compilatore GCC). E ovviamente ne usciva vincente... Quindi?
Ovviamente perché i benchmark li ha manipolati ad arte, com'è suo solito fare e come è stata smascherata, visto che per Apple il PPC970 riusciva a stracciare perfino il Power4, di cui è una versione castrata, nei test di SPEC... :rolleyes:
E' una emulazione hardware vera e propria. Se ti sembra una soluzione semplice e lineare... mah!
Allora è la stessa "emulazione hardware" vera e propria, non semplice e lineare, che IBM implementa da anni nei Power4/5 e nel tuo caro PPC970, visto che le istruzioni native PowerPC vengono convertite in istruzioni "più RISC" e date in pasto all'unità RISC deputata alla loro esecuzione. :rolleyes:

ESATTAMENTE CIO' CHE AVVIENE CON GLI X86 DAL K5 DI AMD, che è stata la pietra miliare in questo campo, e da cui hanno "tratto ispirazione" tutti gli altri, IBM compresa...
Sicuramente sarà questo il limite dei super PPC da consolle per un uso general-pourpose. Su questo concordo. Ma con codice ottimizzato faranno faville!
Con codice ottimizzato anche gli x86 fanno faville, e posso assicurarti che ne fanno di più delle altre architetture, visto che il loro ISA è particolarmente ricco e permette ai programmatori "a basso livello" di sbizarrirsi sulle ottimizzazioni da adottare...
Guarda che ormai di software nato e crescito per Mac ce n'è ben poco. Perfino Adobe ormai che più supportare Apple la SOPPORTA.
Una volta era diverso. Diversi programmi erano effettivamente nati su Mac e andavano meglio su questo. Perfino Excel e Word. Ora di veramente nativo per Mac ci sono solo gli applicativi Apple, dell'ottimo shareware e poco altro.
Balle: Adobe e tante altre software house continuano a sviluppare le loro applicazioni per Mac, curandone parallelemente il porting per PC.
E' difficile che una società e i suoi programmatori abbandonino la piattaforma con cui lavorano da anni, e sui cui molto probabilmente si trovano meglio. Tant'è che i prodotti Adobe, visto che l'hai tirata in ballo, vengono annunciati e commercializzati prima per Mac e poi per PC...
E certo Apple è brava a far brillare il suo hardware negli applicativi (multimediali) PRO o su iLife. Ma nella maggioranza dei confronti PC/Mac quest'ultimo di solito ne esce male principalmente per questioni di porting...
Perché?
Tanto per fare un esempio tra tutti gli applicativi Adobe, Macromedia e Quark che erano il "cuore" degli applicativi Mac classici, non ce n'è UNO veramente nativo OS X. Sono tutti porting, o da Win o dal MacOS 9. Con i limiti del caso in quanto ottimizzazioni...
A me risulta che siano soluzioni che supportano nativamente OS X: hai delle (precise) informazioni in merito?
Gli SPEC non sono multithreading (sbaglio?), riguardano solo un certo set di applicativi e si mormora che Intel ottimizzi i suoi compilatori per loro e quindi i suoi dati siano un po' gonfiati.
Come ho già detto, se non sai come stanno le cose faresti meglio a startene zitto... :rolleyes:
Quella di Intel che ottimizza i propri compilatori per i benchmark di SPEC è una leggenda metropolitana creata ad arte e tirata fuori ogni volta che si parla di questa suite di test, ma che nessuno ha mai dimostrato essere vera.
Penso che IBM, Sun, HP abbiano tutto il know-how, le capacità e soprattutto l'INTERESSE a farlo, visto che nel campo dei server / workstation / supercomputer ci si gioca parecchia credibilità e si fa parecchia pubblicità coi risultati degli SPEC.
La verità è che non l'hanno mai fatto e che questa storiella dei compilatori truccati serve soltanto a certa gente che soffre di "invidia del pene" quando si tirano fuori numeri e si fanno confronti... :mc:

Beh decodificare delle istruzioni e trasformarle in altre (più semplici o complicate poco importa) da eseguire in un'architettura completamente differente, con più registri ecc, io la chiamo "emulazione". Poi tu fai come vuoi...
Invece è il classico "uovo di Colombo" che ha permesso agli x86 di superare i limiti del fatto di essere CISC, portandoli a livelli prestazionali sempre più elevati, e che guarda caso hanno copiato anche mostri sacri come IBM per i loro RISC Power per raggiungere lo stesso obiettivo: salire col clock e aumentare le prestazioni...

Eppure Photoshop ormai è superato: core-image di Tiger lo straccia brutalmente come velocità! (ma grazie alle GPU)
Tiger ha pochi filtri rispetto a Photoshop. Comunque Photoshop potrebbe utilizzare le GPU in futuro: Acrobat lo fa già in parte...
La gestione della memoria è totalmente differente tra OS X e il vecchio Mac OS, e quello incide parecchio.
Parecchio? Quanto. Dipende sempre dall'applicazione, ovviamente.
Se l'applicativo era stato ottimizzato per la gestione della memoria di MacOS 9, un porting diretto sicuramente non giova.
Perché, cosa cambia rispetto a OS X quanto al sistema di allocazione della memoria?
Lo stesso dicasi per il threading...
Cioé? Fai un esempio, così ti capiamo meglio...

Ma visto che ne sapete così tante non potete spiegarmi questi fantomatici floating point a che servono e se sono veramente utili in una console??ù
E poi perchè la 360 sarebbe + potente nei general purpose, come l'IA e la fisica??

Quindi + potente RSX o R500?? :confused:

Non chiedo quale sia la migliore delle 2 console perchè ormai ho capito che per il momento non si può saperlo.... architetture troppo diverse e non si è sicuri delle analisi... in molti foum si fa: aspettaremo e vedremo

Tiger ha pochi filtri rispetto a Photoshop. Comunque Photoshop potrebbe utilizzare le GPU in futuro: Acrobat lo fa già in parte...

Parecchio? Quanto. Dipende sempre dall'applicazione, ovviamente.

Perché, cosa cambia rispetto a OS X quanto al sistema di allocazione della memoria?

Cioé? Fai un esempio, così ti capiamo meglio...


Uff... Su MacOS 9 l'allocazione della memoria era statica, si doveva assegnare manualmente un tot di memoria all'applicazione, e quest'ultima più di quella assegnata non vedeva. Su OS X tutte le applicazioni possono indirizzare 4GB di Ram, poi ci pensa il sistema operativo a fare sì che l'applicazione abbia la memoria vera quando gli serve e a swappare quella inutilizzata su disco.

Su MacOS 9 il multitasking era cooperative, quindi l'applicazione doveva prevedere ogni tanto di rilasciare tempo macchina per le altre applicazioni, mettendo una serie di istruzioni qua e là nel codice. Su OS X il multitasking è preemptive e quindi ci pensa l'OS a dare tempo alle applicazioni. Però quest'ultimo prevede anche applicazioni realtime, cioè con un determinato tempo macchina costante.

Tutte queste differenze fanno sì che nelle implementazioni le applicazioni debbano seguire strategie completamente differenti per ottimizzare il codice. Quindi le applicazioni portate da MacOS 9, cioè che girano con le API carbon, se erano state costruite PENSANDO alla gestione della memoria e dei task del MacOS 9 sicuramente non rendono come le applicazioni pensate per il modello di memoria e di multitasking di OS X.

Non basta una ricompilata per avere il massimo, insomma...

Adobe non userà core-image su Mac (come non usa nessuna delle caratteristiche avanzate di OS X) perchè non c'è un corrispettivo su Windows e quindi le sue applicazioni non potrebbero essere completamente multipiattaforma. Per questo dico che Adobe ormai più che supportare Apple la sopporta. Adobe non ha una singola applicazione nativa Cocoa, sono tutte porting delle versioni per MacOS 9 quindi scritte con API Carbon.

Ma visto che ne sapete così tante non potete spiegarmi questi fantomatici floating point a che servono e se sono veramente utili in una console??ù
E poi perchè la 360 sarebbe + potente nei general purpose, come l'IA e la fisica??
:

Per la fisica sembra molto avvantaggiato il Cell, invece.
Il processore Ageia fatto apposta per velocizzare gli algoritmi di simulazione fisica, a quanto pare, come struttura è molto simile al Cell.
Poi basta vedere i demo dell'E3 per rendersene conto...

Ma visto che ne sapete così tante non potete spiegarmi questi fantomatici floating point a che servono e se sono veramente utili in una console??

Immagina nel tuo computer particolare di avere tre cifre a disposizione in base 10 per rappresentare i numeri interi.
Il tuo computer capisce il numero 120, 960, 265, etc etc. Ognuno con tre cifre, puoi rappresentare numeri interi da 0 a 999.

Immagina ora di dover rappresentare il numero non intero 1.4 su un computer. Come fare?
Una soluzione semplice e' dire che le prime due cifre sono la parte intera del numero che devi rappresentare, l'ultima cifra e' la parte decimale. Questa e' una tua convenzione che il computer non conosce, ma il computer non conosce neppure il significato dei numeri che rappresenta, il significato lo dai sempre tu. Un numero e' un semplice simbolo.
In questa tua notazione, il numero 1.4 sara' rappresentato cosi': 014. Un semplice algoritmo per passare da una notazione all'altra e' moltiplicare il numero non intero per 10 e prendere in considerazione solo le ultime tre cifre e memorizzarlo sul computer. Al momento di usarlo, dividerai per 10.

1.4 * 10 = 014.

Con questa codifica, che si chiama virgola fissa, potrai rappresentare tutti i numeri che vanno da 0.0 a 99.9 con passi fissi di un decimo (questa si chiama precisione della rappresentazione). Come vedi usare questa rappresentazione richiede qualche operazione in piu' rispetto ad usare solo numeri interi che il tuo computer e' in grado di rappresentare nativamente.

La virgola fissa non e' l'unica rappresentazione di numeri non interi possibile. Ricordiamo che hai tre cifre a disposizione che puoi usare come ti pare. Immagina ora di usare la prima cifra come esponente e le altre due cifre come un numero intero da moltiplicare per una base fissa elevata all'esponente variabile. E' meno complicato di quanto sembra scritto. Ora ti faccio vedere con i calcoli, hai tre cifre a disposizione:

E AB = 4 14

Fissiamo la base a 10. La formula per passare da questa rappresentazione che si chiama virgola mobile al tuo numero e' questa:

Numero = AB * 10 ^ (E - 5)

Esempio:

14 * 10 ^ (4 - 5) = 14 * 10 ^ -1 = 14 * 0.1 = 1.4

10 elevato alla -1 e' uguale a 0.1
10 elevato alle 0 e' uguale a 1
10 elevato alla 1 e' uguale a 10
10 elevato alla 2 e' uguale a 100
E cosi' via.
Il 5 che appare e' un numero arbitrario che scegli tu, perche' ricordati che sei tu a scegliere le regole del gioco per i tuoi comodi. In realta', un ente super partes che si chiama IEEE ha gia' scelto tutti questi parametri (la base, la larghezza della mantissa, il bias per l'esponente) una volta sola di modo che io e te possiamo essere d'accordo su come rappresentare i numeri in virgola mobile.

Ti faccio un altro esempio:
7 52 = 52 * 10 ^ (7 - 5) = 52 * 10 ^ 2 = 52 * 100 = 5200.

In questa rappresentazione in virgola mobile puoi' rappresentare numeri che vanno da 0.0001 a 990000. Nulla si crea e nulla si distrugge, non puoi rappresentare piu' numeri diversi, con tre cifre hai sempre 1000 diverse combinazioni, stai solo ridistribuendo queste rappresentazioni in maniera non uniforme rispetto a prima, da qui il termine di virgola mobile.

Come hai visto rappresentare un numero in virgola mobile richiede parecchi calcoli in piu', i chip che supportano la rappresentazione in virgola mobile fanno tutti questi calcoli per te e "comprendono" o meglio ancora "sono in grado di fare calcoli su" numeri a virgola mobile con rappresentazioni standard dettate dall'IEEE.

La rappresentazione in virgola mobile ha vantaggi e svantaggi che trattare tutti richiederebbe un libro intero. Ti segnalo uno svantaggio, in virgola mobile in base due, il numero 0.1 non e' rappresentabile, e' solo approssimabile. Un altro problema e' che (a + b) * c non e' sempre uguale a * c + b * c, non valgono le comuni proprieta' dei numeri.


E poi perchè la 360 sarebbe + potente nei general purpose, come l'IA e la fisica??


Ne abbiamo parlato diffusamente nel thread sul Cell.
C'e' solo un errore: la fisica normalmente usa numeri in virgola mobile, ed e' un buon candidato per essere eseguito sul Cell.


Quindi + potente RSX o R500?? :confused:

Ancora non e' chiaro. E credo che non lo sara' mai.

Per la fisica sembra molto avvantaggiato il Cell, invece.

In realta' per fare fisica si puo' usare la GPU che e' un missile in confronto al Cell.


Il processore Ageia fatto apposta per velocizzare gli algoritmi di simulazione fisica, a quanto pare, come struttura è molto simile al Cell.

Link?


Poi basta vedere i demo dell'E3 per rendersene conto...

Che erano quasi tutti prerenderizzati .

Ancora non e' chiaro. E credo che non lo sara' mai.

Ma sopratutto a parte l'essere argomento di discussioni molto interessanti per chi mastica questi temi, è veramente così importante sapere quale delle due è più potente? Secondo me saranno i giochi (e credo di non poter venire smentito) a fare la differenza. Cioè un GT o un Halo saranno sempre dei best seller sulle console Next Gen, tutto questo nonostante una o l'altra possano risultare più potenti.
Anche XBox è sicuramente più potente di Ps2, ma sappiamo tutti che (a torto o a ragione) la Ps2 ha un gran numero di estimatori a cui poco importa la potenza :)

Link?

Quest'intervista: http://hardware.gamespot.com/Story-ST-17585-2004-4-7-x

Che erano quasi tutti prerenderizzati .

Non quelli più impressionanti dal punto di vista della simulazione fisica(paperelle e città)!

Non quelli più impressionanti dal punto di vista della simulazione fisica(paperelle e città)!

Ah beh, le paperelle erano vera rivoluzione.

In realta' per fare fisica si puo' usare la GPU che e' un missile in confronto al Cell.
Dipende dalla simulazione fisica ;)
Se parliamo di illuminazione, non c'è confronto, a parte casi molto particolari. Se parliamo di corpi rigidi e simulazioni con elementi finiti (ex. fluidodinamica) invece le GPU sono parecchio limitate rispetto al Cell (soprattutto a causa della scarsa flessibilità delle unità e dell'accesso alla memoria).
Con R500 però potresti avere ragione :p

Ah beh, le paperelle erano vera rivoluzione.
Quelle infatti non erano molto interessanti (a parte la quantità industriale mostrata nella demo :D), invece mi ha stupito la facilità con cui è stata gestita la fluidodinamica nella demo dei bicchieri.

Mi mancano delle techdemo da parte di Microsoft. L'R500 è la vera incognita della XBOX 360 e sarebbe stato interessante vedere che cosa è capace di fare.

Dipende dalla simulazione fisica ;)
Se parliamo di illuminazione, non c'è confronto, a parte casi molto particolari. Se parliamo di corpi rigidi e simulazioni con elementi finiti (ex. fluidodinamica) invece le GPU sono parecchio limitate rispetto al Cell (soprattutto a causa della scarsa flessibilità delle unità e dell'accesso alla memoria).
Con R500 però potresti avere ragione :p

Parlo proprio di simulazione di corpi rigidi e non, tipo cloth simulation.
Il problema grosso delle GPU attuali su PC, che in realta' si scopre essere un problema delle Direct3D, e' "chiudere il ciclo", calcolare la posizione di un vertice a seguito di una simulazione fisica e poi usarlo all'inizio del ciclo successivo.

Gia' l'xbox risolveva questo problema.

Risolto questo problema, il modello di programmazione ora e' abbastanza ricco per simulazioni di una certa consistenza. Ho visto applicazioni di fluidodinamica eseguite a framerate interattivi da una 6800 da far impallidire quel bicchiere.

Uff... Su MacOS 9 l'allocazione della memoria era statica, si doveva assegnare manualmente un tot di memoria all'applicazione, e quest'ultima più di quella assegnata non vedeva. Su OS X tutte le applicazioni possono indirizzare 4GB di Ram, poi ci pensa il sistema operativo a fare sì che l'applicazione abbia la memoria vera quando gli serve e a swappare quella inutilizzata su disco.
Bene: questo è un problema del s.o. e non dell'applicazione "classica", per cui non è necessario riscriverla / ricompilarla per risolverlo.
Su MacOS 9 il multitasking era cooperative, quindi l'applicazione doveva prevedere ogni tanto di rilasciare tempo macchina per le altre applicazioni, mettendo una serie di istruzioni qua e là nel codice. Su OS X il multitasking è preemptive e quindi ci pensa l'OS a dare tempo alle applicazioni. Però quest'ultimo prevede anche applicazioni realtime, cioè con un determinato tempo macchina costante.
Anche questo è un problema di poca importanza: si risolvere con una banale:

#define RELEASE_CPU \
#ifdef OS_CLASSIC \
Sleep(); /* E' un esempio: al posto di Sleep() mettici il nome dell'API di MacOS che rilascia il processore allo scheduler, e di cui adesso non ricordo il nome). Lo stesso vale per la definizione della costante OS_CLASSIC. */ \
#endif
E sostituendo la chiamata a "Sleep();" con RELEASE_CPU nel codice: una banale operazione Ricerca & Sostituisci, insomma.

Quindi compilando l'applicazione "classica" viene generata l'apposita istruzione, mentre con OS X non viene aggiunta NESSUNA istruzione al codice (che quindi gira a piena velocità).
Tutte queste differenze fanno sì che nelle implementazioni le applicazioni debbano seguire strategie completamente differenti per ottimizzare il codice. Quindi le applicazioni portate da MacOS 9, cioè che girano con le API carbon, se erano state costruite PENSANDO alla gestione della memoria e dei task del MacOS 9 sicuramente non rendono come le applicazioni pensate per il modello di memoria e di multitasking di OS X.
Vedi sopra: se sono solo questi i problemi, sono eliminabili con estrema facilità... ;)
Non basta una ricompilata per avere il massimo, insomma...
Il massimo no, perché OS X ha delle nuove caratteristiche rispetto a MacOS "Classic", ma come vedi da ciò che ho scritto, si può comunque ottenere un buon prodotto con i dovuti accorgimenti (l'uso della macro di cui sopra) e una banale ricompilazione... :p
Adobe non userà core-image su Mac (come non usa nessuna delle caratteristiche avanzate di OS X) perchè non c'è un corrispettivo su Windows e quindi le sue applicazioni non potrebbero essere completamente multipiattaforma.
Mi sembra che le API di MacOS / OS X e di Windows siano sufficientemente (per non dire completamente) diverse: eppure il porting da MacOS a Windows è stato fatto. Non solo: le GUI sono completamente diverse (a livello di API), per cui ha dovuto fare un bel lavoro.

Non credo che Adobe si possa fermare davanti a un dettaglio come questo...
Per questo dico che Adobe ormai più che supportare Apple la sopporta. Adobe non ha una singola applicazione nativa Cocoa, sono tutte porting delle versioni per MacOS 9 quindi scritte con API Carbon.
Hai qualche link ufficiale in merito?

Mah, ragazzi... concordate con il chi vivrà vedrà...?

ma scusate un attimo ma in pratica state dicendo che la play 3 avra problemi ad applicare aax4 in hd perche non ha i 10 mb di vram incastonata nella gpu? a diferenza della gpu della x360. ma allora la memoria vram dedicata alla gpu da 256 gdd3 a cosa gli serve?secondo me serve anche per aax4 o sbaglio.

Bene: questo è un problema del s.o. e non dell'applicazione "classica", per cui non è necessario riscriverla / ricompilarla per risolverlo.
....


Vabbè, è come di te: una ricompilata e via.
Infatti molti fanno così. Infatti molti porting (anche dal MacOS 9) fanno schifo. Un po' di info:
http://developer.apple.com/technotes/tn/tn2003.html
http://developer.apple.com/documentation/Carbon/Conceptual/carbon_porting_guide/cpg_intro_struct/chapter_1_section_1.html

Hai qualche link ufficiale in merito?

Bah, non servono. Le applicazioni Cocoa (con le API native di OS X) si riconoscono da diversi dettagli, e poi è una cosa nota. Anzi Carbon probabilmente è stato fatto proprio per Adobe e altre software house come lei che non volevano assolutamente convertire le loro applicazioni in cocoa.

ma scusate un attimo ma in pratica state dicendo che la play 3 avra problemi ad applicare aax4 in hd perche non ha i 10 mb di vram incastonata nella gpu? a diferenza della gpu della x360. ma allora la memoria vram dedicata alla gpu da 256 gdd3 a cosa gli serve?secondo me serve anche per aax4 o sbaglio.

Non e' questione di avere problemi o meno, ma del suo costo.

Su PS3 avra' certamente un certo costo, grande, piccolo, ancora non e' possibile stimarlo con sicurezza. Si sa' che questo costo sara' maggiore di quanto lo sia nell'R500 perche' per applicare MSAA 4x l'RSX dovra' leggere i sample dal framebuffer attraverso il bus, applicare il filtro, e riscrivere il risultato nel framebuffer (semplifico un po'). Quest'operazione avra' un certo costo in termini di banda passante che all'inizio non pesera' molto, ma quando in futuro i giochi inizieranno a spremere l'hardware potrebbe avere un impatto negativo.

L'eDRAM dell'X360, al contrario, e' definitiva intelligente perche' e' in grado fra le altre cose di effettuare l'operazione di filtraggio al suo interno in maniera trasparente senza impegnare il bus in costosi cicli di read/modify/write (leggi/modifica/scrivi).

Ma in pratica l'R500 può aiutare il processore in che campi allora??
Fisica e grafica??

Ma in pratica l'R500 può aiutare il processore in che campi allora??
Fisica e grafica??

Sulla grafica ovviamente. Puo' macinare alcuni algoritmi che hanno a che fare con la fisica.

sulla edram bisogna vedere se veramente non l'avrà, secondo me la sony non ne parla perchè non hanno ancora deciso quanta metterne e mancano anche altre cose come la quantità delle pipeline dell'rsx è completamente oscura (forse perchè non hanno deciso neanche quello ? lul)

poi magari sbaglio e non ci sarà veramente però darlo proprio scontato scontato mi pare ancora presto

Il problema grosso delle GPU attuali su PC, che in realta' si scopre essere un problema delle Direct3D, e' "chiudere il ciclo", calcolare la posizione di un vertice a seguito di una simulazione fisica e poi usarlo all'inizio del ciclo successivo.
Non sono sicuro di aver capito... stai parlando di riutilizzare il risultato di uno shader come input di un altro direttamente? Ora si usa una texture intermedia (come descritto nell'esempio che si trova qui: http://download.nvidia.com/developer/SDK/Individual_Samples/featured_samples.html) ma ovviamente si perde in efficienza.

Gia' l'xbox risolveva questo problema.
:confused:
In che senso?

Risolto questo problema, il modello di programmazione ora e' abbastanza ricco per simulazioni di una certa consistenza. Ho visto applicazioni di fluidodinamica eseguite a framerate interattivi da una 6800 da far impallidire quel bicchiere.
C'è un link alla demo? Sulla rete non si riesce a trovare.
La grande potenza nel calcolo vettoriale delle GPU è molto utile per le simulazioni fisiche (e mi fa credere che in futuro GPU e PPU saranno un unico chip) ma credo che in un confronto con il Cell le GPU di oggi ne escano malridotte, anche solo per la potenza bruta in dot product.

Non sono sicuro di aver capito... stai parlando di riutilizzare il risultato di uno shader come input di un altro direttamente? Ora si usa una texture intermedia (come descritto nell'esempio che si trova qui: http://download.nvidia.com/developer/SDK/Individual_Samples/featured_samples.html) ma ovviamente si perde in efficienza.

Su 6800 si puo' usare una texture come input del vertex shader, visto che l'SM3.0 prevede i texture fetch nel vertex shader.
Ma e' comunque un work around noioso per una cosa che e' supportata in hardware fino dall'NV30 via OpenGL. L'idea e' di scrivere il risultato del pixel shader in una texture, che non e' altro che una rappresentazione di una porzione di memoria della scheda grafica, e poi dire alla scheda grafica che quella porzione di memoria non e' piu' una texture, ma un vertex buffer che contiene la geometria. Cosi' si chiude il ciclo. OpenGL permette quest'operazione, Direct3D no.


:confused:
In che senso?


La versione delle Direct3D per xbox permette quest'operazione di "casting" di zone di memoria. Non domandarmi perche' le D3D9 non lo permettono, misteri insondabili della fede :)


C'è un link alla demo? Sulla rete non si riesce a trovare.


Una delle applicazioni piu' interessanti che ho visto e' sul libro GPU Gems 2.


La grande potenza nel calcolo vettoriale delle GPU è molto utile per le simulazioni fisiche (e mi fa credere che in futuro GPU e PPU saranno un unico chip) ma credo che in un confronto con il Cell le GPU di oggi ne escano malridotte, anche solo per la potenza bruta in dot product.

Non sono d'accordo con te. E' proprio su operazioni come il dot product, che le GPU implementano in hardware, che il Cell si troverebbe decisamente svantaggiato. Immagina implementare un'operazione come la normalizzazione (prodotto scalare, inverso di radice e poi moltiplicazione) di un vettore che l'NV40 esegue in un solo colpo di clock in parallello con altre due operazioni semplici su 16 pipeline. Se un'implementazione su Cell richiedesse piu' di 3 colpi di clock, andrebbe piu' piano dell'NV40 facendo solo quello, quando l'NV40 avrebbe spazio per altre due operazioni ed un accesso alla memoria.

Sono d'accordo sulla PPU e la GPU inglobate nello stesso chip che diventerebbe un generico coprocessore vettoriale.

La versione delle Direct3D per xbox permette quest'operazione di "casting" di zone di memoria. Non domandarmi perche' le D3D9 non lo permettono, misteri insondabili della fede :)
Non pensavo che ci fosse un limite così importante fino agli shader 3.0. L'importanza del texture fetch nei vertex shader è più importante per questo motivo che per un (improbabile) displacement mapping :p

Non sono d'accordo con te. E' proprio su operazioni come il dot product, che le GPU implementano in hardware, che il Cell si troverebbe decisamente svantaggiato.
Il tuo discorso è corretto, ma per la grafica ;)
Emulare la normalizzazione con altre operazioni è vantaggioso solo se la penalità non è troppo alta, oppure se non è un'operazione frequente. Con l'uso delle normal map è una operazione quasi onnipresente.
Nei calcoli fisici invece una situazione del genere è molto meno frequente, anzi, spesso si hanno somme pesate o operazioni di algebra lineare, che possono essere eseguite molto velocemente da unità MADD. Ovviamente unità generiche non potranno comunque competere con unità pensate per la simulazione fisica, come quelle presenti in una PPU.

Non pensavo che ci fosse un limite così importante fino agli shader 3.0. L'importanza del texture fetch nei vertex shader è più importante per questo motivo che per un (improbabile) displacement mapping :p


Si', vero :)


Il tuo discorso è corretto, ma per la grafica ;)
Emulare la normalizzazione con altre operazioni è vantaggioso solo se la penalità non è troppo alta, oppure se non è un'operazione frequente. Con l'uso delle normal map è una operazione quasi onnipresente.
Nei calcoli fisici invece una situazione del genere è molto meno frequente, anzi, spesso si hanno somme pesate o operazioni di algebra lineare, che possono essere eseguite molto velocemente da unità MADD. Ovviamente unità generiche non potranno comunque competere con unità pensate per la simulazione fisica, come quelle presenti in una PPU.

Sono d'accordo con te. Ho portato l'esempio della normalizzazione come un altro esempio di operazione complessa come il dot product che hai portato tu, per dire che su questo tipo di operazioni le GPU hanno un vantaggio.
Sull'applicazione di filter kernel, invece, il Cell ha un deciso vantaggio per via dell'ottimo modello di memoria locale a latenze fisse, mentre le GPU in questa situazione hanno un certo numero di indirezioni fra cache e code varie che le penalizzano, e inoltre non riescono a saturare tutte le unita' della pipeline.

ma e piu potente play3 o x360 ,o sono uguali ?pero le caratteristiche tecniche della gpu rsx non sono ancora ufficiali si sa solo che viaggia a 550mhz e macina 1,8 tflops e poche altre cose .

ma e piu potente play3 o x360 ,o sono uguali ?pero le caratteristiche tecniche della gpu rsx non sono ancora ufficiali si sa solo che viaggia a 550mhz e macina 1,8 tflops e poche altre cose .
Per ora è difficile dire quale sarà più potente, sulla carta c'è un certo vantaggio per la PS3, e vedendo il numero di transistor impiegati non c'è da stupirsi. D'altra parte il suo lancio è programmato qualche mese dopo l'uscita di XBOX 360. Le specifiche comunque contano relativamente: è molto più importante come la potenza verrà usata, e soprattutto la presenza di colli di bottiglia (nel caso della PS2 uno era la memoria video) che potrebbero limitare le prestazioni. Ma questo si saprà solo quando l'architettura verrà sviscerata e sfruttata, cioè fra almeno un anno (ad essere ottimisti). Il massimo che si può fare ora è valutare i punti di forza e di debolezza delle due architetture.
I Tflops lasciali stare, da una parte e dall'altra: sono relativi a operazioni non programmabili, e quindi del tutto inutili per un confronto. Discorso analogo per le shader ops, dal momento che RSX può eseguire 5 operazioni scalari per pipe per clock (che contano 5), a differenza di R500 che probabilmente avrà un 4+1 (che contano 2), ma nelle applicazioni tipiche non c'è differenza.

A mio avviso l'R500 è troppo misterioso per poter dare dei verdetti finali, praticamente non si sa nulla, al di la di poche cose. ATI e MS di certo non hanno scelto una strada evolutiva parecchio marcata per andare più piano della precedente generazione grafica, se hanno osato le unità unificate avranno i loro motivi ... non sono di certo dei masochisti :)

Credo sia interessante:

http://punto-informatico.it/p.asp?i=52984&r=PI

Da molti siti leggo che la X360 è molto equilibrata, mentre, a quanto sembra la potenza del cell non potrà usare tutta la sua potenza a causa proprio dei colli di bottiglia... non si riesce a capire se ne avrà???? :confused:

Scusa, Fek. Tu hai detto che l'NV40 è in grado di fare una normalizzazione più 2 operazioni semplici per ciclo di clock (e se non ho capito male, questo per ognuna delle 16 pipelines) e dici che è conveniente il Cell se riuscisse a fare la normalizzazione in 3 cicli di clock. Ma il clock dell'NV40 arriva a circa 500Mhz, mentre quello del Cell, arriva a 3,2Ghz (ed anche 4,6, ma non nella PS3 ;) ). Se ci facciamo i conti il Cell ha 7 (o 8???) SPU, che hanno una potenza non molto distante (credo almeno la metà, ma forse di più) da una pipeline dell'NV40, se consideriamo che una va a 0,5 ed un'altra va a 3,2 (o 4,6) GHz. Considera che ogni SPU ha la sua (seppur piccola) memoria dedicata, invece le pipeline dell'NV40 immagino che condividano la banda... Immagino che il clock dell'NV40 sia molto basso perchè il critical path sia lunghissimo (e te credo... una normalizzazione, immagino FP32, in un ciclo di clock... :eek: ), quindi, in conclusione, tu ritieni non comparabili Cell e una GPU, perchè il Cell, pur avendo un clock molto alto, può fare solo operazioni "semplici" ?

Vabbè, è come di te: una ricompilata e via.
Non ho detto questo: ho semplicemente risposto alle precise questioni che tu hai sollevato.
Infatti molti fanno così. Infatti molti porting (anche dal MacOS 9) fanno schifo. Un po' di info:
http://developer.apple.com/technotes/tn/tn2003.html
http://developer.apple.com/documentation/Carbon/Conceptual/carbon_porting_guide/cpg_intro_struct/chapter_1_section_1.html
Letto, ma dipende sempre dal tipo di applicazione.
Esempio: con Photoshop una volta che la memoria è allocata e l'immagine è caricata, il s.o. non viene chiamato quando si applica un filtro, o si fa un'altra operazione; è tutto a carico della CPU, e questa il lavoro lo fa allo stesso modo, che sotto ci sia MacOS o OS X...
Bah, non servono. Le applicazioni Cocoa (con le API native di OS X) si riconoscono da diversi dettagli,
Quali?
e poi è una cosa nota.
A chi? A me non risulta.
Anzi Carbon probabilmente è stato fatto proprio per Adobe e altre software house come lei che non volevano assolutamente convertire le loro applicazioni in cocoa.
Nessuno ha informazioni in merito: sul campo delle supposizione si può dire tutto e il contrario di tutto, ma non si arriva a niente...

Scusa, Fek. Tu hai detto che l'NV40 è in grado di fare una normalizzazione più 2 operazioni semplici per ciclo di clock (e se non ho capito male, questo per ognuna delle 16 pipelines) e dici che è conveniente il Cell se riuscisse a fare la normalizzazione in 3 cicli di clock. Ma il clock dell'NV40 arriva a circa 500Mhz, mentre quello del Cell, arriva a 3,2Ghz (ed anche 4,6, ma non nella PS3 ;) ). Se ci facciamo i conti il Cell ha 7 (o 8???) SPU, che hanno una potenza non molto distante (credo almeno la metà, ma forse di più) da una pipeline dell'NV40, se consideriamo che una va a 0,5 ed un'altra va a 3,2 (o 4,6) GHz. Considera che ogni SPU ha la sua (seppur piccola) memoria dedicata, invece le pipeline dell'NV40 immagino che condividano la banda... Immagino che il clock dell'NV40 sia molto basso perchè il critical path sia lunghissimo (e te credo... una normalizzazione, immagino FP32, in un ciclo di clock... :eek: ), quindi, in conclusione, tu ritieni non comparabili Cell e una GPU, perchè il Cell, pur avendo un clock molto alto, può fare solo operazioni "semplici" ?

Tieni presente che ho fatto un esempio specifico che non puo' essere generalizzato, come ha giustamente detto Banus.

Vediamo se ricordo i calcoli che ho fatto per tirare fuori il limite delle 3 istruzioni; li ho fatti a mente quindi quasi sicuramente sono sbagliati :p

La normalizzazione e' fp16 (avevo dimenticato di specificarlo).

Il Cell ha un vantaggio di circa 6 volte in quanto a clock. Per ogni colpo di clock dell'NV40, il Cell effettua circa 6 colpi di clock.
In condizioni ideali (che non si verificano mai comunque), l'NV40 puo' eseguire in un secondo un numero di normalizzazioni pari a:

1 clock * 500 mhz * 16 pipeline = 8 miliardi di normalizzazioni al secondo

In un secondo il Cell ha a disposizione un numero di colpi di clock pari a:

3.2ghz * 8 SPE = 25 miliardi di colpi di clock

25 / 8 = circa 3 colpi di clock per normalizzazione (il calcolo era giusto, sono stupito :D)

Quindi, se il Cell e' in grado di eseguire una normalizzazione ogni 3 colpi di clock, sono in pareggio.
Ora non conosco l'ISA del Cell, ma credo sia possibile impacchettare il doppio di vettori se fp16 e fare calcoli su di loro, in questo caso raddoppia il 3.

Io ritengo che il Cell sia ottimo e velocissimo per determinati compiti (i filtri sono un esempio), ma la velocita' costa in termini di flessibilita' e secondo me il Cell diventa velocemente molto lento quando si esce dal suo modello di programmazione per il quale e' ottimizzato.

Per quanto riguarda la virgola mobile Cell dovrebbe supportare solamente valori a 32 bit e a 64 bit (ma in questo caso è dieci volte più lento).
Dovrebbe anche permettere di elaborare valori interi a 8, 16 e 32 bit.

Quindi, se il Cell e' in grado di eseguire una normalizzazione ogni 3 colpi di clock, sono in pareggio.
Ora non conosco l'ISA del Cell, ma credo sia possibile impacchettare il doppio di vettori se fp16 e fare calcoli su di loro, in questo caso raddoppia il 3.
Lo sapevo che avevi fatto quel calcolo :D
Comunque anche impacchettando i dati dubito che si riesca a raddoppiare le prestazioni con fp16. L'influenza delle differenti politiche di accesso alla memoria sono ancora più difficili da stimare, dal momento che non si sa molto di RSX, e poco del modello di programmazione di Cell. Quindi è inutile farsi pippe mentali :p

Io ritengo che il Cell sia ottimo e velocissimo per determinati compiti (i filtri sono un esempio), ma la velocita' costa in termini di flessibilita' e secondo me il Cell diventa velocemente molto lento quando si esce dal suo modello di programmazione per il quale e' ottimizzato.
Infatti l'idea del consorzio era di costruire un chip velocissimo in un ambito abbastanza vasto di applicazioni, comunque limitate alla multimedialità e dintorni. Un'idea della filosofia che sta dietro agli stream preocessor come il Cell si vede in un bell'articolo di ACM queue su Imagine. Cell si pone in dirretta concorrenza con i DSP, rispetto ai quali dovrebbe essere più efficiente sia come velocità sia come consumi.

Lo sapevo che avevi fatto quel calcolo :D

E ti aspettavi che facessi chissa' quale calcolo a mente? :D


Infatti l'idea del consorzio era di costruire un chip velocissimo in un ambito abbastanza vasto di applicazioni, comunque limitate alla multimedialità e dintorni. Un'idea della filosofia che sta dietro agli stream preocessor come il Cell si vede in un bell'articolo di ACM queue su Imagine. Cell si pone in dirretta concorrenza con i DSP, rispetto ai quali dovrebbe essere più efficiente sia come velocità sia come consumi.

Si', come DSP dev'essere un missile.

interessato.ciao

dipende da chi fa il processore, il dual core AMD andrà su socket 939, i dual core intel mi sa che dovranno disporre di un nuovo socket.

Come ti ho già detto, un dual core non serve a nulla se i giochi non sono programmati per il dual core, al massimo puoi avere prestazioni elevatissime con tanti programmi in BG mentre fai partire anche il gioco.


quindi i giochi su ps3 e xbox360 non sfrutteranno i triple core dato che moltissi saranno conversioni d pc, soprattutto i primi????
BAH....avete visto i videoingame per esempio dei giochi EZSPORTS COME FIFA2006 E NBA2006, come si puo' pensare che una pcdesktop possa far girare questa roba???