OpenCL* for CPU
Ask questions and share information on Intel® SDK for OpenCL™ Applications and OpenCL™ implementations for Intel® CPU
Announcements
This forum covers OpenCL* for CPU only. OpenCL* for GPU questions can be asked in the GPU Compute Software forum. Intel® FPGA SDK for OpenCL™ questions can be ask in the FPGA Intel® High Level Design forum.
1663 Discussions

Linux: clCreateContext fails on embedded Linux device

Frédéric_K_
Beginner
242 Views

Hello everybody,

I'm in the process of evaluating the combination of the Intel Media SDK + OpenCL on Linux (using the latest Release of 'MediaServerStudioEssentials2015R6'). For my tests I'm using two Intel NUC5i3RYK. The first NUC is running CentOS 7.1 as described in the 'Intel Media Server Studio 2015 Getting Started Guide'. The second NUC is running a custom embedded Linux created using http://buildroot.uclibc.org/.

The good news:

The NUC running CentOS 7.1 works perfectly fine! I  can use all the Intel Media SDK examples, even those that integrate OpenCL via the plugin mechanism. And the OpenCL examples are running on the GPU rather than CPU, which is perfect!

The bad news:

Our custom embedded Linux is based on the requirements mentioned within the Getting Started Guide, i.e. we are using Kernel 3.14.5 and applied all patches from the Media Server Studio package. We are also using libva and libdrm from the Media Server Studio package. We have been using this setup for quite some time now, and the Intel Media SDK (used for Video Transcoding) is working fine!

But for some reason OpenCL won't work, more precisely calling the clCreateContext function fails with error code -5 (CL_OUT_OF_RESOURCES).

...

// Code from opencl_filter_va.cpp provided by the Media Samples
cl_context_properties props[] = { CL_CONTEXT_VA_API_DISPLAY_INTEL, (cl_context_properties) m_vaDisplay, CL_CONTEXT_INTEROP_USER_SYNC, 1, 0};
m_clcontext = clCreateContext(props, 1, &m_cldevice, NULL, NULL, &error);

...

From my point of view the only difference between CentOS and our Embedded Linux is the Kernel version (3.10.0-229.1.2.39163.MSSr4.el7.centos.x86_64 vs. 3.14.5). We are also not using i915 as a separate kernel module (i915.ko), but instead the module is built into the kernel. But this should not be the reason I guess.

I'm aware that our setup is no official Linux distribution supported by Intel, but perhaps anyone had the same issues I have right now? So I wanted to ask if anyone has ever succeeded in using the generic Kernel 3.14.5 + libva/libdrm sources from the Media Server Package to create a working setup? Or is there any way to get some debug messages out of the OpenCL implementation that might help me to find the reason why OpenCL ain't working?


Greetings from Germany,

Frédéric

 

0 Kudos
1 Solution
Robert_I_Intel
Employee
242 Views

Hi Frédéric,

Could you please do the following:

Please run:

Setup_inspector.py from the MSS package.

Then you can run:

strace -f -s 255 -o strace1.log your_sample 

and send us the log.

Some suggestions that our engineers proposed: upgrading to gcc > 4.7

Also, one comment that I saw on the internal discussion:

 the issue is due to the configuration of the kernel.   Working configuration should have the line “CONFIG_MMU_NOTIFIER=y” which is missing in Cheng’s config.

View solution in original post

2 Replies
Robert_I_Intel
Employee
243 Views

Hi Frédéric,

Could you please do the following:

Please run:

Setup_inspector.py from the MSS package.

Then you can run:

strace -f -s 255 -o strace1.log your_sample 

and send us the log.

Some suggestions that our engineers proposed: upgrading to gcc > 4.7

Also, one comment that I saw on the internal discussion:

 the issue is due to the configuration of the kernel.   Working configuration should have the line “CONFIG_MMU_NOTIFIER=y” which is missing in Cheng’s config.

Frédéric_K_
Beginner
242 Views

Hi Robert,

I modified the Kernel by setting CONFIG_MMU_NOTIFIER=y, and now everything is working as expected!!

Thank you so much for helping me on this! That issue was giving me quite some headache...

Reply