Link alla notizia: http://www.hwupgrade.it/news/skvideo/prime-prove-dell-esistenza-di-intel-larrabee_29666.html

Intel, nel corso del prossimo Siggraph, incontrerà gli sviluppatori in ambito grafico per metterli al corrente, in maniera approfondita, sulla modalità di programmazione di Larrabee, il chip grafico di casa Intel

Click sul link per visualizzare la notizia.

Sarà anche scarso attualmente ma se puntano a supportare anche le istruzioni x86 si apriranno degli scenari molto entusiasmanti, magari affiancandola ad una scheda video "tradizionale" può diventare molto valido

si ma tra gpu che vuole fare la cpu, la cpu con 4 core e la gpgpu voglio vedere chi fa cosa :D

si ma tra gpu che vuole fare la cpu, la cpu con 4 core e la gpgpu voglio vedere chi fa cosa :D

hardware con crisi d'identità...:asd:

forza valentino c'è un altro gran premio il GPgpu.... :D scherzi a parte vedremo solo a conti fatti cosa sarà in grado di fare e non fare....

Larrabee adesso varrà anche poco, ma sulla carta ha possibilità di crescita maggiori e in minor tempo rispetto a Amd/Nvidia.
Intel ha i soldi per lavorare in perdita per un pò, quindi sarà interessante vedere la Larrabee che uscirà magari tra un anno o due, che avrà più chip, più veloci e più piccoli.
A quel punto si potranno tirare le somme, adesso ogni valutazione lascia il tempo che trova.

Un pò di pepe nel settore, mia piace :D

Sarà anche scarso attualmente ma se puntano a supportare anche le istruzioni x86 si apriranno degli scenari molto entusiasmanti, magari affiancandola ad una scheda video "tradizionale" può diventare molto valido

Cioè lo releghi a fare la cpu x86. Bhè è un mercato talmente nuovo che di sicuro lì farà strada. Senza tra l'altro fare concorrenza ad Intel stessa. Poi ci affianchi una scheda video tradizionale ed ottieni... ecco esattamente cosa ottieni di diverso da adesso?
E' un chip grafico. Punto. Particolare ma grafico.

codice x86 per la grafica????????????
si parla di isa vecchie come il cucco e ripropongono x86 per la grafica..........
intel senza x86 è morta,sarebbe come il famoso gigante dai piedi di argilla.
Staremo a vedere,intanto amd va avanti con il fusion e sta sempre più in rapporti stretti con ibm,che un giorno ci sia un ritorno della tecnologia power by amd/ibm?

Cioè lo releghi a fare la cpu x86. Bhè è un mercato talmente nuovo che di sicuro lì farà strada. Senza tra l'altro fare concorrenza ad Intel stessa. Poi ci affianchi una scheda video tradizionale ed ottieni... ecco esattamente cosa ottieni di diverso da adesso?
E' un chip grafico. Punto. Particolare ma grafico.

Non so quanti anni hai, ma tieni presente che tanti anni fa esistevano i famosi coprocessori, venivano affiancati alla cpu per agevolare alcune delle sue operazioni (non erano cpu ed il loro intento non era quello di sostituire la cpu). E' presto per parlare ma potrebbe essere una componente in più in grado di eseguire istruzioni x86, potresti usarlo su soluzioni dove le "capacità grafiche" non devono essere elevate e dare un contributo alla cpu quando occorre, da assegnarli un thread di un'applicazione fino ad eseguire un'intera macchina virtuale sulla "scheda video", cosa che non fanno le schede video attuali (o almeno me lo auguro).

Se intendiamo questo come "chip grafico particolare" allora siamo d'accordo. :)

Se andiamo avanti con 'sto ISA x86 allora HAL 9000 lo vedremmo nel 3001!

Non so quanti anni hai, ma tieni presente che tanti anni fa esistevano i famosi coprocessori, venivano affiancati alla cpu per agevolare alcune delle sue operazioni (non erano cpu ed il loro intento non era quello di sostituire la cpu). E' presto per parlare ma potrebbe essere una componente in più in grado di eseguire istruzioni x86, potresti usarlo su soluzioni dove le "capacità grafiche" non devono essere elevate e dare un contributo alla cpu quando occorre, da assegnarli un thread di un'applicazione fino ad eseguire un'intera macchina virtuale sulla "scheda video", cosa che non fanno le schede video attuali (o almeno me lo auguro).

Se intendiamo questo come "chip grafico particolare" allora siamo d'accordo. :)

E quel'è il motivo per cui i coprocessori sono scomparsi? Semplice, ora possiamo miniaturizzare tutto e quindi un chip separato per fare le cose che la CPU non è in grado, non serve più. I coprocessori non erano processori "aggiuntivi" come un dual core, erano chip specializzati in funzioni che non era possibile includere nella CPU.
Ora questo non è più necessario, anzi, stiamo facendo la corsa a mettere più cose possibile dentro la CPU perchè c'è spazio.

Se metti Larrabee a fare da CPU aggiuntiva, hai ottenuto solo un modo piuttosto bislacco di aggiornare il PC, esistono metodi per aumentare la potenza di calcolo che esulano dal montarlo su una scheda PCI-E.

Il vantaggio di Larrabee è di essere una GPU completamente "software", e questo significa che può adattarsi a fare qualunque cosa, vero, ma è comunque una architettura estremamente parallela, quindi sarà funzionale solo con le elaborazioni che possono essere parallelizzate. Oggettivamente non so quanto potrà essere buona nel gaming (che sbaglio o era il suo obbiettivo principale?) visto che le schede grafiche cambiano specifiche lentamente, quindi il vantaggio dell'adattabilità di Larrabee sarebbe perso.

Per me ha senso soprattutto per utilizzare software x86 (che è molto più facile dei vari linguaggi GPU) parallelizzabile. Infatti esistono in commercio programmi che possono essere eseguiti su più CPU, e quindi potrebbero essere "forzati" a vedere Larrabee come un cluster di CPU, ottenendo quindi una potenza di calcolo elevata senza spendere un botto in processori o in una riscrittura del codice.

Ovviamente IMHO

Se metti Larrabee a fare da CPU aggiuntiva, hai ottenuto solo un modo piuttosto bislacco di aggiornare il PC, esistono metodi per aumentare la potenza di calcolo che esulano dal montarlo su una scheda PCI-E.

Il vantaggio di Larrabee è di essere una GPU completamente "software", e questo significa che può adattarsi a fare qualunque cosa, vero, ma è comunque una architettura estremamente parallela, quindi sarà funzionale solo con le elaborazioni che possono essere parallelizzate. Oggettivamente non so quanto potrà essere buona nel gaming (che sbaglio o era il suo obbiettivo principale?) visto che le schede grafiche cambiano specifiche lentamente, quindi il vantaggio dell'adattabilità di Larrabee sarebbe perso.

Non credo sia nato per il gaming, pensare che verrà usata per il giochi è assurdo, non è questa la sua natura, quindi qui non c'è niente da dire.

Se metti Larrabee a fare da CPU aggiuntiva, hai ottenuto solo un modo piuttosto bislacco di aggiornare il PC, esistono metodi per aumentare la potenza di calcolo che esulano dal montarlo su una scheda PCI-E.

Mah, la tua frase è al quanto discutibile, queste soluzioni raggiungono la sua massima utilità con il calcolo parallelo lo sappiamo tutti, quindi non è e non sarà mai una cpu aggiuntiva, non credo verrà acquistato per aggiornare i pc (lol), poi mi spieghi quali sono i "metodi per aumentare la potenza di calcolo che esulano dal montarlo su una scheda PCI-E" raggiungendo una potenza di calcolo pari alle attuali soluzioni Tesla e Firestream ed i suoi vantaggi rispetto a queste? (tenendo conto che Larrabee sarà in grado di eseguire codice x86), ciao.

Io dubito seriamente la possibilità di poter aggiungere i core presenti sulla scheda video come cpu per eseguire codice "x86 normale". dubito che sia una cosa possibile.

E per realizzare apposta programmi accelerati con la GPU non vedo come le istruzioni x86 possano aiutare. La tendenza e usare linguaggi di alto livello ormai.

Io dubito seriamente la possibilità di poter aggiungere i core presenti sulla scheda video come cpu per eseguire codice "x86 normale". dubito che sia una cosa possibile.

E per realizzare apposta programmi accelerati con la GPU non vedo come le istruzioni x86 possano aiutare. La tendenza e usare linguaggi di alto livello ormai.

Guarda che non è tanto impossibile, così come si può fare in modo che una scheda video esegua del codice che non serva per mandare a video qualcosa, così lo si potrà fare con Larrabee.

Semplicemente perché un programma già scritto per la parallelizzazione su CPU sfrutta le istruzioni x86 in maniera del tutto trasparente (ci pensa il compilatore a tradurre). Un programma scritto in C (ad esempio) per funzionare su cluster di 100 CPU, per funzionare su un cluster di schede video necessita di una riscrittura completa, mentre per funzionare su Larrabee necessiterebbe solo di un'interfaccia adeguata con la scheda video.

Beh ma insomma, a cosa dovebbe servire sto Larrabee se non sarà competitivo nei giochi??? A fare CAD?
Anche a me era sembrato che l'intento di Intel fosse quello di entrare nel mercato delle schede video da gaming, ma non mi pare che Larrabee sia il prodotto giusto: le vetuste x86 non sono utili allo scopo, e mi pare che i Quad Core siano già più che sufficienti per tutti i thread che il 90% degli utenti e forse più usano...
Ora, andrà anche di moda il calcolo fatto dalla GPU - come CUDA insegna - ma lì si tratta di prendere un valido prodotto da gaming (le schede nVidia) e fargli fare del lavoro anche quando non si gioca; qui invece mi pare che si voglia far fare del lavoro alla GPU tanto per diletto, e di quando in quando caricare un videogame. Mi spiace ma IMO preferisco di gran lunga la prima soluzione, non vedo xchè dovrei spendere un botto per avere un prodotto mediocre nel campo a cui dovrebbe essere dedicato (e dove la CPU non te lo può sostituire).

Guarda che non è tanto impossibile, così come si può fare in modo che una scheda video esegua del codice che non serva per mandare a video qualcosa, così lo si potrà fare con Larrabee.



No, è proprio architettura dei PC moderni che non questo. La cpu può guidare i core dei vari labaree a fare operazioni varie, ma non eseguire thread dei programmi normali in esecuzione. (sostanzialmente ha le stesse limitazioni delle schede video correnti)



Semplicemente perché un programma già scritto per la parallelizzazione su CPU sfrutta le istruzioni x86 in maniera del tutto trasparente (ci pensa il compilatore a tradurre). Un programma scritto in C (ad esempio) per funzionare su cluster di 100 CPU, per funzionare su un cluster di schede video necessita di una riscrittura completa, mentre per funzionare su Larrabee necessiterebbe solo di un'interfaccia adeguata con la scheda video.

Penso che tu non sappia cosa sono le istruzioni x86. Sono istruzioni macchina di basso livello che dicono sostanzialmente ha una x86 cpu le operazioni da fare (tipo muovi il contenuto di questa registro in questa zona di memoria, somma due registri etc). Nessuno(tranne qualcuno veramente specializzato in una nicchia immagino) attualmente usa queste istruzioni sono automaticamente generati dai vari compilatori(per esempio il C).

...ragazzi,secondo me fino a quando non usciranno fisicamente realizzate le nuove architetture di intel,nvidia e amd siamo sempre nel campo delle ipotesi e della possibilità.Quando saranno sul mercato Larrabee,GT300 e compagnia bella si prenderà un problema di calcolo "parallelizzabile" si programmerà un algoritmo da dare in pasto a ciascuna architettura e si vedrà quanti Tflops saranno in grado di erogare,sopratutto in doppia precisione.Fino a quel momento tutti questi sbandieramenti di prestazioni stellari sono solo chiacchiere...;)

No, è proprio architettura dei PC moderni che non questo. La cpu può guidare i core dei vari labaree a fare operazioni varie, ma non eseguire thread dei programmi normali in esecuzione. (sostanzialmente ha le stesse limitazioni delle schede video correnti)

Qui non capisco proprio cos'hai detto ma di sicuro è sbagliato (lol)

Penso che tu non sappia cosa sono le istruzioni x86. Sono istruzioni macchina di basso livello che dicono sostanzialmente ha una x86 cpu le operazioni da fare (tipo muovi il contenuto di questa registro in questa zona di memoria, somma due registri etc). Nessuno(tranne qualcuno veramente specializzato in una nicchia immagino) attualmente usa queste istruzioni sono automaticamente generati dai vari compilatori(per esempio il C).

L'utente maumau non ha detto niente di sbagliato, primo sono istruzioni x86, le istruzioni x86 di basso livello non so cosa siano, se pensi che per far sfruttare tutti i thread di un processore il codice dev'essere scritto in assembler allora siamo messi male, poi mi spieghi come da codice assembler gestisci una situazione multicore?, questa mi manca, cmq hai un pò di confusione in testa, mi sa che sei tu che ti devi andare a rileggere cosa sono le istruzioni macchina, compilatori e multicore :rolleyes:

Qui non capisco proprio cos'hai detto ma di sicuro è sbagliato (lol)



L'utente maumau non ha detto niente di sbagliato, primo sono istruzioni x86, le istruzioni x86 di basso livello non so cosa siano, se pensi che per far sfruttare tutti i thread di un processore il codice dev'essere scritto in assembler allora siamo messi male, poi mi spieghi come da codice assembler gestisci una situazione multicore?, questa mi manca, cmq hai un pò di confusione in testa, mi sa che sei tu che ti devi andare a rileggere cosa sono le istruzioni macchina, compilatori e multicore :rolleyes:

guarda che sei tu che hai un bel pò di confusione, le istruzioni x86 sono codice assembler

e avere una gpu x86 o una gpu in un'altra architettura ad un programmatore non cambia assolutamente niente visto che comunque non le userà mai nativamente, sarà chi si sviluppa il compilatore a doversele smazzare

a mio avviso l'unico motivo per cui intel ha sviluppato larrabee su x86 è il fatto che così intel non deve pagare costi di licenza

certo che una gpu 32 bit....

Posso dirlo? :D Che grande, immensa puttanata.
Invece che seppellire sto schifo di x86 che ormai è trattato alla stregua di un bytecode interpretato in hardware (faccio i miei complimenti all'idiozia di un simile modo d'operazione!) adesso lo mettiamo anche nelle schede video.

Così per 1/3 di potenza richiederanno il resto della componentistica che sia 10 volte performante quella di ora, e scalderanno molto, molto di più (*)


(*) questa è una mia opinione, dato che i fatti ancora mancano

Posso dirlo? :D Che grande, immensa puttanata.
Invece che seppellire sto schifo di x86 che ormai è trattato alla stregua di un bytecode interpretato in hardware (faccio i miei complimenti all'idiozia di un simile modo d'operazione!) adesso lo mettiamo anche nelle schede video.

Così per 1/3 di potenza richiederanno il resto della componentistica che sia 10 volte performante quella di ora, e scalderanno molto, molto di più (*)


(*) questa è una mia opinione, dato che i fatti ancora mancano

??? intendi il microcodice? ormai è tutto a microcodice :D

Qui non capisco proprio cos'hai detto ma di sicuro è sbagliato (lol)
maumau dice che secondo lui non è impossibile usare i core delle GPU odierne per eseguire codice x86, e lishi l'ha smentito... io son d'accordo con lishi.

Le GPU di oggi son programmabili soltanto per quel che riguarda pixel e vertex shader, e conoscono soltanto texture e vertici. Difatti l'accelerazione video in HW sfrutta questa programmabilità per far effettuare alla GPU parte della decodifica dei video mpeg, h264, etc., rappresentando i dati di ogni fotogramma come delle textures. Ma da qui a dire che eseguano codice x86 ce ne passa eh!
Oh beh, a meno che domani non esca la ATI HD 5000 con un processore x86 nascosto al suo interno e i marketing rep di ATI che urlano "la prima GPU che esegue nativamente codice x86!!" ... grazie ar casso allora

??? intendi il microcodice? ormai è tutto a microcodice :D

Non penso che i processori RISC come l'ARM usino il microcodice, e io sono fortemente pro-ARM. :D
Se poi parliamo di ottimizzatori vari che rimischiano il codice, non so, però sicuramente da soli portano via molti meno transistor di tutti quelli deputati a interpretare, smazzare, stravolgere e rigirare il codice x86 negli attuali processori Intel e AMD.

Non penso che i processori RISC come l'ARM usino il microcodice, e io sono fortemente pro-ARM. :D
Se poi parliamo di ottimizzatori vari che rimischiano il codice, non so, però sicuramente da soli portano via molti meno transistor di tutti quelli deputati a interpretare, smazzare, stravolgere e rigirare il codice x86 negli attuali processori Intel e AMD.

arm non è x86 e non è una cpu comune (soprattutto come prestazioni c'è un abisso sono processori per sistemi embedded con tutte le limitazioni del caso, più simili a microcontrollori che microprocessori)

e comunque quello che dici tu è sbagliato il microcodice permette di diminuire di tanto il numero di transistor, avere circuiteria dedicata per tutte le istruzioni (x86+x64+mmx+sse1....sseN) porterebbe ad una crescita esponenziale di transistor, costi e complessità dell'hw che diventa per di più statico visto che per aggiungere un set di istruzioni bisogna stravolgere completamente l'architettura della cpu e praticamente riprogettarla da zero.

cmq è un discorso ot se vuoi approfondirlo facciamolo via pm

Qui non capisco proprio cos'hai detto ma di sicuro è sbagliato (lol)


L'utente maumau non ha detto niente di sbagliato, primo sono istruzioni x86, le istruzioni x86 di basso livello non so cosa siano, se pensi che per far sfruttare tutti i thread di un processore il codice dev'essere scritto in assembler allora siamo messi male, poi mi spieghi come da codice assembler gestisci una situazione multicore?, questa mi manca, cmq hai un pò di confusione in testa, mi sa che sei tu che ti devi andare a rileggere cosa sono le istruzioni macchina, compilatori e multicore :rolleyes:

Le istruzioni x86 sono un tipo di ISA (http://en.wikipedia.org/wiki/Instruction_set_architecture) che per definizione è il linguaggio di livello più basso disponile.

Qualunque linguaggio di programmazione può teoricamente avere il multithread, perfino assembler
http://win32assembly.online.fr/tut15.html

Come ho detto il fatto che queste gpu supportino x86 non cambia nulla,
-non possono sostituire la CPU centrale per eseguire programmi normali(possono eseguire instruzioni x86,ma non possono accedere alla memoria centrale),
-nessuno attualmente programma usando instruzioni x86 (nemmeno quelli che scrivono in assembly in quanto usano un assembler per tradurre il codice in linguaggio macchina), queste gpu verranno programmate con OpenCL o la versione intel di cuda o stream.
-cambia solo per gli ingegneri intel che dovranno programmare i driver della scheda.

guarda che sei tu che hai un bel pò di confusione, le istruzioni x86 sono codice assembler

e avere una gpu x86 o una gpu in un'altra architettura ad un programmatore non cambia assolutamente niente visto che comunque non le userà mai nativamente, sarà chi si sviluppa il compilatore a doversele smazzare


Fazz era proprio quello che intendevo, magari con un tono ironico, non capisco come hai interpretato il mio post

Ecco forse ho capito, proprio per il fatto che assembler è codice macchina io intendevo codice come "codice sorgente", visto che l'utente precendente aveva detto che solo alcuni programmatori usavano programmare in quella maniera

Fazz era proprio quello che intendevo, magari con un tono ironico, non capisco come hai interpretato il mio post

Ecco forse ho capito, proprio per il fatto che assembler è codice macchina io intendevo codice come "codice sorgente", visto che l'utente precendente aveva detto che solo alcuni programmatori usavano programmare in quella maniera

praticamente solo chi programma i compilatori/ sistemi speciali dove il determinismo e l'ottimizzazione del codice è molto più importante rispetto ai costi di sviluppo, space shuttle avionica in generale, guide missili ecc ecc anche se per questi campi si sta cmq passando ad appositi linguaggi ad alto livello come ad esempio ada

Posso dirlo? :D Che grande, immensa puttanata.
Invece che seppellire sto schifo di x86 che ormai è trattato alla stregua di un bytecode interpretato in hardware (faccio i miei complimenti all'idiozia di un simile modo d'operazione!) adesso lo mettiamo anche nelle schede video.

Così per 1/3 di potenza richiederanno il resto della componentistica che sia 10 volte performante quella di ora, e scalderanno molto, molto di più (*)


(*) questa è una mia opinione, dato che i fatti ancora mancano

Parliamo di calcolo parallelo, quindi di includere all'interno di un componente tanti core, forse 24, è ovvio che si deve usare un'architettura non recentissima, mi sembra di capire che puntino ad un consumo di circa 300 watt ma anche se fossero 500 è sicuramente migliore di sottomettere una applicazione su 10 pc di un laboratorio

maumau dice che secondo lui non è impossibile usare i core delle GPU odierne per eseguire codice x86, e lishi l'ha smentito... io son d'accordo con lishi.



Ho capito, teoricamente se è un calcolatore si possono adattare le istruzioni di un calcolatore su questo, quindi la risposta è si, ovviamente perdi in prestazioni, esistono una miriade d'esempi, vedi per esempio leopard installato su un processore x86 riesce ad eseguire codice per ppc, un qualsiesi emulatore tipo per ps2, psx, nintendo, gba per PC, un emulatore nintendo su un nokia 6680, o uno di gameboy su psx

praticamente solo chi programma i compilatori/ sistemi speciali dove il determinismo e l'ottimizzazione del codice è molto più importante rispetto ai costi di sviluppo, space shuttle avionica in generale, guide missili ecc ecc anche se per questi campi si sta cmq passando ad appositi linguaggi ad alto livello come ad esempio ada

Certo, è come pretendere di fare un nuovo sistema operativo o un bootloader partendo da java, stesso discorso per un programmatore assembler di gestire una applicazione su 50 core

arm non è x86 e non è una cpu comune (soprattutto come prestazioni c'è un abisso sono processori per sistemi embedded con tutte le limitazioni del caso, più simili a microcontrollori che microprocessori)

e comunque quello che dici tu è sbagliato il microcodice permette di diminuire di tanto il numero di transistor, avere circuiteria dedicata per tutte le istruzioni (x86+x64+mmx+sse1....sseN) porterebbe ad una crescita esponenziale di transistor, costi e complessità dell'hw che diventa per di più statico visto che per aggiungere un set di istruzioni bisogna stravolgere completamente l'architettura della cpu e praticamente riprogettarla da zero.

cmq è un discorso ot se vuoi approfondirlo facciamolo via pm
Perchè è offtopic? Si parla sempre di x86, dato che di larrabee c'è poco da dire ancora...

Comunque io stavo criticando l'x86 in generale. Lo so che il microcodice è essenziale per x86 ma è appunto la sua essenzialità e complessità (con tutti i bug e patch che derivano) che non mi piace. L'x86 è trattato come un bytecode dai processori, e secondo me questo è sbagliato e illogico. Il peccato originale è proprio insito nell'x86, non nei processori che lo eseguono o altrove. Perchè aggiungere strati su strati di isa gratuitamente? Nei processori RISC il microcodice, se c'è, non fa da supplente all'isa, ma ci sono isa direttamente fatte meglio o con istruzioni più specializzate dsp-like presenti già di base (es. "somma e moltiplica"). L'isa x86 invece è dell'età della pietra e cresce in complessità ad ogni aggiunta, non riuscendo per motivi "genetici" a limitare i danni derivanti dal progetto iniziale risalente a tempi bui, dove la tendenza era complex e non reduced :D (es. il Moto 680x0, il principale competitor dell'epoca).
Io poi non definirei l'ARM un microcontroller solo perchè è molto semplice, perchè nella stessa classe dell'ARM ci sono il Cell, il Power, i vari MIPS in giro per i router e la PS2, tutti "microcontroller" con funzioni avanzate e tutti che eseguono sistemi operativi. Se avessero buttato nell'ARM la stessa quantità di soldi che hanno buttato nell'x86 non so chi dei due vincerebbe come prestazioni, ma so per certo chi vincerebbe come efficienza, problemi e consumi.

Ovviamente Imho :D

Provo a rispondere anche te:

Le istruzioni x86 sono un tipo di ISA (http://en.wikipedia.org/wiki/Instruction_set_architecture) che per definizione è il linguaggio di livello più basso disponile.


Quoto ciò che hai scritto: "Penso che tu non sappia cosa sono le istruzioni x86. Sono istruzioni macchina di basso livello" senza che mi inizi a postare link di wikipedia, per piacere siamo seri.

Qualunque linguaggio di programmazione può teoricamente avere il multithread, perfino assembler
http://win32assembly.online.fr/tut15.html


un altro link ok, allora possiamo usare assembler (codice sorgente) per gestire il parallel computing, questo intendi?...



-non possono sostituire la CPU centrale per eseguire programmi normali(possono eseguire instruzioni x86,ma non possono accedere alla memoria centrale)



Ma questo cosa c'entra?, se una scheda video ha 768 mb di ram, ti preoccupi della ram del pc?, perchè non può eseguire applicazioni x86?, tra l'altro non è detto che non sia in grado, penso sia ancora presto per dirlo (almeno che tu non sia uno degli sviluppatori), ancora confusione IMHO


-nessuno attualmente programma usando instruzioni x86 (nemmeno quelli che scrivono in assembly in quanto usano un assembler per tradurre il codice in linguaggio macchina), queste gpu verranno programmate con OpenCL o la versione intel di cuda o stream.

Ti impegni ancora con "programmare usando istruzioni x86", mi sembra che non vuoi capire che il compilatore è in grado compilare (scusate il gioco di parole) a seconda della architettura, un codice sorgente può essere compilato per molte architetture grazie a compilatori appositi, x86 che sia

queste gpu verranno programmate con OpenCL o la versione intel di cuda o stream.

Ok a quanto pare hai deciso anche la piattaforma, mi dici allora perchè dovremmo appoggiarci ad openCL quando sotto abbiamo una architettura a core basata su x86?
Sai almeno cos'è OpenCL?

Ti dico con molta serenità d'informarti bene, guarda non lo dico con cattiveria, alla fine nessuno è nato imparato

Ma questo cosa c'entra?, se una scheda video ha 768 mb di ram, ti preoccupi della ram del pc?, perchè non può eseguire applicazioni x86?, tra l'altro non è detto che non sia in grado, penso sia ancora presto per dirlo (almeno che tu non sia uno degli sviluppatori), ancora confusione IMHO

Va bè, se non erro già oggi le schede video accedono alla ram del sistema, mappata per loro in un certo spazio di indirizzi, semplicemente facendo delle richieste sul bus.

"corrigeretemi" se sbaglio :D

Provo a rispondere anche te:



Quoto ciò che hai scritto: "Penso che tu non sappia cosa sono le istruzioni x86. Sono istruzioni macchina di basso livello" senza che mi inizi a postare link di wikipedia, per piacere siamo seri.



scusa se le istruzioni x86 non sono istruzioni macchina cosa sono? il basso livello è inteso come "C++ linguaggio di alto livello", "Assembly linguaggio di basso livello".




un altro link ok, allora possiamo usare assembler per gestire il parallel computing, questo intendi?...



Ti mi hai chiesto se assembly poteva gestire situazioni multithread io ti ho risposto di si. e ti ho linkato una risorsa web dove si spiega come.
Alternativa era dirti si può fare senza portarti nessuna prova oppure scriverti un tutorial.



Ma questo cosa c'entra?, se una scheda video ha 768 mb di ram, ti preoccupi della ram del pc?, perchè non può eseguire applicazioni x86?, tra l'altro non è detto che non sia in grado, penso sia ancora presto per dirlo (almeno che tu non sia uno degli sviluppatori), ancora confusione IMHO



Si ma i programmi che girano sul mio PC in questo momento risiedono sulla memoria centrale, non su quella della scheda video. C'è una separazione concettuale fra memoria centrale e memoria presente nella GPU. Anche se in certi casi questi coincidono.
La gpu non può eseguire firefox o word, la GPU potrà eseguire parti di programmi sviluppati apposta per essere eseguiti sulla GPU.



Ti impegni ancora con "programmare usando istruzioni x86", mi sembra che non vuoi capire che il compilatore è in grado compilare (scusate il gioco di parole) a seconda della architettura, un codice sorgente può essere compilato per molte architetture grazie a compilatori appositi, x86 che sia


queste gpu verranno programmate con OpenCL o la versione intel di cuda o stream.



Era inteso che non cambia assolutamente nulla, in modo diretto, per un eventuale programmatore che la GPU usi x86 o qualcos'altro.
Quando io faccio un programma non programmo in x86, uso C,C++,Java,etc sta al compilatore o all'interprete(se è un linguaggio interpretato) tradurre quello che ho scritto nel ISA specifico.



Ok a quanto pare hai deciso anche la piattaforma, mi dici allora perchè dovremmo appoggiarci ad openCL quando sotto abbiamo una architettura a core basata su x86?
Sai almeno cos'è OpenCL?

Penso che tu continui ha avere confusione su cosa sia ISA x86.



8048074: b8 01 00 00 00 mov eax,0x1
8048079: bb 07 00 00 00 mov ebx,0x7
804807e: cd 80 int 0x80


Ecco il dissaembly di un pezzo di programma.
La riga centra (quel b8 01 00 00 00 ) e codice istruzione x86 che muove nel registor eax il valore 1(b8 vuol dire muovi in ebx 01 00 00 00 è il valore).
Come vedi non è un particolare user frendly, in quanto è stato progettato per essere cpu friendly, per questo si programma in altri linguaggi e si lascia all'interprete/compilatore ingrato compito di fare la traduzione.

Cose OpenCL? è sostanzialmente un linguaggio basato sul C per poter programmare vari sistemi (in particolari GPU).

Ovvero come per programmi "normali" si scrive la cosa in un linguaggio di alto livello (c,c++, etc) per poi lasciare che il compilatore faccia la traduzione nel ISA opportuna (che potrebbe essere benissimo essere x86, opportuna ISA nvidia o ATI)



Ti dico con molta serenità d'informarti bene, guarda non lo dico con cattiveria, alla fine nessuno è nato imparato

Io ho basato quello che ho scritto su esami dati anni fa e qualche veloce ricerca su google., sono abbastanza sicuro di quello che ho scritto. Potrei sbagliarmi certo ma il tuo consiglio può andare in entrambi i sensi.

Caro lishi mi rendo conto che discutendo con te non andiamo da nessuna parte, ti invito a rileggere bene ciò che ho postato, e sopratutto il tuo ultimo intervento, con questo ti saluto e ti auguro una buona giornata.