Hi Jan, all,
I've changed the default for all is_blocking= keyword arguments from
False to True. This was suggested by Jan (see below). It turns out that
defaulting to a asynchronous transfer is not what most people (including
myself!) expect, and it can lead to crashes/odd results that are hard to
debug. I've therefore made this change in current git, and I'll stick
this into a release soon, likely in January. As Jan points out, this
doesn't technically break code, it may just lead to performance
decreases that are easy to fix in a backward-compatible way, which seems
If your code relies on the non-blocking default, check it to avoid the
slow-down caused by the changed default.
Also, if you strongly disagree with this change, speak up now.
On Wed, 15 Dec 2010 11:58:35 +0100, "Jan H. Meinke"
Thanks for your answer.
On 11/23/10 01:22, Andreas Kloeckner wrote:
> I'm wondering whether we should default cl.enqueue_write_buffer's
> is_blocking to True, which would eliminate this whole class of
> problems. FWIW, I've been bitten by this same issue. Opinions? Ideas on
> how to do this without breaking API? (Rename e_w_b?)
I think the most elegant way would be to make cl.enqueue_write_buffer
increase the reference count to the buffer used until the transfer has
been completed. I assume, however, the transfer is handled by the OpenCL
runtime and not PyOpenCL making this difficult if not impossible without
a fairly large overhead.
Agreed, on both counts. However, in addition to not freeing the buffer,
the user also has to make sure it's not overwritten before the transfer
completes. So, short of copying, we can't take all responsibility for
correct asynch code away from the user.
While defaulting is_blocking to True is a change in the API, it
work for most people. It might impact performance since the transfers
aren't done in the background, but I don't see how it would break code.
I think it would be a good idea.
Again, agreed. I've made this change, see above.