2 Replies Latest reply on Jun 20, 2016 11:49 PM by AlexMcLeod

    FireRays using cl.hpp (Khronos C++ wrapper)

    AlexMcLeod

      I'm trying to add FireRays to an existing project that uses cl.hpp (the OpenCL C++ wrapper from Khronos) to handle the CL context, queue, buffers and so on.

       

      I can't figure out how to get FireRays to recognise wrapper objects like cl::Context (which doesn't seem to provide access to its raw contents), which means I'm stuck at square one and unable to even initialise the API in my own projects.

       

      Given that FireRays is a C++ library, wouldn't it make sense for it to be compatible with the official C++ wapper for OpenCL? CLW appears to be doing the same job as cl.hpp, but not in a compatible way, and I can't find any documentation for CLW, either. I'm sure CLW is all very sensible, but I'm not going to strip the existing CL wrappers out of my project to replace them with the CLW versions in the absence of documentation.

       

      Come to think of it, what little documentation there is for FireRays (ie: FireRays.pdf) is no longer directly applicable to FireRays 2.0. For example:

      FireRays::IntersectionApi::GetIntersectionDeviceInfo() has become FireRays::IntersectionApi::GetDeviceInfo(). It's nicer to look at, sure, but the API is now completely without accurate documentation, and the example app is pretty short on comments.

       

      Could we get some up-to-date docs, please? And maybe some hints as to how we might incorporate FireRays into existing OpenCL applications?

        • Re: FireRays using cl.hpp (Khronos C++ wrapper)
          cgrant78@netzero.com

          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 ?

            • Re: FireRays using cl.hpp (Khronos C++ wrapper)
              AlexMcLeod

              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.