Re: [boost] [compute] Review period starts today December 15, 2014, ends on December 24, 2014

Subject: Re: [boost] [compute] Review period starts today December 15, 2014, ends on December 24, 2014
From: Gruenke,Matt (mgruenke_at_[hidden])
Date: 2014-12-27 06:49:41

Not a full review, but I just wanted to chime in on a couple points.

-----Original Message-----
From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Kyle Lutz
Sent: Saturday, December 20, 2014 3:33
To: Thomas M
Cc: boost_at_[hidden] List
Subject: Re: [boost] [compute] Review period starts today December 15, 2014, ends on December 24, 2014

> On Fri, Dec 19, 2014 at 1:07 PM, Thomas M <firespot71_at_[hidden]> wrote:

<snip>

> One particular issue that makes me hesitant is the lack of OpenCL 2.0 support in the "official" C++
> bindings.  The OpenCL 2.0 specification was released over a year ago (November 2013). The first public
> OpenCL 2.0 implementation was released by Intel three months ago (September 2014, followed closely by
> an AMD implementation). Boost.Compute had OpenCL 2.0 support implemented a week later. As of today
> (over a year since the specification was released), there is still no support for OpenCL 2.0 in the
> Khronos C++ OpenCL wrapper. I don't think it would be prudent to restrict Boost.Compute to a subset
> of the OpenCL API merely because of shortcomings in the "official" C++ wrapper.

Kronos is receptive to contributions.  You can file bugs on their APIs and even contact them regarding patches and other contributions.

<snip>

> > A final but probably very important design consideration:
> > I wonder if boost needs a OpenCL-computing library, or a general
> > parallelization library. Presently the GPGPU world is already split
> > too much between CUDA and OpenCL as main players (hardware vendors
> > doing their parts ...), and technology is really rapidly moving
> > (APUs etc.).  As Hartmut has already pointed out one approach could
> > be to use the current proposal as foundation for a parallelization
> > implementation:

<snip>

> I think developing a unifying parallel framework which can intelligently
> dispatch algorithms to multiple back-ends is outside the scope of Boost.Compute

Perhaps, but I strongly agree that a Boost.Compute library shouldn't be tied to OpenCL.  Beyond CUDA, we should expect to see more OpenCL alternatives enabled by HSA.  And it would seem highly desirable to have a TBB (or equivalent) backend, for the vast multitudes of multi-core machines that don't support OpenCL.

Matt

________________________________

This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.