On 10/05/2014 12:31 PM, O. Hartmann wrote: > I'm not so familiar with the mainstream development, but considering the > dramatic speed of OpenCL development and support of OpenCL 2.0 by hardware > (Intel Broadwell's iGPU is supposed to be OpenCL 2.0 compliant) my personal > vote would be the last option. I understand the terms of OpenCL 2.0 that way, > that it is backward compatible.
Yes, I think this is the way to go. Go towards the 2.0 support by default. If there is an user of pocl that wishes to implement older-version compliance first using pocl for their hardware for some reason, they can just not link in the functions introduced in the later versions of the specs. And perhaps send patches for building pocl in 1.0/1.1/1.2 mode, if there are backward incompatibilities. Speaking on our research project's behalf, we do not need such a mode as we are going to utilize the nice new 2.0 features in our work. For the ICD 2.0. The last time I checked, the dispatch table was not published, even though they claimed in the specs that icd_dispatch.h is available. Therefore, pocl's dispatch table is not populated with the 2.0 functions (we haven't implemented them yet anyways). I assume ocl_icd.h has reverse engineered them from some vendor implementation by now, so we could populate the missing OCL 2.0 functions in case the license allows. BTW, Vincent, any hope for getting pocl into the next Debian Stable? :> -- --Pekka ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ pocl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pocl-devel
