llvm dev - Oct 2011 - [LLVMdev] ANN: libclc (OpenCL C library implementation)

Hi,

This is to announce the availability of libclc, an open source, BSD
licensed implementation of the library requirements of the OpenCL C
programming language, as specified by the OpenCL 1.1 Specification.
libclc is intended to be used with Clang's OpenCL frontend.

libclc website: http://www.pcc.me.uk/~peter/libclc/

libclc is designed to be portable and extensible. To this end,
it provides generic implementations of most library requirements,
allowing the target to override the generic implementation at the
granularity of individual functions.

libclc currently only supports the PTX target, but support for more
targets is welcome.

How does this project relate to the recently announced Portable OpenCL
(POCL) project?  Unlike POCL, this project is not intended to provide
an OpenCL host library (i.e. the OpenCL Platform Layer and OpenCL
Runtime specified in sections 4-5 of the OpenCL specification).
Instead, it provides only the requirements for the OpenCL C
Programming Language (section 6 et seq).  It is intended to be used
with an existing host library implementation, and comply with its
ABI requirements.

An example of such a host library is NVIDIA's OpenCL host library
for PTX -- the intention is to at some point provide a mechanism
for using the NVIDIA implementation of OpenCL with Clang, libclc
and LLVM's PTX backend instead of NVIDIA's own OpenCL compiler.
Another example would be POCL's host library, and the POCL developers
have expressed an interest in using libclc as their OpenCL C library
instead of developing their own.

I will hope to find time over the next few weeks to add libclc support
to the Clang driver.  The intention is that compiling OpenCL C programs
to PTX would be as easy as (something like this):

clang -target ptx32 -S file.cl

such that the driver would automatically locate the libclc headers,
add them to the include path and pre-include the main header file.
(The libclc support will of course be optional, and a -cl-stdlibflag will be
provided to allow for switching between OpenCL standard
library implementations.)

Thanks,
-- 
Peter

On Wed, Oct 19, 2011 at 02:47:42PM +0100, Peter Collingbourne
wrote:
> Hi,
> 
> This is to announce the availability of libclc, an open source, BSD
> licensed implementation of the library requirements of the OpenCL C
> programming language, as specified by the OpenCL 1.1 Specification.
> libclc is intended to be used with Clang's OpenCL frontend.
> 
> libclc website: http://www.pcc.me.uk/~peter/libclc/
> 
> libclc is designed to be portable and extensible. To this end,
> it provides generic implementations of most library requirements,
> allowing the target to override the generic implementation at the
> granularity of individual functions.
> 
> libclc currently only supports the PTX target, but support for more
> targets is welcome.
Just a followup note to say that libclc is at a very early stage
of development, and that only a few functions are implemented.
Developers wanted :)

Thanks,
-- 
Peter

On Wed, Oct 19, 2011 at 9:47 AM, Peter Collingbourne <peter at
pcc.me.uk>wrote:
> Hi,
>
> This is to announce the availability of libclc, an open source, BSD
> licensed implementation of the library requirements of the OpenCL C
> programming language, as specified by the OpenCL 1.1 Specification.
> libclc is intended to be used with Clang's OpenCL frontend.
>
> libclc website: http://www.pcc.me.uk/~peter/libclc/
>
> libclc is designed to be portable and extensible. To this end,
> it provides generic implementations of most library requirements,
> allowing the target to override the generic implementation at the
> granularity of individual functions.
>
> libclc currently only supports the PTX target, but support for more
> targets is welcome.
>
> How does this project relate to the recently announced Portable OpenCL
> (POCL) project?  Unlike POCL, this project is not intended to provide
> an OpenCL host library (i.e. the OpenCL Platform Layer and OpenCL
> Runtime specified in sections 4-5 of the OpenCL specification).
> Instead, it provides only the requirements for the OpenCL C
> Programming Language (section 6 et seq).  It is intended to be used
> with an existing host library implementation, and comply with its
> ABI requirements.
>
> An example of such a host library is NVIDIA's OpenCL host library
> for PTX -- the intention is to at some point provide a mechanism
> for using the NVIDIA implementation of OpenCL with Clang, libclc
> and LLVM's PTX backend instead of NVIDIA's own OpenCL compiler.
>
This is already semi-functional.  You can compile OpenCL code with
Clang+libclc for ptx32, and load the resulting PTX as an OpenCL binary using
Nvidia's OpenCL platform. :)

> Another example would be POCL's host library, and the POCL developers
> have expressed an interest in using libclc as their OpenCL C library
> instead of developing their own.
>
> I will hope to find time over the next few weeks to add libclc support
> to the Clang driver.  The intention is that compiling OpenCL C programs
> to PTX would be as easy as (something like this):
>
> clang -target ptx32 -S file.cl
>
> such that the driver would automatically locate the libclc headers,
> add them to the include path and pre-include the main header file.
> (The libclc support will of course be optional, and a -cl-stdlib> flag
will be provided to allow for switching between OpenCL standard
> library implementations.)
>
> Thanks,
> --
> Peter
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20111019/17708e4d/attachment.html>

Do we have a list of these open-source LLVM-based OpenCL projects
somewhere? Off the top of my head, we have:

libclc: http://www.pcc.me.uk/~peter/libclc/
pocl: https://launchpad.net/pocl
clover: http://cgit.freedesktop.org/~steckdenis/clover/

(I think that all of these have BSD- or MIT-style licenses).

Are there any others?

 -Hal

On Wed, 2011-10-19 at 14:47 +0100, Peter Collingbourne
wrote:
> Hi,
> 
> This is to announce the availability of libclc, an open source, BSD
> licensed implementation of the library requirements of the OpenCL C
> programming language, as specified by the OpenCL 1.1 Specification.
> libclc is intended to be used with Clang's OpenCL frontend.
> 
> libclc website: http://www.pcc.me.uk/~peter/libclc/
> 
> libclc is designed to be portable and extensible. To this end,
> it provides generic implementations of most library requirements,
> allowing the target to override the generic implementation at the
> granularity of individual functions.
> 
> libclc currently only supports the PTX target, but support for more
> targets is welcome.
> 
> How does this project relate to the recently announced Portable OpenCL
> (POCL) project?  Unlike POCL, this project is not intended to provide
> an OpenCL host library (i.e. the OpenCL Platform Layer and OpenCL
> Runtime specified in sections 4-5 of the OpenCL specification).
> Instead, it provides only the requirements for the OpenCL C
> Programming Language (section 6 et seq).  It is intended to be used
> with an existing host library implementation, and comply with its
> ABI requirements.
> 
> An example of such a host library is NVIDIA's OpenCL host library
> for PTX -- the intention is to at some point provide a mechanism
> for using the NVIDIA implementation of OpenCL with Clang, libclc
> and LLVM's PTX backend instead of NVIDIA's own OpenCL compiler.
> Another example would be POCL's host library, and the POCL developers
> have expressed an interest in using libclc as their OpenCL C library
> instead of developing their own.
> 
> I will hope to find time over the next few weeks to add libclc support
> to the Clang driver.  The intention is that compiling OpenCL C programs
> to PTX would be as easy as (something like this):
> 
> clang -target ptx32 -S file.cl
> 
> such that the driver would automatically locate the libclc headers,
> add them to the include path and pre-include the main header file.
> (The libclc support will of course be optional, and a -cl-stdlib> flag
will be provided to allow for switching between OpenCL standard
> library implementations.)
> 
> Thanks,
-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory

Hi everybody,

the compiler design lab at Saarland University (chair of Sebastian Hack) 
is also working on an LLVM-based OpenCL driver.

The project started as a use-case for our "Whole-Function
Vectorization"
library, which allows to transform a function to compute the same as W 
executions of the original code by using SIMD instructions (W = 4 for 
SSE/AltiVec, 8 for AVX).

The algorithm, a few details on the OpenCL driver, and some results were 
published at CGO'11:
http://dx.doi.org/10.1109/CGO.2011.5764682

In contrast to Clover and pocl, we aimed at maximum performance before 
full support of the API (which simply requires more manpower than one 
PhD student).
The driver was evaluated using benchmarks from the AMD APP SDK, e.g. 
Mandelbrot, NBody, FastWalshTransform, Histogram, BlackScholes, DCT, ...
Our measurements show that our driver outperforms both Intel's and AMD's
CPU driver for almost all of the benchmarks.

We plan to release both the vectorization library as well as the OpenCL 
driver under a BSD-style license, but there is still significant work to 
be done in terms of stability and feature completeness (e.g. the ICD 
mechanism only works as expected under Windows).
Also, due to simplicity we currently employ AMD's OpenCL-to-LLVM 
frontend and OpenCL-library from an earlier SDK. libclc sounds like the 
perfect fit for us to get rid of that.

I agree on the fact that we should try to merge the different 
open-source OpenCL projects, but at least at first glance they do not 
seem to share too many design decisions.

More information on Whole-Function Vectorization and our driver can be 
found on the project web page:
http://www.cdl.uni-saarland.de/projects/wfv

Best regards,
Ralf


Am 19.10.2011 17:38, schrieb Hal Finkel:
> Do we have a list of these open-source LLVM-based OpenCL projects
> somewhere? Off the top of my head, we have:
>
> libclc: http://www.pcc.me.uk/~peter/libclc/
> pocl: https://launchpad.net/pocl
> clover: http://cgit.freedesktop.org/~steckdenis/clover/
>
> (I think that all of these have BSD- or MIT-style licenses).
>
> Are there any others?
>
>   -Hal
>
> On Wed, 2011-10-19 at 14:47 +0100, Peter Collingbourne wrote:
>> Hi,
>>
>> This is to announce the availability of libclc, an open source, BSD
>> licensed implementation of the library requirements of the OpenCL C
>> programming language, as specified by the OpenCL 1.1 Specification.
>> libclc is intended to be used with Clang's OpenCL frontend.
>>
>> libclc website: http://www.pcc.me.uk/~peter/libclc/
>>
>> libclc is designed to be portable and extensible. To this end,
>> it provides generic implementations of most library requirements,
>> allowing the target to override the generic implementation at the
>> granularity of individual functions.
>>
>> libclc currently only supports the PTX target, but support for more
>> targets is welcome.
>>
>> How does this project relate to the recently announced Portable OpenCL
>> (POCL) project?  Unlike POCL, this project is not intended to provide
>> an OpenCL host library (i.e. the OpenCL Platform Layer and OpenCL
>> Runtime specified in sections 4-5 of the OpenCL specification).
>> Instead, it provides only the requirements for the OpenCL C
>> Programming Language (section 6 et seq).  It is intended to be used
>> with an existing host library implementation, and comply with its
>> ABI requirements.
>>
>> An example of such a host library is NVIDIA's OpenCL host library
>> for PTX -- the intention is to at some point provide a mechanism
>> for using the NVIDIA implementation of OpenCL with Clang, libclc
>> and LLVM's PTX backend instead of NVIDIA's own OpenCL compiler.
>> Another example would be POCL's host library, and the POCL
developers
>> have expressed an interest in using libclc as their OpenCL C library
>> instead of developing their own.
>>
>> I will hope to find time over the next few weeks to add libclc support
>> to the Clang driver.  The intention is that compiling OpenCL C programs
>> to PTX would be as easy as (something like this):
>>
>> clang -target ptx32 -S file.cl
>>
>> such that the driver would automatically locate the libclc headers,
>> add them to the include path and pre-include the main header file.
>> (The libclc support will of course be optional, and a
-cl-stdlib>> flag will be provided to allow for switching between OpenCL
standard
>> library implementations.)
>>
>> Thanks,
>

Hi,
> libclc: http://www.pcc.me.uk/~peter/libclc/
> pocl: https://launchpad.net/pocl
> clover: http://cgit.freedesktop.org/~steckdenis/clover/
I have pushed our implementation on GitHub:

https://github.com/speziale-ettore/OpenCRun

I have focused on desiging a modular system, because OpenCRun is
intended to be used for research purpose -- not many people, no too much
time, so clean design is not an option. For the same reason, I have
tried to re-use as much as possible what LLVM/CLANG offers: compiler,
jit, build system, diagnostic routines, testing infrastructure, ...

Currently I have implemented an OpenCL backend for i386 and X86_64 CPUs.
I have coded work-item stacks by hand because after some sintetic
benchmarks I have observed that both ucontext and setjmp/longjmp contain
some extra overheads.

Code is not fully documented -- sorry -- and some mandatory features are
still missing (e.g. local variables).

Looking at the code, you can observe that there are a lot of LLVM
passes. I have implemented some features through passed because I want
to keep the code as much modular as possible.

Best regards,
speziale.ettore at gmail.com

PS-1: OpenCRun requires some extra metadata to be generated by clang. In
sources root directory there is a clang patch to add support for
metadata generation

PS-2: some parts are very bad-coded. I know, but I haven't had yet time
to do some refactoring