<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <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#c9">Comment # 9</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 <a class="email" href="mailto:freedesktop@treblig.org" title="Dave Gilbert <freedesktop@treblig.org>"> Dave Gilbert</a> <pre>(In reply to Jan Vesely from <a href="show_bug.cgi?id=103586#c8">comment #8</a>) > (In reply to Dave Gilbert from <a href="show_bug.cgi?id=103586#c6">comment #6</a>) > > (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 <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> > > > > 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 > > thanks for testing. I see you are using mesa 17.2. > > there were few changes to blocking call synchronization that went to mesa > 17.3: > 02f8ac6b70033a1b240d497c4664c359d2398cc3 (clover: Wrap event::wait_count in > a method taking care of the required locking.) > bc4000ee40c78efe1e5e8a6244d4bb55389d8418 (clover: Run the associated action > before an event is signalled.) > 3a5b69c09ba355c616c274b0c7f5aba3bd21fd54 (clover: Wait for requested > operation if blocking flag is set) > > which might help address the issue. Can you test mesa 17.3? Yeh, I'll figure out how to get 17.3 built on this box.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>