You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #1 I touched upon the issue of how to present utilities from the SDK to the users.
The way I imagine the OpenCL SDK hosted by Khronos, is that it provides all the necessary files to compile an OpenCL application (the ICD loader and headers) as well as a utility library which applications could rely on to take care of some tedium in the API.
Consume via CMake
The way I imagined this was to extend the current CMake namespace with the SDK library. Applications consuming both sub-projects may do so via:
In #1 I touched upon the issue of how to present utilities from the SDK to the users.
The way I imagine the OpenCL SDK hosted by Khronos, is that it provides all the necessary files to compile an OpenCL application (the ICD loader and headers) as well as a utility library which applications could rely on to take care of some tedium in the API.
Consume via CMake
The way I imagined this was to extend the current CMake namespace with the SDK library. Applications consuming both sub-projects may do so via:
Utilities
Here is a short list of things I've grown to use in a few applications of mine.
profiling a la
std::chrono
implementation
Iterator-based entry point
This I would like to propose as well for
opencl.hpp
std::vector<cl::Platform> platforms(cl::util::Platform::begin(), cl::util::Platform::end());
implementation
Obtain executable path
implementation
The text was updated successfully, but these errors were encountered: