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

Not a full review, but I just wanted to chime in on a couple points. -----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Kyle Lutz Sent: Saturday, December 20, 2014 3:33 To: Thomas M Cc: boost@lists.boost.org 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 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.