similar to: [LLVMdev] Portable OpenCL (pocl) v0.7 released

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 portability of OpenCL programs with compiler optimizations, reducing the

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 performance portability of OpenCL programs with compiler optimizations, reducing the

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 kernel compiler and the task runtime, reducing the need for target-dependent manual

Hi all, we have release our (still quite in progress) OpenCL implementation. It uses a set of LLVM passes to statically replicate the workitems and generate a bytecode of the actual code to be run, taking into account the WI synchronization (barriers). >From the project description: Portable OpenCL is an open source implementation of the OpenCL standard which can be easily adapted for new

What would be ideal is to have the alloca instruction be able to allocate memory indifferent address spaces instead of only being in private. Micah > -----Original Message----- > From: Pekka Jääskeläinen [mailto:pekka.jaaskelainen at tut.fi] > Sent: Friday, September 28, 2012 1:17 PM > To: James Molloy > Cc: Villmow, Micah; Carlos Sánchez de La Lama; Ouriel, Boaz; pocl- > devel

Maybe it would be easier to provide a bitcode example of this problem. After thinking about this more, I'm not sure if this is applicable to SPIR itself. For you to have a constant GEP expression, you have to know the pointer size in order to correctly generate the expression. Since the pointer size itself is not known, I don't yet see how you can generate a constant expression that is

Micah, You're saying it works for you, but Clang doesn't currently anywhere near the range of horrible constantexpr constructs it is possible to create. You can "get by" at the moment with just handling ConstantGEPs, because of the way Clang works. But SPIR isn't restricted to Clang, and the problem is that it is *possible* (although not probable, or nice, but that is

Hi guys, > So it is valid SPIR, as the specification stands, to manipulate __local > variables as Constants in a way that is extremely difficult to undo. That > is, in order to transform SPIR to code that can run on a CPU, the > GlobalVariable (which is a subclass of Constant) must be replaced with a > dynamically calculated Value (which is not a subclass of constant). What about

Hi Ralf, > 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). Quite interesting. We were planning to add "vectorization" to our passes also, but if I understood the

I was hoping you would come to the collaborative, joint solution. I've been waiting for Clang to have a settled OpenCL implementation to start working on OpenCL. Dealing with 3 parallel projects would be just that, a pain in the rear. - Marc On 10/20/2011 03:45 AM, Ralf Karrenberg wrote: > Hi Carlos, > > On 10/20/11 9:54 AM, Carlos Sánchez de La Lama wrote: >>> The

----- Original Message ----- > From: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi> > To: "Ralf Karrenberg" <Chareos at gmx.de> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Thursday, January 31, 2013 11:15:43 AM > Subject: Re: [LLVMdev] LoopVectorizer in OpenCL C work group autovectorization > > Hi

Carlos, AMD's OpenCL implementation(both CPU and GPU) has worked for years with the way SPIR represents locals. If there is problems with the representation then it is an implementation issue. One of the issues with using extra kernel arguments is that it requires extra validation and complexity at the runtime level that is not needed if it is handled internally by the compiler. That being

Hi Ralf, On 01/31/2013 05:44 PM, Ralf Karrenberg wrote: > As for the current status, the loop vectorizer is only able to vectorize > inner loops and (I think) does not handle function calls and memory > operations well. This will prevent it from vectorizing a large group of > OpenCL kernels, and certainly all "interesting", more complex ones. Agreed -- but not being able to

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:

Ralf, What version of the SDK were you using for your analysis? I don't see that in the slides/pdf. Thanks, Micah > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Ralf Karrenberg > Sent: Wednesday, October 19, 2011 2:13 PM > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] ANN: libclc (OpenCL C

Hi Micah, The numbers from the paper were measured with the ATI Stream SDK v2.1 (it's only mentioned in the references I think). The most recent measurements I have were done with the current v2.5. Best, Ralf Am 19.10.2011 23:43, schrieb Villmow, Micah: > Ralf, > What version of the SDK were you using for your analysis? I don't see that in the slides/pdf. > > Thanks, >

----- Original Message ----- > From: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi> > To: "Nadav Rotem" <nrotem at apple.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, January 25, 2013 5:35:16 AM > Subject: Re: [LLVMdev] LoopVectorizer in OpenCL C work group autovectorization > > On

Hi Carlos, On 10/20/11 9:54 AM, Carlos Sánchez de La Lama wrote: >> 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). > > Quite interesting. We were planning to

Hi Pekka, hi Nadav, I didn't find the time to read this thread until now, sorry for that. I actually think you are both right :). As for the current status, the loop vectorizer is only able to vectorize inner loops and (I think) does not handle function calls and memory operations well. This will prevent it from vectorizing a large group of OpenCL kernels, and certainly all

Pekka, I am in favor of adding metadata to control different aspects of vectorization, mainly for supporting user-level pargmas [1] but also for DSLs. Before we start adding metadata to the IR we need to define the semantics of the tags. "Parallel_for" is too general. We also want to control vectorization factor, unroll factor, cost model, etc. Doug Gregor suggested to add the