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