Summary
When I run my app and select the GPU OpenCL device, the feeder thread stalls inside a blocking call to clEnqueueMapBuffer().
Preamble
Build: Yocto from the Apollo Lake BSP release gold,
Hardware: Oxbow Hill Rev B CRB with Intel Atom E3950 and 4GB DDR3 RAM (one SODIMM)
Build: core-image-sato-sdk
Installed on the onboard eMMC.
OpenCL: installed user space drivers from SRB4 https://software.intel.com/file/533571/download
I'm currently evaluating the Apollo Lake platform as a candidate to run our embedded application. We already have this application running on less powerful ARM based Linux systems with Mali GPU using OpenCL 1.2. We're now evaluating the E3950 as a faster alternative. To evaluate the application I need OpenCL 1.2 or later.
To verify the OpenCL installation I have built and run the Intel demo apps: CapsBasic and Bitonic Sort. CapsBasic sees two devices: CPU and GPU and Bitonic sort can run its kernels correctly on both the CPU and the GPU.
The issue
Simply put, the application has
- thread 1 (feeder): has a loop that feeds data into OpenCL and queues kernels
- thread 2 (consumer): waits for results and reads output data.
- an OpenCL Host command queue with out-of-order execution enabled
When I run my app and select the GPU OpenCL device, the feeder thread stalls inside a blocking call to clEnqueueMapBuffer(). At this point only one thing has been queued on the command queue: a buffer unmap command for a different buffer. This unmap is waiting for an OpenCL event that will indicate data ready to be processed.
When I run my app and select the CPU OpenCL device, it works perfectly.
Does anyone have any ideas on
- what might be causing this?
- how to debug this on the Yocto platform?
I'm now working on a short reproducer that I can publish here.
Thanks,
Tony