From: Savonichev, A. <and...@in...> - 2019-02-14 16:44:45
|
Hello POCL developers, I work at Intel Compiler team, and we develop the Intel OpenCL Compiler and Runtime for CPU. Our code is based on LLVM and Clang, and it remains proprietary since the early days of development. We are now investigating a possibility to make an open source product by either opening our current codebase, or contributing our LLVM passes and runtime features into an existing open source project. POCL is a great example of such project: it does a very good job being portable, and supports different devices such as CPU, GPU, DSP, etc. 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? Another question is about collaboration between OpenCL implementers. As you probably know, LLVM and Clang are used by majority of OpenCL implementations, and at least the frontend (Clang) is more or less the same in all these implementations. This is really good for end users, because they get a consistent experience from every platform. 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. 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? Anyway, our plans are not finalized yet, and I will be happy to hear any feedback. -- Andrew |
From: Benson M. <ben...@em...> - 2019-02-14 20:37:06
|
Hi, From a user perspective, some choice is good, though one also wants to minimize reduplicated work. Choices allow finding errors when they exist and possibly testing of new features that support a particular hardware advance. How would runtime support for specific features on different hardware be flexibly incorporated, ie. which runtime features should be shared? What will happen to beignet? Regards, Benson On 2/14/19 6:44 PM, Savonichev, Andrew wrote: > Hello POCL developers, > > I work at Intel Compiler team, and we develop the Intel OpenCL > Compiler and Runtime for CPU. Our code is based on LLVM and Clang, and > it remains proprietary since the early days of development. > > We are now investigating a possibility to make an open source product > by either opening our current codebase, or contributing our LLVM > passes and runtime features into an existing open source project. > POCL is a great example of such project: it does a very good job being > portable, and supports different devices such as CPU, GPU, DSP, etc. > > 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? > > Another question is about collaboration between OpenCL implementers. > As you probably know, LLVM and Clang are used by majority of OpenCL > implementations, and at least the frontend (Clang) is more or less the > same in all these implementations. This is really good for end users, > because they get a consistent experience from every platform. > > 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. > > 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? > > Anyway, our plans are not finalized yet, and I will be happy to hear > any feedback. > |
From: Savonichev, A. <and...@in...> - 2019-02-15 08:04:30
|
Benson Muite wrote: > From a user perspective, some choice is good, though one also wants to > minimize reduplicated work. Choices allow finding errors when they > exist and possibly testing of new features that support a particular > hardware advance. I agree that there is some benefit from having a choice between runtimes, but given the fragmentation of the OpenCL ecosystem, it may do more harm than good. > How would runtime support for specific features on different hardware > be flexibly incorporated, ie. which runtime features should be shared? If you look at the available open source OpenCL runtimes, you'll find many repetitive patterns: OpenCL object system (with refcounting), error handling, bindings with LLVM and Clang for JIT-capable runtimes, and many others. Design of many of these features is implicitly enforced by the OpenCL specification, so such similarity is expected. In addition to that, co-existence of different runtimes in the same codebase opens up a possibility of having a "shared context", where buffers or other objects can be shared between devices. See [1] for an example of this. > What will happen to beignet? According to its website[2], starting in Q1'2018, Beignet has been deprecated in favor of NEO OpenCL driver[3]. Beignet still supports Intel platforms up to Haswell, while NEO supports recent platforms starting from Broadwell. [1]: https://software.intel.com/en-us/node/540471 [2]: https://01.org/beignet [3]: https://01.org/compute-runtime > On 2/14/19 6:44 PM, Savonichev, Andrew wrote: >> Hello POCL developers, >> >> I work at Intel Compiler team, and we develop the Intel OpenCL >> Compiler and Runtime for CPU. Our code is based on LLVM and Clang, and >> it remains proprietary since the early days of development. >> >> We are now investigating a possibility to make an open source product >> by either opening our current codebase, or contributing our LLVM >> passes and runtime features into an existing open source project. >> POCL is a great example of such project: it does a very good job being >> portable, and supports different devices such as CPU, GPU, DSP, etc. >> >> 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? >> >> Another question is about collaboration between OpenCL implementers. >> As you probably know, LLVM and Clang are used by majority of OpenCL >> implementations, and at least the frontend (Clang) is more or less the >> same in all these implementations. This is really good for end users, >> because they get a consistent experience from every platform. >> >> 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. >> >> 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? >> >> Anyway, our plans are not finalized yet, and I will be happy to hear >> any feedback. >> -- Andrew |
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 |
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 |