Alessandro Del Rosso

Intel: Larrabee non è pronto

Il chipmaker di Santa Clara ammette che la prima GPU basata su core x86 non è ancora pronta per il mercato. Resterà un progetto sperimentale. Ma c'è chi sospetta che sia stato cancellato o fortemente ridimensionato

Roma - Sembra proprio che il mercato delle GPU di tipo discreto, ossia quelle utilizzate sulle schede video PCI Express, resterà ancora per un po' nelle sole mani di AMD e Nvidia. Con un clamoroso dietro-front, Intel ha infatti ammesso che il suo tanto chiacchierato processore grafico x86, Larrabee, è in forte ritardo, e almeno inizialmente verrà rilasciato solo come software development kit per sviluppatori e studenti universitari.

"Il design hardware di Larrabee e il relativo software sono indietro rispetto a dove ci auguravamo fossero a questo punto del progetto" ha spiegato Nick Knupffer, portavoce Intel. "Di conseguenza, la nostra prima soluzione Larrabee non verrà lanciata come un prodotto stand alone".

Per il momento, dunque, i piani di lancio relativi ad una versione consumer di Larrabee sono in sospeso. Intel non ha specificato se si tratti di una cancellazione definitiva o di un semplice ritardo: Knupffer si è limitato a dire che la sua azienda non ha affatto abbandonato l'obiettivo di introdurre sul mercato soluzioni grafiche many-core. Ma come suggerisce Ars Technica, le future GPU discrete di Intel potrebbero essere qualcosa di diverso da Larrabee.
Restando nel campo delle ipotesi, il design ibrido di Larrabee, che combina in modo molto stretto hardware e software, potrebbe debuttare esclusivamente nel segmento dei server e dell'high performance computing (HPC). In ambito consumer, invece, Larrabee potrebbe non vedere mai la luce, o vederla solo tra molti anni, quando la sua architettura hardware e il relativo software avranno raggiunto un sufficiente grado di maturità.

Come probabilmente si è resa conto anche Intel, progettare una GPU non è affatto semplice, soprattutto perché in questo tipo di componente lo sviluppo e il collaudo dei driver è altrettanto importante della progettazione dell'hardware: un driver grafico, infatti, non solo dev'essere ottimizzato sotto ogni aspetto, ma va anche testato praticamente con tutti i videogiochi in commercio (tanto per fare un esempio).

Ma se i driver sono già una componente importantissima nelle tradizionali GPU, in Larrabee rivestono un ruolo ancor più cruciale: a differenza delle tradizionali architetture video, in Larrabee le funzionalità richieste dalle API DirectX sono implementate esclusivamente a livello di software. Tempo fa Intel ha citato come esempio la specifica Piexel Shader 5.0, che in Larrabee potrà essere supportata attraverso un semplice aggiornamento software (mentre le GPU tradizionali andranno riprogettate a livello hardware).

Questo approccio ha indubbiamente enormi potenzialità dal punto di vista dello sviluppo del software, tantopiù che Larrabee potrà essere programmato in modo molto simile ad una tipica CPU x86 multicore. È altrettanto indubbio, però, che si tratta di un approccio del tutto inedito in questo ambito del computing, e come tale non solo esige una quantità molto elevata di investimenti e di risorse per la ricerca e lo sviluppo, ma porta anche con sé problematiche mai affrontate prima.

Lo scorso settembre, in occasione dell'Intel Developer Forum di San Francisco, il chipmaker di Santa Clarà mostrò un prototipo di Larrabee che, stando agli ingegneri dell'azienda, forniva una potenza di circa 1 TFLOPS, all'incirca quanto una tipica GPU di fascia media. Il problema è che l'architettura di Larrabee, per sua stessa natura, è assai meno specializzata di quella dei processori grafici tradizionali: nel chip di Intel gli elementi in grafica raster devono essere convertiti in istruzioni vettoriali prima di essere elaborati, e questo perché Larrabee, a differenza delle GPU di NVidia e ATI, non include alcuna circuiteria specifica per la rasterizzazione. Resta pertanto da capire quanto della potenza dichiarata da Intel per il suo prototipo di Larrabee si traduca effettivamente in frame per secondo, che è poi ciò che interessa ai videogamer.

Larrabee potrebbe fornire dei vantaggi, nei confronti delle GPU tradizionali, nell'elaborazione grafica di tipo ray tracing, ma questa tecnica non viene utilizzata nel mondo dei videogame, e un'eventuale migrazione al ray tracing richiederebbe agli sviluppatori di giochi tempo e investimenti che difficilmente sarebbero disposti a sobbarcarsi.

Sul destino del progetto Larrabee si saprà sicuramente di più il prossimo anno, quando Intel rilascerà il promesso SDK.

Alessandro Del Rosso
Notizie collegate
  • TecnologiaSpeciale IDF/ Il futuro prossimo dei chip IntelAll'Intel Developer Forum Fall 2009 il chipmaker californiano si è mostrato a tutto tondo. Nuove informazioni sui futuri processori, sulle tecnologie a 32 e 22 nm, sulla GPU Larrabee e sulle prossime piattaforme Atom-based
  • TecnologiaUSB 3.0 sale sui primi HDD esterniFreecom e Buffalo hanno presentato i primi due hard disk esterni da 3,5 pollici ad utilizzare la neonata interfaccia USB 3.0. Promesse velocità di trasferimento superiori ai 120 MB/s
  • TecnologiaLinux fa amicizia con USB 3.0È il primo sistema operativo ad ottenere un driver per la giovane interfaccia, diventando così una piattaforma di test ideale per i dispositivi basati sulla nuova specifica
22 Commenti alla Notizia Intel: Larrabee non è pronto
Ordina
  • a conferma dei dubbi sollevati alla presentazione del progetto.
    Implementare via software (tra l'altro in un'architettura non specializzata come x86) porta maggiore flessibilita', ma anche prestazioni piu' scadenti, e nell'ambito delle schede video, dove le prestazioni sono tutto, la storia era gia' scritta...
    non+autenticato
  • la questione però è più complessa

    oggi i motori grafici usano directx o opengl per le loro necessità e quindi sono costretti ad operare entro un determinato recinto sia come funzionalità supportate che come implementazione

    ovviamente potendo creare un motore grafico software vuol dire che puoi usare delle scorciatoie, compattare il codice, renderlo più veloce in termini di numero di operazioni rispetto alla controparte hardware e ottenere così risultati migliori dell'hardware

    questo però sempre che sotto ci sia un hardware adeguato e realisticamente gli x86 non sono quella che si può definire un'architettura flessibile, moderna e leggera

    gli arm lo dimostrano riuscendo ad erogare le stesse performance ad una frazione del costo in termini di silicio e di corrente consumata

    secondo me intel se proprio vuole provarci deve usare un'architettura nuova oppure giocare la carta degli fpga, cosa che per loro non dovrebbe essere troppo difficile, anche se attualmente ati e nvidia ci arriverebbero molto prima
  • > oggi i motori grafici usano directx o opengl per
    > le loro necessità e quindi sono costretti ad
    > operare entro un determinato recinto sia come
    > funzionalità supportate che come
    > implementazione

    I motori grafici si appoggiano a directx o a opengl per una infinita' di motivi, primo fra tutti la compatibilita'. Non vedo inoltre come tali librerie possano essere viste come un "recinto", dato che supportano tutte le chiamate grafiche necessarie, e te lo garantisce uno che ha programmato in opengl 17 anni fa ...

    Se proprio vuoi uscire dal recinto, esiste CUDA. L'architettura x86 e' obsoleta da almeno un decennio, ma siamo costretti a contiunare ad usarla (principalmente per colpa di M$).
    non+autenticato
  • se hai usato cuda, avrai notato però che mancano molte cose....la flessibilità del modello a kernel non è lontanamente paragonabile a quella del modello di programmazione delle cpu

    altro problema è la possibilità di avere un modello di memoria coerente, non essere sbatacchiato tra ram video e ram di sistema continuamente

    altro problema è la possibilità di avere un supporto al c++ e agli oggetti....cuda usa il c fondamentalmente

    cuda usa la gpu e gli stream processor e quindi è limitato ad operare su matrici, vettori, a far conti in sostanza...manca la flessibilità necessaria per manipolare efficacemente stringhe, supportare il branching

    e poi perchè no, bisogna ragionare in parallelo con le gpu e tenendo conto che i programmatori odiano ragionare in termini di multithread, multiprocessi, ecc... non è uno svantaggio da poco

    del resto se le gpu fossero general purpose verrebbero usate al posto delle cpu
  • - Scritto da: pabloski
    > se hai usato cuda, avrai notato però che mancano
    > molte cose....la flessibilità del modello a
    > kernel non è lontanamente paragonabile a quella
    > del modello di programmazione delle
    > cpu

    ?!?!?!?!?!?

    > altro problema è la possibilità di avere un
    > modello di memoria coerente, non essere
    > sbatacchiato tra ram video e ram di sistema
    > continuamente

    Attualmente in fase di programmazione tu te ne sbatti della memoria video e della memoria di sistema, in quanto sono i driver a gestire la memoria in base alle chiamate alle varie api.
    Operando direttamente sull'hw è diverso; CUDA e Stream ti permettono di programmare direttamente sulla GPU e di conseguenza vedi unicamente le risorse GPU.

    > altro problema è la possibilità di avere un
    > supporto al c++ e agli oggetti....cuda usa il c
    > fondamentalmente

    Non ti sta bene che CUDA sia modellato sul C? diventa presidente di Nvidia e cambia le cose; comunque vi sono binding per un fot*io di linguaggi.

    > cuda usa la gpu e gli stream processor e quindi è
    > limitato ad operare su matrici, vettori, a far
    > conti in sostanza...manca la flessibilità
    > necessaria per manipolare efficacemente stringhe,
    > supportare il
    > branching

    So it shall be written so it shall be done

    Tradotto se un auto viene progettata per essere un mezzo di trasporto terrestre è assurdo volerla usare come supposta.

    > e poi perchè no, bisogna ragionare in parallelo
    > con le gpu e tenendo conto che i programmatori
    > odiano ragionare in termini di multithread,
    > multiprocessi, ecc... non è uno svantaggio da
    > poco

    ed è per questo che cuda o chi per esso ha delle funzioni per gestire agilmente i thread senza andare con fork(); if (pid==0){..}else{..} ...

    > del resto se le gpu fossero general purpose
    > verrebbero usate al posto delle
    > cpu

    Fermo ... inverti .. Bravo, ora sai cosa vuole fare intel, più o meno il contrario di quello che eri convinto.
    non+autenticato
  • - Scritto da: Vault Dweller
    > - Scritto da: pabloski
    > > se hai usato cuda, avrai notato però che mancano
    > > molte cose....la flessibilità del modello a
    > > kernel non è lontanamente paragonabile a quella
    > > del modello di programmazione delle
    > > cpu
    >
    > ?!?!?!?!?!?
    >

    è lunga da spiegare, leggiti la documentazione di cuda

    > Attualmente in fase di programmazione tu te ne
    > sbatti della memoria video e della memoria di
    > sistema, in quanto sono i driver a gestire la
    > memoria in base alle chiamate alle varie
    > api.

    ah si? e la necessità di copiare da e verso la memoria video tutti i dati da elaborare? a volte si parla di matrici di enormi dimensioni

    > Operando direttamente sull'hw è diverso; CUDA e
    > Stream ti permettono di programmare direttamente
    > sulla GPU e di conseguenza vedi unicamente le
    > risorse
    > GPU.
    >

    no il software gira sulla cpu e invia kernels e dati alla gpu

    puoi allocare degli oggetti dati in memoria video e usare i kernel per manipolarli

    > Non ti sta bene che CUDA sia modellato sul C?
    > diventa presidente di Nvidia e cambia le cose;
    > comunque vi sono binding per un fot*io di
    > linguaggi.
    >

    che risposta è inutile....i binding servono per interfacciarsi a cuda non per scrivere i kernel da eseguire sulla gpu

    > So it shall be written so it shall be done
    >
    > Tradotto se un auto viene progettata per essere
    > un mezzo di trasporto terrestre è assurdo volerla
    > usare come
    > supposta.
    >

    appunto, quindi larrabee un senso ce l'ha

    > ed è per questo che cuda o chi per esso ha delle
    > funzioni per gestire agilmente i thread senza
    > andare con fork(); if (pid==0){..}else{..}
    > ...
    >

    ci sono pure sistemi operativi che gestiscono i thread, il fork riguardo il multiprocessing non il multithreading, sono due cose completamente differenti

    > Fermo ... inverti .. Bravo, ora sai cosa vuole
    > fare intel, più o meno il contrario di quello che
    > eri
    > convinto.

    ecco, finiscila di dire cazzate
  • - Scritto da: pabloski
    > - Scritto da: Vault Dweller
    > > - Scritto da: pabloski
    > > > se hai usato cuda, avrai notato però che
    > mancano
    > > > molte cose....la flessibilità del modello a
    > > > kernel non è lontanamente paragonabile a
    > quella
    > > > del modello di programmazione delle
    > > > cpu
    > >
    > > ?!?!?!?!?!?
    > >
    >
    > è lunga da spiegare, leggiti la documentazione di
    > cuda
    >
    > > Attualmente in fase di programmazione tu te ne
    > > sbatti della memoria video e della memoria di
    > > sistema, in quanto sono i driver a gestire la
    > > memoria in base alle chiamate alle varie
    > > api.
    >
    > ah si? e la necessità di copiare da e verso la
    > memoria video tutti i dati da elaborare? a volte
    > si parla di matrici di enormi
    > dimensioni

    Scusa l'incomprensione ma visto che avevi risposto ad un commento che parlava di opengl &co ho creduto che ti colleggassi ad esso. Comunque è assolutamente logico, in quanto per varie questioni, tra cui la sicurezza e l'integrità dei dati le GPU non possono accedere autonomamente ai dati nella memoria di sistema; le GPU sono come ogni altro componente asservite alla CPU, non a caso essa si chaima così anziche Superflous Processing Unit.

    > > Operando direttamente sull'hw è diverso; CUDA e
    > > Stream ti permettono di programmare direttamente
    > > sulla GPU e di conseguenza vedi unicamente le
    > > risorse
    > > GPU.
    > >
    >
    > no il software gira sulla cpu e invia kernels e
    > dati alla
    > gpu
    >
    > puoi allocare degli oggetti dati in memoria video
    > e usare i kernel per
    > manipolarli

    Kernel = modulo CUDA
    Software : vede interfaccia CUDA

    Ciò implica che se tu scrivi in CUDA scrivi codice per la GPU, che richiami in software ttramite l'interfaccia driver di cuda.

    > > So it shall be written so it shall be done
    > >
    > > Tradotto se un auto viene progettata per essere
    > > un mezzo di trasporto terrestre è assurdo
    > volerla
    > > usare come
    > > supposta.
    > >
    >
    > appunto, quindi larrabee un senso ce l'ha

    No perché se è solo la divisone della memoria che tu lamenti essa esisterebbe anche con larrabee, in quanto essa non sostituirebbe la cpu nel suo ruolo di controlore e arbitro del sistema.

    > > ed è per questo che cuda o chi per esso ha delle
    > > funzioni per gestire agilmente i thread senza
    > > andare con fork(); if (pid==0){..}else{..}
    > > ...
    > >
    >
    > ci sono pure sistemi operativi che gestiscono i
    > thread, il fork riguardo il multiprocessing non
    > il multithreading, sono due cose completamente
    > differenti

    Ehm ... NO! il multiprocessing è l'abilità di utilizzare più unità elaborative su una stessa macchina, il multi threading implica l'utilizzo di più thread nello scope di esecuzione di un programma; a a meno che scrivendo in C l'istruzione fork ti cresca una cpu in più sulla motherboard, esso è multithreading e non multiprocessing.

    > > Fermo ... inverti .. Bravo, ora sai cosa vuole
    > > fare intel, più o meno il contrario di quello
    > che
    > > eri
    > > convinto.
    >
    > ecco, finiscila di dire cazzate

    Ah, mi sembra quasi che dovella mi abbia accusato di essere un M4 fanboy...
    non+autenticato
  • > a differenza delle tradizionali architetture video, in Larrabee le funzionalità richieste dalle API DirectX sono implementate esclusivamente a livello di software. Tempo fa Intel ha citato come esempio la specifica Pixel Shader 5.0, che in Larrabee potrà essere supportata attraverso un semplice aggiornamento software (mentre le GPU tradizionali andranno riprogettate a livello hardware).

    Non avevo capito questa cosa, il fallimento di Larrabee è scontato.

    Le GPU andranno riprogettate a livello hardware?
    Puo' darsi, ma poi andranno n volte piu' veloci di Larrabee.

    MAH
    non+autenticato
  • e che c'entra la frase "il dominio delle directx"? mi pare che le gpu moderne supportino pure opengl
    non+autenticato
  • - Scritto da: iosonodio
    > e che c'entra la frase "il dominio delle
    > directx"? mi pare che le gpu moderne supportino
    > pure
    > opengl

    In realtà anche quelle non troppo "moderne". Il supporto opengl è già presente da anni su molte schede.
    Poi tutto dipende dagli utilizzi. Se rimaniamo nel campo gaming allora directx fa il 99%. In altri campi il discorso cambia.
    Comunque come già le schede attuali dimostrano, la vera chiave di successo non è solo la GPU fine a se stessa, ma l'architettura complessiva della scheda, unita soprattutto alla bontà del driver abbinato.
    non+autenticato
  • nemmeno nel gaming, le directx hanno questo dominio

    pensa a playstation e wii tanto per citarne due....parliamo di miliardi di consolle che usano opengl

    è che molti sono abituati a pensare informatica=pc=windows=ie=directx=....
  • - Scritto da: pabloski
    > nemmeno nel gaming, le directx hanno questo
    > dominio
    >
    > pensa a playstation e wii tanto per citarne
    > due....parliamo di miliardi di consolle che usano
    > opengl

    Ah, non sapevo.

    Ma allora altro che 99%... se aggiungiamo i giochi per iPhone, direi che possiamo parlare di 0,99%, più che 99%...
    ruppolo
    33147
  • - Scritto da: Ste
    > Poi tutto dipende dagli utilizzi. Se rimaniamo
    > nel campo gaming allora directx fa il 99%. In
    > altri campi il discorso
    > cambia.

    Io direi che questo 99% sta scendendo a vista d'occhio...
    ruppolo
    33147
  • Spero che AMD rilasci al più presto la sua CPU/GPU multicore, potrebbe specie nei sistemi economici spazzare via la concorrenza di Intel e di nVidia e anche nei sistemi di fascia medio/alta impiegando la GPU interna in associazione con una scheda grafica discreta potrebbe coniugare performance con il risparmio energetico... speriamo che AMD che certo una GPU convenzionale ma ben performante la sa disegnare senza problemi si dia una mossa!
  • La roadmap per fusion è già stata stillata, e accelerare i tempi sarebbe controproducente in quanto si andrebbe a tagliare sul testing; e nulla nuoce di più alle vendite di un errore in progettazione.

    Sinceramente spero che il progetto vada in porto, secondo i tempi stabiliti, in modo da fornire una migliore soluzione per i pc di fascia media.
    non+autenticato
  • col fallimento di larrabee, amd avrà vita facile

    allo stato attuale nvidia è troppo impegnata a cazzeggiare con i supercomputer per accorgersi che la fascia media se la sta mangiando tutta amd e intel l'ha fatta fuori dal vaso pensando di usare l'architettura fatiscente x86 per fare calcoli matriciali
    non+autenticato
  • E tu pensi che sia finita qui ?
    Molti già da tempo ritenevano che Larrabee non potesse avvicinarsi alle prestazioni di ATI/Nvidia e l'uscita del chip è stata ritardata, ma non cancellata.
    Intel ha risorse per sviluppare un proprio chip ma è chiaro il ritardo da ATI/Nvidia è duro da colmenre e non tanto a livello hardware, quanto software. Magari ci metterà ancora un paio di anno ma vedrei che arriva.

    .... e se si comprasse Nvidia?
    non+autenticato
  • - Scritto da: James Kirk
    > E tu pensi che sia finita qui ?

    Sinceramente lo spero per loro.

    > Molti già da tempo ritenevano che Larrabee non
    > potesse avvicinarsi alle prestazioni di
    > ATI/Nvidia e l'uscita del chip è stata ritardata,
    > ma non
    > cancellata.

    Il passo è breve ed è auspicabile.

    > Intel ha risorse per sviluppare un proprio chip
    > ma è chiaro il ritardo da ATI/Nvidia è duro da
    > colmenre e non tanto a livello hardware, quanto
    > software. Magari ci metterà ancora un paio di
    > anno ma vedrei che
    > arriva.

    Se fosse così tecnicamente avanzato mi spieghi perché i due competitor principali nell'ambito grafico si orientano verso stream processor RISC superscalabili invece che verso x86; e ti ricordo che AMD produce e ha licenza di produrre hardware con arch x86.

    > .... e se si comprasse Nvidia?

    AMD otterrebbe il monopolio, sempre se non abbandonano quest'assurda idea.

    P.S. William Shatner si sta rivoltando nella tomba, scavata per l'occasione.
    non+autenticato
  • Sinceramente non ho capito le tue obiezioni (forse un po' affrettate), comunque se vuoi approfondire eccoti questi links:

    http://www.appuntidigitali.it/5374/gpu-arriva-larr.../

    http://www.semiaccurate.com/2009/12/04/intel-kills.../
    non+autenticato
  • - Scritto da: James Kirk
    > Sinceramente non ho capito le tue obiezioni
    > (forse un po' affrettate), comunque se vuoi
    > approfondire eccoti questi
    > links:
    >
    > http://www.appuntidigitali.it/5374/gpu-arriva-larr
    >
    > http://www.semiaccurate.com/2009/12/04/intel-kills

    Le mie obbiezioni sono semplici in realtà: dubito fortemente che terminato uno studio di fattibilità, valutante le possibili prestazioni di Larrabee, intel decida di continuare il progetto; in quanto pur conoscendo bene l'arch x86 essa non è adatta allo sviluppo di GPU (neanche di CPU, in quanto per migliorare le performance le istruzioni x86 dal pentium pro ad oggi vengono traslate da un chip posto sullla cpu in istruzioni RISC eseguite dal vero processore, e questo comunque genera un overhead tale da ridurre di un terzo le performance possibili dalle cpu odierne), inoltre il concetto di programmabilità si scontra anch'esso con le performance della scheda, in quanto si passerebbe effettivamente ad un rendering software.
    non+autenticato
  • Infatti il progetto verrà probabilmente deviato per un utilizzo GPGPU, in cui un sistema x86 fortemente ottimizzatoi per operazioni FB vettoriali potrebbe avere vantaggi su una architettura Tesla che deriva da GPU ed ha i suoi limiti ... ma tutto è da vedere, in particilare alla luce di 'Fermi'.

    Ciò non toglie che Intel si debba prima o poi dotare du una GPU decente, sia per migliorare quei chipset da battaglia che produce, sia per contrastare AMD che è in grado di offire tutto il pacchetto completo CPU+Chipset (e che chipset!) + GPU , per non parlare di quando riuscitanno a mettere tutto in us solo Chip (grossomodo tra un anno abbondante).

    Per cui il progetto Larrabee continua, ma probabilmente (IMHO) con una approccio più tradizionale ... altrimenti, ripeto, si compra Nvidia (che al momento non sta benissimo).
    non+autenticato
  • - Scritto da: Vault Dweller
    > (neanche di CPU, in quanto per migliorare le
    > performance le istruzioni x86 dal pentium pro ad
    > oggi vengono traslate da un chip posto sullla cpu
    > in istruzioni RISC eseguite dal vero processore,
    > e questo comunque genera un overhead tale da
    > ridurre di un terzo le performance possibili
    > dalle cpu odierne),

    Oltre che un numero maggiore di componenti, quindi di costo e di consumo energetico.

    Ma di tutto questo dobbiamo ringraziare Microsoft, è questa putrida azienda che non vuole schiodarsi da x86.
    ruppolo
    33147