HighScore/ PS3, hard disk e Linux optional

Ken Kutaragi torna a parlare di PlayStation 3, della concorrenza, del Cell, delle specifiche tecniche, dell'hard disk e, più in generale, dell'intrattenimento elettronico secondo Sony. Revolution non sembra una prerogativa solo di Nintendo


Roma – Continua a restare alto l’interesse suscitato dalla presentazione di PlayStation 3 all’E3 e, conseguentemente, l’impegno di Ken Kutaragi, CEO di Sony Computer Entertainment , nel cercare di spiegare le scelte tecniche e i punti di forza della sua nuova creatura.

In una lunga intervista rilasciata al sito PC Watch, il padre di PlayStation è tornato sui concetti già espressi circa la filosofia alla base di PlayStation 3 che, a suo dire, non si propone come una console per giocare, ma come un completo sistema di intrattenimento elettronico.

Secondo Kutaragi, i PC sarebbero ormai al capolinea e PlayStation 3 non si propone come elaborazione domestica della tecnologia PC, ma come sistema del futuro e pietra di paragone per i sistemi a venire, ragione per cui il nome è stato per la prima volta proposto in lettere maiuscole, come se PLAYSTATION fosse un nome proprio da contrapporre al generico playstation . Kutaragi ha poi ribadito che la presenza del Cell all’interno di PlayStation 3 permetterà nuovi approcci alla realizzazione del software che abbandonerà la classica via dell’assemblaggio di scene e metodi precalcolati, come per il motion capture, per passare al calcolo in real-time, cosa che consentirà la realizzazione di software molto più realistici.

Pressato da PC Watch circa la possibilità che i programmatori si allineino a questo tipo di approccio, Kutaragi ha ribadito che i demo mostrati all’E3 erano realizzati in real-time, mostrandosi fiducioso che i programmatori vorranno sfruttare le possibilità offerte dal Cell, con cui verrà calcolato anche l’audio (Kutaragi ha confermato che PlayStation 3 non è dotata di chip audio perché non ne ha bisogno). Nel criticare nuovamente l’approccio di Microsoft alla nuova generazione di console, Kutaragi ha riportato la battuta di un giornalista presente sia alla presentazione di PlayStation 3 che di Xbox 360, il quale avrebbe detto che mentre Microsoft aveva presentato la Xbox 1.5, Sony aveva presentato PlayStation 3.5, dato che PlayStation 3 era sopra le aspettative.

Kutaragi sostiene che Microsoft pretende di battere PlayStation 3 senza sapere cosa stia in effetti costruendo Sony e pertanto la futura console made in Redmond può al massimo avere come obiettivo battere PlayStation 2 (o una sua versione potenziata), ribadendo poi che la differenza tra PS3 e Xbox 360 sarà avvertibile più che dalle specifiche, dal funzionamento delle due macchine. Kutaragi ha esemplificato il suo pensiero ricordando come ai tempi della prima PlayStation, Sony ricevesse critiche circa la somiglianza tra PSX e 3DO (entrambe macchine dotate di CD-ROM e grafica 3D), da parte di coloro che non concepivano il salto generazionale che la grafica in 3D calcolato stava per far compiere alle console.

Oltre che una critica al concetto stesso di evoluzione seguito da Microsoft, queste parole potrebbero nascondere la possibilità che le specifiche di PlayStation 3 possano essere tutt’altro che definitive.

Riguardo alla presenza di un hard disk, Kutaragi ha confermato le voci circa le intenzioni di Sony di non fornire un disco fisso in dotazione, motivando la decisione con la certezza che qualunque taglio non avrebbe mai garantito spazio a sufficienza. Sebbene PS3 potrà contare sulla presenza di network drive, le cui dimensioni potrebbero anche superare il terabyte, la presenza di un drive magnetico locale verrà comunque lasciata come opzione per tutte le eventuali applicazioni locali. Tra queste applicazioni, Kutaragi ha menzionato la presenza di un sistema operativo.

Lamentandosi dell’atteggiamento di Nintendo e Microsoft, che cercano in ogni modo di far passare le loro console come giocattoli, Kutaragi ha detto che non è giusto che un dispositivo della potenza di un supercomputer sia trattato come semplice passatempo, e così per cambiare la percezione di PS3, Linux potrebbe essere incluso in ogni hard disk. A questo proposito, però, Kutaragi ha dichiarato che, poiché le caratteristiche del Cell permettono di vedere i sistemi operativi (il Cell è in grado di eseguirne molti contemporaneamente, N.d.R.) alla stregua di semplici programmi, l’introduzione di Linux potrebbe essere solo l’inizio e Lindows, Tiger, Windows o sistemi completamente nuovi potrebbero rappresentare il futuro.

Augurandosi che PlayStation 3 sia capace di attirare lo sviluppo di software alla stregua di quanto fatto in passato da Apple e Windows, Kutaragi ha anche accennato al fatto che non è più possibile per Sony rilasciare le librerie di programmazione e sperare che i programmatori facciano tutto il lavoro da soli, accennando in proposito al supporto fornito in forma open. I software di cui parla Kutaragi non sono necessariamente giochi: lo stesso padre di PlayStation, citando un recente software di sincronizzazione iTunes realizzato da terze parti per la PSP, ha ricordato come il Cell e interfacce basate su Eye Toy potrebbero portare beneficio ad applicazioni come il fotoritocco, o l’authoring video non lineare, oltre che, naturalmente, i giochi.

Sembra insomma che Sony abbia ricevuto e recepito le critiche espresse dalla concorrenza e stia lavorando alacremente nelle direzioni opportune: solo il tempo potrà dire chi, fra marketing e sviluppo, catalizzerà i maggiori sforzi.

Fonte: HighScore.it

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • Anonimo scrive:
    SCOUT è disponibile?
    dove si scarica?tipo di licenza?manuali, tutorial, esempi?Qualcuno ha notizie?Graize
  • Vide scrive:
    OpenGL? Ma come?
    Le migliori librerie non erano le Direct3D? :D:D (troll)
    • Anonimo scrive:
      Re: OpenGL? Ma come?
      - Scritto da: Vide
      Le migliori librerie non erano le Direct3D? :D:D
      (troll)No, ovviamente sono sempre state le OpenGL (troll2)
    • Anonimo scrive:
      Re: OpenGL? Ma come?
      - Scritto da: Vide
      Le migliori librerie non erano le Direct3D? :D:D
      (troll)Le OpenGL sono leggermente più indietro rispetto alle Direct3D ma sono più semplici da programmare e, soprattutto, sono multipiattaforma.Poi neanche tanto indietro, ci hanno fatto l'engine di Doom3...
  • Anonimo scrive:
    E' vecchia...
    Gia' in alcune aziende di "livello" (e pure italiane) si era cominciato a farlo...E pure i militari Coreani (tecnologia per sommergibili)Con le PS2 della Sony...E circa 8/9 anni fa...Dove sta la novita'?
    • h3rm3s scrive:
      Re: E' vecchia...
      Io ricordo (vagamente) che ai tempi del c64 c'è qualcuno che implemento il Life usando la gpu perchè faceva operazioni vettoriali e andava molto più velocemente di x86 e workstation unix. E' ovvio che se fai una cosa sola la PUOI far meglio di chi ne fa diverse. Ma se un programmatore oggi conosce solo Java e .Net è altrettanto evidente che ti serve hardware molto potente perchè l'efficienza nell'utilizzo della macchina è ridicola. Però puoi usare un programmatore junior e pagarlo un pugno di riso.
      • Anonimo scrive:
        Re: E' vecchia...
        allora c'e da fare una cosa:x86 asembler, c++ (nelle scuole niente java, php, asp)di base il c++ e asembler il resto non e' necessariopoi .net c# sono solo c@zzate per fare soldi e far programmi infretta (altra cosa)non mi sognerei mai di far scrivere un gestionale in c++o in asembler
        • Anonimo scrive:
          Re: E' vecchia...
          non c'è bisogno di portare così all'estremo le cose, ma è innegabile che chi sa programmare in assembler o in C ha una mentalità (non una capacità, una mentalità) che lo porta a sfruttare meglio le risorse hardware. In particolare ritengono che i programmi devono essere maledettamente efficienti sia nell'uso della CPU che nel consumo di RAM. Ricordo che anni fa, sul mitico BYTE c'era il confronto tra Lotus 1-2-3 nelle varie versioni e si notava un enorme salto tra la versione scritta in assembler e quella scritta in C. Ti puoi immaginare passare da C a VB, .Net, ... Non dico che i gestionali vadano scritti in C, ma quando vedi che per avere la visione dello stato della tastiera sul desktop ti devi mangiare mega e mega di RAM ti chiedi cos'hanno in testa certi programmatori. Diciamo allora, che per ogni tipo di programma ci vuole il suo linguaggio: utilità di sistema ? C e assembler. gestionali ? VB e .net e compagnia. In mezzo ci sono decine e decine di altri linguaggi. madder
          • Anonimo scrive:
            Re: E' vecchia...
            E' anche vero che i programmatoruccoli che fanno i gestionali non conoscono assolutamente che cosa possa essere una struttura dati e cosa si intenda per costo computazionale. Quindi fanno programmi che per fare due boiate fanno 50000 cicli o anche solo una ricerca sequenziale, quando una ricerca in un albero sarebbe piu' consigliato.
          • Anonimo scrive:
            Re: E' vecchia...
            - Scritto da: Anonimo
            quando una ricerca
            in un albero sarebbe piu' consigliato.Hai trovato la banana, sull'albero ?
    • Anonimo scrive:
      Re: E' vecchia...
      - Scritto da: Anonimo
      Dove sta la novita'?Quindi se una notizia non contiene una novita' strabiliante non va riportata?E' una notizia.
  • scorpioprise scrive:
    Sinceramente? era ovvio ;)
    Innanzitutto fare loro i complimenti è d'obbligo, in quanto sono stati in grado di fare meglio di uno Xeon con una GPU, e in effetti non è poco.Tuttavia:La GPU di una scheda grafica è un DSP, alias un digital signal processor. Era *ovvio* che desse delle gran legnate ai processori general purpose!!!(Chi ci abbia lavorato sopra capirà cosa intendo) Un normalissimo DSP, che vada alla mirabolante frequenza di 200MHz, con un programma scritto BENE (e questo è il suo segreto, ma per scrivere bene il programma bisogna veramente essere esperti, e conoscere a MEMORIA il dsp che si usa), riesce a fare 20 volte più veloce i conti che un x86 a clock dieci volte superiore. :oNon si possono trasformare in general purpose, ossia, non si possono adattare a qualunque applicazione proprio perchè ad esempio un semplice "salto" da una parte di programma ad un altro (chiamate a funzione, "if", cose simili) irrimediabilmente causa una perdita di prestazioni impressionante, perchè interrompe la pipeline, blocca i loop di ripetizione, impone almeno due context switch (ossia salvataggi in memoria dello stato interno del DSP ) causa insomma una perdita di tempo che a 200MHz si fa sentire.==================================Modificato dall'autore il 13/06/2005 10.10.27
    • Anonimo scrive:
      Re: Sinceramente? era ovvio ;)
      - Scritto da: scorpioprise
      Tuttavia:
      La GPU di una scheda grafica è un DSP, alias un
      digital signal processor. Era *ovvio* che desse
      delle gran legnate ai processori general
      purpose!!!(Chi ci abbia lavorato sopra capirà
      cosa intendo) Dillo a Microsoft, che sostiene che Xbox360 darà le legnate a PS3 perché il processore di PS3 è un SOLO un dsp, mentre quello di Xbox360 è BEN un general purpose...
    • pikappa scrive:
      Re: Sinceramente? era ovvio ;)
      - Scritto da: scorpioprise
      Innanzitutto fare loro i complimenti è d'obbligo,
      in quanto sono stati in grado di fare meglio di
      uno Xeon con una GPU, e in effetti non è poco.

      Tuttavia:
      La GPU di una scheda grafica è un DSP, alias un
      digital signal processor. Era *ovvio* che desse
      delle gran legnate ai processori general
      purpose!!!(Chi ci abbia lavorato sopra capirà
      cosa intendo)

      Un normalissimo DSP, che vada alla mirabolante
      frequenza di 200MHz, con un programma scritto
      BENE (e questo è il suo segreto, ma per scrivere
      bene il programma bisogna veramente essere
      esperti, e conoscere a MEMORIA il dsp che si
      usa), riesce a fare 20 volte più veloce i conti
      che un x86 a clock dieci volte superiore. :o

      Non si possono trasformare in general purpose,
      ossia, non si possono adattare a qualunque
      applicazione proprio perchè ad esempio un
      semplice "salto" da una parte di programma ad un
      altro (chiamate a funzione, "if", cose simili)
      irrimediabilmente causa una perdita di
      prestazioni impressionante, perchè interrompe la
      pipeline, blocca i loop di ripetizione, impone
      almeno due context switch (ossia salvataggi in
      memoria dello stato interno del DSP ) causa
      insomma una perdita di tempo che a 200MHz si fa
      sentire.E a questo punto mi chiedo, a quando la possibilità di utilizzarli come coprocessori e rendendoli accessibili alle applicazioni che ne hanno bisogno? (penso al rendering, ma anche ad un window manager ipercolorato :-P)
    • Anonimo scrive:
      Re: Sinceramente? era ovvio ;)
      Per spiegare meglio , prima che la gente si chieda perchè non mettere i DSP al posto dei pentium.In realtà i DSP sono si dei processori iperveloci ma dipende cosa li usi a fare .Come hai detto tu i DSP hanno i loro programmi scritti internamente che però sono fatti solo per l'esecuzione di certi specifici calcoli o quanto meno, piccoli programmi velocemente, quindi possono essere programmati per eseguire per esempio una trasformata di Fourier per il processo MPEG o cose simili .Usare una scheda 3D per la simulazione di una esplosione è una cosa molto semplice, visto che il 3D si basa su vettori di 4 elementi che oltre a servire nel calcolo delle rototraslazioni (matrici) serve eregiamente nei calcoli di meccanica (razionale) per gli stati non solidi, attraverso l'astrazione dei quaternioni (quelli che usa il motore di certi giochi come Tomb Rider). Dunque il DSP di una scheda grafica è PERFETTO per quel lavoro.McZ
      • JoJo79 scrive:
        Re: Sinceramente? era ovvio ;)
        - Scritto da: Anonimo
        Per spiegare meglio , prima che la gente si
        chieda perchè non mettere i DSP al posto dei
        pentium.

        In realtà i DSP sono si dei processori iperveloci
        ma dipende cosa li usi a fare .

        Come hai detto tu i DSP hanno i loro programmi
        scritti internamente che però sono fatti solo per
        l'esecuzione di certi specifici calcoli o quanto
        meno, piccoli programmi velocemente, quindi
        possono essere programmati per eseguire per
        esempio una trasformata di Fourier per il
        processo MPEG o cose simili .

        Usare una scheda 3D per la simulazione di una
        esplosione è una cosa molto semplice, visto che
        il 3D si basa su vettori di 4 elementi che oltre
        a servire nel calcolo delle rototraslazioni
        (matrici) serve eregiamente nei calcoli di
        meccanica (razionale) per gli stati non solidi,
        attraverso l'astrazione dei quaternioni (quelli
        che usa il motore di certi giochi come Tomb
        Rider).

        Dunque il DSP di una scheda grafica è PERFETTO
        per quel lavoro.

        McZParla come mangi! ;)
        • Anonimo scrive:
          Re: Sinceramente? era ovvio ;)
          te la scrivo io più semplice. I processori delle schede grafiche si programmano con i vertex ed i pixel shader. Questi sono ottimizzati per operazioni grafiche che prevedono poche operazioni con vettori da 4 elementi (xyzw) che possono essere i vertici di modelli geometrici ed i pixel delle texture. Non esistono molti tipi di registri, ne molti tipi di istruzioni ma questi sono ottimizzati per operazioni tra vettori e matrici (una matrice4x4 sono 4 vettori). Un processore normale invece non è ottimizzato per l'elaborazione di vettori. Fare un calcolo scientifico con una scheda grafica è una operazione molto diversa dal farla con un processore normale perchè in pratica bisogna usare texture come zone in cui allocare la memoria. Ho visto numerosi articoli di chi utilizzava gli shader per path finding, calcoli scientifici ed altro. Il libro GPU Gems 2 dedica un intero capitolo all'utilizzo delle gpu per calcoli scientifici. I tipi in questione hanno solo usato questo sistema e non sono stati di certo i primi visto che moltissimi programmatori già lo fanno
  • Anonimo scrive:
    La storia si ripete
    Quest'uso delle gpu mi ricorda tanto i co-processori matematici per i calcoli in virgola mobile del 386...
    • avvelenato scrive:
      Re: La storia si ripete
      - Scritto da: Anonimo
      Quest'uso delle gpu mi ricorda tanto i
      co-processori matematici per i calcoli in virgola
      mobile del 386...ma infatti mi domando quand'é che monteremo le gpu direttamente sulla mobo, senza necessità di scheda e con bus molto più veloce degli attuali.
      • Anonimo scrive:
        Re: La storia si ripete
        - Scritto da: avvelenato

        - Scritto da: Anonimo

        Quest'uso delle gpu mi ricorda tanto i

        co-processori matematici per i calcoli in
        virgola

        mobile del 386...

        ma infatti mi domando quand'é che monteremo le
        gpu direttamente sulla mobo, senza necessità di
        scheda e con bus molto più veloce degli attuali.Pigliati una grafica integrata 8)Poi non lamentarti che è difficilmente aggiornabile.(Sò cosa pensi, socket per la GPU.Questo si che sarebbe castrare lo sviluppo delle schede video.La possibilità di progettare tutto il sottosistema GPU/VRAM è la forza della loro evoluzione, ricorderai bene che qualche anno fà si poteva espandere la VRAM delle schede.Ma "forse" i chip saldati sul PCB reggono bus più elevati che agganciati negli slot ;) )
        • avvelenato scrive:
          Re: La storia si ripete
          - Scritto da: Anonimo

          - Scritto da: avvelenato



          - Scritto da: Anonimo


          Quest'uso delle gpu mi ricorda tanto i


          co-processori matematici per i calcoli in

          virgola


          mobile del 386...



          ma infatti mi domando quand'é che monteremo le

          gpu direttamente sulla mobo, senza necessità di

          scheda e con bus molto più veloce degli attuali.

          Pigliati una grafica integrata 8)
          Poi non lamentarti che è difficilmente
          aggiornabile.

          (Sò cosa pensi, socket per la GPU.
          Questo si che sarebbe castrare lo sviluppo delle
          schede video.
          La possibilità di progettare tutto il
          sottosistema GPU/VRAM è la forza della loro
          evoluzione, ricorderai bene che qualche anno fà
          si poteva espandere la VRAM delle schede.
          Ma "forse" i chip saldati sul PCB reggono bus più
          elevati che agganciati negli slot ;) )sì, ma nello stesso tempo la vram diventa lenta nel comunicare con la cpu (a quell'altro che dice che il pci-e 16x è più o meno come il bus quad-pumped o l'hypertransport, insomma, non ci giurerei, soprattutto le latenze devono essere di un paio o tre ordini di grandezza superiori.Se questo non ha alcuna importanza in ambito strettamente grafico, magari potrebbe averlo in un'architettura nuova del pc dove le memorie vram, le memorie ram, la cpu e la gpu collaborano in ogni task, dalla grafica delle gui, al calcolo intensivo, eccetera.==================================Modificato dall'autore il 13/06/2005 20.26.24
      • s0r4 scrive:
        Re: La storia si ripete

        ma infatti mi domando quand'é che monteremo le
        gpu direttamente sulla mobo, senza necessità di
        scheda e con bus molto più veloce degli attuali.Ma perchè? il PCIe 16X ed il PCIe2 non ti sembrano abbastanza veloci?Teoricamente smuovono tanti dati quanto ne smuove il bus del p4 o dell'A64
Chiudi i commenti