"clCreateCommandQueue failed" error on OS X 10.11.5

[ericwa]

When I try to run the "App" target of the Xcode project, I get an exception thrown on CLWCommandQueue.cpp:37, and the message "clCreateCommandQueue failed" prints before exiting.

The status returned by clCreateCommandQueue is -33, CL_INVALID_DEVICE.

Here is the results of printing platform in ConfigManager::CreateConfigs:

(lldb) print platforms
(std::__1::vector<CLWPlatform, std::__1::allocator<CLWPlatform> >) $2 = size=1 {
  [0] = {
    ReferenceCounter<_cl_platform_id *, int (*)(_cl_platform_id *), int (*)(_cl_platform_id *)> = (object_ = 0x000000007fff0000)
    name_ = "Apple"
    profile_ = "FULL_PROFILE"
    version_ = "OpenCL 1.2 (Apr 26 2016 00:05:53)"
    vendor_ = "Apple"
    extensions_ = ""
    devices_ = size=2 {
      [0] = {
        ReferenceCounter<_cl_device_id *, cl_int (*)(_cl_device_id *), cl_int (*)(_cl_device_id *)> = (object_ = 0x0000000001024400)
        name_ = "HD Graphics 4000"
        vendor_ = "Intel"
        version_ = "OpenCL 1.2 "
        profile_ = "FULL_PROFILE"
        extensions_ = "cl_APPLE_SetMemObjectDestructor cl_APPLE_ContextLoggingFunctions cl_APPLE_clut cl_APPLE_query_kernel_names cl_APPLE_gl_sharing cl_khr_gl_event cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_image2d_from_buffer cl_khr_gl_depth_images cl_khr_depth_images cl_khr_3d_image_writes "
        type_ = 4
        localMemSize_ = 65536
        globalMemSize_ = 1610612736
        maxAllocSize_ = 402653184
        localMemType_ = 1
        maxWorkGroupSize_ = 512
        minAlignSize_ = 128
      }
      [1] = {
        ReferenceCounter<_cl_device_id *, cl_int (*)(_cl_device_id *), cl_int (*)(_cl_device_id *)> = (object_ = 0x0000000001022700)
        name_ = "GeForce GT 650M"
        vendor_ = "NVIDIA"
        version_ = "OpenCL 1.2 "
        profile_ = "FULL_PROFILE"
        extensions_ = "cl_APPLE_SetMemObjectDestructor cl_APPLE_ContextLoggingFunctions cl_APPLE_clut cl_APPLE_query_kernel_names cl_APPLE_gl_sharing cl_khr_gl_event cl_khr_byte_addressable_store cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_APPLE_fp64_basic_ops cl_khr_fp64 cl_khr_3d_image_writes cl_khr_depth_images cl_khr_gl_depth_images cl_khr_gl_msaa_sharing cl_khr_image2d_from_buffer cl_APPLE_ycbcr_422 cl_APPLE_rgb_422 "
        type_ = 4
        localMemSize_ = 49152
        globalMemSize_ = 1073741824
        maxAllocSize_ = 268435456
        localMemType_ = 1
        maxWorkGroupSize_ = 1024
        minAlignSize_ = 128
      }
    }
    type_ = 4
  }
}

Only device 0, "Intel HD Graphics 4000" is failing to create a command queue. If I adjust ConfigManager::CreateConfigs to start with device 1, the nvidia card, the command queue creation succeeds.

Maybe the CLWContext::Create calls in ConfigManager::CreateConfigs should be done in a try {} catch {} block so if an exception happens, the loop over devices just continues to try the next device?

[yozhijk]

Hi ericwa,

Does it behave differently if you disable GL interop by setting --interop 0 command line option?

[ericwa]

--interop 0 didn't have any effect, but with -interop 0 the command queue creation succeeds, but I get a different error. After waiting several seconds, the clBuildProgram in CLWProgram::CreateFromSource fails with CL_BUILD_PROGRAM_FAILURE and a build log "Compile Server Error."

This was with the "Intel HD Graphics" OpenCL device.

[yozhijk]

Can you try using --embed_kernels premake option? (You'll have to revert angle brackets back to use it I guess). That's most likely due to incorrect handling of includes in Apple CL compiler.

[ericwa]

btw, here is the workaround I am using at the moment to allow the non-working "Intel HD Graphics" device to be skipped:

diff --git a/App/config_manager.cpp b/App/config_manager.cpp
index 172fc1d..b2c1b9b 100644
--- a/App/config_manager.cpp
+++ b/App/config_manager.cpp
@@ -124,7 +124,17 @@ void ConfigManager::CreateConfigs(Mode mode, bool interop, std::vector<Config>&
                     (cl_context_properties)kCGLShareGroup, 0
                     };

-                    cfg.context = CLWContext::Create(platforms[i].GetDevice(d), props);
+                    try
+                    {
+                        cfg.context = CLWContext::Create(platforms[i].GetDevice(d), props);
+                    }
+                    catch (CLWException& e)
+                    {
+                        std::cout << "Error creating device "
+                            << platforms[i].GetDevice(d).GetName()
+                            << ": " << e.what() << std::endl;
+                        continue;
+                    }
                     devices.push_back(platforms[i].GetDevice(d));
                     cfg.devidx = 0;
                     cfg.type = kPrimary;

[trigeorgis]

I have the same issue as @ericwa when the device is intel 6000, but unfortunately his workaround did not work for nor the --embed_kernels premake option. When using his workaround I get

the following error in Debug mode:

tid = 0x332f82, 0x0000000100201caf     
libFireRays64D.dylib`FireRays::BvhStrategy::GpuData::~GpuData(this=0x000000010695fd50)
+ 175 at bvhstrategy.cpp:100,
queue = 'com.apple.main-thread',
stop reason = EXC_BAD_ACCESS (code=1, address=0x0)

[yozhijk]

Hi @trigeorgis,

This does not seem like a compiler bug @ericwa has experienced. Unfortunately I do not have Mac with Iris 6000 at hand. Can you tell me an exact model? I will try to find similar config and debug.

[trigeorgis]

Thanks a lot yozhijk! It's the 15'' MacBook Pro (Retina, Mid 2012) - the first retina macbook. Btw I meant to write Intel HD Graphics 4000, not 6000.

[yozhijk]

Hi @trigeorgis ,

I have just tested my latest code from depth-of-field branch on 13" MacBook (Early 2013, HD4000): https://github.com/GPUOpen-LibrariesAndSDKs/FireRays_SDK/commit/21cd14e364ac6d853cbbd882d1100312dd18767d

Everything worked right off the bat (even without --embed_kernels):

This makes me think this bug is specific for NV GPU config (13" does not have NV adapter). Do you think it would be possible for you to give me TeamViewer access to your machine to debug? (Should not take too long).

[trigeorgis]

Hi Dmitry,

Thanks for putting so much effort on this! I will test this out on the same commit asap. If I have the same issue I would be more than happy to allow you some remote access to the machine.

Thanks again!

On Fri, 8 Jul 2016 at 13:09 Dmitry Kozlov notifications@github.com wrote:

Hi @trigeorgis https://github.com/trigeorgis ,

I have just tested my latest code from depth-of-field branch on 13" MacBook (Early 2013, HD4000): 21cd14e https://github.com/GPUOpen-LibrariesAndSDKs/FireRays_SDK/commit/21cd14e364ac6d853cbbd882d1100312dd18767d

Everything worked right off the bat (even without --embed_kernels): [image: 1] https://cloud.githubusercontent.com/assets/4111901/16700014/b17404a4-4568-11e6-9f81-c117ea5c9d96.png [image: 2] https://cloud.githubusercontent.com/assets/4111901/16700018/b5f4d13e-4568-11e6-9589-28e848d79ff3.png

This makes me think this bug is specific for NV GPU config (13" does not have NV adapter). Do you think it would be possible for you to give me TeamViewer access to your machine to debug? (Should not take too long).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/GPUOpen-LibrariesAndSDKs/FireRays_SDK/issues/33#issuecomment-231459884, or mute the thread https://github.com/notifications/unsubscribe/AAWOodguEMRZJxdyDmDm1mJKPHOFlNt1ks5qTq57gaJpZM4IijTb .

[ericwa]

Hi, I think I have the same computer as @trigeorgis (original Retina MBP 15 inch, Mid 2012. Intel HD 4000 and Nvidia GT650M 1024MB GPUs).

I can reproduce the EXC_BAD_ACCESS in FireRays::BvhStrategy::GpuData::~GpuData.. this happens when the app can't find ../FireRays/src/kernel/CL/bvh.cl. As a workaround, setting the working directory to FireRays_SDK/App for the App target will fix that error. (this setting is in Xcode under "Product -> Scheme -> Edit Scheme -> Options -> Working Directory")

Contrary to my previous comment, adding the -interop 0 command line flag is now working for me as a workaround for the "clCreateCommandQueue failed" error, without the patch I posted earlier. The App runs successfully on my Intel HD 4000 gpu with that flag. This is on ca660eb0bc21d2ae48a4745053ed499c435a1b87 .

[trigeorgis]

Actually I just got it working as well by disabling GL interop with -interop 0 on the latest commit. I still get the same "clCreateCommandQueue failed" without it.

[trigeorgis]

An update: On the master branch I no longer get any segmentation faults and the programs fails safely by ignoring the opengl interop.

OpenGL interop is not supported, disabled, -interop flag is ignored.

Thanks Dmitry!

[yozhijk]

@trigeorgis, thanks to @dubik for fixing that;)