Ok, thanks for that. Sorry if I mislead you but my setup isn't really standalone; I will be using a host and simulator, however I need to compile the kernels and merge the work-items offline. I believe what I will need to do is modify your passes to do this without generating the workgroup functions, so that kernels can be used using the proper API. I haven't published anything yet, this is work towards my first paper, so I will let you know once I have something.
Regards, Sam ________________________________________ From: [email protected] [[email protected]] Sent: 16 October 2012 15:26 To: [email protected] Subject: pocl-devel Digest, Vol 13, Issue 6 Send pocl-devel mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/pocl-devel or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of pocl-devel digest..." Today's Topics: 1. Re: standalone workgroups (Pekka J??skel?inen) 2. Re: build pocl-0.6 on ARM board (Pekka J??skel?inen) 3. Re: Instruction does not dominate all uses! (Pekka J??skel?inen) 4. Re: build pocl-0.6 on ARM board (Yi Ge) 5. Re: build pocl-0.6 on ARM board (Kalle Raiskila) 6. Re: build pocl-0.6 on ARM board (Pekka J??skel?inen) ---------------------------------------------------------------------- Message: 1 Date: Tue, 09 Oct 2012 17:48:56 +0300 From: Pekka J??skel?inen <[email protected]> Subject: Re: [pocl-devel] standalone workgroups To: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi, On 10/09/2012 03:33 PM, Sam Parker wrote: > I am creating a custom target which will run just the kernels, I want > the kernels to be compiled and linked statically with everything needed > to run the kernel included. So I believe the standalone method of > compilation is right, is this correct? > > I am using a configurable VLIW so I will want to combine work items to > expose ILP but the device is also multi-core. I am compiling the simple > standalone example and just would like to know how get_global_id is > calculated in the produced bytecode? And how I should use the > _*kernel*_workgroup and _*kernel*_workgroup_fast functions? I'm trying > to go through the code, but without comments, I am not making very fast > progress. It sounds you want to do exactly what we have done in TUT and what was the original use case for the pocl kernel compiler passes before pocl was published a year ago. The main difference, I suppose, is that we use TTA as a processor template instead of a traditional "OTA" VLIW. The problematic part for the "standalone mode" are the host API parts, unless you create a custom launcher for your kernel which is not "official OpenCL". The standalone compilation of the host API together with the kernel binary is not supported in pocl, but I implemented the APIs I need in TCE libraries in the TCE source tree. Basically the host API stubs assume that the kernels are linked with the program, and thus the clBuildProgram etc. are dummy no-operations. The pocl-standalone script generates the work group function assuming you have the required work group attribute in place which is then called with a "trampoline function" glued in using the compiler driver script. Thus, check the TCE sources and its tcecc compiler driver (a python script) (http://tce.cs.tut.fi). The standalone mode of TCE is an incomplete proof-of-concept and I think the best way to get it more robust is to reuse the pocl implementations for the standalone mode as well. It should be possible to make it almost transparent to the OpenCL app whether it's compiled in the standalone mode offline or with an online compiler. There's a quick tutorial in TCE user manual: http://tce.cs.tut.fi/user_manual/TCE/node21.html Some papers we have written about this subject are available in the http://tce.cs.tut.fi/publications.html page. "OpenCL-based Design Methodology for Application-Specific Processors" and "TCEMC: A Co-Design Flow for Application-Specific Multicores" are the most relevant ones. Do you have any publications of your work, BTW? BR, -- --Pekka ------------------------------ Message: 2 Date: Tue, 09 Oct 2012 17:58:07 +0300 From: Pekka J??skel?inen <[email protected]> Subject: Re: [pocl-devel] build pocl-0.6 on ARM board To: Yi Ge <[email protected]> Cc: "[email protected]" <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 10/09/2012 05:31 PM, Yi Ge wrote: > it seems that pocl-kernel script somehow didn't convert kernel.bc into so > file, > because when I used ldd to see the descriptor.so, it tells me that it is not a > dynamic executable This is what I meant that there's probably some switch missing for the ARM case in the pocl-kernel compilation calls (e.g., -shared missing somewhere where it should be?). Perhaps the CLANG command line before the ld should have -shared or both of them should have it? Also you could check with 'ldd' whether the plugin requires some dynamic libraries it cannot find. Probably not in this case but could happen when you get to the actual kernel compilation part. -- --Pekka ------------------------------ Message: 3 Date: Wed, 10 Oct 2012 19:31:20 +0300 From: Pekka J??skel?inen <[email protected]> Subject: Re: [pocl-devel] Instruction does not dominate all uses! To: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi, I think I forgot to reply to this, sorry. On 09/27/2012 03:33 PM, Panagiotis Apostolou wrote: > Continue from question #209709 > (https://answers.launchpad.net/pocl/+question/209709) > > The disassembly of kernel_linked.bc follows: ... Can you test with the latest pocl (bzr co lp:pocl)? It got a large change merged last friday so it could work now. If not, please open a bug report with the input kernel and host app to reproduce the problem. -- Pekka ------------------------------ Message: 4 Date: Mon, 15 Oct 2012 12:37:08 -0700 (PDT) From: Yi Ge <[email protected]> Subject: Re: [pocl-devel] build pocl-0.6 on ARM board To: Pekka J??skel?inen <[email protected]> Cc: "[email protected]" <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset="iso-8859-1" I still cannot resolved the dynamic library below, Could u check what kind of flags I should bring it? I saw -shared flag is there. I manually did what I did on the X86, but on X86, it works fine, but on ARM platform is not. I figured out that only difference is that LLVM was built in cross compile for ARM. unfortunately, I cannot build LLVM successfully on ARM platform natively. Anybody built pocl ARM version successfully? Could u share the environment details and build process? ? Regards, Yi ________________________________ From: Pekka J??skel?inen <[email protected]> To: Yi Ge <[email protected]> Cc: "[email protected]" <[email protected]> Sent: Tuesday, October 9, 2012 10:58 AM Subject: Re: [pocl-devel] build pocl-0.6 on ARM board On 10/09/2012 05:31 PM, Yi Ge wrote: > it seems that pocl-kernel script somehow didn't convert kernel.bc into so > file, > because when I used ldd to see the descriptor.so, it tells me that it is not a > dynamic executable This is what I meant that there's probably some switch missing for the ARM case in the pocl-kernel compilation calls (e.g., -shared missing somewhere where it should be?). Perhaps the CLANG command line before the ld should have -shared or both of them should have it? Also you could check with 'ldd' whether the plugin requires some dynamic libraries it cannot find. Probably not in this case but could happen when you get to the actual kernel compilation part. -- --Pekka -------------- next part -------------- An HTML attachment was scrubbed... ------------------------------ Message: 5 Date: Tue, 16 Oct 2012 16:11:22 +0300 From: Kalle Raiskila <[email protected]> Subject: Re: [pocl-devel] build pocl-0.6 on ARM board To: <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed On 15/10/12 22:37, ext Yi Ge wrote: > Anybody built pocl ARM > version successfully? Could u share the environment details and build > process? Don't know if our problems here are related, but I failed to get pocl compiled on ARM too. My setup is a pandaboard, I tried with ubuntu 12.04 and 11.04. On the 12.04 clang-3.1 was not able to build binaries at all, even when used outside of pocl as a plain C compiler. It tried to link in some crt.o files that didn't seem to exists on unbuntu 12.04-arm. This could be due to the 12.04 being an upgraded distro, not a fresh install (i.e. some glitch in apt, or in me using it). This file in clang: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp?view=markup shows there are a some platform-specifics needed :) I tried on ubuntu 11.04 too, with more success - clang was able to compile 'hello_world.c', at least. But with pocl, I noticed that the clang-binary does not like what the ./configure of pocl sets as host/target triple. clang wanted to change this (armv7-....) into armv4...., and thus use an ABI with soft-floats. And such a library was not found on the platform (not found by pocl/clang, at least). Both cases used a natively built LLVM+Clang 3.1. I had no problems building it with the standard "./configure" on either distro (well, except that on the 12.04 clang didn't work). As toolchain I used what gcc the ubuntu had as default. kalle -- But beware the debugger. Dark side of the source it is. If once you start down the dark path, forever will it dominate your destiny. Consume you it will. ------------------------------ Message: 6 Date: Tue, 16 Oct 2012 17:26:14 +0300 From: Pekka J??skel?inen <[email protected]> Subject: Re: [pocl-devel] build pocl-0.6 on ARM board To: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 10/16/2012 04:11 PM, Kalle Raiskila wrote: > I tried on ubuntu 11.04 too, with more success - clang was able to > compile 'hello_world.c', at least. But with pocl, I noticed that the > clang-binary does not like what the ./configure of pocl sets as > host/target triple. clang wanted to change this (armv7-....) into > armv4...., and thus use an ABI with soft-floats. And such a library was > not found on the platform (not found by pocl/clang, at least). Seems all these problems are related to Clang vs gcc mismatches. More specifically the problem comes from building the kernels and the metadata plugins (using clang) with incompatible ABI/target specifics in comparison to what the pocl loader was compiled with (using gcc). Did you try if LLVM 3.2 works any better? -- --Pekka ------------------------------ ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ------------------------------ _______________________________________________ pocl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pocl-devel End of pocl-devel Digest, Vol 13, Issue 6 ***************************************** ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ pocl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pocl-devel
