4 Replies Latest reply on Sep 2, 2015 11:08 AM by chesik

    Why clCreateCommandQueueWithProperties needs CL_QUEUE_PROFILING_ENABLE explicitly set?

    doqtor

      CodeXL to profile queue created using clCreateCommandQueue does not need to be explicitly set to CL_QUEUE_PROFILING_ENABLE whereas the flag must be set for queue created using clCreateCommandQueueWithProperties.

       

      Is this a bug in CodeXL?

        • Re: Why clCreateCommandQueueWithProperties needs CL_QUEUE_PROFILING_ENABLE explicitly set?
          chesik

          Hi doqtor,

           

          Thanks for the report.  I've tried a few different scenarios with various combinations of properties passed to clCreateCommandQueueWithProperties, and in all cases, the profiler is able to add CL_QUEUE_PROFILING_ENABLE and profiling appears to work fine.

           

          Can you let me know what you are passing in the properties parameter of clCreateCommandQueueWithProperties when this fails?  Also, what incorrect behavior are you seeing when this is not explicitly set?

           

          Thanks,

          Chris

            • Re: Why clCreateCommandQueueWithProperties needs CL_QUEUE_PROFILING_ENABLE explicitly set?
              doqtor

              Hi Chris,

               

              cl_command_queue_properties is set to 0 and the error returned is CL_INVALID_QUEUE_PROPERTIES.

               

              Additional information in case is useful:

              I use GPU: Performance Counters profiling mode. It is remote profiling Ubuntu 14.04 VM to Ubuntu 14.04 server on Radeon R9 295.

              CodeXL Agent version is: 1.8.9654.0

              CodeXL GUI: CodeXL_1.8-9654

              fglrx 15.20.3

              AMD APP SDK 3.0

               

              Btw. I don't know if this can be somehow related but I cannot make Application Timeline Trace work after I upgraded from CodeXL 1.7.

                • Re: Why clCreateCommandQueueWithProperties needs CL_QUEUE_PROFILING_ENABLE explicitly set?
                  doqtor

                  To be more precise: I'm using Khronos C++ bindings: cl.hpp for OpenCL1.x and cl2.hpp for OpenCL2.0. Internally they set the queue properties a little bit differently though, maybe that is making a problem?

                   

                  cl.hpp:

                   

                  CommandQueue(

                          const Context& context,

                          const Device& device,

                          cl_command_queue_properties properties = 0,

                          cl_int* err = NULL)

                      {

                          cl_int error;

                          object_ = ::clCreateCommandQueue(

                              context(), device(), properties, &error);

                   

                     // ... error handling code here

                      }

                   

                  cl2.hpp:

                   

                  CommandQueue(

                          const Context& context,

                          const Device& device,

                          cl_command_queue_properties properties = 0,

                          cl_int* err = NULL)

                      {

                          cl_int error;

                  #if CL_HPP_TARGET_OPENCL_VERSION >= 200

                          cl_queue_properties queue_properties[] = {

                              CL_QUEUE_PROPERTIES, properties, 0 };

                          if ((properties & CL_QUEUE_ON_DEVICE) == 0) {

                              object_ = ::clCreateCommandQueueWithProperties(

                                  context(), device(), queue_properties, &error);

                          }

                          // ... error handling and code for CL_HPP_TARGET_OPENCL_VERSION  < 200 here

                   

                   

                  In both cases properties parameter is set to zero.

                  1 of 1 people found this helpful