di  -  venerdì 21 gennaio 2011

Il 2010 è stato un anno particolarmente fortunato per l’accoppiata social networking / smartphone, un abbinamento spinto dalla crescente offerta rappresentata da vere e proprie piattaforme di divulgazione dell’ambito mobile e delle applicazioni annesse.

Apple, Google e Microsoft con i loro sistemi operativi ed i loro sistemi di commercializzazione delle applicazioni, rappresentano i principali attori, almeno per quanto concerne il mercato consumer, ma non sono certamente i soli.

Esiste un mercato parallelo e silenzioso alle orecchie del grande pubblico, che si nutre dei medesimi profitti e che si occupa di sviluppare le piattaforme hardware sulla base delle quali prendono forma i nostri amati smartphone e tablet.

Diversi sono i nomi che compongono questa cerchia tra i quali alcuni non molto conosciuti dagli utenti finali come Texas Instrument e Qualcomm, mentre altri, come Apple e NVIDIA, sono certamente più famosi.

Poco più di un anno fa vi parlai di NVIDIA e della presentazione di Tegra 2 al Consumer Electronics Show (CES) 2010, un prodotto che ha ormai raggiunto piena maturazione essendo stato adottato per la realizzazione di diversi dispositivi mobile di ultima generazione, consacrando NVIDIA, già produttore leader di GPU per gaming e GPGPU, anche nel mercato dei System On Chip (SoC).

Un anno fa forse (anche se c’era già qualche sospetto da parte mia) non era ben delineata la strategia dell’azienda di Santa Clara in merito al futuro di Tegra, ma oggi, dopo che tutti, ma proprio tutti, hanno giurato amore eterno ad ARM, ecco che anche NVIDIA scopre le sue carte parlando di Tegra 3 e Denver.

Il mercato dei SoC è molto diverso da quello delle CPU x86 o delle GPU e, osservandolo da diversi anni, posso affermare che una delle differenze sostanziali è la velocità di concretizzazione di un nuovo chip. Dal momento in cui un SoC viene annunciato, a quando questo è disponibile sul mercato adottato da più o meno prodotti, passano svariati mesi (a volte anni).

Le motivazioni di questa lentezza sono dovute ad un lavoro di integrazione hardware / software molto più delicato rispetto a quanto normalmente accade nel mondo dei personal computer. Nonostante tutto, con la scelta di presentare una nuova famiglia di SoC all’anno, e con un tempo di commercializzazione molto competitivo, NVIDIA ha dimostrato grande vivacità, in grado di infondere parecchia pressione ai suoi concorrenti.

Benché, infatti, Qualcomm abbia presentato parecchi mesi fa un SoC dual core, ancora non si sono visti smartphone in commercio che lo montano, mentre Tegra 2 può vantare la sua presenza nel LG Optimus 2X. Esiste, inoltre, un fattore molto importante su cui NVIDIA può puntare: la GPU integrata. Tegra 2 vanta un picco di quasi 80 milioni di poligoni al secondo, dimostrando di possedere tutte le carte in regola per essere la soluzione più prestante in questo ambito.

Qualcomm, invece, dopo aver acquisito da AMD la divisione Imageon, non sembra riuscire ad essere all’altezza della situazione con le sue GPU della famiglia Adreno. Texas Instrument e Apple, invece, si affidano ai core grafici PowerVR che, benché siano di tutto rispetto sia sul profilo tecnologico, che prestazionale, non si rinnovano da diverso tempo ormai: la PowerVR Serie 5 di Imagination Technologies è sul mercato da oltre tre anni e della Serie 6 (nome in codice Rogue) si attendono notizie a breve.

Secondo le ultime indiscrezioni, Tegra 3, evoluzione dell’attuale soluzione Tegra 2, verrà presentato il prossimo mese al Mobile World Congress di Barcellona. Per quanto concerne Denver, invece, si tratta di un progetto più a lungo termine e particolarmente ambizioso: se Tegra è dedicato al mondo mobile, Denver è un processore ARM destinato a personal computer, server e supercomputer. Si tratta, in sostanza, della risposta di NVIDIA all’impossibilità di ottenere una licenza x86 da Intel, una risposta che rischia di riscuotere un inaspettato successo dopo che, tra gli altri, anche Microsoft ha deciso di supportare ARM e ha dimostrato al CES di poter far funzionare Windows anche su questa piattaforma.

24 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    floriano
     scrive: 

    se Nvidia vuole produrre degli x86 perchè non fa come AMD? è proprio necessaria una licenza?

  • # 2
    Andrea Del Bene
     scrive: 

    @floriano

    Si :-). L’architettura x86 è esclusiva di Intel e se vuoi fare un processore x86 gli devi pagare una royalties. E lo fa anche AMD ovviamente.
    Questo significa anche se compri un AMD un pò di soldi finiscono comunque nelle tasche di Intel.

  • # 3
    n0v0
     scrive: 

    motivo in più per boicottare intel

    avanti tutta tegra 3, sarà il mio prossimo desktop :P

  • # 4
    alessiodp
     scrive: 

    diciamo che amd e intel hanno sepolto da tempo l’ascia di guerra…da quando le istruzioni x86-64 sono diventate uno standard e quelle sono di proprietà di AMD

  • # 5
    n0v0
     scrive: 

    volevo dire denver ;-)

  • # 6
    DottorNi
     scrive: 

    Per floriano: Non capisco a cosa ti riferisci dicendo “perché non fa come amd?” AMD ed Intel hanno un accordo di Cross-Licence, infatti se noti l’Intel ha sviluppato l’architettura x86 ma le estensioni x86-64 sono fatte da AMD e chiamate AMD64 (e le usa anche Intel nei suoi processori). Dunque se Nvidia non ha un accorto con entrambe le società difficile che riesca a costruire un processore x86 senza venir istantamente denunciata (e non credo che intel e amd sia interessate ad un accordo)

    Comunque è una svolta che io personalmente non mi aspettavo proprio quella di Nvidia. C’è però anche da dire che architetturalmente gli ARM sono fatti molto bene a quanto pare. Vedremo in futuro!

  • # 7
    Ale Molgora
     scrive: 

    @floriano
    oltre a quello che ha scritto Andrea, va precisato che Intel e’ costretta dall’antitrust a dare la licenza x86 ad almeno un’azienda che non sia di proprieta’ della stessa Intel, e quindi AMD ha potuto acquisirla e tenerla.
    Ma Intel NON ha voluto dare la licenza ad Nvidia (cosi’ come ha fatto per i chipset compatibili con gli i7), e quindi Nvidia deve percorrere questa strada con ARM, fattibile da quando Microsoft ha annunciato che Win8 girera’ anche su ARM…
    Secondo me una rivoluzione e’ alle porte!

  • # 8
    mik
     scrive: 

    Allora, AMD non deve dare neanche un centesimo ad Intel, esistono tra le due società accordi di cross-licensing, ovvero accordi secono i quali una società può utilizzare le proprietà intellettuali dell’altra senza pagare. Questo è dovuto al fatto che negli attuali processori x86, alcuni set di istruzioni sono proprietà di Intel e altri di AMD.
    Di conseguenza per poter creare un processore x86 Nvidia dovrebbe stringere accordi con entrambe le aziende, cosa alquanto improbabile.
    Per quanto riguarda l’antitrust, questo non vieta né impone assolutamente niente. L’origine dell’accordo di cross-licensing è da imputare a IBM che al momento di stringere l’accordo con Intel per l’utilizzo del 8086 nei suoi PC richiese una seconda fornitrice, in modo da non dipendere da una sola azienda, la scelta ricadde su AMD, che aveva a quel tempo prodotto una variante dell’8080.

  • # 9
    Nessuno
     scrive: 

    Il progetto Denver potrebbe davvero essere una rivoluzione se si evolverà verso la possibilità di rendere la GPU come la conosciamo oggi come un vero coprocessore senza il problema della estrema lentezza di comunicazione e sincronizzazione dei dati con la CPU.
    La possibilità di avere un micro (qualunque esso sia) che esegue dei task in maniera indipendente sulla GPU mentre aspetta i risultati provenienti dalle unità di calcolo potrebbe aprire nuove strade e rendere molto più efficienti le GPU. E la possibilità di avere dei driver ottimizzati sulla scheda invece che nel sistema operativo in modo che si possa finalmente sfruttare configurazioni eterogenee (più GPU separate o perfino unità diverse in funzionalità) in maniera trasparente.

    Potrebbe, nell’assurdo (ma non tanto) evolvere tutto come un potentissimo Cell con unità di calcolo diverse e indipendenti che comunicano solo quando necessario i risultati alla CPU principale.

    Le CPU sulle schede video potrebbero anche semplicemente portare la possibilità di creare del cluster di calcolo indipendenti senza necessità di nodi basati su altri micro (unità Tesla 100% indipendenti).

  • # 10
    pleg
     scrive: 

    @ Nessuno

    Cosa intendi con “micro”?

    Cmq, e’ esattamente quello che AMD sta facendo con Fusion: usare la GPU come coprocessore parallelo per tutti quei tipi di calcoli che beneficiano di uan soluzione del genere.
    Nel caso di NVidia sara’ la stessa cosa, ma con un multicore ARM64 + GPU Maxwell. Purtroppo mi sa che ci sara’ ancora un bel po’ da aspettare (direi 2012/13 come riferimento).

  • # 11
    asd
     scrive: 

    non corriamo, è positivo che ARM venga ad infilarsi nei desktop, ma si tratta ancora di un futuro non propriamente prossimo. Inoltre prima di intaccare anche solo minimamente la granitica presenza degli x86, ce ne vuole, e non è che Intel se ne starà a guardare

  • # 12
    pleg
     scrive: 

    Di sicuro non sta a guardare :) e’ proprio notizia di oggi di un Atom negli smartphone Nokia!
    Penso che tra quest’anno e il prossimo Intel comincera’ a sbarcare in forze quantomeno nel segmento tablet.

  • # 13
    Raffaele Fanizzi (Autore del post)
     scrive: 

    Secondo me, molto dipenderà più che da Intel, da Microsoft. Il problema di ARM è che ha un ISA differente. Se Microsoft decide di supportarlo, così come ha fatto, e adegua i suoi strumenti di sviluppo (Visual Studio e company) con compilatori adeguati, il gioco è fatto: i produttori di hardware potranno serenamente sviluppare i propri driver. Quest’ultimo è un punto cruciale: se non c’è un supporto da parte dei produttori hardware con i driver adeguati, ARM resterà sempre e solo nei ristretti ambiti SoC che, per quanto affascinanti con il loro mondo tutto integrato, non possono prescindere dall’interfacciamento con periferiche di altro genere (scanner, stampanti, schede di rete, hard disk, ecc….).

  • # 14
    pleg
     scrive: 

    Indubbiamente senza il supporto di Microsoft ARM non potrebbe arrivare nel mondo consumer (non parlo dei server, dove non e’ importante).

    Ma per il mondo mobile Intel potrebbe tagliar via uan grossa fetta ad ARM se si mette a giocare duro: se riesce a far uscire SoC con prestazioni migliori e consumi inferiori (cosa che potrebbe benissimo, visto il vantaggio in termini di tecnologia e risorse) quanto tempo ci vorrebbe prima che qualche OS da tablet migri a x86?

  • # 15
    SorenStirner
     scrive: 

    @pleg quanto tempo ci vorrebbe prima che qualche OS da tablet migri a x86?

    Intel sta lavorando al suo OS x86 (ovviamente) “da tablet” (perché ora il segmento ha più senso, prima si parlava di MID, poi di Smartphone) da diversi anni ormai e i risultati non hanno raggiunto la commercializzazione. Sto parlando di quello che fu Moblin e che adesso, grazie ad un partner d’eccezione come Nokia e il suo Maemo (che almeno lui ha avuto l’onore di arrivare sugli scaffali con la serie Nx00) stanno di nuovo rimpastando tutto in MeeGo. Questo la dice lunga su come sia difficile infilare un X86 con un OS adeguato nel mondo Mobile nonostante le risorse infinite di Intel e Nokia. A Barcellona dovrebbero presentare il Nokia N9 (MeeGo su Atom)… staremo a vedere.

    Per contro, Android ha bruciato le tappe cavalcando le recenti evoluzioni di ARM. 300.000 dispositivi mobile venduti al giorno da più di un anno. Stessa cosa ha fatto Apple. Non dimentichiamoci che uno dei più grandi licenziatari di ARM è proprio Apple che grazie alla suo modello di buisness verticale ha reso possibile il miracolo economico di iPhone (ARM+OS su misura+parco software+marketing=$$$). nVidia si è infilata in un mercato in fortissima ascesa e in fase di espansione verso il mondo PC.

    In definitiva è molto più rapida l’ascesa di ARM (e tutti quelli che su vari livelli gli girano intorno: Samsung, Apple, Qualcomm, Texas Instrument, motorola, Google ed ora anche nVidia e Microsoft) verso il desktop che la discesa di Intel con i suoi X86 verso il mondo mobile.

  • # 16
    pleg
     scrive: 

    Beh l’ascesa di ARM verso il desktop e’ solo nel progetto Denver di NVidia, al momento, non c’e’ nessun altro (che io sappia) che sta sviluppando CPU cosi’ potenti, e Denver e’ lontana direi un 1–2 anni da essere un prodotto commercializzabile. Mentre Intel dovrebbe presentare la sua nuova linea per tablet gia’ quest’anno.

    Certo Microsoft che si muove verso i sistemi mobile e multi-ISA ha aperto scenari molto interessanti: sia per ARM/NVidia/etc. (perche’ Windows girera’ anche suoi loro processori), sia per Intel, perche’ Windows si porta dietro il suo mastodontico parco software che pero’ gira per lo piu’ solo per x86.

    Molto difficile dire ad oggi come evolvera’ la situazione. Ma i prossimi due anni saranno sicuramente molto interessanti.

  • # 17
    Nessuno
     scrive: 

    Cosa intendi con “micro”?

    Cmq, e’ esattamente quello che AMD sta facendo con Fusion: usare la GPU come coprocessore parallelo per tutti quei tipi di calcoli che beneficiano di uan soluzione del genere.

    Micro = CPU di qualsiasi genere e ISA in grado di eseguire codice seriale come tutte le attuali CPU desktop.
    Fusion per ora è solo una forma di integrazione fisica in un unico dispositivo di CPU + GPU. Da lì ad avere una stretta coesione tra i due mondi ne corre ancora parecchio. Sono ancora 2 mondi separati altamente inefficienti da far convivere e neanche con OpenCL la cosa si risolve o risolverà.
    O si aggiungerà (ancora???) una estensione alla ISA x86 per supportare nativamente le istruzioni che vanno ad usare le unità di calcolo della GPU (collegate direttamente alla pipeline della CPU) o non si riuscirà a migliorare nulla.
    In quest’ottica 2 anni per la soluzione nvidia non sono per nulla molti. Vedremo piuttosto come si comporterà Windows 8 nel supporto ad architetture diverse e se garantirà la compatibilità binaria (e con quale inefficienza).

  • # 18
    Riccardo
     scrive: 

    Per me l’ ascesa (che poi è sempre stata molto presente nel mondo dell’ eletronica ….diciamo più a livello di immagine e pubblicità ) di AMR è strettamente da vedersi nella crescita esponenziale dell’ integrazione e della sinergia tra i vari settori dell’ elettronica. Infatti al CES di questo anno ( e anche passati) tutto era collegato e smart. Ora se notate io non conosco nessun TV, lettore BR, frigo, cucina, lettore multimediale portatile, che abbia una architettura x86 in questo campo la fanno da padrone AMR e MIPS d’altra parte perché aziende come Samsung, Sony, Thoshiba, TexasInstruments, Philips, ecc. devono sottostare ad un fornitore come Intel quando possono fare da loro in maniera più economica, semplice e meglio implementata alle loro esigenze . Infine non dimentichiamoci che il motore di questo cambiamento non è windows ma bensì internet quindi molti discorsi di compatibilità vengono a cadere automaticamente.

  • # 19
    pleg
     scrive: 

    @ Nessuno

    Non sono d’accordo: avere GPU e CPU integrate sullo stesso die e’ questo piu’ vicino puoi metterle, non puoi metterle piu’ vicine di cosi’, perche’ sono due oggetti radicalmente diversi, come architettura e modo d’impiego.

    Non puoi collegare direttamente le pipeline della GPU a quella della CPU e al suo scheduler di istruzioni, perche’ a quel punto perdi esattamente quello che e’ il vantaggio della soluzione: la GPU come motore massicciamente parallelo, che schedula istruzioni parallele al suo ritmo, collegato solo ad alto livello alle CPU (ad es. via cache L3).

    Quello che dici tu e’ piu’ simile a quello che ha fatto Intel col Larrabee, dove c’e’ uno sciame di core con una piccola CPU in-order affiancata da una grossa unita’ vettoriale. In quel caso si’ le unita’ parallele e non sono a strettissimo contatto (soluzione interessante), ma perdi da altre parti (i piccoli core sequenziali hanno prestazioni basse, non riuscirebbero a macinare programmi non altamente paralleli tanto quanto un Core i7, sono piu’ simili a degli Atom). E alla fine Larrabee non e’ uscito perche’ non funzionava bene neanche come GPU (anche se adesso dovremmo vedere qualcosa, riproposto come processore per HPC (sotto forma di Knights Ferry).

    Cmq, quello che fara’ NVidia e’ la stessa cosa del Fusion di AMD: AMD usa x86 + OpenCL, NVidia usera’ ARM64 + CUDA. Ma l’idea e’ la stessa.

  • # 20
    Nessuno
     scrive: 

    mmmmm…. la vicinanza fisica tra CPU e GPU è necessaria ma non è sufficiente per rendere la gestione tra i due mondi migliore.
    Il collegamento con la pipeline è il modo più efficiente per avere la piena potenza elaborativa delle due unità. Poichè, come hai detto tu non è possibile collegare tutte le unità della GPU hai bisogno di un livello intermedio che intercetti le istruzioni ad hoc per la GPU e le esegua autonomamente con le ALU parallelizzate.
    Oggi la CPU deve preparare una lista di istruzioni da inviare alla GPU e deve aspettare il risultato. Con moltissimo tempo perso per la comunicazione e sincronizzazione tra i due dispositivi. Oltre al fatto che la logica sulla GPU per interpretare questa lista di istruzioni deve essere piuttosto complessa.
    Se al posto della logica cablata nella GPU ci fosse un micro (ARM, MIPS, qualisiasi altra architettura seriale) che riceve un programma più complesso di una lista di istruzioni da elaborare con la capacità di \prendere decisioni\ più autonomamente, l’efficienza potrebbe aumentare notevolmente.

    E non è escluso che si arrivi ad una soluzione più integrata sulla GPU dove i gruppi di shader possano diventare delle vere unità di calcolo connesse alla pipeline della CPU non perdendo il vantaggio della parallelizzazione ma aumentando in maniera considerevole l’efficienza. Una sorta di DSP con gli shader module come unità di calcolo super vettoriali SIMD accanto alle normali ALU per il codice seriale.

    Solo una idea. E strasicuro che in nvidia sapranno meglio come utilizzare il vantaggio di poter intgrare una CPU che possono farsi in casa con la propria pipieline grafica.

  • # 21
    shodan
     scrive: 

    Ciao a tutti,
    in effetti sembra che le intenzioni di Nvidia coincidano con la visione di Pleg. Riprendo una news di hardware upgrade:
    “Tra oggi e Maxwell, andremo ad introdurre virtual memory, pre emption e la possibilità alla GPU di gestire in modo autonomo i processi, in modo da non bloccare la CPU e non dipendere quindi direttamente da questo componente. Questo consentirà al GPU computing di raggiungere un nuovo livello”, ha affermato Jen-Hsun Huang, CEO di NVIDIA nel corso del GTC.
    In poche parole, CPU + GPU su un singolo die, così come ora fa AMD.

    Questo però non significa necessariamente che in futuro non sia possibile connettere le unità SIMD direttamente alle pipeline classiche e usarle tramite un’estensione delle X86. Ricordo che, in base a delle slide diffuse nel 2006 da AMD, questo passaggio era in effetti previsto (per quanto in una fase molto avanzata).
    E’ anche vero che da allora la situazione di AMD e le sue roadmap sono cambiate molto… be’, vedremo.

    Ciao.

  • # 22
    pleg
     scrive: 

    Non si puo’ semplicemente “attaccare” gli shader e le unita’ vettoriali alla pipeline della CPU come fosse un’altra unita’ funzionale.

    Uno dei problema e’ che a quel punto devi decodificare e schedulare le istruzioni per la “GPU” (che non sarebbe piu’ tale, separata dal resto… chiamiamole istruzioni vettoriali, che l’unico modo per farlo e’ quello) insieme a tutte le altre, pagando un prezzo di complessita’ ed energia tale da rendere il processore meno performante (in applicazioni massicciamente parallele come appunto quelle per cui la GPU e’ progettata).

    Un altro problema e’ che le unita’ vettoriali sarebbero sparpagliate un po’ per tutti i core, con la necessita’ di dividere artificiosamente il carico di lavoro tra i core laddove non sarebbe necessario, con ulteriore spreco di risorse, energia, e complessita’ nello scrivere il software e/o i compilatori.

    Un altro problema e’ che per la grafica hai comunque bisogno di un bel po’ di funzioni fisse (puro hardware) per ottenere certe prestazioni ad un costo energetico accettabile, per esempio il polymorph engine che NVidia ha nei chip Fermi per la tessellation. Inserire queste grosse unita’ specifiche nelle pipeline della CPU e’ assurdo, e metterle fuori (e lontane) comprometterebbe prestazioni e consumi (bisognerebbe spedire i dati lontano, e spostare moli di dati costa una cifra di energia).

    Nel complesso, costruire un processore ibrido come AMD sta facendo (e NVidia fara’) ha perfettamente senso: dei grossi e potenti processori superscalari ottimizzati per codice sequenziale (o comunque con basso Instruction Level Parallelism), o su cui mandare task multithreaded “normali” (pochi, grossi thread), e di fianco una fettazza enorme di hardware super-parallelo, ottimizzato per calcoli massicciamente vettorializzabili, che puo’ eseguire in modo autonomo (in parallelo ai task in esecuzione sulla CPU) con un’efficienza energetica inarrivabile per una CPU. In questo modo puoi ottimizzare le due parti per due deisgn point diversi, e spremere il amssimo da ognuna; e programmarle anche con due paradignmi diversi, ognuno ottimizzato per diversi carichi di lavoro.

    La cosa piu’ vicina a fondere pipeline scalari della CPU e unita’ vettoriali e’ il LArrabee, ma anche in quel caso comunque le unita’ funzionali sono ben separate:
    http://www.anandtech.com/show/2580/4

    pipeline separate, ALU separate, Register File separati. I due motori (scalare e vettoriale) comunicano via cache L1 nello stesso core, e via cache L2 tra core diversi.

    Il design del Larrabee e’ certamente molto interessante, ma come GPU ha fatto flop: non e’ nemmeno uscito. Come processore HPC invece potrebbe essere molto interessante; vedremo come evolvera’ l’architettura, appena si vedranno in azione i Knights Ferry.

  • # 23
    shodan
     scrive: 

    @ Pleg
    Si, condivido in pieno la tua visione.

    Il punto è che non mi stupirei, né da parte Intel né da parte AMD, chip in stile Larrabee anche per il mercato consumer di fascia medio-bassa, ovviamente più in la con il tempo. E magari con dei CPU Core più performanti rispetto ad Atom (la base da cui parte Bobcat non mi pare niente male).

    In questo caso non sarebbe così utopistico veder girare un intero S.O. su questo chip ibrido, con accesso alle capacità GPGPU tramite istruzioni vettoriali.

    Ovviamente poi per avere una GPU valida devi avere hardware dedicato, ed è proprio qui che Larrabee ha mostrato tutti i suoi limiti.

    Ciao.

  • # 24
    Nessuno
     scrive: 

    @Pleg
    hai ragione in parte.
    Perchè alla pipeline non attaccheresti solo il gruppo di shaders ma tutto un SM con tutto quello che c’è dentro (shaders, TMU, polymorph engine) e manterresti parte dello scheduler interno allo stesso.
    La complessità di decodifica delle istruzioni non cambia rispetto a come è fatto ora. Devi sempre avere un qualcosa che prenda la lista delle istruzioni della GPU e inviarle agli shader bilanciando il carico tra di essi. Questa parte è oggi fatta da una logica nella GPU che è abbastanza complessa. Domani la lista delle istruzioni potrebbe benissimo essere gestita dalla CPU stessa che non richiede di preparare buffer da inviare ad un dispositivo esterno ed aspettare la risposta con la replica dei dati tra la memoria CPU e quella GPU.

    Puoi vedere la cosa nel senso inverso se vuoi. Una logica della GPU che prevede, oltre allo smistamento delle istruzioni tra gli SM come fa adesso anche quelle verso una (o più) unità di calcolo seriali (i core della CPU) condividendo con questi memoria, thread, buffers e una più facile sincronizzazione.

    La cosa più semplice che mi viene in mente è quella di affidare a questo ibrido tutta la gestione della scena, geometria (oggi a carico della CPU esterna) inclusa. La CPU esterna deve solo comunicare le modifiche del punto di vista e tutta la scena viene ricalcolata sulla GPU senza che la CPU debba fare altro come passare quintali di informazioni alla GPU.

    Vedremo comunque presto cosa comporterà la possibilità di avere un CPU che lavora a stretto contatto con una GPU.

    Larrabee non è che fosse questa rivoluzione. E’ un chip con grandi unità di calcolo vettoriale ma senza tutte quelle funzionalità fixed function che comunque, come hai detto tu, sono necessarie per il calcolo grafico. Un Cell, per esempio, è già qualcosa di più avanti in questo senso. Pensa ad un Cell multicore core con 64 SPE (magari divisi in gruppi). Non sarebbe certo meno della soluzione ManyCore d Intel.
    Magari IBM ci sta pensando nel caso un domani si arriverà ad poter fare raytracing in tempo reale invece che usare complessi metodi di rasterizzazione.

    Chi vivrà vedrà :)

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.