The Khronos Group - a non-profit industry consortium to develop, publish and promote open standard, royalty-free media authoring and acceleration standards for desktop and handheld devices, combined with conformance qualification programs for platform and device interoperability.

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Official SYCL 1.2 Provisional feedback thread

March 19, 2014 – San Francisco, Game Developer’s Conference – The Khronos™ Group today announced the release of SYCL™ 1.2 as a provisional specification to enable community feedback. SYCL is a royalty-free, cross-platform abstraction layer that enables the development of applications and frameworks that build on the underlying concepts, portability and efficiency of OpenCL™, while adding the ease-of-use and flexibility of C++. For example, SYCL can provide single source development where C++ template functions can contain both host and device code to construct complex algorithms that use OpenCL acceleration - and then enable re-use of those templates throughout the source code of an application to operate on different types of data.

The SYCL 1.2 provisional specification supports OpenCL 1.2 and has been released to enable the growing community of OpenCL developers to provide feedback before the specification is finalized. The specification and links to feedback forums are available at: www.khronos.org/opencl/sycl.

While SYCL is one possible solution for high-level parallel programming that leverages C++ programming techniques, the OpenCL group encourages innovation in diverse programming models for heterogeneous systems, including building on top of the SPIR™ low-level intermediate representation, using the open source CLU libraries for prototyping, or through custom techniques.

“Developers have been requesting C++ for OpenCL to help them build large applications quickly and efficiently and there are lots of useful C++ libraries that want to port to OpenCL,” said Andrew Richards, CEO at Codeplay and chair of the SYCL working group. “SYCL makes this possible and we are looking forward to the community feedback to help drive the final release and future roadmap. We are especially keen to work with C++ library developers who want to accelerate their libraries using the performance of OpenCL devices.”

Going through the specs slowly. Very high level feedback is that we need more examples. I already mentioned this to Andrew on twitter.
Also, compilation workflow is really unclear.
For example:

1. Let us say I have my favourite C++11 compiler installed. GCC, VS2013 whatever. Let's say I do NOT have any other compilers installed, nor any OpenCL drivers and just want to compile SYCL code to (parallel) native code using my native compiler. I guess this will require you to release some header files so that classes such as cl::sycl:buffer are understood by the C++ compiler to allow it to generate CPU code. This will be useful for development at least and for porting code to platforms where OpenCL drivers are not available (eg: WinRT).
Will this supported? If so, how do things work? Should we expect a royalty-free solution for this?

2. Single-source SYCL compilers are easy to understand. These will take all your source files, including both regular C++ and SYCL, and generate a single binary containing both host and device code. What about multi-compiler solutions mentioned? Are those solutions likely to look like, say, nvcc? I.e. compiling device code itself and inserting any required glue code for host, and then pass all the original host code as well as generated host code to available C++ compiler such as gcc, vs etc.?

Any SYCL implementation is require to support execution of any code on the host CPU using just the host compiler as well as execution of device code on one or more OpenCL devices. A host-only implementation would not be conformant, but you could use a conformant implementation of SYCL to run code only on host.

SYCL is a royalty-free standard. Whether a specific implementation has licensing terms requiring payment or royalties is up to individual implementers.

How SYCL is compiled is not actually defined in the spec. This was a deliberate decision to allow implementers freedom. However, an implementation could operate like this:

You compile your source file with a SYCL device compiler and it produces a header file containing the compiled kernel and implementation-specific glue code to invoke the kernel on an OpenCL device. E.g. mysyclcompiler mysourcefile.cpp -omysyclheader.h

Then you could compile the same source file with your host compiler and tell it where the compiled kernel header is. E.g. gcc -c -DSYCLHEADER="mysycleheader.h" mysourcefile.cpp

More examples would definitely help in describing the features of the SYCL specification and this is something that we are currently looking into. We will shortly be posting a series of blogs on the Codeplay website that will be aimed at describing the SYCL programming model and the available work flow solutions as well as providing more practical examples.

p.14: "For a kernel to access local memory on a device, the user can either create a dynamically-sized local accessor object to the kernel as a parameter." -- typically "either" is followed by an "or", and also "to the kernel as a parameter" seems like it is missing something ahead of it.

p.75: "the device." is hanging there by itself with blank space above it. It seems like something is missing prior to it.

I am happy to see something like SyCL develop. The question of how to we best program accelerators is still unanswered. I doubt there is an universal answer at all. The more things we try, the closer we will get to a satisfying solution. So I applaud your efforts. I read the provisional specification and I have a few questions and comments:

* SyCL is not something that can be implemented as a standard C++ library but is a compiler extension or an additional compiler, not unlike C++ AMP is that correct?

* command_group: this concept seems to try to fuse memory transfer and compute together; with command_groups are things like pipelines and double-buffering still possible? How would one go about implementing overlapping copy and compute using the command_group concept?

* The accessor seems interesting - it's actual usefulnesses can best be assessed once we can implement code using SyCL: when can we expect a working prototype? I really dislike the name "accessor" though. C++ AMP calls this an array_view which is a lot nicer.

* I dislike the name of the queue concept; it is too generic and usually means something completely different. I know there is the namespace but still. I obsessed about the exact name for the thing that is a stream or a command_queue and came up with the concept of a 'feed' in my GPU library Aura.

SYCL defines two components; a C++ runtime library and a device compiler. The SYCL runtime library uses C++11 features, however as it includes OpenCL language extensions, no new language extensions are required.

As SYCL is asynchronous; all commands defined within a command_group are enqueued asynchronously, double buffering can be achieved automatically by the runtime providing that the command_groups or the individual commands are defined such that they can be executed in parallel.

There is currently no implementation of SYCL available, the only announced implementer is Codeplay. If you are interested in more practical examples of SYCL, a series of blogs will be posted on the Codeplay website, the first of these can be found here.

SYCL is still in the provisional stage of specification and is therefore still subject to change based on the feedback from potential developers and implementers so any feedback regarding naming and the programming model are appreciated and will be discussed within the Khronos working group.

The SYCL header sycl.hpp includes cl.h, but doesn't not include cl.hpp. SYCL is an alternative to the C++ wrappers and does not conflict with them, therefore they will continue exist as part of OpenCL as long as the OpenCL working group maintains them.