khronosgroup/opencl-clhpp

Khronos OpenCL-CLHPP

OpenCL^TM API C++ bindings

Doxgen documentation for the bindings is available here:

http://khronosgroup.github.io/OpenCL-CLHPP/

Components:

• include/CL/opencl.hpp: The latest, maintained, version of the C++ bindings. It should work with all versions of OpenCL (including 1.x). This is what most users will want.

• include/CL/cl2.hpp: Includes opencl.hpp and emits a warning, for backwards compability.

• docs: Doxygen file used to generate HTML documentation for opencl.hpp.

• examples: A simple example application using the very basic features of the bindings.

• tests: A (very small, incomplete) set of regression tests. Building the tests requires Python, Ruby, and CMock. For the last one we use CMock top-of-tree from Github, as the latest (at the time this was written) released CMock version, v2.5.3, has some issues.

• CMakeLists.txt: Build system for the examples and tests and logic for the bindings installation.

Build Instructions

While the C++ Headers can be built and installed in isolation, it is part of the OpenCL SDK. If looking for streamlined build experience and a complete development package, refer to the SDK build instructions instead of the following guide.

Dependencies

The C++ Headers require:

• the OpenCL Headers.
  • It is recommended to install the headers via CMake, however a convenience shorthand is provided. Providing OPENCL_CLHPP_HEADERS_DIR to CMake, one may specify the location of OpenCL Headers. By default, the C++ Headers will look for OpenCL Headers under ${OPENCL_DIST_DIR}/include.
• the OpenCL-ICD-Loader when building the examples
  • It is recommended to install the ICD loader via CMake, however a convenience shorthand is provided. Providing OPENCL_CLHPP_LOADER_DIR to CMake, one may specify the location of the OpenCL ICD loader. By default, the C++ headers will look for OpenCL ICD loader under ${OPENCL_DIST_DIR}/lib.
• The C++ Headers uses CMake for its build system. If CMake is not provided by your build system or OS package manager, please consult the CMake website.
• The unit tests require CMock. To get this external dependency, use --recursive when cloning the repository, or run git submodule update --init --recursive.
• Generating the mock input requires Ruby.
• Generating the docs requires Doxygen. When it is available, you can generate HTML documentation by building the docs target.

Example Build

1. Clone this repo, the OpenCL ICD Loader and the OpenCL Headers:

    git clone --recursive https://github.com/KhronosGroup/OpenCL-CLHPP
    git clone https://github.com/KhronosGroup/OpenCL-ICD-Loader
    git clone https://github.com/KhronosGroup/OpenCL-Headers
   

2. Install OpenCL Headers CMake package

    cmake -D CMAKE_INSTALL_PREFIX=./OpenCL-Headers/install -S ./OpenCL-Headers -B ./OpenCL-Headers/build 
    cmake --build ./OpenCL-Headers/build --target install
   

3. Build and install OpenCL ICD Loader CMake package. (Note that CMAKE_PREFIX_PATH need to be an absolute path. Update as needed.)

    cmake -D CMAKE_PREFIX_PATH=/absolute/path/to/OpenCL-Headers/install -D CMAKE_INSTALL_PREFIX=./OpenCL-ICD-Loader/install -S ./OpenCL-ICD-Loader -B ./OpenCL-ICD-Loader/build 
    cmake --build ./OpenCL-ICD-Loader/build --target install
   

4. Build and install OpenCL C++ Headers CMake package.

    cmake -D CMAKE_PREFIX_PATH="/absolute/path/to/OpenCL-Headers/install;/absolute/path/to/OpenCL-ICD-Loader/install" -D CMAKE_INSTALL_PREFIX=./OpenCL-CLHPP/install -S ./OpenCL-CLHPP -B ./OpenCL-CLHPP/build 
    cmake --build ./OpenCL-CLHPP/build --target install
   

Example Use

Example CMake invocation

cmake -D CMAKE_PREFIX_PATH="/chosen/install/prefix/of/headers;/chosen/install/prefix/of/loader;/chosen/install/prefix/of/cppheaders" /path/to/opencl/app

and sample CMakeLists.txt

cmake_minimum_required(VERSION 3.0)
cmake_policy(VERSION 3.0...3.18.4)
project(proj)
add_executable(app main.cpp)
find_package(OpenCLHeaders REQUIRED)
find_package(OpenCLICDLoader REQUIRED)
find_package(OpenCLHeadersCpp REQUIRED)
target_link_libraries(app PRIVATE OpenCL::Headers OpenCL::OpenCL OpenCL::HeadersCpp)

opencl-clhpp's Issues

isReferenceCountable(cl_device_id device) unused variable warning

When compiling with this parameters -Wall -Wextra -std=c++11 -O2 -Os -s -DNDEBUG, I got

cl2.hpp: In static member function 'static bool cl::detail::Wrapper<_cl_device_id*>::isReferenceCountable(cl_device_id)':
cl2.hpp:1740:51: warning: unused parameter 'device' [-Wunused-parameter]
static bool isReferenceCountable(cl_device_id device)

Cannot compile cl2.hpp using libc++

When I attempt to use the OpenCL C++ wrappers version 2.1.0 (cl2.hpp) together with CLang 3.9/3.6 and libc++ 1.0~svn199600-1 the following program does not compile. I am running Ubuntu 14.04.

#define CL_HPP_MINIMUM_OPENCL_VERSION 100
#define CL_HPP_TARGET_OPENCL_VERSION 110
#define CL_HPP_ENABLE_EXCEPTIONS
#include "CL/cl2.hpp"

int main(int argc, char *argv[])
{
}

Compiler Output:

$ clang++-3.9 -std=c++11 opencl.cpp -I Build/Host-Linux-Clang/Release/Thirdparty/OpenCl/include/ -lOpenCL -stdlib=libc++
In file included from opencl.cpp:8:
In file included from Build/Host-Linux-Clang/Release/Thirdparty/OpenCl/include/CL/cl2.hpp:504:
/usr/include/c++/v1/utility:253:9: error: field has incomplete type 'cl::Device'
    _T1 first;
        ^
/usr/include/c++/v1/type_traits:2023:27: note: in instantiation of template class 'std::__1::pair<cl::Device, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >' requested here
                 decltype(__is_constructible_test(declval<_Tp>(), declval<_Args>()...))
                          ^
/usr/include/c++/v1/type_traits:2072:14: note: in instantiation of template class 'std::__1::__is_constructible<false, std::__1::allocator<std::__1::pair<cl::Device, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >,
      std::__1::allocator<std::__1::pair<cl::Device, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > &&>' requested here
    : public __is_constructible<is_scalar<_Tp>::value || is_reference<_Tp>::value,
             ^
/usr/include/c++/v1/type_traits:2098:14: note: in instantiation of template class 'std::__1::__is_constructible_void_check<false, std::__1::allocator<std::__1::pair<cl::Device, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >,
      std::__1::allocator<std::__1::pair<cl::Device, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > &&>' requested here
    : public __is_constructible_void_check<__contains_void<_Tp, _Args...>::value
             ^
/usr/include/c++/v1/type_traits:2578:34: note: in instantiation of template class 'std::__1::is_constructible<std::__1::allocator<std::__1::pair<cl::Device, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >,
      std::__1::allocator<std::__1::pair<cl::Device, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > &&>' requested here
    : __is_nothrow_constructible<is_constructible<_Tp, _Args...>::value, _Tp, _Args...>
                                 ^
/usr/include/c++/v1/type_traits:2713:14: note: in instantiation of template class 'std::__1::is_nothrow_constructible<std::__1::allocator<std::__1::pair<cl::Device, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >,
      std::__1::allocator<std::__1::pair<cl::Device, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > &&>' requested here
    : public is_nothrow_constructible<_Tp, typename add_rvalue_reference<_Tp>::type>
             ^
/usr/include/c++/v1/vector:575:20: note: in instantiation of template class 'std::__1::is_nothrow_move_constructible<std::__1::allocator<std::__1::pair<cl::Device, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > >' requested here
        _NOEXCEPT_(is_nothrow_move_constructible<allocator_type>::value);
                   ^
Build/Host-Linux-Clang/Release/Thirdparty/OpenCl/include/CL/cl2.hpp:1905:7: note: in instantiation of exception specification for 'vector' requested here
class BuildError : public Error
      ^
Build/Host-Linux-Clang/Release/Thirdparty/OpenCl/include/CL/cl2.hpp:660:11: note: forward declaration of 'cl::Device'
    class Device;
          ^
Build/Host-Linux-Clang/Release/Thirdparty/OpenCl/include/CL/cl2.hpp:1926:19: note: implicit move constructor for 'cl::BuildError' first required here
            throw BuildError(err, errStr, buildLogs);
                  ^
1 error generated.

More precise template parameter type for Platform::getInfo<>()

Couldn't the declaration

    template <cl_int name> typename
    detail::param_traits<detail::cl_platform_info, name>::param_type
    getInfo(cl_int* err = NULL) const

at Line 2466 of cl2.hpp be changed without braking compatibility to this?

    template <cl_platform_info name> typename
    detail::param_traits<detail::cl_platform_info, name>::param_type
    getInfo(cl_int* err = NULL) const

(changing the template parameter type of name)

This way it would be much more obvious what kind of values can be accepted as the template parameter.

Telling cl::Program to auto-build source causes "aclBinary init failure" on certain AMD architectures

The computer in question is using an AMD Radeon HD 5450, which as best as I can determine, is capped at OpenCL version 1.2. It lists a total of 2 platforms with 3 devices for the first platform (two of which seem to be identical except for device ID, are GPU-types, and simply have the name "Cedar"; the third is the Intel CPU-type device being driven by the AMD platform), and 1 device for the second (which is on the Intel Experimental 2.0 platform, using the CPU as a CPU-type device).

In my program, when I write the following code:

cl::Program program{context, src, true};

The two GPU-based devices (referred to as "Ceder" by their name) fail to compile, simply reporting "aclBinary init failure". The other two devices work perfectly fine.

If, however, I write this code instead:

cl::Program program{context, src, false};
program.build();

All four devices are able to behave normally, as expected.

The issue seems to be an inconsistency between how Program::Program implements its build of the kernel source, and how Program::build implements its build.

If there's something I should be doing on my end, or if you need more information, let me know.

New stable release soon?

Following the discussion started in here, we were wondering whether a new stable release of clhpp was planned soon (2.0.10?), which would include the includes this fix (befe77b) in particular. This way, Linux distributions such as Debian could target the packaging on this specific stable release, rather than take an arbitrary snapshot.

Thanks,
Ghis

Please make releases

It's been close to 4 years since the v2.0.10 tag was made. Linux distributions enjoy being able to ship tagged releases because it helps identify what software is included and makes cross-distro comparisons much simpler.

Nothing more needs to be done from your side than pushing a git tag.

Compiler warnings

Hi there, I don't know if any of these are important, but I shared them in another project who uses these files (leela-zero/leela-zero#702) so I'm pushing the issue upstream. :)

g++ -I/usr/include/openblas -I. -Wall -Wextra -pipe -O3 -g -ffast-math -flto -march=native -std=c++14 -DNDEBUG -MD -MP -c -o Network.o Network.cpp
In file included from OpenCL.h:27:0,
                 from OpenCLScheduler.h:26,
                 from Network.cpp:44:
./CL/cl2.hpp:1831:5: warning: type qualifiers ignored on function return type [-Wignored-qualifiers]
     const cl_type get() const { return object_; }
     ^~~~~
In file included from OpenCL.h:27:0,
                 from OpenCLScheduler.h:26,
                 from Network.cpp:44:
./CL/cl2.hpp:5857:63: warning: ignoring attributes on template argument âcl_int {aka int}â [-Wignored-attributes]
     typename std::enable_if<!std::is_pointer<T>::value, cl_int>::type
                                                               ^
./CL/cl2.hpp:6157:22: warning: ignoring attributes on template argument âcl_int {aka int}â [-Wignored-attributes]
         vector<cl_int>* binaryStatus = NULL,
                      ^

g++ -I/usr/include/openblas -I. -Wall -Wextra -pipe -O3 -g -ffast-math -flto -march=native -std=c++14 -DNDEBUG -MD -MP -c -o OpenCL.o OpenCL.cpp
In file included from OpenCL.h:27:0,
                 from OpenCL.cpp:22:
./CL/cl2.hpp:1831:5: warning: type qualifiers ignored on function return type [-Wignored-qualifiers]
     const cl_type get() const { return object_; }
     ^~~~~
In file included from OpenCL.h:27:0,
                 from OpenCL.cpp:22:
./CL/cl2.hpp:5857:63: warning: ignoring attributes on template argument âcl_int {aka int}â [-Wignored-attributes]
     typename std::enable_if<!std::is_pointer<T>::value, cl_int>::type
                                                               ^
./CL/cl2.hpp:6157:22: warning: ignoring attributes on template argument âcl_int {aka int}â [-Wignored-attributes]
         vector<cl_int>* binaryStatus = NULL,
                      ^
g++ -I/usr/include/openblas -I. -Wall -Wextra -pipe -O3 -g -ffast-math -flto -march=native -std=c++14 -DNDEBUG -MD -MP -c -o OpenCLScheduler.o OpenCLScheduler.cpp
In file included from OpenCL.h:27:0,
                 from OpenCLScheduler.h:26,
                 from OpenCLScheduler.cpp:23:
./CL/cl2.hpp:1831:5: warning: type qualifiers ignored on function return type [-Wignored-qualifiers]
     const cl_type get() const { return object_; }
     ^~~~~
In file included from OpenCL.h:27:0,
                 from OpenCLScheduler.h:26,
                 from OpenCLScheduler.cpp:23:
./CL/cl2.hpp:5857:63: warning: ignoring attributes on template argument âcl_int {aka int}â [-Wignored-attributes]
     typename std::enable_if<!std::is_pointer<T>::value, cl_int>::type
                                                               ^
./CL/cl2.hpp:6157:22: warning: ignoring attributes on template argument âcl_int {aka int}â [-Wignored-attributes]
         vector<cl_int>* binaryStatus = NULL,
                      ^

g++ -I/usr/include/openblas -I. -Wall -Wextra -pipe -O3 -g -ffast-math -flto -march=native -std=c++14 -DNDEBUG -MD -MP -c -o Tuner.o Tuner.cpp
In file included from OpenCL.h:27:0,
                 from Tuner.cpp:33:
./CL/cl2.hpp:1831:5: warning: type qualifiers ignored on function return type [-Wignored-qualifiers]
     const cl_type get() const { return object_; }
     ^~~~~
In file included from OpenCL.h:27:0,
                 from Tuner.cpp:33:
./CL/cl2.hpp:5857:63: warning: ignoring attributes on template argument âcl_int {aka int}â [-Wignored-attributes]
     typename std::enable_if<!std::is_pointer<T>::value, cl_int>::type
                                                               ^
./CL/cl2.hpp:6157:22: warning: ignoring attributes on template argument âcl_int {aka int}â [-Wignored-attributes]
         vector<cl_int>* binaryStatus = NULL,
                      ^

Test matrix

We support a lot of configuration options (probably too many), compilers, OpenCL versions etc with these bindings; definitely too many to test all combinations exhaustively. The testing we have currently is however pretty weak. The purpose of this issue is to gather feedback on the configurations that we do need to test to try and find a sweet spot. Here's a list of the variables with values we may want to test:

Compilers:

• GCC
• Clang
• MSVC

OpenCL versions:

• OpenCL 1.0
• OpenCL 1.1
• OpenCL 1.2
• OpenCL 2.0
• OpenCL 2.1
• OpenCL 2.2

Operating systems:

• Linux
• Windows
• MacOS

Configuration options:

• CL_HPP_ENABLE_EXCEPTIONS
• More?

C++ versions:

• C++ 11
• C++ 14
• C++ 17
• C++ 20

Anything to add/remove?

cl2.hpp throwing errors when compiling project on Linux

I'm trying to compile my project that's using cl2.hpp on Linux (Ubuntu 16.04), it throws a lot of errors.

Here are some of them:

cl2.hpp:6606:5: error: expected identifier before numeric constant
     None = 0,

cl2.hpp:6606:5: error: expected ‘}’ before numeric constant

cl2.hpp:6611:8: error: ‘QueueProperties’ does not name a type; did you mean ‘XSetWMProperties’?
 inline QueueProperties operator|(QueueProperties lhs, QueueProperties rhs)

cl2.hpp:8230:51: error: invalid use of incomplete type ‘class CommandQueue’
 CL_HPP_DEFINE_STATIC_MEMBER_ cl_int CommandQueue::default_error_ = CL_SUCCESS;

cl2.hpp:9366:54: error: ‘NDRange’ has not been declared
     EnqueueArgs(CommandQueue &queue, NDRange offset, NDRange global, NDRange local)

Please add specialization cl::Program::build(cl::Device&)

It is possible to create cl::Context using cl::Device instead of std::vector<cl::Device>, so it would be nice to use cl::Program::build in the same way.

BTW, this special constructor of cl::Context is not documented in opencl-cplusplus-1.2.pdf, please add it there.

Add support for creating a cl::CommandQueue with arbitrary properties

Only properties defined using CL_QUEUE_PROPERTIES are currently supported. Arbitrary queue properties such as the ones added by vendor extensions aren't supported.

undefined behaviour in tests/test_cl2hpp.cpp

The clGetKernelSubGroupInfo_testSubGroups in tests/test_cl2hpp.cpp is defined with a return type of cl_int, but does not return any value which is an undefined behaviour. It should either be declared void or return some value.

Errors with cl2.hpp

Hi,

Using cl2.hpp results to compile error. The system is Ubuntu 16.04 and has following related packages (nvidia-384, nvidia-opencl-dev, nvidia-opencl-icd-384). What could be wrong?

/tmp/ccG4wJ8n.o: In function cl::detail::ReferenceHandler<_cl_device_id*>::release(_cl_device_id*)': dummy.cpp:(.text._ZN2cl6detail16ReferenceHandlerIP13_cl_device_idE7releaseES3_[_ZN2cl6detail16ReferenceHandlerIP13_cl_device_idE7releaseES3_]+0x14): undefined reference to clReleaseDevice'
/tmp/ccG4wJ8n.o: In function cl::detail::ReferenceHandler<_cl_context*>::release(_cl_context*)': dummy.cpp:(.text._ZN2cl6detail16ReferenceHandlerIP11_cl_contextE7releaseES3_[_ZN2cl6detail16ReferenceHandlerIP11_cl_contextE7releaseES3_]+0x14): undefined reference to clReleaseContext'
/tmp/ccG4wJ8n.o: In function cl::detail::ReferenceHandler<_cl_command_queue*>::release(_cl_command_queue*)': dummy.cpp:(.text._ZN2cl6detail16ReferenceHandlerIP17_cl_command_queueE7releaseES3_[_ZN2cl6detail16ReferenceHandlerIP17_cl_command_queueE7releaseES3_]+0x14): undefined reference to clReleaseCommandQueue'
collect2: error: ld returned 1 exit status

--- compile command --
g++ -std=c++17 -lOpenCL dummy.cpp -o dummy

--- dummy.cpp --
#define CL_HPP_ENABLE_EXCEPTIONS
#define CL_HPP_TARGET_OPENCL_VERSION 200

#include "cl2.hpp"

int main(int argc, char** argv)
{
return 0;
}

cl2.hpp/cl.hpp does not work for OpenCL 1.1

So according to the cl2.hpp

C++ bindings for OpenCL 1.0 (rev 48), OpenCL 1.1 (rev 33), OpenCL 1.2 (rev 15) and OpenCL 2.0 (rev 29)

However when I tried targeting my project for openCL 1.1 using these defines

#define CL_MINIMUM_OPENCL_VERSION 110
#define CL_HPP_MINIMUM_OPENCL_VERSION 110
#define CL_HPP_TARGET_OPENCL_VERSION 110
#define CL_TARGET_OPENCL_VERSION 110

It throws a bunch of errors shown below. The errors remain the same if i use cl.hpp

The project compiles fine if I change the last two defines to 1.2.0 or greater. I have tried both, using the precompiled release version which gives cl2.hpp and compiling the cl2.hpp myself using cmake.

Any help would be appreciated.

Additional Information.
OS: Win 7 64-bit
IDE: Codeblocks
Compiler : Mingw-w64 gcc 8.1.0 (32- bit version) Have also tried (mingw32 gcc 6.3.0)
GPU: Radeon hd 7950 (OpenCL 2.0 supported)

Parallel builds are broken

See #74

static cl::Platform::get() is masking cl::detail::Wrapper<cl_platform_id>::get()

Incorrect description "Constructor from cl_mem" in cl2.hpp

The description "Constructor from cl_mem" seems to be incorrect at line 6531 and line 7427 - or at least I don't see what those constructors have to do with cl_mem... 😀

update README regarding cl2.hpp

After #68 there is no more input_cl2.hpp. Need to update the README accordingly.

Merge changes from master into opencl21 branch

There have been a lot of fixes in master that deal with compilation errors. These have not been merged into opencl21 branch yet.

Would it be possible to perform a merge from master into opencl21?

CMake Error at tests/CMakeLists.txt:79 (add_executable):

How to fix this issue?

-- Configuring done
CMake Error at tests/CMakeLists.txt:79 (add_executable):
  Cannot find source file:

    /home/linaro/Downloads/OpenCL-CLHPP-master/external/CMock/src/cmock.c

  Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
  .hxx .in .txx


CMake Error: CMake can not determine linker language for target: test_clhpp_deprecated_1_2
CMake Error: Cannot determine link language for target "test_clhpp_deprecated_1_2".
CMake Error: CMake can not determine linker language for target: test_cl2hpp
CMake Error: Cannot determine link language for target "test_cl2hpp".
CMake Error: CMake can not determine linker language for target: test_clhpp
CMake Error: Cannot determine link language for target "test_clhpp".
CMake Error: CMake can not determine linker language for target: test_clhpp_cxx11
CMake Error: Cannot determine link language for target "test_clhpp_cxx11".
CMake Error: CMake can not determine linker language for target: test_clhpp_deprecated_1_1
CMake Error: Cannot determine link language for target "test_clhpp_deprecated_1_1".
-- Generating done

SubBuffers & RefCounts of cl_mem

Good evening,

I think that I've found a bug in your cl.hpp files (possibly cl2.hpp as well, I haven't checked.)

The issue is that when creating a SubBuffer of an ordinary Buffer, you call clCreateSubBuffer and store the resulting cl_mem in a Buffer object. When this Buffer goes out of scope, it calls clReleaseMemObject on its wrapped cl_men object. Since you didn't retain the cl_mem object when you created the SubBuffer, this means that the ref count of the cl_mem is one too low.

Consider this:

cl::Buffer buf = cl::Buffer(context,CL_MEM_READ_WRITE,sizeof(int)*100);
cl::Buffer subbuf = buf.createSubBuffer(CL_MEM_READ_WRITE,CL_BUFFER_CREATE_TYPE_REGION, &region); // region needs to exists
/* as soon as subbuf goes out of scope this invalidates buf! */

Solution: call buffer.retain() in createSubBuffer wrapper.

Remark: I don't even know if you're supposed to retain/release sub buffer objects in opencl. I couldn't find any specification about this as well.

default_initialized_ declared weak after being used

Got a few of these errors with gcc -fsanitize=undefined.
Removing "attribute((weak))" gets it to compile.

Device to host cl::copy in cl2.hpp is not MSVC checked iterator friendly

Currently, only the host to device cl::copy is MSVC checked iterator friendly. Please add the same addition to Device to host as well.

Not able to use the cl2 header with the Intel FPGA SVM implementation

The Intel FPGA OpenCL implementation is based on the 1.1 standard but also supports SVM as a non-standard extension. It would be great to be able to use the SVM capabilities of Intel FPGAs while coding against this modern C++ API. This is currently not possible because there is no macro to enable SVM if the target OpenCL version is set below 2.0. Would you consider adding such a macro (e.g. something like CL_HPP_ENABLE_SVM that would allow the user to selectively enable SVM for targets like Intel FPGAs?

I would be willing to send in a pull request with the required changes...

Add Test for Platform with Zero Devices

PR #85 adds better handling for a platform with zero devices. We should add a test case for this, also.

How to get CL_KERNEL_GLOBAL_WORK_SIZE values?

I want to query the maximum global size that can be used to execute a kernel.
I do this
cl::array<size_t, 3> kernel_global_work_size = my_kernel.getWorkGroupInfo<CL_KERNEL_GLOBAL_WORK_SIZE>(my_device);

But I got error

cl2.hpp:5771:12: note: candidate: template<class T> cl_int cl::Kernel::getWorkGroupInfo(const cl::Device&, cl_kernel_work_group_info, T*) const
     cl_int getWorkGroupInfo(
            ^~~~~~~~~~~~~~~~
cl2.hpp:5771:12: note:   template argument deduction/substitution failed:
cl2.hpp:5782:9: note: candidate: template<int name> typename cl::detail::param_traits<cl::detail::cl_kernel_work_group_info, name>::param_type cl::Kernel::getWorkGroupInfo(const cl::Device&, cl_int*) const
         getWorkGroupInfo(const Device& device, cl_int* err = NULL) const

How can I get size_t[3] values ?

linking error with mingw

Macro CL_HPP_DEFINE_STATIC_MEMBER_ is defined as attribute((weak)) on linux, and as declspec(selectany) on windows. It is not work for mingw.

Invalid call to clGetKernelWorkGroupInfo?

When calling kernel.getWorkGroupInfo<CL_KERNEL_COMPILE_WORK_GROUP_SIZE>(device, &err), this will lead to https://github.com/KhronosGroup/OpenCL-CLHPP/blob/master/input_cl2.hpp#L1052:

// Specialized GetInfoHelper for clsize_t params
template <typename Func, size_type N>
inline cl_int getInfoHelper(Func f, cl_uint name, array<size_type, N>* param, long)
{
    size_type required;
    cl_int err = f(name, 0, NULL, &required);
    if (err != CL_SUCCESS) {
        return err;
    }

When I run this with the latest Intel OpenCL runtime for Core & Xeon (version 16.1.1) CPUs, the required variable will get 0 written to it, subsequently resulting in no values being written to the return array. Instead the return array is left uninitialized, which is clearly broken.

And actually, according to the spec, this is the correct behavior:

param_value_size_ret
Returns the actual size in bytes of data copied to param_value. If param_value_size_ret is NULL, it is ignored.

Note that it says "actual size in bytes of data copied to param_value", not "the actual size in bytes of data being queried by param_value" that is the case for e.g. clGetPlatformInfo.

Since it is known exactly how much space is needed statically, the simple fix seems to be removing the "required" check:

        // Specialized GetInfoHelper for clsize_t params
        template <typename Func, size_type N>
        inline cl_int getInfoHelper(Func f, cl_uint name, array<size_type, N>* param, long)
        {
            size_type required = N * sizeof(size_type);

            cl_int err = f(name, required, param->data(), NULL);
            if (err != CL_SUCCESS) {
                return err;
            }

            return CL_SUCCESS;
        }

If this is not acceptable, then a special case would be needed for clGetKernelWorkGroupInfo, and possibly others.

CL_HPP_MINIMUM/TARGET_OPENCL_VERSION is not forwarded

The OpenCL headers were switched to a unified build: KhronosGroup/OpenCL-Headers@de26592

Which now expects CL_TARGET_OPENCL_VERSION to be set.

If CL_HPP_TARGET_OPENCL_VERSION is set, then this is not forwarded to the above configuration variable, so the code will start to produce warnings which can only be fixed by defining both. That's a rather ugly kludge.

Add error code and description to what() string of exceptions

When building with CL_HPP_ENABLE_EXCEPTIONS enabled, exceptions are thrown when OpenCL calls fail. The string returned by the what() method of the exceptions tends to only contain the entrypoint name. Adding the error code in numeric and text form would be really useful.

VkCpp bindings?

Hello? Have you plan to create vulkan hpp bindings?
I very want C++ bindings for Vulkan API, not only OpenCL.
Please, make!

For opengl already have boosty oglplus (oglplu2).

cl::SVMAllocator::allocate() has a high change to fail when sizeof(T) is not a power of 2

amd app sdk no longer available

the amd app sdk doesn't appear to be available on the amd website. can you update your cmake example?

Warning C26439 when compiling in Visual Studio 2019

When using cl2.hpp in Visual Studio 2019 I'm getting a lot of C26439 IntelliSense Warnings ("This kind of function may not throw. Declare it 'noexcept'.").

The problem seems to be, that at Line 532 it is not detected, that nothrow is supported, because Visual Studio doesn't set __cplusplus to an up to date value by default. (Only if /Zc:__cplusplus comandline option is given.)

#if (__cplusplus >= 201103L)
#define CL_HPP_NOEXCEPT_ noexcept
#else
#define CL_HPP_NOEXCEPT_
#endif

Could Line 532 be changed to this?

#if (__cplusplus >= 201103L || _MSVC_LANG >= 201103L )

If _MSVC_LANG is not defined it will be evaluated as 0. (section 16.1 paragraph 4: "After all replacements due to macro expansion and the defined unary operator have been performed, all remaining identifiers and keywords, except for true and false, are replaced with the pp-number 0") If it is defined, than it's at least Visual Studio 2015 Update 3, which is AFAIK does support noexcept ("noexcept operator was introduced and is supported in Visual Studio 2015").

<Edit>
noexcept was added in the November 2013 CTP (customer technology preview) of the Visual C++ Compiler. Officially available starting in Visual Studio 2015 (see here)
</Edit>

This doesn't seem to remove all C26439 warnings but at least more than half of them.

<Edit2>
Note: Although exception specifications in Visual C++ are only completely standard conform if /std:c++17 is used, it is not necessary to test for _MSVC_LANG >= 201703L, because the behavior of noexcept is standard conform even without /std:c++17.
</Edit2>

OpenCL 2.2 support?

Build cl.hpp for releases, not just cl2.hpp

Could the release builds be extended to include generating the old cl.hpp as well? That would let me remove it from the OpenCL registry, where it's the only header file still stored there instead of in github.

Creating 2D image from buffer in OpenCL 1.2 implementations

Creating 2D images from buffer should be allowed when cl_khr_image2d_from_buffer is supported by a device.

Currently the image2d constructor is guarded by this #ifdef:

if CL_HPP_TARGET_OPENCL_VERSION >= 200

Error when compiling KernelFunctor::setArgs

When I compile a opencl program on Win10, VS2019, use

#define CL_HPP_ENABLE_EXCEPTIONS
#define CL_HPP_MINIMUM_OPENCL_VERSION 100
#define CL_HPP_TARGET_OPENCL_VERSION 120
#include <cl/cl2.hpp>
...
	cl::KernelFunctor<cl_uint4*> func {
		program, "main" 
	};

	cl_uint4 res;
	func(cl::EnqueueArgs(cl::NDRange(dims[0], dims[1], dims[2])), &res);

It gives me the following error：

1>C:\vcpkg\installed\x86-windows\include\cl\cl2.hpp(9457): error C2660: “cl::Kernel::setArg”: 函数不接受 2 个参数
1>C:\vcpkg\installed\x86-windows\include\cl\cl2.hpp(5867): note: 参见“cl::Kernel::setArg”的声明
1>C:\vcpkg\installed\x86-windows\include\cl\cl2.hpp(9488): note: 参见对正在编译的函数 模板 实例化“void cl::KernelFunctor<cl_uint4 *>::setArgs<0,_Ty>(T0 &&)”的引用
1>        with
1>        [
1>            _Ty=cl_uint4 *,
1>            T0=cl_uint4 *
1>        ]
1>C:\vcpkg\installed\x86-windows\include\cl\cl2.hpp(9490): note: 参见对正在编译的函数 模板 实例化“void cl::KernelFunctor<cl_uint4 *>::setArgs<0,_Ty>(T0 &&)”的引用
1>        with
1>        [
1>            _Ty=cl_uint4 *,
1>            T0=cl_uint4 *
1>        ]
1>C:\vcpkg\installed\x86-windows\include\cl\cl2.hpp(9488): note: 编译 类 模板 成员函数 "cl::Event cl::KernelFunctor<cl_uint4 *>::operator ()(const cl::EnqueueArgs &,cl_uint4 *)" 时
1>C:\Users\yangl\source\repos\ConsoleApplication1\ConsoleApplication1.cpp(100): note: 参见对正在编译的函数 模板 实例化“cl::Event cl::KernelFunctor<cl_uint4 *>::operator ()(const cl::EnqueueArgs &,cl_uint4 *)”的引用
1>C:\Users\yangl\source\repos\ConsoleApplication1\ConsoleApplication1.cpp(95): note: 参见对正在编译的 类 模板 实例化 "cl::KernelFunctor<cl_uint4 *>" 的引用

It seems that the function cl::Kernel::setArg cannot take 2 params when the template arg T is pointer, but KernelFunctor::setArgs just passed it with 2 of them.

Am I wrong when wroting my code? Any help will be appreciated.

Defect: includes cl::Kernel::getInfo() string contains an explicit NUL byte

For information where device or kernel info of type char[] are returned,
e.g. clGetKernelInfo(...,CL_KERNEL_FUNCTION_NAME,&size)
(tested on NVidia and Intel SDK's, not sure about AMD)
The size value returned includes the terminating byte for these SDKs. Consequently, when the cl.hpp helper function copies out the string data it ends up including the explicit NUL byte as part of the string (and it's size).

  // Specialized GetInfoHelper for STRING_CLASS params
  template <typename Func>
  inline cl_int getInfoHelper(Func f, cl_uint name, STRING_CLASS* param, long) {
    ...
    if (param) {
        param->assign(value.begin(), value.end()); // <<< COPIES NUL byte explicitly into std::string
    }
}

This leads to a fairly difficult debugging task since the following expression evaluates to false.
(k.getInfo<CL_KERNEL_FUNCTION_NAME>() == std::string("foo"))
And worse, some debuggers typically don't show the explicit null byte in the std::string.

The OpenCL spec is not terribly clear on whether the NUL byte should be included for (char[]) info types. I confirmed this behavior on Intel and NVidia's SDKs at least, but I am not sure what AMD and other do and hence I don't know what the "right" solution is, but I think the current approach adds a "sharp edge" to this otherwise wonderful C++ wrapper API.

g++-7: error: call of overloaded ‘setSVMPointersHelper(std::array<void*, 1>&, int* const&)’ is ambiguous

trivialCL2.cpp fails to compile with GCC >= 7. (Building with GCC <= 6 or Clang 4.0/5.0 works fine)

Originally reported here: https://bugs.debian.org/853474

Easily reproduced with git master, configured with:

cmake .. -DBUILD_TESTS=OFF -DCMAKE_C_COMPILER=gcc-7 -DCMAKE_CXX_COMPILER=g++-7

make -f examples/src/CMakeFiles/trivialCL2.dir/build.make examples/src/CMakeFiles/trivialCL2.dir/build
make[2]: Entering directory '/tmp/OpenCL-CLHPP/build'
[ 70%] Building CXX object examples/src/CMakeFiles/trivialCL2.dir/trivialCL2.cpp.o
cd /tmp/OpenCL-CLHPP/build/examples/src && /usr/bin/g++-7    -I/tmp/OpenCL-CLHPP/build/include -I/tmp/OpenCL-CLHPP/examples/src/Hello/include  -Wall -std=c++0x   -o CMakeFiles/trivialCL2.dir/trivialCL2.cpp.o -c /tmp/OpenCL-CLHPP/examples/src/trivialCL2.cpp
In file included from /tmp/OpenCL-CLHPP/examples/src/trivialCL2.cpp:6:0:
/tmp/OpenCL-CLHPP/build/include/CL/cl2.hpp:5845:62: warning: ignoring attributes on template argument ‘cl_int {aka int}’ [-Wignored-attributes]
     typename std::enable_if<std::is_pointer<T>::value, cl_int>::type
                                                              ^
/tmp/OpenCL-CLHPP/build/include/CL/cl2.hpp:5857:63: warning: ignoring attributes on template argument ‘cl_int {aka int}’ [-Wignored-attributes]
     typename std::enable_if<!std::is_pointer<T>::value, cl_int>::type
                                                               ^
/tmp/OpenCL-CLHPP/build/include/CL/cl2.hpp:6157:22: warning: ignoring attributes on template argument ‘cl_int {aka int}’ [-Wignored-attributes]
         vector<cl_int>* binaryStatus = NULL,
                      ^
/tmp/OpenCL-CLHPP/examples/src/trivialCL2.cpp: In function ‘int main()’:
/tmp/OpenCL-CLHPP/examples/src/trivialCL2.cpp:239:18: warning: unused variable ‘clD’ [-Wunused-variable]
     cl_device_id clD = d();
                  ^~~
/tmp/OpenCL-CLHPP/examples/src/trivialCL2.cpp:240:18: warning: unused variable ‘clD2’ [-Wunused-variable]
     cl_device_id clD2 = d.get();
                  ^~~~
In file included from /tmp/OpenCL-CLHPP/examples/src/trivialCL2.cpp:6:0:
/tmp/OpenCL-CLHPP/build/include/CL/cl2.hpp: In instantiation of ‘cl_int cl::Kernel::setSVMPointers(const T0&, Ts ...) [with T0 = int*; Ts = {}; cl_int = int]’:
/tmp/OpenCL-CLHPP/build/include/CL/cl2.hpp:9538:48:   required from ‘cl_int cl::KernelFunctor<Ts>::setSVMPointers(const T0&, T1s ...) [with T0 = int*; T1s = {}; Ts = {std::unique_ptr<main()::Foo, cl::detail::Deleter<cl::SVMAllocator<main()::Foo, cl::SVMTraitCoarse<cl::SVMTraitReadOnly<cl::detail::SVMTraitNull> > > > >&, int*, std::vector<int, cl::SVMAllocator<int, cl::SVMTraitCoarse<cl::SVMTraitReadWrite<cl::detail::SVMTraitNull> > > >&, cl::Buffer, std::vector<int, cl::SVMAllocator<int, cl::SVMTraitCoarse<cl::SVMTraitReadWrite<cl::detail::SVMTraitNull> > > >&, int, cl::Pipe&, cl::DeviceCommandQueue}; cl_int = int]’
/tmp/OpenCL-CLHPP/examples/src/trivialCL2.cpp:198:50:   required from here
/tmp/OpenCL-CLHPP/build/include/CL/cl2.hpp:5963:51: error: call of overloaded ‘setSVMPointersHelper(std::array<void*, 1>&, int* const&)’ is ambiguous
         setSVMPointersHelper<0, 1 + sizeof...(Ts)>(pointerList, t0, ts...);
         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
/tmp/OpenCL-CLHPP/build/include/CL/cl2.hpp:5939:5: note: candidate: typename std::enable_if<std::is_pointer<T0>::value, void>::type cl::Kernel::setSVMPointersHelper(std::array<void*, ArrayLength>&, T0, Ts ...) [with int index = 0; int ArrayLength = 1; T0 = int*; Ts = {}; typename std::enable_if<std::is_pointer<T0>::value, void>::type = void]
     setSVMPointersHelper(std::array<void*, ArrayLength> &pointerList, T0 t0, Ts... ts)
     ^~~~~~~~~~~~~~~~~~~~
/tmp/OpenCL-CLHPP/build/include/CL/cl2.hpp:5953:5: note: candidate: typename std::enable_if<std::is_pointer<T0>::value, void>::type cl::Kernel::setSVMPointersHelper(std::array<void*, ArrayLength>&, T0) [with int index = 0; int ArrayLength = 1; T0 = int*; typename std::enable_if<std::is_pointer<T0>::value, void>::type = void]
     setSVMPointersHelper(std::array<void*, ArrayLength> &pointerList, T0 t0)
     ^~~~~~~~~~~~~~~~~~~~
/tmp/OpenCL-CLHPP/build/include/CL/cl2.hpp: In instantiation of ‘cl_int cl::Kernel::setSVMPointers(const T0&, Ts ...) [with T0 = std::unique_ptr<int, cl::detail::Deleter<cl::SVMAllocator<int, cl::SVMTraitCoarse<> > > >; Ts = {}; cl_int = int]’:
/tmp/OpenCL-CLHPP/build/include/CL/cl2.hpp:9538:48:   required from ‘cl_int cl::KernelFunctor<Ts>::setSVMPointers(const T0&, T1s ...) [with T0 = std::unique_ptr<int, cl::detail::Deleter<cl::SVMAllocator<int, cl::SVMTraitCoarse<> > > >; T1s = {}; Ts = {std::unique_ptr<main()::Foo, cl::detail::Deleter<cl::SVMAllocator<main()::Foo, cl::SVMTraitCoarse<cl::SVMTraitReadOnly<cl::detail::SVMTraitNull> > > > >&, int*, std::vector<int, cl::SVMAllocator<int, cl::SVMTraitCoarse<cl::SVMTraitReadWrite<cl::detail::SVMTraitNull> > > >&, cl::Buffer, std::vector<int, cl::SVMAllocator<int, cl::SVMTraitCoarse<cl::SVMTraitReadWrite<cl::detail::SVMTraitNull> > > >&, int, cl::Pipe&, cl::DeviceCommandQueue}; cl_int = int]’
/tmp/OpenCL-CLHPP/examples/src/trivialCL2.cpp:199:44:   required from here
/tmp/OpenCL-CLHPP/build/include/CL/cl2.hpp:5963:51: error: call of overloaded ‘setSVMPointersHelper(std::array<void*, 1>&, const std::unique_ptr<int, cl::detail::Deleter<cl::SVMAllocator<int, cl::SVMTraitCoarse<> > > >&)’ is ambiguous
         setSVMPointersHelper<0, 1 + sizeof...(Ts)>(pointerList, t0, ts...);
         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
/tmp/OpenCL-CLHPP/build/include/CL/cl2.hpp:5931:10: note: candidate: void cl::Kernel::setSVMPointersHelper(std::array<void*, ArrayLength>&, cl::pointer<T0, D>&, Ts ...) [with int index = 0; int ArrayLength = 1; D = cl::detail::Deleter<cl::SVMAllocator<int, cl::SVMTraitCoarse<> > >; T0 = int; Ts = {}; cl::pointer<T0, D> = std::unique_ptr<int, cl::detail::Deleter<cl::SVMAllocator<int, cl::SVMTraitCoarse<> > > >]
     void setSVMPointersHelper(std::array<void*, ArrayLength> &pointerList, const pointer<T0, D> &t0, Ts... ts)
          ^~~~~~~~~~~~~~~~~~~~
/tmp/OpenCL-CLHPP/build/include/CL/cl2.hpp:5946:10: note: candidate: void cl::Kernel::setSVMPointersHelper(std::array<void*, ArrayLength>&, cl::pointer<T0, D>&) [with int index = 0; int ArrayLength = 1; T0 = int; D = cl::detail::Deleter<cl::SVMAllocator<int, cl::SVMTraitCoarse<> > >; cl::pointer<T0, D> = std::unique_ptr<int, cl::detail::Deleter<cl::SVMAllocator<int, cl::SVMTraitCoarse<> > > >]
     void setSVMPointersHelper(std::array<void*, ArrayLength> &pointerList, const pointer<T0, D> &t0)
          ^~~~~~~~~~~~~~~~~~~~
examples/src/CMakeFiles/trivialCL2.dir/build.make:62: recipe for target 'examples/src/CMakeFiles/trivialCL2.dir/trivialCL2.cpp.o' failed
make[2]: *** [examples/src/CMakeFiles/trivialCL2.dir/trivialCL2.cpp.o] Error 1
make[2]: Leaving directory '/tmp/OpenCL-CLHPP/build'
CMakeFiles/Makefile2:327: recipe for target 'examples/src/CMakeFiles/trivialCL2.dir/all' failed

Automatically build and publish the Doxygen documentation

Add continuous integration

• Run the header generation script
• Build the tests
• Run the tests
• Anything else?

const cl_type get() type qualifiers warning

When compiling with this parameters -Wall -Wextra -std=c++11 -O2 -Os -s -DNDEBUG, I got

cl2.hpp:1829:5: warning: type qualifiers ignored on function return type [-Wignored-qualifiers]
const cl_type get() const { return object_; }

License?

Is it possible to indicate licensing in readme? Assume some open source license since there are forks and variations, eg. https://github.com/9prady9/OpenCL-CLHPP.git

Kernel Functor not compiling?

A basic example like this does not seem to compile. Why is this the case?

cl::Buffer buffer; // assume to be allocated
cl::KernelFunctor<cl::Buffer> kf = cl::KernelFunctor<cl::Buffer>(resizeAndMergeKernel);
kf.setArgs(buffer);

error: no matching function for call to ‘cl::KernelFunctor<cl::Buffer>::setArgs(cl::Buffer&)’
                             kf.setArgs(buffer);

cl2.hpp with OSX?

Has anyone been able to compile cl2.hpp with OSX? Is it even supported?

I get a ton of errors as such:

/Users/user/op/openpose/include/openpose/gpu/cl2.hpp:1321:1: error: use of undeclared identifier 'CL_DEVICE_QUEUE_ON_HOST_PROPERTIES'
CL_HPP_PARAM_NAME_INFO_2_0_(CL_HPP_DECLARE_PARAM_TRAITS_)
^
/Users/user/op/openpose/include/openpose/gpu/cl2.hpp:1275:23: note: expanded from macro 'CL_HPP_PARAM_NAME_INFO_2_0_'
    F(cl_device_info, CL_DEVICE_QUEUE_ON_HOST_PROPERTIES, cl_command_queue_properties) \
                      ^
/Users/user/op/openpose/include/openpose/gpu/cl2.hpp:1307:36: note: expanded from macro 'CL_HPP_DECLARE_PARAM_TRAITS_'
struct param_traits<detail:: token,param_name>       \
                                   ^
/Users/user/op/openpose/include/openpose/gpu/cl2.hpp:1321:1: error: use of undeclared identifier 'CL_DEVICE_QUEUE_ON_DEVICE_PROPERTIES'
/Users/user/op/openpose/include/openpose/gpu/cl2.hpp:1276:23: note: expanded from macro 'CL_HPP_PARAM_NAME_INFO_2_0_'
    F(cl_device_info, CL_DEVICE_QUEUE_ON_DEVICE_PROPERTIES, cl_command_queue_properties) \
                      ^
/Users/user/op/openpose/include/openpose/gpu/cl2.hpp:1307:36: note: expanded from macro 'CL_HPP_DECLARE_PARAM_TRAITS_'
struct param_traits<detail:: token,param_name>       \

I then changed the flags to version 120, and now I get

In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/mutex:177:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/functional:477:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:598:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/utility:253:9: error: field has incomplete type 'cl::Device'
    _T1 first;
        ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/type_traits:2023:27: note: in instantiation of template class
      'std::__1::pair<cl::Device, std::__1::basic_string<char> >' requested here
                 decltype(__is_constructible_test(declval<_Tp>(), declval<_Args>()...))

Segmentation fault executing header example

Hi, I'm trying to execute this program (https://raw.githubusercontent.com/KhronosGroup/OpenCL-CLHPP/master/examples/src/headerexampleCL2.cpp) using cl2.hpp (https://www.khronos.org/registry/cl/api/2.0/cl2.hpp)

Here is my compilation and execution commands.

g++ -v -g headerexampleCL2.cpp -I ../../Cpp_common -lOpenCL -std=c++11  -o HeaderExample
./HeaderExample 

The compilation is OK. but unfortunately i always got a segmentation fault.

[1]    12260 segmentation fault (core dumped)  ./HeaderExample

From dmesg i got:

[13484.039185] HeaderExample[12697]: segfault at 0 ip           (null) sp 00007ffe46e01b48 error 14 in HeaderExample[400000+1c000]

Here is my gcc verbose log: http://pastebin.com/pNJE8mjy
Here is my platform info:http://pastebin.com/xH5LN9YY

My AMD APP SDK Version is 3.0

Please let me know if I'm doing something wrong.

When SSE is enabled, the compilation fails with VS2015

When including cl.hpp, we have the following errors:

CL/cl.hpp(6044): error C2719: 'fillColor': formal parameter with requested alignment of 16 won't be aligned
CL/cl.hpp(6078): error C2719: 'fillColor': formal parameter with requested alignment of 16 won't be aligned

These, I think, are linked to the type cl_int4 which is a union that contains __cl_int4 v4; when __CL_INT4__ is defined, itself defined if __SSE2__ is defined.
I guess that __m128i variables must be aligned, which cannot be done in function parameters on VS.

The workaround that we use is to change the fillcolor parameter from a cl_int4 to a const cl_int4&. Then it compiles fine.

CMake Install Destination is Wrong

The line at https://github.com/KhronosGroup/OpenCL-CLHPP/blob/master/include/CMakeLists.txt#L18 should be DESTINATION include.

Currently, the CL directory is installed into the install prefix base, e.g., '/usr/local' instead of '/usr/local/include'.

No enqueueFreeSVM in CommandQueue?

just a quick question as clEnqueueSVMFree is available in 2.0 specs.