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 _______________________________________________ pocl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pocl-devel
