<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="ZH-CN" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Hi,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"> Thanks for reporting this. It looks like a bug. The driver use wait_rendering on last_batch.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">But nobody is actually rendering into last_batch.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">We will fix that.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Zou Nanhai<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> beignet-bounces+nanhai.zou=intel.com@lists.freedesktop.org [mailto:beignet-bounces+nanhai.zou=intel.com@lists.freedesktop.org]
<b>On Behalf Of </b>Edward Ching<br>
<b>Sent:</b> Thursday, June 06, 2013 8:03 AM<br>
<b>To:</b> beignet@lists.freedesktop.org<br>
<b>Subject:</b> [Beignet] clEnqueueNDRangeKernel and kernel completion<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US">I hope this is the right forum to post comments/questions on Beignet OpenCL API behaviour. If not, please ignore and excuse the disruption.<o:p></o:p></span></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US">I'm running Beignet on an Ivy Bridge machine and noticed that clFinish would return before the GPU has complete processing of previously submitted commands.<br>
<br>
e.g: <br>
I submitted an OpenCL kernel via clEnqueueNDRangeKernel, followed by clFinish, and expected the GPU to have finished all processing when clFinish returns.<br>
<br>
But clFinish returned right away, and when I then call clEnqueueMapBuffer to access data, the call blocks, so I traced the logic all the way into the Ivy Bridge GPU device driver (~/drivers/gpu/drm/i915/*), and it looks like every IvyBr GPU batchbuffer used
to submit an OpenCL kernel has an associated sequence number which the GPU would write to a special location which has to be monitored in order to tell if the GPU has finished processing the submtted kernel (details in Intel HD graphics PRM and i915/GEM design
notes). Neither clFinish nor clEnqueueNDRangeKernel does this monitoring, and clEnqueueMapBuffer happened to do it when it tried to transfer the buffer objects from GPU to CPU domain.<o:p></o:p></span></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US">Does this make sense? It seems to me that clFinish should instead be monitoring and blocking if the GPU is still busy executing an OpenCL kernel.<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US">/Ed<o:p></o:p></span></p>
</div>
</div>
</body>
</html>