On 11/22/2013 01:35 AM, Erik Schnetter wrote: > I noticed that almost nothing in pocl depends on the fact that kernels are > written in OpenCL C. With a minimal patch, we can support other languages > as well. And when discussing OpenCL with others, I generally find that most > people would prefer to have some kind of templating mechanism available, as > is offered e.g. by C++. > > What do you think?
One of the motivations of the SPIR work is to enable this in a portable fashion. So, AFAIU, the standard way to support other languages will be to produce SPIR binaries from a compiler and load them as cl_programs in the OpenCL runtime instead of sources or vendor and device-specific binaries. How the kernels are compiled is unclear; whether one is able to use the standard OpenCL compilation APIs to produce the SPIR binaries or not. > This is the patch required for pocl to accept a kernel build option > "-DPOCL_KERNEL_CXX" that builds kernel as C++ instead of as OpenCL C: How would, the C++ kernels relate to the SPMD programming model? Expose the barrier() and other OpenCL C built-ins to it, just use C++ as the language and let the work-group generator phase deal with the barrier semantics? Or allow other languages just in the "task mode" (1WI WGs) only? Quickly thinking, both alternatives should work. Perhaps to support this initially we can remain "standards conformant" by using the OpenCL vendor extension mechanism so one can query if a device supports an extension that allows describing the kernels in C++? E.g. cl_pocl_cxxkernels. However, when we support SPIR then the app can both remain portable (to platforms that support SPIR) and use whatever languages that can produce SPIR output. So I suggest to check how easy it would be to switch to use SPIR as our internal IR in the pocl. Or at least as a supported input. Using it as a "pocl IR" could help us to fix the long living kernel ABI-related bugs 54: struct kernel arguments - lp:987905 55: vector kernel arguments - lp:987905 Because SPIR now defines how the aggregates are passed to kernels (as pointers). These cases now break as they might split the aggregates to multiple function arguments according to the target's CC/ABI and we cannot map them 1:1 to the clSetKernelArg parameters. -- Pekka ------------------------------------------------------------------------------ Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk _______________________________________________ pocl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pocl-devel
