Intel OpenCL crash when used with optirun

[Vincent_Danjean]

On laptop with two graphics cards (Intel in processor + NVidia) where the Optimus technology is used, the Intel OpenCL ICD does not work when run with the 'optirun' program. The optirun program allows one to use the alternate (NVidia) graphic card. But, as Intel OpenCL ICD only use the processor for now, there is no reason why it cannot run, and, in any case, it should not crash. A code such as error = clGetPlatformInfo(platforms, CL_PLATFORM_EXTENSIONS, 0, NULL, &param_value_size_ret ); platform_vendor = (char *)malloc(param_value_size_ret); clGetPlatformInfo(platforms, CL_PLATFORM_EXTENSIONS, param_value_size_ret, platform_vendor, NULL ); printf("Extensions: %s\n",platform_vendor); free(platform_vendor); crashes when run with the Intel OpenCL plateform under optirun. It means that the Intel OpenCL ICD cannot be loaded at all by a ICD loader that respects Kronos specification (check that the ICD declare the cl_khr_icd extension) : the program will crash (segmentation fault) at initialisation time. Note that ICD loaders from Intel, AMD and NVidia does not respect this specification and load any ICD even if the cl_khr_icd extension is not declared (ocl-icd checks it but, due to this bug, the check can be disabled by using the envvar OCL_ICD_ASSUME_ICD_EXTENSION). Moreover, when run under optirun, Intel OpenCL clGetDeviceIDs function returns CL_DEVICE_NOT_FOUND. It probably means that something is not initialized correctly in the Intel ICD. Do not hesitate to point me to a better place for such bug reports. Regards, Vincent

[Raghupathi_M_Intel]

When you say optirun are you talking about the Bumblebee's command line utility? OpenCL for Linux is not support on Intel GPU. Thanks, Raghu

[Vincent_Danjean]

Yes, I'm talking about the Bumblebee's command line utility (that I installed from http://suwako.nomanga.net/debian/) And yes, I know that Intel OpenCL for Linux does not support Intel GPU. But OpenCL for Linux is not usable at all (for processors) when run through optirun. Moreover, as the Intel OpenCL ICD segfault when asking ICD extensions (ie calling "clGetPlatformInfo(intel_plateform, CL_PLATFORM_EXTENSIONS, ...)") under optirun, an ICD loader that follows the Kronos specifications (ie verifying that the ICD declares the cl_khr_icd extension) will segfault (while executing the Intel call) at initialization time. So, in this case, the presence of the Intel ICD will forbid any use of OpenCL under optirun (even if the OpenCL program want to use other ICDs). I do not have the sources of Intel OpenCL for Linux, but my guess is that, at initialization time, the Intel ICD try to look at GL stuff (presence, version, ... ?) and something goes wrong as it is NVidia GL libraries that are loaded instead of the classical ones. Or perhaps, the Intel ICD correctly detect a foreign GL library but does not handle correctly this error path... Regards, Vincent

[Raghupathi_M_Intel]

Sorry I can't be of much help here since I am not sure if we support Optimus technology or optirun. Have you tried posting on Bumblebee's or NVidia's forum? Thanks, Raghu

[Vincent_Danjean]

Digging more closely, the bug comes indeed from VirtualGL (used by bumblebee) that divert dlopen but breaks rpath and runpath when they are set to $ORIGIN. The result is that, when libintelocl.so tries to dlopen libaticaldd.so, libclang_compiler.so and libcpu_device.so, all these three dlopen return NULL. The bug can be workaround by setting LD_LIBRARY_PATH to the directory where libintelocl.so is installed. The bug is in VirtualGL and not Intel OpenCL ICD. But Intel OpenCL ICD might be interested into checking the results of its dlopen and put a useful error message (or declaring no plate-form at all) in case of an error with dlopen (NULL result) occurs. It would be better than the current behavior that seems to continue in a very unstable state. Regards, Vincent PS: here is the bug I just opened in VirtualGL: http://sourceforge.net/tracker/?func=detail&aid=3572525&group_id=117509&atid=678327