Following Monday’s announcement of OpenGL ES 3.1, Khronos is back again with a slate of new standards announcements. Unlike Monday’s focus on OpenGL ES, the bulk of these announcements fall on the compute side of the spectrum, which for Khronos and its members is still a new and somewhat unpredictable market to participate in.

WebCL 1.0

The headliner for today’s specification releases is WebCL, Khronos’s standard for allowing OpenCL within a web browser. Khronos has been working on the standard for nearly 2 years in draft form, and as of today the final specification is being released.

With WebCL Khronos and its members are looking to do for OpenCL what WebGL has done for OpenGL, which is to make a suitable subset of these APIs available in browsers. With heavy “web application” style websites continuing to grow in popularity, the idea is to expose these APIs to programs running in a web browser, to reap the many of the same benefits that native programs would have from using the full-fledged version of their respective API. WebGL has already seen some success in offering hardware accelerated 2D/3D graphics within browsers, and now Khronos has turned their eye towards high performance heterogeneous computing with WebCL.

Fundamentally, WebCL is based on the OpenCL 1.1 Embedded Profile. OpenCL 1.1 EB is a scaled down version of OpenCL that was originally designed to be a better fit for embedded and other non-desktop devices, offering a relaxed set of OpenCL 1.1 features that are better matched to the more limited capabilities of hardware in this class. This means that devices and web browsers that implement just the baseline WebCL specification won’t have access to the full capabilities of OpenCL, but many of the differences come down to just floating point precision and memory access modes. Not surprisingly then this makes WebCL a lot like WebGL: WebGL is based on OpenGL ES, Khronos’s OpenGL standard for handheld/embedded devices, and now WebCL is based on Khronos’s OpenCL standard for handheld/embedded devices.

Ultimately with WebCL Khronos is looking at solving the same general issues that led to OpenCL in the first place: the need for high performance computing, chiefly on non-CPU devices. On the consumer desktop OpenCL hasn’t been a massive success so far but it does have its niches, and those niches are expected to be similar for web based applications. This would mean image manipulation would be a strong use case for WebCL, similar to how we see OpenCL and OpenGL used together on the desktop, the API reflecting which style of programming is faster for the algorithm at hand. Though as with WebCL, as an open ended compute programming environment, it’s up to programmers to figure out how to best fit it in to their workflows.

In the meantime however, Khronos and its members have first needed to address the potential security implications of WebCL, which is part of the reason it has been in development for so long. The release of WebGL brought to light the fact that GPU drivers weren’t fully hardened against exploitation, due to the fact that until WebGL there was an implicit assumption that all code was trusted before it was being run in the first place, an assumption that is not true for web environments. WebCL in turn has amplified these concerns due to the fact that it is a far more flexible and powerful environment, and conceivably would be easier to exploit.

The end result is that a number of steps have been taken to secure WebCL against exploits. Chief among these steps, a collection of inherently risky OpenCL features have been dropped, particularly pointers (pointers can be used safely, but often are not). At the same time the WebCL environment itself will undertake its own exploit mitigation efforts; the runtime dynamically checks for exploit behavior, and Khronos is providing a validation tool for developers to do static kernel analysis to identify potential security problems ahead of time. Finally, driver vendors have played their own part in locking down WebCL (being the final failsafe), hardening their drivers against attacks and implementing better context management to ensure that contexts stay separated (the WebCL equivalent of preventing a XSS attack). Ultimately we can only wait and see how well WebCL is going to be able to resist attacks, but it’s clear that Khronos and its members have put a lot of thought and effort into the matter.

SYCL 1.2

Khronos’s second announcement of the day is SYCL 1.2 SYCL (pronounced like sickle) is being released as a provisional specification, and is designed to provide an abstraction layer for implementing C++ on OpenCL. SYCL in turn builds off of SPIR, the standard portable intermediate representation format for OpenCL.

With SYCL, Khronos is looking to solve one of the greatest programmer demands of OpenCL, which is to enable OpenCL programming in C++. OpenCL itself is based on C, and while the languages have similarities, at the end of the day C is functionally a lower level language than C++, both a blessing and a curse in the case of OpenCL. One of the reasons for the success of competing platforms such as CUDA has been their better support for high level languages like C++, so SYCL is Khronos’s attempt to push ahead in that space. And unlike platforms like CUDA, the wider array of hardware OpenCL supports means that SYCL will be focusing on a few features that don’t necessarily exist on alternative platforms, such as single source C++ programming for OpenCL.

The consumer impact of SYCL is going to be minimal (at least at first), but given SYCL’s intended audience it’s expected to be a very big deal for developers. AMD in particular has a very vested interest in this, as OpenCL is one of the chief platforms intended to expose their Heterogeneous System Architecture; so having C++ available to OpenCL in turn makes it easier to use C++ to access HSA. Though similar principles apply to any program that wants to use C++ to access GPUs and other processors through OpenCL.

Finally, for the moment SYCL is starting out as a provisional specification. Despite the 1.2 version number, this is the first release of SYCL, with the version number indicating which version of OpenCL it’s being designed against – in this case OpenCL 1.2 Future versions of SYCL will target OpenCL 2.0, which should prove to be interesting given OpenCL’s virtual memory and dynamic parallelism improvements. Though the multi-layered approach of this setup – SYCL is built on SPIR is built upon OpenCL – means that SYCL itself will always trail OpenCL to some extent. SPIR 1.2 was only recently finalized, to give you an idea of where the various standards stand.

EGL 1.5

Khronos’s final announcement of the day is that the EGL specification is now up to 1.5. EGL is not a standard we hear much about, as it’s primarily used by operating systems rather than applications. To that end, EGL in a nutshell is Khronos’s standard for interfacing their other standards (OpenGL, OpenCL, etc) to the native platform windowing system of an OS.

EGL is used rather transparently in a number of operating systems, the most significant of which for the purposes of today’s announcement is Android. Significant portions of the Android rendering system use EGL, which mean that certain aspects of Android’s development track EGL and vice-versa. EGL 1.5 in turn is introducing some new features and changes to keep up with Android, chief among these being enhanced support for 64bit platforms (to coincide with the 64bit Android transition). Also a highlight in EGL 1.5 is the addition of support for sRGB color rendering, which will make it easier for OS and application developers to properly manipulate images in the sRGB color space, improving color accuracy in a class of products that until recently haven’t been concerned with such accuracy.

Finally, EGL 1.5 also introduces some changes to better support WebGL and OpenCL. These are fairly low level changes, but we’re looking at interoperability improvements to better allow OpenGL ES and OpenCL to work together when EGL is in use, and some new restrictions on graphics context creation to better harden WebGL against attacks.