Boost logo

Boost :

Subject: Re: [boost] [compute] Review
From: Kyle Lutz (kyle.r.lutz_at_[hidden])
Date: 2014-12-30 23:28:11

On Tue, Dec 30, 2014 at 8:13 PM, John Bytheway
<jbytheway+boost_at_[hidden]> wrote:
> On 2014-12-30 21:46, Gruenke,Matt wrote:
>> -----Original Message----- From: Boost
>> [mailto:boost-bounces_at_[hidden]] On Behalf Of John Bytheway
>> Sent: Tuesday, December 30, 2014 21:23 To: boost_at_[hidden]
>> Subject: Re: [boost] [compute] Review
>>> On 2014-12-29 02:01, Kyle Lutz wrote:
>>>> Currently it will just buffer the entire range into a
>>>> std::vector<T> and then copy that to the device. If this is a
>>>> bottleneck it could also be improved to copy the data in smaller
>>>> batches. Let me know if you encounter issues with this.
>>> Does this also work with copy_async? I presume not, because there
>>> would be troubles with the lifetime of the temporary vector...
>> Async host <-> device copies only exist at the low level
>> (command_queue). They sidestep the issue by using raw pointers and
>> size.
> I dispute that. There's a copy_async to which you need not supply a
> command_queue. It seems high-level to me.
> <>
> Indeed, the following compiles:
> typedef uint64_t T;
> std::list<T> list = {0, 1, 2};
> compute::vector<T> device_vector(list.size());
> compute::copy_async(list.begin(), list.end(), device_vector.begin());
> but then fails at runtime because copy_async doesn't support
> non-contiguous iterators. This is bad. The condition inside copy_async
> is compile-time, so this assert could be a static_assert. I made an
> issue.

Thanks for reporting this, I'll get it fixed.


Boost list run by bdawes at, gregod at, cpdaniel at, john at