/triSYCL

An open source implementation of OpenCL SYCL from Khronos Group

Primary LanguageC++OtherNOASSERTION

triSYCL

1   News

  • 2017/03/03: triSYCL can use CMake & ctest and works on Windows 10 with Visual Studio 2017. It works also with Ubuntu WSL on Windows. :-) More info
  • 2017/01/12: Add test case using the Xilinx compiler for FPGA
  • 2016/11/18: If you missed the free SYCL T-shirt on the Khronos booth during SC16, you can always buy some on https://teespring.com/khronos-hpc (lady's sizes available, so no excuse! :-) )
  • 2016/08/12: OpenCL kernels can be run with OpenCL kernel interoperability mode now.
  • 2016/04/18: SYCL 2.2 provisional specification is out.
  • This version implement SYCL 2.2 pipes and reservations plus the blocking pipe extension from Xilinx.

2   Table of content

Contents

3   Introduction

triSYCL is an open source implementation to experiment with the specification of the OpenCL SYCL 1.2.1 and 2.2 C++ layer and to give feedback to the Khronos OpenCL SYCL and OpenCL C++ 2.2 kernel language committees.

This SYCL implementation is mainly based on C++1z (2017?) and OpenMP with execution on the CPU right now, but some parts of the non single-source OpenCL interoperability layer are implemented and the device compiler development is on-going for SPIR and SPIR-V. Since in SYCL there is a host fall-back, this CPU implementation can be seen as an implementation of this fall-back too...

The parallel kernels can be executed in parallel on the CPU with OpenMP in the first range dimension, if compiled with OpenMP support or on an OpenCL device with the interoperability mode (which is not single source)

For legal reasons, the specification used for this open source project is the published current provisional specification and not the last one currently discussed in the Khronos OpenCL SYCL committee. If you are a Khronos member, you can access to https://gitlab.khronos.org/sycl/triSYCL where you might find more futuristic branches.

This is provided as is, without any warranty, with the same license as LLVM/Clang.

Technical lead: Ronan at keryell point FR. Developments started first at AMD and are now mainly funded by Xilinx.

4   OpenCL SYCL

OpenCL SYCL is a single-source C++14/C++17-based DSEL (Domain Specific Embedded Language) aimed at facilitating the programming of heterogeneous accelerators by leveraging the OpenCL language and concepts.

Note that even if the concepts behind SYCL are inspired by OpenCL concepts, the SYCL programming model is a very general asynchronous task graph model for heterogeneous computing with no relation with OpenCL itself, except when using the OpenCL API interoperability mode.

OpenCL SYCL is developed inside the Khronos OpenCL SYCL committee and thus, for more information on SYCL, look at http://www.khronos.org/sycl

For the SYCL ecosystem, look at http://sycl.tech

4.1   Why you could use SYCL

SYCL has a lot of interesting advantages compared to plain OpenCL or other approaches:

  • SYCL is an open standard from Khronos with a working committee (you can contribute!) and we can expect several implementations (commercial or open source) on many platforms soon, ranging from GPU, APU, FPGA, DSP... down to plain CPU;

  • it offers a single-source C++ programming model that allows taking advantage of the modern C++14/C++17 superpower, unifying both the host and accelerator sides. For example it is possible to write generic accelerated functions on the accelerators in a terse way by using (variadic) templates, meta-programming and generic variadic lambda expressions. This allows to build templated libraries such as Eigen or TensorFlow in a seamless way;

  • SYCL abstracts and leverages the concepts behind OpenCL and provides higher-level concepts such as tasks (or command group in OpenCL SYCL jargon) that allow the runtime to take advantage of a more task graph-oriented view of the computations. This allows lazy data transfers between accelerators and host or to use platform capabilities such as OpenCL 2 SVM or HSA for sharing data between host and accelerators;

  • the entry cost of the technology is zero since, after all, an existing OpenCL or C++ program is a valid SYCL program;

  • the exit cost is low since it is pure C++ without any extension or #pragma, by opposition to C++AMP or OpenMP for example. Retargeting the SYCL classes and functions to use other frameworks such as OpenMP 4 or C++AMP is feasible without rewriting a new compiler for example;

  • easier debugging

    • since all memory accesses to array parameters in kernels go through accessors, all the memory bound checks can be done in them if needed;
    • since there is a pure host mode, the kernel code can be run also on the host and debugged using the usual tools and use any system (such <cstdio> or <iostream>...) or data libraries (for nice data visualization);
    • since the kernel code is C++ code even when run on an accelerator, instrumenting the code by using special array classes or overloading some operators allows deep intrusive debugging or code analysis without changing the algorithmic parts of the code;

  • SYCL is high-level standard modern C++ without any extension, that means that you can use your usual compiler and the host part can use at the same time some cool and common extensions such as OpenMP, OpenHMPP, OpenACC,... or libraries such as MPI or PGAS Coarray++, be linked with other parts written in other languages (Fortran...). Thus SYCL is already Exascale-ready!

  • even if SYCL hides the OpenCL world by default, it inherits from all the OpenCL world:

    • same interoperability as the OpenCL underlying platform: Vulkan, OpenGL, DirectX...
    • access to all the underlying basic OpenCL objects behind the SYCL abstraction for interoperability and hard-core optimization;
    • construction of SYCL objects from basic OpenCL objects to add some SYCL parts to an existing OpenCL application;
    • so it provides a continuum from higher-level programming à la C++AMP or OpenMP 4 down to low-level OpenCL, according to the optimization needs, from using simple OpenCL intrinsics or vector operation from the cl::sycl namespace down to providing a real OpenCL kernel to be executed without requiring all the verbose usual OpenCL host API.

    This OpenCL seamless integration plus the gradual optimization features are perhaps the most compelling arguments for SYCL because it allows high-level programming simplicity without giving-up hard-core performance when needed;

  • since the SYCL task graph execution model is asynchronous, this can be used by side effect to overcome some underlying OpenCL implementation limitations. For example, some OpenCL stacks may have only in-order execution queues or even synchronous (blocking) ND-range enqueue, or some weird constrained mapping between OpenCL programmer level queue(s) and the hardware queues.

    In this case, a SYCL implementation can deal with this, relying for example on multiple host CPU threads, multiple thread-local-storage (TLS) queues, its own scheduler, etc. atop the limited OpenCL stack to provide computation and communication overlap in a natural pain-free fashion. This relieves the programmer to reorganize her application to work around these limitation, which can be quite a cumbersome work.

for introduction material on the interest of DSEL in this area, look for example at these articles:

4.2   Some other implementations

Some other known implementations:

4.3   Some presentations and publications related to SYCL

By reverse chronological order:

There are also many interesting articles in the publication list from Codeplay.

4.4   Related projects

5   OpenCL triSYCL code documentation

The documentation of the triSYCL implementation itself can be found in http://xilinx.github.io/triSYCL/Doxygen/triSYCL/html and http://xilinx.github.io/triSYCL/Doxygen/triSYCL/triSYCL-implementation-refman.pdf

6   Installation

Only Clang 3.9+ or GCC 5.4+, Boost.MultiArray (which adds to C++ the nice Fortran array semantics and syntax), Boost.Operators and a few other Boost libraries are needed.

To install them on latest Linux Debian/unstable (this should work on latest Ubuntu too, just adapt the compiler versions):

sudo apt-get install clang-3.9 g++-6 libboost-dev

There is nothing else to do for now to use the include files from triSYCL include directory when compiling a program. Just add a -I.../include option and -std=c++1y when compiling.

triSYCL is configurable through preprocessor macros described in macros.

Also use -fopenmp if you want to use multicore parallelism on the CPU.

The CMake support is described in doc/cmake.rst.

7   Examples and tests

There are simple examples and tests in the tests directory. Look at tests/README.rst description.

7.1   Generating the Doxygen documentation

In the top directory, run

make

that will produce tmp/Doxygen/SYCL with the API documentation and tmp/Doxygen/triSYCL with the documented triSYCL implementation source code.

To publish the documentation on GitHub:

make publish

and finish as explained by the make output.

8   Possible futures

Some ideas of future developments where you can contribute too: :-)