Hi Alun. Answers to a few of the questions inline below.
On 16/08/13 00:18, ext Alun Evans wrote: > I was wondering what the thoughts were on adding a device API like > .discover() or .probe() so that the driver can report whether it found > any of its devices ? discover how, and report where? Currently the set of drivers is a bit fixed, and certainly a bit of work is needed in this area. > Also, I've been toying with the idea of having multiple devices of the > same type, e.g. like if you plugged two GPUs into the same board. Any > thoughts on that? Certainly that feature needs to exist. > > I'm building the host to be staged installed on x86_64, and when I > installed pocl onto my staged system, I've got this ICD file: > > bash$ cat /etc/OpenCL/vendors/pocl.icd > libpocl.so.1.2.0 > > yet annoyingly the ICD can't find the pocl lib when it does dlopen() > on it since dlopen only checks: Ah, this one again. It used to have the full path in the icd file, but that got reverted for a reason of multiarch support in packaging. You are not the first user to stumble on this, and I think I will revert to the full path in the .icd, with a note in the README.packaging. > -------------------------------------------------------------------------------- > > What are your thoughts on debian and/or rpm packaging of libpocl ? Seems fabiand (on the #pocl irc channel) is hard at work adding it to Fedora. I'm not aware of any other distros packaging it. > -------------------------------------------------------------------------------- > > I noticed cellspu.c seems to be using: > > al = &(kernel->dyn_arguments[i]); > > Whereas all the other devices are using run.arguments ? cellspu is untested, unmaintained, buggy and slated for removal. It used to run only a handful of tests correctly at its peak. So I guess that is a bug. > -------------------------------------------------------------------------------- > > When I compile, I see a few gcc warnings fly past, any plans for > "-Wall -Werror" ? Oh, yes, they should be added. As soon as the warnings stop flying. Or do you mean to suggest the causality should be the other way round? ;) > -------------------------------------------------------------------------------- > > As I'm building the host to be staged installed on x86_64, as well as > compiling an arm target, so I'm passing the following to configure: > > LLVM_CONFIG=/home/alun/local-llvm/usr/local/bin/llvm-config > > (Since I'm doing a DESTDIR:=~/local-llvm/ install, then tarball) > > This of course means that I have a problem with @CLANG@ > > config.h: > > /* LLVM compiler executable. */ > #define LLC "/home/alun/local-llvm/usr/local/bin/llc" > > /* clang executable. */ > #define CLANG "/home/alun/local-llvm/usr/local/bin/clang" > I'm, not sure what the problem and the supposed fix is here. Why do you override LLVM_CONFIG? And why do you make a tarball out of LLVM? > > So far I've just been hacking the scripts/pocl-* but some nicer > solution would be good...? I just committed yesterday the last part of the API-call version of interfacing with LLVM. I.e. no more scripts needed. It is still heavily work-in-progress (just grep TODO or FIXME in lib/CL/pocl_llvm_api.cc), definetly not tested for cross-compilation, and even has x86_64 hard-coded at one point. But should have no LLVM installation path issues. > > - I guess I don't care about these paths: > > *** lib/CL/devices/common.c:llvm_codegen() > CLANG " -target %s %s -c -o %s.o %s", > LLC " " HOST_LLC_FLAGS " -o %s %s", > LINK_CMD " -target "OCL_KERNEL_TARGET > > Unless I begin to try to call llvm_codegen() from my new > device.run()... but more about that in a minute... This part too should be implemented with API calls. Unfortunately, LLVM doesn't yet (last I checked) have a working linker, so at least one system call is needed. Unless one could do JITting. > For building pocl, it seems like the goal of configure.ac is to get > this triple of variables: > > OCL_TARGETS, KERNEL_DIR, OCL_KERNEL_TARGET > > And the default AC $TARGET stuff is unused. Yeah, originally pocl built the kernel libraries for all targets, so those variables are a bit of a remnant from that. Also, for two OCL devices (pthread, basic) HOST==TARGET, which confuses the issue further. > Since I have: > > KERNEL_TARGET=@OCL_KERNEL_TARGET@ > TARGET_DIR=arm > > and that'll get me issues like: > > ,---- > | /home/alun/local-llvm/usr/local/bin/clang -Xclang > -ffake-address-space-map -emit-llvm -fsigned-char -c -target > x86_64-unknown-linux-gnu -o add_sat.cl.bc -x cl ./../add_sat.cl -include > ../../../include/arm/types.h -include So you have OCL_KERNEL_TARGET="x86_64-unknown-linux-gnu"? This sounds wrong. I think the crux of the matter is that the pthreads driver never was intended to run cross targets. You need a device driver of your own, dedicated to your setup. What is your HW setup, btw? I got the image of something like this: http://www.theregister.co.uk/2012/09/12/raspberry_pi_supercomputer/ > ,---- > | WARNING: Linking two modules of different target triples: > | /usr/local/lib/pocl/arm/kernel-arm-linux-gnueabihf.bc: > | 'armv7-linux-gnueabihf' and 'armv4t-linux-gnueabihf' > `---- This is a clang "feature". If you give the wrong target triplet to it, it will revert to armv4t as default. E.g. on ubuntu 12.04, the system triplet is armv7l-... which clang doesn't understand to be a ARMv7 ISA. You seem to hit the same issue above. (sorry for skipping the difficult questions ;)) kalle ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ pocl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pocl-devel
