[SYCL] PI interface.

[romanovvlad]

Signed-off-by: Vlad Romanov [email protected]

[keryell]

The concept is super useful.
We need this to have SYCL more general!
But SYCL is about modern C++ and reimplementing a C-like ICD in SYCL seems not like the right abstraction in 2019. OpenCL is written in C with its limitations...
You are reimplementing dynamic polymorphism in C while it is already available in C++.
An alternative approach can be to have the SYCL implementation classes inheriting from some more or less abstract classes and the SYCL runtime can just use transparently a launch kernel virtual member function of the device class to redirect to the actual kernel launch.
The ICD C-like method does not solve well the adaptation problem because it forces at the first place to encapsulate any runtime (even when written in C++!) to the same low-level C method...
I planned to come with an example of this in triSYCL about using dynamic polymorphism for these extensions triSYCL/triSYCL#237 but we are late... I made some presentation in the SYCL committee with some ideas and in triSYCL there is already the use of dynamic polymorphism but without the ability to inject different runtime on the fly yet...
Your plug-in mechanism can be a class inheriting from the runtime interface and implementing various operations or customization points.
A multilayered abstraction seems better suited than going directly down to the metal, because probably some SYCL implementation parts will be common to some classes of devices or API (for example some devices require eager buffer allocation, other lazy late allocation, and this does not fit well is a low-level only approach).

[keryell]

Looks to me like the start of the idea of a virtual table... :-)

[smaslov-intel]

Right, this is how C-interface implements it.

[smaslov-intel]

please review #222 and leave any further comments there.

[keryell]

You might be kidding, I guess... :-)

[keryell]

The OpenCL ICD exists just because it is implemented in C according to 1970's techniques...
SYCL is about modern C++...
Your method can work actually, just by reusing the OpenCL ICD or the OpenCL intercepting layer from Intel.
But then do it there, not inside the SYCL implementation.

[smaslov-intel]

This comment moved to #222 for any further discussion there.

[romanovvlad]

The concept is super useful.
We need this to have SYCL more general!
But SYCL is about modern C++ and reimplementing a C-like ICD in SYCL seems not like the right abstraction in 2019. OpenCL is written in C with its limitations...
You are reimplementing dynamic polymorphism in C while it is already available in C++.
An alternative approach can be to have the SYCL implementation classes inheriting from some more or less abstract classes and the SYCL runtime can just use transparently a launch kernel virtual member function of the device class to redirect to the actual kernel launch.
The ICD C-like method does not solve well the adaptation problem because it forces at the first place to encapsulate any runtime (even when written in C++!) to the same low-level C method...
I planned to come with an example of this in triSYCL about using dynamic polymorphism for these extensions triSYCL/triSYCL#237 but we are late... I made some presentation in the SYCL committee with some ideas and in triSYCL there is already the use of dynamic polymorphism but without the ability to inject different runtime on the fly yet...
Your plug-in mechanism can be a class inheriting from the runtime interface and implementing various operations or customization points.
A multilayered abstraction seems better suited than going directly down to the metal, because probably some SYCL implementation parts will be common to some classes of devices or API (for example some devices require eager buffer allocation, other lazy late allocation, and this does not fit well is a low-level only approach).

Hi Ronan,

Thank you for your comments!

We had to completely rework the patch, new patch is here #222. Some of your
comments were addressed, some weren't yet. Unfortunately, we can't move the
comments to the new pull request. Most of the design related comments still
applicable to the new patch, so let's discuss them there.