Hacker News Reader

Comment by profquail | Hacker News Reader

oneAPI uses DPC++ (Data-Parallel C++), which is pretty much just SYCL, which itself is a C++ library on top of OpenCL.

From my understanding, the Khronos group realized OpenCL 2.x was much too complicated so vendors just weren’t implementing it, or only implementing parts of it, so they came up with OpenCL 3.0 which is slimmed-down and much more modular. It’s hard to say how much adoption it’ll get, but with Intel focused on DPC++ and oneAPI now, there will definitely be more numerical software coming out in the next few years that compiles down to and runs on OpenCL.

For example, Intel engineers are building a numpy clone on top of DPC++, so unlike regular numpy it’ll take advantage of multiple CPU cores: https://github.com/IntelPython/dpnp

View on HN

Kind of right.

DPC++ has more stuff than just SYSCL, some of it might find its way back to SYSCL standardization, some of it might remain Intel only.

OpenCL 3.0 is basically OpenCL 1.2 with a new name.

Meanwhile people are busy waiting for Vulkan compute to take off, got to love Khronos standards.

Some people are working on being able to run OpenCL kernels on Vulkan: https://github.com/google/clspv

Sure, but it will take off to actually matter?

So far I am only aware of Adobe using it to port their shaders to Vulkan on Android.

> From my understanding, the Khronos group realized OpenCL 2.x was much too complicated so vendors just weren’t implementing it, or only implementing parts of it, so they came up with OpenCL 3.0 which is slimmed-down and much more modular.

Something like this also happened to OpenGL 4.3. It added a compute shader extension which was essentially all of OpenCL again, except different, so you had 2x the implementation work. This is about when some people stopped implementing OpenGL.

OpenGL compute shaders are a natural step if you have unified programmable shader cores, and less complicated than adding new pipeline stages for everything (tessellation shaders, geometry shaders, …).

Khronos could have chosen only to add OpenCL integration, but OpenCL C is a very different language to GLSL, the memory model (among other things) is different, and so on. I don't see why video game developers should be forced to use OpenCL when they want to work with the outputs of OpenGL rendering passes, to produce inputs to OpenGL rendering passes, scheduled in OpenGL, to do things that don't fit neatly into vertex or fragment shaders?

On the contrary, for example on Android OpenGL ES you get compute shaders, but no OpenCL.

By the way, the latest version is OpenGL 4.6, it is also available on the Switch.

Reply on news.ycombinator.com