Hi, On 7 August 2013 00:37, Kalle Raiskila <[email protected]> wrote: > On Tue, 6 Aug 2013 21:28:19 -0700 > Alun Evans <[email protected]> wrote: > >> i.e. I'm compiling pocl natively on x86_64, but trying to add a new >> device that is an ARM based platform. >> >> I've actually got a few more questions on that, but I think I'm making >> some progress. I just thought about checking whether this has been >> successfully attempted before? > > So you are building a system where 'build'=='host'==x86_64, > 'target'=arm? That should be doable, e.g. the ttasim and cellspu > drivers have a similar setup.
That's exactly right, I've been modifying configure.ac to conditionally add OCL_DRIVERS="$OCL_DRIVERS my-device" OCL_TARGETS="$OCL_TARGETS arm" > But if you are building as system where 'build'==x86_64, > 'host'=='target'==arm, then that has been unsuccessfully tried in the > past, and no reports on successes has reached me. Patches welcome :) That's is what I started to try first thinking it would be easier than the former :) i.e. specifically I wouldn't have to build the Host<->Target communication mechanism immediately before checking the execution works correctly on the target device. >> Well infact the device is a bit space limited, so holding a a >> toolchain out there would have been a bit of a pain. > > 'A bit space limited' is a bit subjective. But this is clearly an issue > on the TODO list. Well it's not pocl, it's llvm: 58M bin 284K docs 16M include 107M lib 36K share 180M total I guess I could remove a few of them from the target, but the bulk of it would be needed (and not-stripped it's 260M) Though it is : LLVM (http://llvm.org/): LLVM version 3.3svn Optimized build with assertions. Built Jul 24 2013 (21:04:05). Default target: x86_64-unknown-linux-gnu Host CPU: corei7 Registered Targets: arm - ARM cpp - C++ backend thumb - Thumb x86 - 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 - i.e. I would have made an arm host/target combo, and avoided all the x86 targets, that would hopefully shave a bit more off it. > OpenCL's clCreateProgramWithBinary documentation does suggest that the > program binary should be loadable without invoking compilers past that > point. That is what I'd been wondering :) > However, pocl's optimizations (and code generation) kick in > "later", at clEnqueueKenrnel call time. So getting current pocl (not in > standalone mode) to run on a compilerless system would require quite a > bit of work. But at least I would see this as a worthy goal. Sure, it > would place some restrictions to the usage of OpenCL (like fixing WG > sizes at compile time). But somehow I think such restrictions would be > a minor thing in the context of this sort of embedded systems. Yeah, that is what I noticed. I'll see if I ever get back to this task. thanks for the notes! A. -- Alun Evans ------------------------------------------------------------------------------ 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
