There are already some ideas on GitHub issues, https://github.com/triSYCL/triSYCL/issues and internally to Xilinx https://gitenterprise.xilinx.com/rkeryell/triSYCL/issues
Some ideas of future developments where you can contribute too: :-)
- go on using the official OpenCL SYCL conformance test suite (CTS) to extend/debug/validate this implementation;
- finish implementation of basic classes without any OpenCL support to have SYCL 1.2.1 passing the CTS on CPU;
- go on extending the device compiler, based on Clang/LLVM and some specific runtime, to generate OpenCL/SPIR from C++ single-source kernels;
- move to CMake even for the device compiler for better portability the tests;
- improve the test infrastructure (for example move to something more standard with Boost.Test. Status: started) instead of having some tests using LIT to test some textual output;
- update the dataflow SYCL infrastructure from plain C++
std::thread
andstd::condition_variable
to some more efficient library, such as TBB; - implement the dataflow SYCL infrastructure directly on top of OpenCL event-framework instead of layering the CPU dataflow dependency graph on top of it;
- add vector swizzle support by following ideas from https://github.com/gwiazdorrr/CxxSwizzle http://glm.g-truc.net http://jojendersie.de/performance-optimal-vector-swizzling-in-c http://www.reedbeta.com/blog/2013/12/28/on-vector-math-libraries ;
- add OpenCL 2.x support with SYCL 2.x;
- since SYCL is a pretty general programming model for heterogeneous computing, if the OpenCL compatibility layer is not required, some other back-ends could be written besides the current OpenMP one: CUDA, RenderScript, OpenAMP, etc.
- make an alternative accelerator version based on OpenMP 4 accelerator target, OpenHMPP or OpenACC;
- make an alternative accelerator version based on wrapper classes for the C++AMP HCC Open Source compiler;
- SYCL concepts (well, classes) can also be ported to some other languages to provide heterogeneous support: SYJSCL, SYCamlCL, SYJavaCL... It is not clear yet if SYFortranCL is possible with Fortran 2008 or 2015+.