Beignet Continues Slowly Tackling OpenCL 2.0 For Intel Linux Graphics

[phoronix]

Phoronix: Beignet Continues Slowly Tackling OpenCL 2.0 For Intel Linux Graphics

While Intel has already supported OpenCL 2.0 on Windows, under Linux the current Beignet project for open-source OpenCL is still limited to the 1.2 specification. Fortunately, in recent weeks the OpenCL 2.0 branch has seen some new activity...

http://www.phoronix.com/scan.php?page=news_item&px=Beignet-OpenCL-2.0-Jan16

[gururise]

OpenCL 2.0 support cannot happen FAST enough... With most scientists and researchers now moving on to the proprietary CUDA (Nvidia), the chances of an open and industry-wide standard for GPU computing is dwindling by the day. AMD, Intel and the other gfx manufacturers (are there others?) need to band together and really push OpenCL, otherwise we will be stuck with over-priced and intentionally crippled Nvidia hardware for GPU compute.

[Guest]

OpenCL 2.0 support cannot happen FAST enough... With most scientists and researchers now moving on to the proprietary CUDA (Nvidia), the chances of an open and industry-wide standard for GPU computing is dwindling by the day. AMD, Intel and the other gfx manufacturers (are there others?) need to band together and really push OpenCL, otherwise we will be stuck with over-priced and intentionally crippled Nvidia hardware for GPU compute.

Is Nvidia preventing others to reimplement CUDA?

[andrei_me]

What is the state of OpenCL in Nouveau/RadeonSI/ADMGPU?

[boxie]

Is Nvidia preventing others to reimplement CUDA?

Yes and No. CUDA is proprietary and therefore lawyers would have a field day. AMD's approach here is the Boltzmann initiative http://www.amd.com/en-us/press-relea...2015nov16.aspx which transpiles the cuda code into opencl

[boxie]

OpenCL 2.0 support cannot happen FAST enough... With most scientists and researchers now moving on to the proprietary CUDA (Nvidia), the chances of an open and industry-wide standard for GPU computing is dwindling by the day. AMD, Intel and the other gfx manufacturers (are there others?) need to band together and really push OpenCL, otherwise we will be stuck with over-priced and intentionally crippled Nvidia hardware for GPU compute.

Not Really - there is a new open compute thing (SPIR) coming with the Vulkan release that will make using GPU compute *much* easier (afaik) and because it is part of Vulkan, it must be implemented across the board.

[bridgman]

Yes and No. CUDA is proprietary and therefore lawyers would have a field day. AMD's approach here is the Boltzmann initiative http://www.amd.com/en-us/press-relea...2015nov16.aspx which transpiles the cuda code into opencl

Actually not into OpenCL, but a C++17 subset with the parallel extensions.

That gets us a lot closer to a single code base that can run on AMD, Intel and NVidia HW.

http://www.open-std.org/jtc1/sc22/wg...15/p0069r0.pdf

[boxie]

Actually not into OpenCL, but a C++17 subset with the parallel extensions.

I stand corrected - and in fact, that is cooler!

[erendorn]

OpenCL 2.0 support cannot happen FAST enough... With most scientists and researchers now moving on to the proprietary CUDA (Nvidia), the chances of an open and industry-wide standard for GPU computing is dwindling by the day. AMD, Intel and the other gfx manufacturers (are there others?) need to band together and really push OpenCL, otherwise we will be stuck with over-priced and intentionally crippled Nvidia hardware for GPU compute.

How does this initiative compare to SYCL + SPIR-V?
OpenCl 2.1 looks very promising, I hope some support will be available soon too.

[bridgman]

I think the idea is that SYCL will evolve to align with what we are doing with HCC now, ie everything will converge around C++ parallel STL.

SYCL allows you to use C++ parallel code and run it over an OpenCL 2.0 implementation, while HCC skips over the OpenCL layer and goes straight to hardware via the HSA stack.

Here's an SC14 presentation that does a pretty good job of tying it all together:

http://ronan.keryell.fr/Talks/2014/2...YCL-expose.pdf