Khronos Unveils OpenCL 2.2, SPIR-V 1.2, OpenCL CTS Open-Sourced

[phoronix]

Phoronix: Khronos Unveils OpenCL 2.2, SPIR-V 1.2, OpenCL CTS Open-Sourced

There are some exciting Khronos announcements this morning, including more open-source greatness!..

http://www.phoronix.com/scan.php?page=news_item&px=OpenCL-2.2-Released

[andrei_me]

About vulkan compute vs OpenCL, we heard a lot of vulkan graphic capabilities, but I can't remember someone saying something about it's compute capabilities...

It is like a OpenGL compute shader?

What vulkan brings to table regarding to compute? The multithread dispatch part?

[Veerappan]

The conformance tests being opened up today are for OpenCL 1.2, 2.0, and 2.1 while more releases are coming.

Thank you, Khronos!

This should help my spare-time clover/libclc efforts immensely.

[andre30correia]

About vulkan compute vs OpenCL, we heard a lot of vulkan graphic capabilities, but I can't remember someone saying something about it's compute capabilities...

It is like a OpenGL compute shader?

What vulkan brings to table regarding to compute? The multithread dispatch part?

What i think right now we need to use spirit-v for compute in Vulkan but I'm probaly wrong

[nevion]

I think reading between the lines for NVidia's treatment of OpenCL provides the motive for merging with Vulkan. This is certainly debatable, they probably have more than one reason for doing it, but it could be an elegant way to get Nvidia to play ball.

[liam]

Big update.
I really hope to see more projects start making use of this multivendor api.
That ocl can work as well as openmp is even better.

[coder]

As excited as I am for C++ kernel support, I think the open Conformance Test Suite is possibly a bigger deal! With this, we can clearly see what works & what doesn't, on implementation XYZ. This is a big deal, if you're doing any OpenCL development on embedded or mobile platforms. It will hopefully push vendors to offer better support, even if by embracing one of the open stacks mentioned in the article.

That said, it's hard to overstate the importance of C++ kernel language support. It's sorely needed to implement generic libraries of parallel algorithms and datastructures. I tried this with C preprocessor metaprogramming, but it's clumsy, complicated, and perceived as non-standard.

[nevion]

coder yes, same for me regarding the C++ kernel language on all points. Preprocessor sucks so much at it. So few of the population understand it too, and this is the surprising part - they want to stay C so they can code out the exact same algorithm each time every time and / or deal with macros inlining code with the problems it brings...