[Pkg-opencl-devel] pocl packaging

[Michal Babej]

On Fri, 23 Feb 2018 15:46:15 +0100, Andreas Beckmann <anbe at debian.org> wrote:

> I didn't check whether 1.1rc1 introduces new POCL_ABORT() without \n

It probably doesn't, at least i don't remember any new ones

> Why does pocl still set -fno-rtti for all llvm versions?
> the comments indicate a workaround for an ancient bug

That's quite likely the reason. I'll remove those CMake lines and run some tests.

> By default pocl does the equivalent of a -march=native build at both
> compile time and runtime. This is a no-go for a distribution.

Of course..

> I didn't find a way to hint pocl to
> do this. So I'm trying to find out what's the correct baseline cpu for
> each architecture to pass that as -DLLC_HOST_CPU ...

... right, so the official way to force a CPU is -DLLC_HOST_CPU.
If it does not work, then i'll try to fix it. (but it seems to work on my
ARM, that's why i was wondering why you need *another* option..)

> Which does not seem to be always
> compatible with the baseline kernellib (e.g. i386 chroot on amd64
> (ivybridge) machine, building with -DLLC_HOST_CPU=i686).

That's probably one of the many setups that nobody tests. I'll try to
take a look at it before 1.1 release

> I know this results in suboptimal pocl performance.

Honestly I don't mind if pocl has suboptimal performance on
everything except x86-64, but i'd like it to be reasonable at
least that there...

> And the interesting question is: how to test the different kernel
> libraries (and cpu targets)? 

Well, if (on x86-64) it's built with -DKERNELLIB_HOST_CPU_VARIANTS=distro,
there is no CPU-native kernel library, only "CPU feature subset" libraries.
So CPU feature detection must work even on the machine where you
build it. As for how to test the other combinations without the extra 
hardware.. no idea. You would have to trick LLVM CPU recognition
somehow, or maybe use VMs.

> So far, we only got successful pocl builds for Debian on amd64 and i386:

Yes, that's because pocl development team is quite small, and we also
have some academic projects on pocl, so from CPU hardware, x86-64
is really the only one getting sufficient attention. And of course pocl
requires good LLVM support for the target... so i'm not surprised.

(Though quickly looking at those logs, some of the issues have been 
resolved in 1.1; my ARM builds are now failing only 1-2 tests).

> mips*:
> This looks like a macro messed up the bool type ...

There used to be a person who actually took care of MIPS support,
we even had a MIPS build bot... but they silently disappeared and
i'm afraid MIPS code has been rotting ever since.

Regards,
 -- mb