search for: pocl

Portable OpenCL (pocl) v0.6 released ------------------------------------ Portable OpenCL aims to be an efficient open source (MIT-licensed) implementation of the OpenCL 1.2 standard. In addition to producing an easily portable open source OpenCL implementation, another major goal of the project is improving perfor...

Portable Computing Language (pocl) v0.8 released Pocl's goal is to become an efficient open source (MIT-licensed) implementation of the OpenCL 1.2 (and soon OpenCL 2.0) standard. In addition to producing an easily portable open-source OpenCL implementation, another major goal of this project is improving performance portabili...

...he OpenCL 1.2 standard. In addition to producing an easily portable open source OpenCL implementation, another major goal of the project is improving performance portability of OpenCL programs with compiler optimizations, reducing the need for target-dependent manual optimizations. At the core of pocl is the kernel compiler that consists of a set of LLVM passes used to statically generate multiple work-item work group functions of kernels, even in the presence of work-group barriers. These functions are suitable for parallelization in multiple ways (SIMD, VLIW, superscalar,...). This release ad...

> > For the record, I just workarounded it in pocl by borrowing the > BreakConstantGEPs code from SAFECode. But for SPIR specs, IMHO, this should > be reconsidered. Yes, I agree. On 24 September 2012 15:08, Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi>wrote: > Well, > > To be honest I'm not very comfortable with the...

...> I don't fully understand your problem description. > > ...is caused by LLVM/Clang thinking >> >> they are buffers with a constant base which they eventually won't be in >> a parallel WG implementation. This triggers an issue I'm currently >> working on pocl: https://bugs.launchpad.net/pocl/+bug/1032203 because >> Clang generates >> constant GEPs for the local buffer accesses (even though in a parallel >> thread-safe implementation the local variables cannot be stored to >> constant locations). >> > > Surely if you&...

...bably wasn't very clear ;) Anyways, me bringing it up was meant as an example of what can happen if one (mis)uses the C function static variable semantics for something that really is a thread local variable (in usual thread parallel implementations). For the record, I just workarounded it in pocl by borrowing the BreakConstantGEPs code from SAFECode. But for SPIR specs, IMHO, this should be reconsidered. On 09/24/2012 05:00 PM, James Molloy wrote: > Hi, > > Sorry, With a prod from Silviu (cc'd) I now understand - I was interpreting > your use of "constant GEP" as...

...is at least one outer loop that has increments of > one, runs a multiple of the SIMD width iterations, and that every > iteration is independent (barriers can be handled by the OpenCL driver > *after* WFV). Yes, this is the case with the "wiloops" work group generation method of pocl. The parallel outer loops are the max 3 dimensions of the local space. The actual wg barrier calls are converted to no-ops (compiler barriers) for the current targets. > On the other hand, LoopVectorizer may not be aimed at covering all kinds > of code inside the body and/or instead focus mo...

...", thus works as is only when multiple work groups of the same kernel are not executed in parallel. Therefore, some other compiler pass is assumed to convert those function static (module global variables) to some other storage where the local buffers are allocated per work group thread. The pocl implementation is what was suggested some time ago in this list: the locals are converted to local arguments to the kernel function which are then passed per-thread buffers when the work group is executed. Thus, pocl needs to convert the references to these dummy globals to local buffer pointers at...

Micah, Boaz, Do you guys have any ideas about how to fix this issue? Cheers, James On 24 September 2012 16:04, James Molloy <james at jamesmolloy.co.uk> wrote: > For the record, I just workarounded it in pocl by borrowing the >> BreakConstantGEPs code from SAFECode. But for SPIR specs, IMHO, this >> should >> be reconsidered. > > > Yes, I agree. > > On 24 September 2012 15:08, Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi>wrote: > >> Well, >> >...

...= 4 for > SSE/AltiVec, 8 for AVX). Quite interesting. We were planning to add "vectorization" to our passes also, but if I understood the paper correctly your approach uses full speculation, which is all right for SIMD architectures but might not be so for multi-issue processors. The pocl project comes from a generalization of our work in using OpenCL as entry language for static ILP architectures (http://dx.doi.org/10.1109/ICSAMOS.2010.5642061), so we do not only focus on DLP but also ILP (ultimate goal of pocl is portable performance of OpenCL code among different platforms). Our...

...unction 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...

Hi, I don't fully understand your problem description. ...is caused by LLVM/Clang thinking > they are buffers with a constant base which they eventually won't be in > a parallel WG implementation. This triggers an issue I'm currently working > on pocl: https://bugs.launchpad.net/pocl/+bug/1032203 because Clang > generates > constant GEPs for the local buffer accesses (even though in a parallel > thread-safe implementation the local variables cannot be stored to > constant locations). Surely if you're passing in pointers to the...

...ions 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...

Pocl is a portable open source (MIT-licensed) implementation of the OpenCL standard (1.2 with some 2.0 features supported). In addition to producing an easily portable open-source OpenCL implementation, another major goal of this project is improving performance portability of OpenCL programs with the k...

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...

...tomatic locals to function scope pointers? This will make handling of automatic locals and local pointer arguments similar, which is desirable as they are just a way to describe the same thing (I understand automatic locals as just a simpler way to use local buffers than local arguments). In fact, pocl converts automatic locals to implicit "extra" kernel arguments and manages both cases the same way. Carlos

...on > that this maps more cleanly to the device model. Device and kernel > functions are represented differently in PTX, including (sometimes) the > way parameters are passed. For the record, marking the kernels with "calling conventions" instead of metadata is fine also for the pocl use case. It's enough if there is a way to differentiate OpenCL C kernels from the "device functions" for the reason I discussed in the previous email. That is, in the pocl point of view we just need a way to pick the "host-callable" kernel functions as they need the special...

...t to lower global variables to function arguments given SPIR representation. Micah > -----Original Message----- > From: Carlos Sánchez de La Lama [mailto:csanchezdll at gmail.com] > Sent: Friday, September 28, 2012 12:34 AM > To: James Molloy > Cc: Pekka Jääskeläinen; Ouriel, Boaz; pocl-devel at lists.sourceforge.net; > Villmow, Micah; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > Subject: Re: [pocl-devel] [cfe-dev] [LLVMdev] SPIR provisional > specification is now available in the Khronos website > > Hi guys, > > > So it is valid SPIR, as the specific...

...ght for SIMD architectures but might not be > so for multi-issue processors. I don't know what you mean with "speculation" here, but other than that you are right: for best performance, we explicitly target machines with SIMD instruction sets. >> 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). > > That is wrong, at least for pocl. We do not (by far) support the whole > API, the main new point on pocl is the LLVM passes to statically create...

...n arguments given SPIR representation. > > Micah > > > -----Original Message----- > > From: Carlos Sánchez de La Lama [mailto:csanchezdll at gmail.com] > > Sent: Friday, September 28, 2012 12:34 AM > > To: James Molloy > > Cc: Pekka Jääskeläinen; Ouriel, Boaz; pocl-devel at lists.sourceforge.net; > > Villmow, Micah; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > > Subject: Re: [pocl-devel] [cfe-dev] [LLVMdev] SPIR provisional > > specification is now available in the Khronos website > > > > Hi guys, > > > > > So...