From: Pekka J. (T. <pek...@tu...> - 2019-02-15 06:05:49
|
Hi Andrew, Savonichev, Andrew kirjoitti 14.2.2019 klo 18.44: > As far as I know, POCL does not support several features that we > support in our proprietary CPU runtime, so if we decide to switch > our development to POCL (with your agreement, of course), we'll need > to port all these features. This includes the features required for > the OpenCL 2.1 Conformance (we have 100% pass rate now), as well as > various performance improvements for Intel CPU. > > What is your opinion on this? I'm glad you are considering this. Open source helps best when it reduces duplicated work and the collaboration via a shared code base leads to improved results for everyone. > OpenCL runtimes, by contrast, are all independent, and have nothing > shared (except maybe for the ICD loader). This situation seems bad > for developers because of effort duplication, but it is also bad from > a user perspective: anyone who tries to make an OpenCL program > portable between different OpenCL implementations, will inevitably > deal with quirks and bugs of each runtime. Right, I personally don't see the benefit in users having to deal with different quirks especially if the different runtimes all conform to a standard and if it's possible to use a fully open option which everyone can improve. > This makes me wonder whether this situation will improve if we have > an OpenCL runtime under the LLVM.org umbrella. LLVM community values > portability a lot, so POCL seems to be a good choice for this > purpose. Have you ever considered upstreaming POCL to LLVM.org? My longer term hope with pocl has been to clean up the generic de-SPMD kernel compiler passes gradually and try to contribute them to the main LLVM project as IR passes. Too bad I don't have enough time for pocl open source maintenance these days so this doesn't seem to realize very quickly without others stepping in to help. About moving rest of pocl under the LLVM.org umbrella as an LLVM project, I'm not sure if it's the logical thing to do, or what the benefits would be outside more visibility. pocl code base is designed such that it does not require LLVM; one can implement device drivers that support only offline compilation and other exotic setups we actively work on in our lab. Of course majority of the devices and use cases rely on Clang/LLVM for online compilation. Having said that, the visibility as such would not hurt, so I'm open for this. > Anyway, our plans are not finalized yet, and I will be happy to hear > any feedback. If you decide to move on with merging your code towards pocl code base, let's have a technical telco or even a face-to-face on how to proceed. In any case, don't hesitate to ask further questions. Regards, -- Pekka |