Link alla notizia: https://www.hwupgrade.it/news/cpu/intel-oneapi-raggiunge-la-versione-10-e-guarda-alle-gpu-amd_92415.html

Intel OneAPI ha raggiunto la versione 1.0. L'API aperta e agnostica di Intel, che punta a offrire un modello di programmazione unificato per semplificare lo sviluppo tra diverse architetture, punta a espandersi supportando anche le GPU AMD.

Click sul link per visualizzare la notizia.

ME COJONI!

non ho ben capito di che si tratta, :stordita: ma sembra una cosa interessante

non ho ben capito di che si tratta, :stordita: ma sembra una cosa interessante
la risposta di intel a CUDA di Nvidia, un Framework che copre a 360 gradi tutto l'hardware e software che si usa in questo campo, se prende piede farebbe il botto

non ho capito a cosa servono queste API.

non ho capito a cosa servono queste API.

per fare quello che fa cuda ma in maniera open senza vincoli di hardware e licenze varie

Il problema come sempre saranno le prestazioni. Difficilmente si raggiunge quelle di un codice scritto direttamente in CUDA. D'altro canto c'è la maggior semplicità e flessibilità. Tutto da verificare, vedremo.

non ho capito a cosa servono queste API.A produrre miele.







Si, insultatemi pure :asd:

Il problema come sempre saranno le prestazioni. Difficilmente si raggiunge quelle di un codice scritto direttamente in CUDA. D'altro canto c'è la maggior semplicità e flessibilità. Tutto da verificare, vedremo.

magari, e non è nemmeno detto, sarà difficile farlo con la sola architettura grafica che supporta Cuda.
Cuda rende facile la costruzione del codice perchè hai già pacchetti preconfezionati, ma non è assolutamente un framework che fa lavorare al meglio tutte le architetture... su CPU gira molto meglio openCL e ci sono diverse evidenze a supporto di tale questione.

per quanto riguarda OneAPI non credevo che Intel volesse aprirla al resto dell'HW, o quantomeno sono incredulo che lo voglia fare in maniera Open...
a vedere come si tiene strette le AVX, splittando su codice generico qualsiasi cosa che non sia Genuine Intel su FPU se si usa il suo complilatore e le sue librerie, ero quasi sicuro che l'avrebbe usata esclusivamente per imporre altri standard chiusi.

L'andamento attuale sembra essere quello di utilizzare C++ (nelle sue ultime versioni, la 17 e la 20) come base per la programmazione eterogenea e i vari framework (CUDA, OpenCL, ecc) come una sorta di "dialetti" per gpu attraverso vari layer, come Sycl (su cui si basano queste OneApi), C++ for OpenCl e CUDA C++.
Sarebbe veramente un grosso passo in avanti programmare direttamente in C++ e passare il codice facilmente su gpu, fpga, ecc

è un pò diverso da come è scritto, intanto il fautore principale della cosa è l'università di Heidelberg ( Heidelberg University Computing Center, URZ)

e l'annuncio ufficiale è questo

Intel and Heidelberg University Computing Center (URZ) today announced that they have established oneAPI Academic Center of Excellence (CoE) at UZR. The newly established CoE has a goal to further develop Intel's oneAPI standard and enable it to work on AMD GPUs. This information is a bit shocking, however, Intel believes that the technology should work on a wide range of processors, no matter the vendor. The heterogeneous hardware programming is the main goal here. In a Twitter thread, an Intel employee specifies that Intel has also been working with Arm and NVIDIA to bring Data-Parallel C++ (DPC++), a core of oneAPI, to those vendors as well. That should bring this universal programming model to every device and adapt to every platform, which is a goal of heterogeneous programming - whatever you need to program a CPU, GPU, or some other ASIC, it is covered by a single API, specifically oneAPI.

e continua

URZ's work as a oneAPI CoE will add advanced DPC++ capabilities into hipSYCL, which supports systems based on AMD GPUs, NVIDIA GPUs, and CPUs. New DPC++ extensions are part of the SYCL 2020 provisional specification that brings features such as unified shared memory to hipSYCL and the platforms it supports - furthering the promise of oneAPI application support across system architectures and vendors.


poi se passa alla telenovela su twitter dove un utente ha risposto all'annuncio:

That is kind of shocking. I thought oneAPI would only be contained within and supported by Intel products only.

This is good news.

a cui hanno risposto due persone

Tom Deaking (che è il ricercatore senior per l'high computing archidecture dell'università di brisotol)

OneAPI DPC++ = Khronos SYCL + Intel vendor extensions. Being essentially SYCL means you get a proper royalty-free cross-vendor open standard to use.

e quantum dot che, nonostante il nome, è un accreditato sviluppatore di api per calcolo distribuito di intel:

Not only is it theoretically portable but Intel employees like me care deeply about it actually being so and have worked on the ARM and NVIDIA ports of DPC++ when necessary.


Quindi la traduzione è che fondamentalmente intel stava sviluppando la sua estenzione di openCL (tanto tutto parte sempre da li) per rendere il porting più facile. L'università di Heidelberg vuole portare one api a funzionare sulle gpu amd (ma non capisco perchè già girano su openCL e già esiste SYCL di khronos grup, dove dentro ci stanno MS, AMD, Nvidia, ARM, e pure intel) e c'è stata la conferma che oneAPI , con le dovute modifiche ha girato anche su arm e roba nvidia (grazie al kaiser, visto che già gira SYCL ,che già comprende le estensioni AI del tensorflow di nvidia e il backend con cuda, quindi se mi fai un sycl che ha estensioni per roba intel, ma si porta dietro tutto il resto me pare abbastanza ovvio che giri anche su tutto il resto)

Imho onestamente so contento che l'università di Heidemberg (ci lavora un mio carissimo amico) con sta storia abbia raspato i soldi per aprirsi un centro di eccellenza in computing con i soldi di intel , ma sta cosa di oneAPI me pare il classico annuncio di marketing da grande azienda per dire "sto facendo gratis quello che il consorzio a cui faccio parte già fa in maniera gratuita, ma mi voglio fare un pò di pubblicità e dire che ci sta sta mirabolante cosa che già esiste".

L'unica cosa interessante che vedo è il fatto che ci sia il supporto alle FPGA (visto che intel ha comprato altera), però va capito se agiranno solo sulla parte del core arm che hanno integrato dentro (ormai le più recenti hanno anche un dual core arm integrato, me vengono in mente le xilinx zynq-7020 che ormai costano veramente poco e dentro hanno un arm a9 dual core) o anche sulla parte di logica programmabile (o se quella toccherà sempre scriverla in vhdl o in verilog)

su CPU gira molto meglio openCL e ci sono diverse evidenze a supporto di tale questione.
Pure sulle gpu AMD OpenCl funziona meglio

per quanto riguarda OneAPI non credevo che Intel volesse aprirla al resto dell'HW, o quantomeno sono incredulo che lo voglia fare in maniera Open...
E' "basato" su SyCL, che è aperto...

L'università di Heidelberg vuole portare one api a funzionare sulle gpu amd (ma non capisco perchè già girano su openCL e già esiste SYCL di khronos grup, dove dentro ci stanno MS, AMD, Nvidia, ARM, e pure intel) e c'è stata la conferma che oneAPI , con le dovute modifiche ha girato anche su arm e roba nvidia (grazie al kaiser, visto che già gira SYCL ,che già comprende le estensioni AI del tensorflow di nvidia e il backend con cuda, quindi se mi fai un sycl che ha estensioni per roba intel, ma si porta dietro tutto il resto me pare abbastanza ovvio che giri anche su tutto il resto)

Ma infatti, Kronos sta facendo un ottimo lavoro con Sycl e non capisco perchè Intel voglia farne una propria "versione".

a vedere come si tiene strette le AVX, splittando su codice generico qualsiasi cosa che non sia Genuine Intel su FPU se si usa il suo complilatore e le sue librerie, ero quasi sicuro che l'avrebbe usata esclusivamente per imporre altri standard chiusi.

quest è una fesseria non ho mai avuto fra le mani codice intel che su amd non sfruttasse pure meglio le avx, pure il clear linux 100% codice intel nativo su amd va pure meglio

Ma infatti, Kronos sta facendo un ottimo lavoro con Sycl e non capisco perchè Intel voglia farne una propria "versione".

perche Kronos ci mette 10 anni a fare quello che ha fatto intel in 1 questa è la differenza un po come le opengl che dopo 10 anni sono arrivate al livello delle directx

perche Kronos ci mette 10 anni a fare quello che ha fatto intel in 1 questa è la differenza un po come le opengl che dopo 10 anni sono arrivate al livello delle directx
Su questo posso anche darti ragione (se penso che per arrivare ad OpenCl 3.0, rilasciato ieri, ci han messo anni), ma su Sycl mi sembra siano stati decisamente più spediti (ed Intel ci ha messo poco perchè ha trovato gran parte del codice già pronto). Ma forse mi sbaglio io.

quest è una fesseria non ho mai avuto fra le mani codice intel che su amd non sfruttasse pure meglio le avx, pure il clear linux 100% codice intel nativo su amd va pure meglio

perche Kronos ci mette 10 anni a fare quello che ha fatto intel in 1 questa è la differenza un po come le opengl che dopo 10 anni sono arrivate al livello delle directx

Su questo posso anche darti ragione (se penso che per arrivare ad OpenCl 3.0, rilasciato ieri, ci han messo anni), ma su Sycl mi sembra siano stati decisamente più spediti (ed Intel ci ha messo poco perchè ha trovato gran parte del codice già pronto). Ma forse mi sbaglio io.

bah onestamente doveva aggiungere solo le estensioni intel allo sycl e questo ha fatto.
Nvdia pure lo ha fatto aggiungendo il tensorflow per le ai e la backend con cuda.
Semplicemente credo sia marketing. A nvidia fa gioco tenere su il marchio CUDA, che aveva senso all'inzio del gpgpu e adesso un pò di meno, però ormai è un marchio consolidato.
A intel probabilmente fa comodo dire che ha una cosa fatta da lei che però gira su tutto l'hw, qualche gonzo sicuro ci casca, chi lo sa semplicemente fa il discorso sopra "grazie al quasi che gira su tutto, visto che hai preso una cosa che gira su tutto e hai aggiunto le tue estensioni per la roba tua".

Poi chi lo usa ed è informato, semplicemente fa la scelta di quale pacchetto gli piace di più a livello grafico XD.