From: Savonichev, A. <and...@in...> - 2019-02-18 13:08:17
|
Hi Pekka, Pekka Jääskeläinen wrote: > 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. We have our own set of OpenCL specific LLVM passes, which we are going to upstream to LLVM.org at some point. Some of our passes are really similar to LLVM passes implemented in POCL[1], so I guess it makes sense for us to collaborate on this. > > 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. Visibility is very important, but there are also some of technical reasons to do this. Compiler engineers who contribute OpenCL specific changes to LLVM or Clang will be able to test their changes on a "reference" OpenCL runtime. Since the runtime is a subproject, it is always in sync with LLVM and buildbots can enforce this. In addition to that, if we assume that all passes are moved to LLVM, vendors who do not use the opencl subproject will still be able to use these passes. > >> 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. Good idea. I will follow up on this off-list. [1]: https://github.com/pocl/pocl/tree/master/lib/llvmopencl -- Andrew |