Re: [meta-intel] OpenCL stalls on Apollo Lake GPU

2017-01-24 Thread Wold, Saul

Sorry for the delay in getting back to you.


On Mon, 2017-01-16 at 12:27 +, Tony Whittam wrote:
> Hi everyone,
> 
> I don't know if this is too specialised for this list. I was directed
> to the Yocto Resources by Intel Premier Support. Anyway, no harm in
> asking the question :-)
> 
Right, it was a little more complex since the we generally work with
the core BSP, but we want to help just took trying to find the right
people.

> 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
> 
Have you looked at the Beignet (https://01.org/beignet)?

I am still tracking information down.

Sau!

> 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?
> Best regards,
> 
> Tony
> 
> 
> -- 
> Tony Whittam
> Rapt Touch
> 
> Confidentiality Notice: 
> 
> The information contained in this message, including any attachments
> hereto, may be confidential and is intended to be read only by the
> individual or entity to whom this message is addressed. If the reader
> of this message is not the intended recipient or an agent or designee
> of the intended recipient, please note that any review, use,
> disclosure or distribution of this message or its attachments, in any
> form, is strictly prohibited. If you have received this message in
> error, please immediately notify the sender and/or Rapt Touch Ltd via
> email at i...@rapttouch.com and delete or destroy any copy of this
> message and its attachments.
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel


[meta-intel] OpenCL stalls on Apollo Lake GPU

2017-01-16 Thread Tony Whittam
Hi everyone,

I don't know if this is too specialised for this list. I was directed to
the Yocto Resources by Intel Premier Support. Anyway, no harm in asking the
question :-)

*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

   1. what might be causing this?
   2. how to debug this on the Yocto platform?

Best regards,

Tony


-- 
Tony Whittam
Rapt Touch

-- 
Confidentiality Notice: 

The information contained in this message, including any attachments 
hereto, may be confidential and is intended to be read only by the 
individual or entity to whom this message is addressed. If the reader of 
this message is not the intended recipient or an agent or designee of the 
intended recipient, please note that any review, use, disclosure or 
distribution of this message or its attachments, in any form, is strictly 
prohibited. If you have received this message in error, please immediately 
notify the sender and/or Rapt Touch Ltd via email at i...@rapttouch.com and 
delete or destroy any copy of this message and its attachments.
-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel