Intel Xeon Phi ufficialmente al debutto: schede x86 per GPU Computing

quello che chiedi è impossibile da raggiungere, è il software che sfrutta l'hardware non viceversa.

Citavi i software di rendering, quelli sono per natura difficilmente accelerabili da soluzioni GPGPU il codice è troppo complesso per poter "girare" su quel tipo di hardware solo certe modalità sono supportate, gia questa soluzione intel sarebbe piu adatta per come è implementata internamente ma è arrivata appena oggi quindi dobbiamo vedere cosa ci riserva il futuro. Quindi ne i tuoi software di rendering non si sono adattati è perche non potevano farlo non per pigrizia.

ci scrivono loro un driver intendo... ma sul layer dell'os vengono visti come processori aggiuntivi cosa c'e' di cosi' impossibile..?

per farla breve

se è utilizzabile solo riscrivendo codice a se stante ma con pieno supporto delle x86 è una "win" per gli sviluppatori

se è utilizzabile da chiunque come processori extra x86 "quelli nel task manager" (stiamo parlando ovviamente di un potenziale inferiore a quella che potrebbe essere na mobo quad socket con varie cpu multicore seria) sarebbe una "win" per tutti...

---

nel caso a, è solo un altro competitor e devi aspettare che... che so' adobe decida di abilitare il supporto completo in tutta la suite... ma sono tutti rilasci molto lenti

nel caso b invece, da subito qualsiasi software semplicemente scritto per scalare in multithread al numero dei core disponibili vola e ti fa risparmiare un sacco di tempo

neh che sto parlando di chissà quali software eh? cioe' anche il + semplice Adobe Lightroom quando renderizza i raw li esporta sfruttando tutti i core disponibili fallo con 4 o con 8 è una cosa fallo con 64 è un'altra

praticamente qualsiasi software che codifica massicciamente flussi audio/video può essere accelerato da quelle soluzioni... con i flussi hd e 4k ben più che alle porte la potenza di calcolo non basta mai

anche per filtri e tutto il resto

per i giochi 3d hanno fatto framework allucinanti e sono relativamente vicini come tipo di calcolo anche se gli ambiti sono distanti...

sono pigrizia + incertezza se buttarsi a riscrivere una marea di codice per una soluzione che oggi dura 5 minuti e domani non si sa se sarà uno standard e aggiungiamo anche una bella dose di... scrivo il codice nel linguaggio tot affine a certe gpu perchè ho fatto una bella partnership :\ cosa che poi ti obbliga ad acquistare uno specifico brand

difficile, anche perchè i 60 core non sono nè di classe Core nè Atom ma a quanto pare si tratta di derivati del P5 (pentium) (quindi niente MMX, (S)SSE-x , niente AVX, e pare niente X87 legacy) a cui è stata aggiunta la compatibilità X64 e un' unità SIMD a 512 bit (IMCI)

quindi come minimo (e a patto di avere caso di codice C / C++ e di appoggiarsi ai tool e performance libraries intel - che incapsulino l' assembly ottimizzato per lo specifico core target) è necessario aggiungere delle direttive che istruiscano il compilatore a fare uso dell' unità IMCI piuttosto che delle varie SIMD attualmente mainstream, e ricompilare
ma devi tenere presente che il target a cui questo oggetto è indirizzato non è il sw mainstream, ma quegli ambiti in cui il sw è scritto una tantum per l' architettura del supercomputer / cluster in uso

in questo senso, far girare codice preesistente con minime modifiche è un notevole vantaggio rispetto all' alternativa finora disponibile - doverlo rivedere integrarlmente per migrarlo a soluzioni GPGPU con annesso cambio di paradigma, cosa che in effetti equivale a un progetto sw a sè stante
non funziona così...
in modalità hosted è una periferica PCI Express come un' altra, gestita attraverso driver ed enumerata ad uso delle applicazioni che necessitano di un compute acccelerator - presumibilmente le applicazioni faranno richiesta via librerie e driver di istanziare 1...60 thread di calcolo sul Phi, al che librerie e driver uploaderanno alla scheda segmenti di codice e dati su cui operare - più o meno come adesso funziona per gli shader, ma con codice X86-64+IMCI piuttosto che shader assembly proprietario
in modalità clustered è un nodo indirizzabile con un suo indirizzo IP - in questo caso può esserci maggiore flessibilità visto che molti sistemi facenti uso di calcolo distribuito implementano meccanismi di comunicazione e sincronizzazione interni, quindi basterebbe avviare i thread di calcolo sulla scheda (ma mancando come pare uno storage locale da cui avviare il firmware sarà cmq l' host a occuparsi di farne l' upload, di nuovo attraverso i driver da parte di un processo di controllo )
o in alternativa può essere il sistema operativo a farlo, allora l' OS dovrà supportare protocolli di clustering e thread migration cluster-wise
ma quello che tutti questi casi hanno in comune è che in nessuno dovresti vedere processori (logici) aggiuntivi nel task manager, perchè non si tratterebbero di processori "locali"

sono daccordo... il punto era: essendo molto vicini ad un x86 completo tuttavia creare una scheda che facesse anche quello che dicevo io avrebbe permesso anche di sfondare un altro mercato con conseguente aumento dei profitti schede del genere andrebbero a ruba..

L'efficacia di queste schede non si sta neppure a discutere.con questo Intel ha superato se stessa.

..no, aspetta, almeno X87 lo sono, se no sarebbero derivati dal 486!
e' un superscalare che dovrebbe avere almeno una FPU e comunque le SMID 512 sono null'altro che le sse4.1 (dubito nativo sull'X64... probabile che il compilatore dissassembli il codice?).
poi non ho capito perche' ne considerano 60 quando se ne contano 64.
i restanti 4 sono per il coordinamento?

comunque sono giocattolini carini...

in questo documento sembra che sia appunto un x86 e non un x86-64:
http://software.intel.com/sites/def...rol-2012-08.pdf
anche se poi la distro che viene applicata e' su kernel 64bit....
discrepanze..

Si non ho capito neanche io

Questa e' uns scheda video che viene vista come molte cpu ?
Cio' se la installo su windows seven la posso usare per fare dei render che usano la parallelizzazione dei calcoli ?
O la posso instllar ein windows seven ma alla fine comunque bisogna avere un programma scritto per lei se no non si puo' usare in modo adeguato ?

Grazie ciao

http://software.intel.com/en-us/art...re-architecture
magari cosi' e' piu' chiaro...

no, non la puoi usare come periferica di rendering se non hai un programma che ne sfrutta la sua abilita' nei calcoli.

hai windows sulla WS in cui e' istallata questa scheda;
hai un programma che comunica con questa scheda e da' nozione del lavoro che vuoi far fare a questa scheda;
la distribuzione REALE e non virtuale che e' istallata sulla scheda rispondera' come se fosse un server cluster di calcolo;
sulla scheda dev'essere istallato una appendice del software che operi i calcoli che il tuo software di rendering gli ha affidato, sfruttando, con le giuste API, la potenza di calcolo.

e' un server nella tua WS, ma devi istruirlo....
quindi se non c'e' il software d'appoggio non ci fai nulla.

puo' essere programmata nativamente, ma credo solo per ricerca e non per uso professionale (e chi ti si mette a programmarla direttamente per fare un rendering! il solo software ti costa un occhio della testa!)

nella pratica devi aspettare software commerciali che sfruttano tale soluzione (che siano basati su openCL, openGL o nativi).

eh

sembrava troppo bello avevo capito che il software era gia' preinstallato e vedeva qualunque applicazione in automatico .Ma se fosse cosi Intel non venderebbe piu' workstation per render farm..... Pero' un amico che e' un genio che lavora in un agenzia spaziale americana , forse lui....