The World Wide Web has several advantages over traditional software platforms. An application or service that is hosted on the web can be accessed from any device at any time, does not have to be installed, is always up-to-date, and facilitates flexible sharing of data and computation between the client and the server. As a result, an increasing number of applications are being developed for, and migrated to, the web.

At the same time, web applications are also becoming more complex, more interactive, and more visual. This creates demand for high-performance computing in a browser environment. Browser vendors have been able to meet this demand by improving the performance of JavaScript execution by orders of magnitude during the past few years. However, JavaScript engines are still unable to match the performance of native code, and they will continue to lag in performance due to the inherent properties of the language. In particular, JavaScript is not designed to exploit the multithreaded data-parallel computing capabilities available on modern GPUs, CPUs, and digital signal processors.

OpenCL, by contrast, is explicitly designed for that purpose. WebCL is a set of JavaScript bindings for OpenCL that aim to provide access to such capabilities from within a JavaScript application. This allows web developers to tackle computationally intensive tasks such as image processing and physics simulation from an environment that they are used to. These classes of applications are prohibitively slow when developed and run in JavaScript alone. To some degree, WebCL (Khronos Group, n.d.) already meets many of these needs, but this is only partially true: WebGL shaders are severely constrained compared to OpenCL kernels, are heavily biased toward three-dimensional graphics, and can only be executed on the GPU.

This chapter discusses preliminary work on using OpenCL in client-side web applications. The version of WebCL described here has been implemented as a Firefox 4.0 extension, mimicking WebGL in the API design. The WebCL version discussed is available at http://webcl.nokiaresearch.com. The system works on multiple platforms and can provide orders of magnitude speed-up over JavaScript when running compute-intensive workloads such as image processing. However, significant challenges remain in the areas of security, robustness, portability, interoperability with WebGL, interfacing to JavaScript engines, and the availability of OpenCL support in the underlying platforms.

The ultimate goal of WebCL is to effectively use all of the underlying computing resources for client-side web applications. Therefore, to reserve and initialize the resources as well as control the execution, we also need a general-purpose framework, a language to describe the processing, and a library to manage the processing.

The approach should be capable of supporting a wide range of device capabilities. For example, mobile and embedded devices typically include a large degree of heterogeneity, with powerful execution environments supported by limited support for programming frameworks. Consequently, the programming language used to describe the computation should be widely and commonly supported by as many platforms as possible, as well as being well known and widely used from a developer's viewpoint.

C is a well-known, widely used, and widely supported language. However, C does not inherently possess any features that support parallel programming and would need enhancements to provide such support. When beginning to consider creating a parallel processing management library, the design suddenly starts to resemble the OpenCL framework. To develop a WebCL framework, this resemblance motivates us to leverage the established approach used for WebGL: a thin layer on top of native drivers, where the native API is bound to JavaScript by following the original API as closely as possible (Table 13.1). The thin layer approach presents us with several benefits: (1) That the adaptation layer has been developed to be as “lightweight” as possible provides for ease of maintenance; (2) porting OpenCL code to WebCL requires minimal effort; and (3) additional abstraction on the native side might restrict the usage, whereas abstracted user-friendly JavaScript utility libraries can be designed on top of this implementation.

Web usage would require that the approach be specified using generic semantics for portability. The programmer should not need to make choices based on the target platform. The framework should not assume binary compatibility nor depend on a fixed set of system libraries. The framework must therefore exclude OpenCL native and binary kernels. Moreover, host pointers are not supported because there is no intuitive mechanism to implement them in JavaScript and because host pointers could be exploited to expose a possible security hole.

In OpenCL, error management is based on checking return codes that come in the form of either return values or output parameters. The status of each operation must be checked individually. JavaScript utilizes exceptions for error handling, enabling the developer to encase a block of code in a try-catch construct.

The WebCL API is provided as a Mozilla Firefox browser extension. The framework discussed previously serves as the starting point for this implementation. WebCL is designed to work together with other state-of-the-art web technologies, some of which, such as WebGL, have been recently introduced or are still under development. The Firefox extension gives us a good experimental starting point.

The usage of WebCL resembles OpenCL coding. The difference from native coding is the host code that is now JavaScript code in web applications. Naturally, the different environments, JavaScript versus C, introduce several differences from the application standpoint, but these differences are not discussed in detail in this chapter. Also, we choose to omit checks that are normally essential when developing quality applications. The emphasis in these examples is on highlighting the differences between OpenCL and WebCL.

In the following, WebCL syntax is demonstrated by comparing it with an OpenCL implementation of gray scale conversion of a color image. The complete and additional WebCL examples can be found at http://webcl.nokiaresearch.com. The kernel assumes the input image is provided in a pixel format of RGBA color components, with a byte for each color component, and returns the gray scale image in the same format. As mentioned previously, the kernel source code is written in OpenCL C, and it can be identical for both OpenCL and WebCL.

Kernel source:

The host source codes for both OpenCL and WebCL implementations are presented on the following pages. The implementations are compared in parallel as the reader is introduced to the application in logical steps. First, an OpenCL context must be set up. The default device of the first available platform is chosen without discrimination in order to keep the example simple.

The following source code illustrates how information retrieval from the OpenCL API is simplified in WebCL. In native OpenCL, it is necessary to first obtain the number of platforms, allocate necessary memory buffers, and, finally, retrieve the platform information and store it in the allocated buffer. WebCL implements this as a simple return value. A property array is delivered as a plain JavaScript array, and constants, as well as certain high-level functionality such as retrieving platforms and creating contexts, are accessed via a global WebCL object. A notable difference is the omission of error reporting/handling code. Error handling on WebCL is implemented using the exception mechanism of JavaScript (callbacks may be implemented as well in the future).

OpenCL:

WebCL:

The next step is to set up buffers. The size of both the input and the output buffers, bufSize, is the size of the image pixel data in bytes (i.e., the number of pixels on the image multiplied by the number of bytes per pixel). Because WebCL utilizes an object-oriented programming paradigm, createBuffer is called as a member function of the ctx object, instead of ctx being given as a parameter. Host pointers are omitted in WebCL.

OpenCL:

WebCL:

Next, the OpenCL program needs to be created from kernel sources and then built. Native OpenCL takes the source code as an array of pointers to C strings. This array offers the opportunity to divide the string into multiple parts. In WebCL, the need for dividing the source string is not recognized and so the count parameter can be removed as well.

OpenCL:

WebCL:

We create the kernel and set its arguments in the following source lines. The actual types of kernel arguments must be known for proper WebCL type conversions. In JavaScript, variable typing is dynamic and thus very different from C. Because the kernel code expects data of an exact size and type, the JavaScript value must be correctly converted. WebCL objects, such as memory objects bufIn and bufOut in the example, do not require the type because there is no room for interpretation in this case, so bufOut is used without specifying an explicit type as in the example.

OpenCL:

WebCL:

Finally, we require a command queue, into which we enqueue a write command to copy source data, the execution of the kernel, and a read command to copy the result data. In relation to OpenCL memory objects, the data pointer (pixels) is replaced by the use of a WebCLDataObject in WebCL that wraps the binary data without using a JavaScript array, as discussed previously.

OpenCL:

WebCL:

In WebCL, the resulting data is now available on the data object and can be utilized further by the application.

To test and benchmark WebCL in a realistic application scenario, we provide a web-based photo editor prototype, which is shown in Figure 13.2. The editor is available for testing at http://webcl.nokiaresearch.com.

The Web Photo Editor example features a touch screen optimized user interface with buttons and sliders and also an experimental set of image processing operators. The operators include basic adjustments such as cropping, scaling, and rotation, as well as red-eye removal, blurring, smoothing, edge enhancement, distortion, and other special effects. The application runs entirely in the browser, without any server-side processing.

Due to WebGL and WebCL, most of the image processing operators are able to process dozens or even hundreds of megapixels per second on a regular laptop computer. This makes for a smooth, interactive editing experience that would remain a distant dream without being able to harness the parallel processing power of modern GPUs and multi-core, vector-accelerated CPUs.

At the heart of the editing experience lies the painting mode. This mode allows image processing operators to be applied interactively on selected parts of the image using a paintbrush (Figure 13.3). To identify the main subject in a photo, you could first apply a global blur filter and then “paint in” the desired parts from the original image.

When the user selects an image for editing, four WebGL textures are allocated: (1) a source texture for storing the original image, (2) a temporary texture for storing intermediate results, (3) an alpha mask texture for the interactive paint mode, and (4) a destination texture for storing the processed and painted final image. The roles of the source and destination textures are reversed each time the user decides to “Apply” the pending edits. All the textures are the same size as the original image.

Most of the processing time in the photo editor is spent in WebGL shaders, WebCL kernels, and moving data back and forth. A WebGL shader is invoked every time the canvas needs to be redrawn, whether due to zooming, panning, painting, resizing the window, or other activities. Because all shaders and kernels operate on full-size images, the computational load, as well as the amount of data transferred back and forth between the CPU and the GPU, can be very high. Most of the data traffic is in fact redundant, stemming from the current restriction on sharing of textures between WebGL and WebCL.

The WebCL implementation utilizes and works together with several novel technologies that are still under development. This makes the setup relatively unstable for commercial adoption at this time. However, to evaluate the performance opportunities provided by WebCL, we provide early performance data in Table 13.2. In this setup, a 2.5 MPix RGB image was filtered using the previously described grayscaling filter and bilateral filter. The bilateral filter is implemented according to the straight bilateral definition. The numbers depict the achieved improvement in performance compared to a JavaScript implementation. The results depend heavily on execution environment, and we intend these results to be an indication of performance rather than to be fully defined.

When WebCL applications are written, or existing code utilizing OpenCL is ported to WebCL, it is essential to realize that specific characteristics of the target environment can have a major impact on the quality and the usefulness of the result. Because WebCL is built on top of the OpenCL API, there will be unavoidable overhead (especially when data is being moved between the JavaScript context and native code). For this reason, it is generally best to avoid frequent data transfers. Once the data is pushed to the native side, it is best to keep it there until it is required in the JavaScript application.

During application development, no assumptions should be made about the underlying platform. Modern web applications should be expected to be run on a wide variety of devices ranging from desktops and mobile devices to game consoles. When executed in a native environment, it is more likely that an application will be specialized to take advantage of a specific type of platform, such as desktop workstations or AMD GPUs. Web applications should take care to gather a sufficient amount of information about the execution environment before performing any specialization. For example, kernel compilation times can be expected to be much higher when running on a mobile device. Also, as with native OpenCL applications, the kernel execution parameters should be set so that maximum values are retrieved as information parameters are honored.

As discussed previously, memory management in WebCL is based on the garbage collector built into the JavaScript runtime. Moreover, because limited OpenCL hardware and runtime resources are also associated with this mechanism through the WebCL API, overuse can lead to problems. Therefore, careful thought must be given to resource use throughout the application. Resource-heavy objects, such as contexts or memory objects, should be created once and reused as much as possible.

Algorithms used in kernels should be designed to be fast and efficient. However, any optimizations should be meaningful and evaluated against the fact that the web context is easily dominated by JavaScript speed (or lack thereof) and garbage collection overhead. Also, the web favors cross-platform solutions, so any designs sacrificing this should be avoided.

In the future, we hope to see more widespread support for the TypedArray data type in HTML and JavaScript. For example, the canvas element would benefit from the ability to read and write the complete image pixel data with a TypedArray type versus using the currently supported pixel-by-pixel approach. In addition, WebCL inputs and outputs should ideally be bound to WebGL textures and buffers without any intermediate buffers. Unfortunately, because the current prototype is a Firefox add-on (as opposed to an integral part of the browser), our WebCL extension currently has no means to access WebGL resources. This can be remedied by either integrating WebCL into the browser engine or persuading the browser vendors to expose the necessary C/C++ APIs to extensions.

In the web environment, any API that the browser exposes to the outside world will, without exception, be attacked by malware. WebCL must therefore be designed with the assumption that every piece of host code or kernel code is potentially hostile. If the underlying OpenCL driver or platform is not sufficiently secure and robust, then the WebCL implementation must either put the driver/platform combination on a blacklist or provide additional safeguards via process isolation, memory protection, kernel code analysis, or other means. Unfortunately, the current-generation OpenCL hardware does not support context switches and, hence, driver controls for misbehaving code tend to be harsh and intrusive.

Writing performance portable OpenCL C can be very challenging. Moreover, most laptop and desktop computers, in addition to smartphones or other portable devices, do not yet ship with OpenCL drivers preinstalled. To make WebCL prevalent, it may be necessary to ship a CPU implementation of OpenCL with the browser.

In this chapter, we described an early implementation of WebCL as a Firefox extension, which provides a JavaScript API corresponding to the OpenCL API. The extension works on top of native OpenCL drivers, and OpenCL C kernel descriptions are passed as such to the OpenCL driver.

This approach to developing WebCL is promising, although there remain open issues, with security being the most obvious. Nevertheless, WebCL takes web applications to the next level by introducing remarkable performance. GPUs are already accessible through WebGL, but WebCL would further the use of GPUs for web-based execution. For the computation kernels, the CPU gave up to 20× and the GPU up to 200× performance compared to plain JavaScript on a modern laptop. These results show that the approach provides good performance in use cases that would otherwise be completely outside of JavaScript scope.