On 11/11/2013 04:35 PM, Tom Stellard wrote: > One thing I've discussed with some developers from Intel is moving > Clover's OpenCL code into core Mesa, which would make it possible for > an external OpenCL implementation, like Beignet to be moved into the > Mesa tree. This would make it possible to port Pocl's backends to > Mesa. Do you have any thoughts about this?
We discussed this briefly at IRC with Tom. The conclusion (as far as I can see, Tom please add) is: * Creating a generic "low level" compute API (to Mesa or Gallium) that both supports OpenCL 1.2 and 2.0 (and even other heterogeneous compute APIs like CUDA, OpenACC, C++AMP, ...) is not easy without ending up with a set of OpenCL-specific APIs like pocl's device layer or with most of the OpenCL APIs included. * Also more capable (GP)GPU devices than the currently supported GPUs might be supported in the future in Mesa by extending the Clover 'core' API. E.g., to support more scheduling/control/coordination in the devices than just executing a single kernel at a time initiated by the host. How to coordinate the "big picture" (whole platform) will remain to be figured out. * Getting to a situation where we have a fully open OpenCL stack with both an efficient CPU/SIMD device and one or more GPU devices in the same platform (for efficient event-based synch and optimization as an entity) means either a) doing an implementation of the (possibly) upcoming Clover core API for pocl's CPU drivers (basic and/or pthread) that also calls the kernel compiler to produce the parallelizable work-group functions, or b) creating a pocl device layer implementation that calls the upcoming core API for any GPU devices supporting it * Combination of efforts in the open OpenCL implementation would happen in these alternatives as follows: a) Clover host API implementations, libclc built-in libs for GPUs, kernel compiler of pocl for MIMD machines (CPU+SIMD, VLIW), optimized built-in libs for CPUs (ARM, x86(-64), ppc...) b) pocl host API implementations, libclc built-in libs for GPUs, kernel compiler of pocl for MIMD machines (CPU+SIMD, VLIW), optimized built-in libs for CPUs (ARM, x86(-64), ppc...) Unfortunately a) does not fulfill our use cases in the current research projects at TUT. We need the host API in C for cross- compilation scenarios to bare bone machines without proper C++ support or operating systems (e.g. simple soft-cores in FPGAs that also run the host/control code - the 'standalone' scenario). Clover is implemented in C++. Also, we have some work ongoing related to the top level app optimization for multiple device out-of-order queue programs which relies on the current host lib structure. Implementing both alternatives might be a way, but then there will be duplication of work in the host APIs. Oh well, nothing's perfect, I guess :) If you Tom go forward with the Clover 'core' API separation, let me know, and I'll find time to try the b). BR, -- --Pekka ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ pocl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pocl-devel
