OpenCL C

I would disagree on the “OpenCL users have mixed feelings” part, infact it’s just the contrary. One of the biggest flaws of SPIR is that there is no standard way of generating it from OpenCL C. Each vendor will have their own generator that will most likely be tuned for their own compilers. This might not be deliberate, but will happen, as the same people will be writing the C and the SPIR compilers. Having an unbiased SPIR generator is definately beneficial.

As to going further, generating binary (or platform dependant intermediate) from OpenCL C should be left to the end-user, but that IMHO should not affect OpenCL C being declared as a supported language.

Feladó: Renato Golin
Elküldve: ‎kedd‎, ‎2013‎. ‎december‎ ‎17‎. ‎14‎:‎34
Címzett: Pekka Jääskeläinen
Másolat: Clang Dev

I would disagree on the “OpenCL users have mixed feelings” part, infact
it’s just the contrary. One of the biggest flaws of SPIR is that there is
no standard way of generating it from OpenCL C. Each vendor will have their
own generator that will most likely be tuned for their own compilers. This
might not be deliberate, but will happen, as the same people will be
writing the C and the SPIR compilers. Having an unbiased SPIR generator is
definately beneficial.

While most sensible people would agree with you, there are lawyers
(chuckle) and they make technical decisions. There are many people that
*know* how sensible this is, but still advocate the opposite because
they're told so. Once software patents, copyright, and all that jazz gets
fixed, we'll be able to go back to being sensible. But I digress...

As to going further, generating binary (or platform dependant intermediate)

from OpenCL C should be left to the end-user, but that IMHO should not
affect OpenCL C being declared as a supported language.

Absolutely! But someone has to own it, and most interested parties won't,
because they have their own front- and back-ends. Sigh...

At least we know of a few folks that are interested (you, Pekka, Clover
guys), so I think it's up to you guys to make that evolve into a fully
supported product.

Note that the "support" part is complicated. "Patches welcome" is not
really acceptable when you claim compatibility, you have to fix some of the
mess yourself, because the user will report and won't be able to fix it
(sometimes, you won't even want his patch!).

Having a code owner is paramount to that, as Pekka said. But there is
something even more important: continuous integration. You must have a
reference platform, a good battery of tests, running continuously on every
commit (ish) to make sure no one breaks anything, etc. Buildbots,
test-suites, benchmarks. You need open source libraries, so that all that
can happen upstream, and you need interested people fixing bugs, adding
features, etc.

I haven't seen this much from the OpenCL folks, and "requesting" it to be
listed as "supported" is not enough. Where there's a will, there's a way...
:wink:

cheers,
--renato

Having a code owner is paramount to that, as Pekka said. But there is
something even more important: continuous integration. You must have a
reference platform, a good battery of tests, running continuously on
every commit (ish) to make sure no one breaks anything, etc. Buildbots,
test-suites, benchmarks. You need open source libraries, so that all
that can happen upstream, and you need interested people fixing bugs,
adding features, etc.

We have these things in pocl.

Isee the language support for OpenCL C and the OpenCL as a whole
(built-in libs, the host API, kernel compiler for non SPMD machines,...) are two separate things.

I was referring to the OpenCL C language support here.

I haven't seen this much from the OpenCL folks, and "requesting" it to
be listed as "supported" is not enough. Where there's a will, there's a
way... :wink:

Agreed. I think this progress requires a "code owner" that cares.

Without a proper stack, it's hard to show that you are generating the
correct code, or that it will execute at all in at least one reference
platform.

I'd recommend to get wither x86_64 (+AVX) or ARM (+NEON) as the reference
platform and test GPUs later.

Agreed. I think this progress requires a "code owner" that cares.

Not really. Most contributions to make the ARM back-end a first-class
target didn't come from the code owners, but from the general community.

Since you don't even have one, I agree that you need it for the sake of
having one (that's a different issue), but the code owner doesn't need to
care much, if everyone else does.

cheers,
--renato