<html>
    <head>
      <base href="https://bugs.freedesktop.org/">
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - OpenCL/Clover: AMD Turks: corrupt output buffer (depending on dimension order?)"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=103586#c13">Comment # 13</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - OpenCL/Clover: AMD Turks: corrupt output buffer (depending on dimension order?)"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=103586">bug 103586</a>
              from <span class="vcard"><a class="email" href="mailto:vedran@miletic.net" title="Vedran Miletić <vedran@miletic.net>"> <span class="fn">Vedran Miletić</span></a>
</span></b>
        <pre>(In reply to Dave Gilbert from <a href="show_bug.cgi?id=103586#c6">comment #6</a>)
<span class="quote">> (In reply to Jan Vesely from <a href="show_bug.cgi?id=103586#c5">comment #5</a>)
> > (In reply to Dave Gilbert from <a href="show_bug.cgi?id=103586#c4">comment #4</a>)
> > > Created <span class=""><a href="attachment.cgi?id=135313" name="attach_135313" title="foo.link-0.ll">attachment 135313</a> <a href="attachment.cgi?id=135313&action=edit" title="foo.link-0.ll">[details]</a></span>
> > > foo.link-0.ll
> > > 
> > > That's all 3 of the debug files it produced.
> > > (I wasn't sure which were the llvm and which the isa dumps; I guess the asm
> > > is the isa? and the ll's are both llvm dumps?)
> > 
> > yes. the first .ll is from compilation step, the other one is from linking
> > step.
> > 
> > .ll dump looks correct.
> > .asm also looks correct.
> > 
> > you can try producing multiple asm dumps for working and non-working runs.
> > But I don't think that the llvm is the culprit here.
> > 
> > Can you try waiting for the kernel execution to complete explicitly before
> > mapping the buffer?
> > Ideally call clFinish() on line 63.

> Since I'm on the C++ binding (probably a mistake) I used:
>   queue.finish();

> and it seems to be working.

> (This also corresponds possibly to what I'm seeing on a more complex kernel;
> with a more complex kernel I'm seeing on a whole pile of data on the last
> few Z slices as being bogus suggesting it's not finished).

> Dave</span >

This reminds me of a certain issue I experienced with OpenMM. Is it limited to
Turks, or it happens on SI+ cards?</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the assignee for the bug.</li>
          <li>You are the QA Contact for the bug.</li>
      </ul>
    </body>
</html>