Portable OpenCL

[8l]

[dar]

This project looks interesting, especially the work on kernel optimizatons. Practical issue is the use of LLVM which does not support Epiphany. The OpenCL implementation for Parallella/Epiphany uses GCC for JIT compilation.

[stealthpaladin]

[dar]

Here is the technical issue. Right now Epiphany is supported with a GCC back-end so we are using an OpenCL JIT compiler based on GCC that gets most of OpenCL kernel language right (see below for details). We use a lifting technique that "lifts" OpenCL into C++ for compilation. (Performance, an obvious concern, can be very good using this technique.)

If an LLVM-based tool chain were constructed to target Epiphany it would be trivial to modify it to treat OpenCL, since OpenCL is almost entirely compatible with C with a few unfortunate choices that break C compliance. Without an LLVM back-end for Epiphany this is a non-starter. POCL might possibly be very useful for the LLVM compiler front-end, not sure but its worth a look. COPRTHR already provides the Epiphany run-time. Integrating these components might be useful for Epiphany.

In every direction there is work to be done. What needs to be done is fairly well understood. Its just a resource allocation issue.

For now Epiphany can be programmed using OpenCL provided by COPRTHR with the few limitations of the lifting technique, which are: no out-of-order swizzels, no Apple-style vector initialization. The former breaks the C language and is just a bad idea, the latter conflicts with GCC. Local memory is also a problem, but that really gets to the difference between Epiphany and a GPU. OpenCL local memory is a GPU construct.

If I had a wish list for anyone who wanted to work on compilers, it would be to add support for OpenCL anomalies to the GCC C++ front-end since they are few - picturing a flag that enables them. A full "OpenCL compiler" is mostly unnecessary unless someone wants kernel vectorization, and that would move the problem from tweaking a compiler to a compiler project.

An LLVM tool chain for epiphany would be nice, but it would need to match the performance of GCC-4.8 for Epiphany or it would not be worth considering. Functional is difficult enough, performance/optimization might take some serious work. The GCC developer working on this has put very good compiler support in place for Epiphany. I would not underestimate the work needed to catch up.

[stealthpaladin]

Thanks for the good point of reference here. I'll switch focus from LLVM curiosity towards the GCC front-end, given the state of things you describe. Would be best to pitch in with those tasks and potentially come back around in the long run for LLVM once the GCC chain is feature-complete and optimized.

Regarding local memory, is this an issue due to the way cores in the same 'work group' wouldn't be able to communicate at the same speed with each other, but only their neighbor - combined with the fact they dont have a normal shared memory but share their banks?

Since I haven't got a Parallella just yet, I've been trying to write a few OpenCL kernels that run horridly slow on my GPU but in theory communication should be happening with the right neighbors. I'd like to make it more generic like some kind of HAL but I dont think I would have to use kernel vectorization as long as each kernel keeps context well enough to vectorize the dataflow after they are bound.

Wish I could actually test my thoughts and make more sense =) In any case, if I get in the compiler contributing spirit, I'll definitely check in to helping on GCC first.

[dar]

quote]Regarding local memory, is this an issue due to the way cores in the same 'work group' wouldn't be able to communicate at the same speed with each other, but only their neighbor - combined with the fact they dont have a normal shared memory but share their banks?[[/quote]

The issue of memory architecture is complicated, and defines most everything about Epiphany. Basically, OpenCL uses address space qualifiers to describe two distinct characteristics of a memory architecture - physical locality and visibility. This makes sense for GPUs since the definitions are aligned. Epiphany shows the limitations of this terminology. The memory that one considers to be "local" for Epiphany, which I refer to as "core-local" memory, is physically local to a single core executing a work item in a workgroup. However, that memory is visible from all other cores with very fast, albeit non-uniform access from all other cores. An effective way to use this core-local memory is to allocate it similar to "OpenCL private" memory for each core, but then allow data to be exchanged between cores using extensions. It is possible to implement OpenCL local memory concept, which we do, but it is not efficient or a good way to use the processor. It can be used in theory by following various "rules" for access, similar to analogous rules we learned to use for GPUs, but since this is not a GPU, the rules will be different. The entire exercise is a detour from just understanding the memory architecture and writing your algorithms accordingly. It is a trade-off between portability vs performance. Performance is not portable with OpenCL anyway, so there is nothing special with Epiphany in that regard.

[stealthpaladin]

[Gravis]

one giant difference is that on the epiphany, branching will not be horridly slow like on GPUs. a lot of the time you can work around branching with clever math tricks but now you can use all the branching you like without a huge penalty. i suppose the tradeoff is that you dont get a zillion pipelines... unless you link multiple chips.

[stealthpaladin]