Hi,
Thank you for the answers. I will definitely look into this and try to at
least add some extra search directories (not sure which ones, perhaps
through an environment variable?) or support for relative paths for the
_kernel.h and *.bc files.
I had a look at what Pekka wrote about supporting multiple binary-coded
files (compiling them during installation - or perhaps first use - or not
using pre-compiled functions altogether) and although they really seem to
be the proper solutions, but they do indeed sound like a larger project.
The only disadvantage that I see with these solutions is that in this case
the sources would have to be installed with pocl - or, like in my case,
where I do not want to force users to always install pocl system wide,
packaged with my application.
In my case at least I would actually prefer to have a set of pre-compiled
*.bc files and a run-time discovery mechanism for choosing the right one
(AVX, AVX2, SSE4 - falling back to a minimum of, say, a SSE2/3 machine).
This would go more along the lines of what Kalle suggested, and I think
that I will go this way (at least at first).
One unrelated question: the cmake build does not seem to support the
generation of the static libs, am I'm missing something or is this really
not yet supported?
Thanks again,
Tiago
On Tue, Apr 21, 2015 at 2:05 PM, Pekka Jääskeläinen <
[email protected]> wrote:
> Hi,
>
> 20.4.2015 0:41, Tiago Gehring kirjoitti:
>
>> i) The _kernel.h and the kernel_*.bc files (not sure if others as
>> well) seem to be hardcoded at compilation time. Is it possible to
>> specify an alternative (or relative) path at runtime? The reason is
>> that I don't
>>
>
> Not at the moment, I'm afraid. If you want to contribute,
> the code for this is in pocl_llvm_api.cc's kernel_library()
> function.
>
> ii) I saw from some discussions in this mailing list that there was a
>> proposal for adding support for multiple target CPUs (i.e.
>> kernel_*.bc). Is this still planned (or already supported)? It would
>> be great to pre-compile a few different kernels (e.g. SSE4 only, AVX,
>> AVX2 and so on) and having a runtime discovery mechanism.
>> Alternatively I would like to pre-compile those kernels anyway (even
>> if this means one full pocl build per architecture) and just having
>> users (or an automatic mechanism) choose the correct *.bc file once
>> (renaming or symlinking it to a predefined location);
>>
>
> There were discussions and planning, but I'm not aware of anyone
> starting to actually implement it. So if you wish to implement it,
> this feature is very much welcomed (especially from distribution binary
> package point of view it's crucial for performance).
>
> When we discussed this the last time, I scetched a plan for this
> (mainly as a description for a possible student project):
>
> https://github.com/pocl/pocl/wiki/Install-time-or-run-time-built-kernel-builtin-libraries
>
> BR,
> --
> Pekka
>
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
pocl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pocl-devel
