PoCL 3.0 Released With Minimal OpenCL 3.0 Implementation For CPUs

[coder]

Vulkan compute (or Vulkan in general) i know is strong low level, and has quite diffrent philosophy. But I know projects that succesfully employed it.

You can write compute shaders in Vulkan without using the Vulkan Compute SPIRV. A lot of the projects using Vulkan for computation are doing just that.

We have waifu2x for example that doesn't have popular OpenCL backend, but has CUDA and Vulkan.

That's deep learning, which has far lower precision requirements. That you can use Vulkan for it says nothing about Vulkan's suitability for things like CAD, CFD, FEA, finance, or HPC.

Point about precision : I don't agree with you here. If you have device compliant with OpenCL and Vulkan it is obvious that they gonna use same underlying hardware with same underlying precision for same kind of operation.

It sounds like you've never seen the inside of a math library. GPUs don't have a hardware block for each and every mathematical function - they have hardware for doing like Taylor series expansions, but it can only evaluate a certain number of terms per cycle, for instance. For greater accuracy, you have to evaluate more terms, which takes longer. If the implementation assumes you don't need higher precision, it's going to stop sooner.

And if you look at the precision requirements in the Vulkan spec, they match those of GLSL, which are far lower than OpenCL's.

So when Vulkan doesn't mandate it, precision issue you talk about is only potential issue

Yes, you can have an implementation which delivers more than the minimum precision, but it can't be assumed. That impacts portability and limits the ability of software developers to support customers, if we're talking about software with any special precision requirements.

Also as far as i know devices that support Vulkan actually does offer full IEEE754 compliance in practise.

That spec doesn't dictate the accuracy of actual implementations.

Vulkan spec gives quite good doc about maximum allowed error for operations.

Yes, I've read it, and it's quite a bit looser than OpenCL. Rather than me reposting it, you can just read this post for my comparative analysis of Vulkan vs OpenCL precision guarantees:

https://www.phoronix.com/forums/foru...e2#post1297669

[coder]

There is only a solution: C++ !!! :-P

Yeah, and plenty of half-way solutions, like C++AMP, DPC++, and SYCL. Even OpenCL 2.2 added many C++ features to the kernel language.

The HSA IR supposedly has all of the facilities needed to support generic C++ (including exceptions!), but then HSA never really caught on.

The problem with running naive C++ on GPUs is that you have to keep branch divergence to a minimum, or else your performance is going to be garbage. And that means large swaths of STL are out of the question, due to the amount of heap allocation.

[boboviz]

The problem with running naive C++ on GPUs is that you have to keep branch divergence to a minimum, or else your performance is going to be garbage. And that means large swaths of STL are out of the question, due to the amount of heap allocation.

I know there are some problems with C++, but the idea to have a "unique" (and STANDARD) starting point...