From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Whittam Subject: =?utf-8?q?=28no_subject=29?= Date: Mon, 16 Jan 2017 16:28:46 +0000 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0097433068==" Return-path: Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) by gabe.freedesktop.org (Postfix) with ESMTPS id 42AE789D1D for ; Mon, 16 Jan 2017 16:28:48 +0000 (UTC) Received: by mail-ua0-x231.google.com with SMTP id 96so84541697uaq.3 for ; Mon, 16 Jan 2017 08:28:48 -0800 (PST) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org --===============0097433068== Content-Type: multipart/alternative; boundary=001a113cf7848c5a83054638ad6f --001a113cf7848c5a83054638ad6f Content-Type: text/plain; charset=UTF-8 Hi everyone, I don't know if this is too specialised for this list. 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. In contrast, 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 problem running with the GPU? 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 info@rapttouch.com and delete or destroy any copy of this message and its attachments. --001a113cf7848c5a83054638ad6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi everyone,

I don&#= 39;t know if this is too specialised for this list. Anyway, no harm in aski= ng the question :-)

Preamble
Build: Yocto from the Apollo Lake BSP release=C2=A0gold,=C2=A0
Hardware: Oxbow Hill Rev B CRB with Intel= Atom E3950 and 4GB DDR3 RAM (one SODIMM)
Build: core-image-sato-sdk
Ins= talled on the onboard eMMC.
OpenCL= : installed user space drivers from SRB4=C2=A0https://software.intel.com/file/533571/download

I'm currently evaluating the Apollo Lake platform as a candidate to r= un our embedded application. We already have this application running on le= ss 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 applic= ation 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. Caps= Basic sees two devices: CPU and GPU and Bitonic sort can run its kernels co= rrectly on both the CPU and the GPU.=C2=A0

The issue
Simply put, the applica= tion has=C2=A0
  • thread 1 (feede= r): has a loop that feeds data into OpenCL and queues kernels
  • thread 2 (consumer): waits for results and reads outp= ut data.=C2=A0
  • an OpenCL Host command qu= eue with out-of-order execution enabled
When I run my app and sele= ct the GPU OpenCL device, the feeder thread=C2=A0stalls inside a=C2=A0bl= ocking call to clEnqueueMapBuffer().=C2=A0At this point only one thing = has been queued on the command queue: a buffer unmap command for a differen= t buffer. This unmap is waiting for an OpenCL event that will indicate data= ready to be processed.

In contrast, 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 problem running with the GPU?
  2. how to debug this on the Yocto platform?
Best regards,

Tony
<= div>
--
Tony W= hittam
Rapt Touch

Confidentiality Notice:=C2=A0

The information contained in this message, including any at= tachments hereto, may be confidential and is intended to be read only by th= e 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 i= ntended recipient, please note that any review, use, disclosure or distribu= tion of this message or its attachments, in any form, is strictly prohibite= d. If you have received this message in error, please immediately notify th= e sender and/or Rapt Touch Ltd via email at=C2=A0info@ra= pttouch.com=C2=A0and delete or dest= roy any copy of this message and its attachments. --001a113cf7848c5a83054638ad6f-- --===============0097433068== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4 IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4Cg== --===============0097433068==--