Are you referring to trying to build the library or using it ? If this is in regards to building, just because FireRays is a C++ library does not means that it has to use the OpenCL C++ bindings..there is also the C binding. If this is using the library then the whole purpose of the library its to shield users from the low level aspect of device selection, program setup, kernel dispatch and the other trimmings required in this example to use OpenCL. If you are still required to do all that work..why use FireRays at all ?
I'm referring to using the library, not building it.
I already have a healthy & productive C++/OpenCL project, and I'm using the OpenCL C++ wrapper from Khronos Group (cl.hpp) to shield me from low-level stuff, as you say. I have a cl::Context object, cl::Kernel objects and so on. What I can't find is a way to incorporate FireRays into this existing project, using the CL context and buffers I already have.
In order to use FireRays in this project, would I have to remove the existing wrappers, go back to OpenCL's raw C API, and then figure out how to use CLW instead, without documentation? Or would I have to give FireRays its own context etc. and sandbox it from the rest of the application?
Wouldn't it make more sense if FireRays had some awareness of the Khronos wrapper objects? For example, we have:
static IntersectionApiCL* CreateFromOpenClContext(cl_context context, cl_device_id device, cl_command_queue queue);
why not also:
static IntersectionApiCL* CreateFromOpenClContext(cl::Context& context, cl::Device& device, cl::CommandQueue& queue);
The Khronos wrappers are used liberally throughout the AMD APP SDK, after all.