Alcuni sviluppatori di Red Hat lavorano a un'alternativa a NVIDIA CUDA

Ma direi che OpenCL non ha proprio niente da invidiare a CUDA in tutti i sensi. Il discorso dell'ottimizzazione e' relativo, soprattutto quando hai alle spalle una toolchain basata su LLVM.

Il problema di OpenCL e' che i co****ni che lo implementano si contano sulle dita di una mano.

E' normale che, cercando di accelerare una rete neurale deep, su un RK3288 con GPU Mali, io debba passare due settimane a sclerare per ottenere risultati sub ottimali, solo perche' OpenCL e' implementato a dovere solo sulla carta? Cioe' nemmeno coloro che in teoria dovrebbero avere tutto l'interesse ad implementarlo lo fanno e questo perche' perseguono pure loro logiche da standard proprietari ( si stanno radunando intorno ad ARM Compute Library ).

Stessa cosa i campioni di AMD che s'inventano ROCm. Ma perche'? Quando poi se proprio gli fa schifo il nome OpenCL, ci sono all'orizzonte le estensioni compute per Vulkan.

No, vogliono fare pure i loro il lock-in, sperando di replicare il giochetto riuscito a Nvidia.

Ovviamente devono spiegarci come intenderanno muoversi sul fronte FPGA, NPU, TPU e compagnia cantante. Prevedo un altro caos di proporzioni bibliche, che richiedera' 30 anni per essere sbrogliato.

IBM ha integrato l'nVlink di nVidia direttamente nei suoi processori....

semmai è proprio il contrario... nVidia è l'unico modo che ha per rimanere nel mondo dei mainframe, visto che, di anno in anno, il calcolo si sta spostando verso le GPU e le CPU stanno diventando "di contorno".

AMD si fa tutto in casa, Intel sta sviluppando GPU principalmente per questo motivo ( nVidia ha rubato a Intel qualcosa come 2 Miliardi di fatturato in ambito HPC nel 2017 e quest'anno, ne rubera quasi altri 3 ), quindi, o IBM si mette a progettare GPU o gli rimane solo nVidia perchè il futuro è GPU.... gli piacera poco "legarsi" a un produttore, ma una volta che gli altri si fanno tutto in casa non trovo molto furbo perdere tempo a sviluppare un nuovo linguaggio quando poi va a finire che se prendo GPU AMD prendo anche CPU AMD e con GPU Intel prendero CPU Intel... perchè alla fine, finira che i processori avranno un bus di collegamento diretto come IBM+nVlink, ( AMD ha l'Infinity Fabric e credo che Intel arrivera con qualche cosa di simile ).

nVidia se la sta giocando bene con l'nVlink e 16 GPU con solo 2 CPU.

Sono d'accordo con te. Rocm non è altro che una variante di opencl (che ne è alla base, infatti). Boh, gli piaceranno i nomi diversi.


Non saprei. Rocm gira anche su piattaforme Intel, per esempio.
C'è da dire che AMD non sembra particolarmente "forzare" su OpenCl. Basti vedere, per esempio, che non supporta ufficialmente il meeting annuale IWOCL...


Lasceranno fare, come spesso è accaduto.
Portassero avanti delle direttive chiare e consistenti.
Già si comincia a parlare di OpenCL-Next e ho paura, come te, che sarà un delirio peggiore.


P.S. Sono andato a leggermi la presentazione originale dei tipi di Red Hat e sembra, più che altro, un utilizzo diverso e migliore di SYCL.

sono d'accordo. 1000 standard = nessuno standard.

Si ok, ma in alcuni campi le prestazioni sono fondamentali ed è meglio rivolgersi direttamente a CUDA (purtroppo).. Quindi tutto dipende da che codice stai sviluppando.



Non è questione di "copiare" CUDA, è che se tu giri OpenCL su GPU Nvidia e ti proponi come standard devi supportare il più possibile ciò che la scheda sotto ti mette a disposizione, altrimenti rischi di non sfruttarla appieno. E lo stesso per le GPU AMD o per un qualunque acceleratore. Detto questo io sono pienamente favorevole ad usare OpenCL, ma se serve sfruttare le ultime potenzialità di una scheda non è detto che sia la scelta migliore.