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.

POST A COMMENT

7 Comments

View All Comments

  • JDG1980 - Wednesday, March 19, 2014 - link

    WebCL? Really? I wonder how long it will be before people start writing pages designed so that whenever your browser visits the page, it will use your GPU to do scrypt mining in the background (for their benefit). Reply
  • inighthawki - Wednesday, March 19, 2014 - link

    WebCL just sounds like a giant security hole in the making. I can't think of a SINGLE reason why I would need GPU compute on the web. Not a single one.

    Let me know when browsers start supporting this so I can disable it first thing :)
    Reply
  • ddriver - Wednesday, March 19, 2014 - link

    I think the whole "web" moniker is getting ridiculous. There can be found a use for GPU compute in applications running in browsers, but hey - that's as simple as linking the browser executable to OpenCL - really no need for yet-another-standard.

    God forbid the implementations suck as much as WebGL does...
    Reply
  • matt321 - Thursday, March 20, 2014 - link

    The use-cases I can think of would be something like Photoshop or a Near-Line Editor in a Chrome Browser, something used on a Chromebook, to expedite exports, renders, etc. Reply
  • Haravikk - Monday, March 24, 2014 - link

    As Matt says, this is useful for continuing with the ability to port programs from traditional native apps to fully web-based versions. Currently any kind of complex number crunching is extremely difficult to do efficiently in Javascript alone, meanwhile OpenCL presents a very powerful abstraction allowing an app (web or otherwise) to easily take fuller advantage of both CPU and GPUs in a system. The security concerns are of course understandable, but this could potentially allow web-based games to implement very sophisticated physics engines.

    For example, the web-based version of the Unreal engine uses asm.js to more efficiently compile code ported from C/C++, but it's still stuck within Javascript's comparatively limited environment. If you read articles about it then the main stumbling block is when too many physics operations are needed, as they start to interrupt rendering since everything is forced to work in a single main thread. By offloading physics to WebCL the web version of Unreal could actually truly start to approach native levels of performance, even more so whenever WebGL gets updated to match the upcoming OpenGL version (which should reduce reliance on the CPU)
    Reply
  • extide - Wednesday, March 19, 2014 - link

    There is already an implementation of a bitcoin miner like this... Reply
  • Haravikk - Monday, March 24, 2014 - link

    Interesting stuff, especially this SYCL update for OpenCL; as much as I like C, if you're working in C++ already then diving between the two languages gets to be a huge pain for developing with any consistency, so it'll be nice to see C++ support at last.

    One thing I'd really like to see the Khronos group look toward is allowing OpenCL to actually issue OpenGL commands; rather than trying to follow what AMD are doing with Mantle. This would allow a program to effectively offload some or all of its rendering engine entirely onto the GPU, leaving the CPU to only process what commands need to be issued to change view point, add/remove objects in the scene and so-on. With a suitably re-structured version of OpenGL with that in mind, we could end up with a truly significant modern rendering system. Especially since a game could dispatch different rendering engines to different GPUs. For example, in a system with integrated GPU and a discrete GPU the main rendering engine would go to the discrete GPU, while a "helper" engine would go to the integrated one to handle things like off-screen rendering jobs.

    I think SYCL probably is needed first to make such a system easier to develop with, but it could be extremely powerful, and potentially give us a truly modern OpenGL that's ahead of other APIs for a change.
    Reply

Log in

Don't have an account? Sign up now