WebCL


WebCL is a JavaScript binding to OpenCL for heterogeneous parallel computing within any compatible web browser without the use of plug-ins, first announced in March 2011. It is developed on similar grounds as OpenCL and is considered as a browser version of the latter. Primarily, WebCL allows web applications to actualize speed with multi-core CPUs and GPUs. With the growing popularity of applications that need parallel processing like image editing, augmented reality applications and sophisticated gaming, it has become more important to improve the computational speed. With these background reasons, a non-profit Khronos Group designed and developed WebCL, which is a Javascript binding to OpenCL with a portable kernel programming, enabling parallel computing on web browsers, across a wide range of devices. In short, WebCL consists of two parts, one being Kernel programming, which runs on the processors and the other being JavaScript, which binds the web application to OpenCL. The completed and ratified specification for WebCL 1.0 was released on March 19, 2014.

Implementation

Currently, no browsers natively support WebCL. However, non-native add-ons are used to implement WebCL. For example, Nokia developed a WebCL extension. Mozilla does not plan to implement WebCL in favor of OpenGL ES 3.1 Compute Shaders.
The basic unit of a parallel program is kernel. A kernel is any parallelizable task used to perform a specific job. More often functions can be realized as kernels. A program can be composed of one or more kernels. In order to realize a kernel, it is essential that a task is parallelizable. Data dependencies and order of execution play a vital role in producing efficient parallelized algorithms. A simple example can be thought of the case of loop unrolling performed by C compilers, where a statement like:
for
c = a + b;
can be unrolled into:
c = a + b;
c = a + b;
c = a + b;
Above statements can be parallelized and can be made to run simultaneously. A kernel follows a similar approach where only the snapshot of the ith iteration is captured inside kernel.
Let's rewrite the above code using a kernel:
__kernel add
Running a WebCL application involves the following steps:
  1. Allow access to devices and provide context
  2. Hand over the kernel to a device
  3. Cause the device to execute the kernel
  4. Retrieve results from the device
  5. Use the data inside JavaScript
Further details about the same can be found at

Exceptions List

WebCL, being a JavaScript based implementation, doesn't return an error code when errors occur. Instead, it throws an exception such as OUT_OF_RESOURCES, OUT_OF_HOST_MEMORY, or the WebCL-specific WEBCL_IMPLEMENTATION_FAILURE. The exception object describes the machine-readable name and human-readable message describing the error. The syntax is as follows:
exception WebCLException : DOMException ;
From the code above, it can be observed that the message field can be a NULL value.
List of few other exceptions:
  1. INVALID_OPERATION – if the blocking form of this function is called from a WebCLCallback
  2. INVALID_VALUE – if eventWaitList is empty
  3. INVALID_CONTEXT – if events specified in eventWaitList do not belong to the same context
  4. INVALID_DEVICE_TYPE – if deviceType is given, but is not one of the valid enumerated values
  5. DEVICE_NOT_FOUND – if there is no WebCLDevice available that matches the given deviceType
More information on exceptions can be found in the specs document.
There is another exception that is raised upon trying to call an object that is ‘released’. On using the release method, the object doesn't get deleted permanently but it frees the resources associated with that object. In order to avoid this exception, ‘releaseAll’ method can be used, which not only frees the resources but also deletes all the associated objects created.

Security

WebCL, being an open-ended software developed for web applications, there is lot of scope for vulnerabilities in the design and development fields too. This forced the developers working on WebCL to give security the utmost importance. Few concerns that were addressed are:
  1. Out-of-bounds Memory Access: This occurs by accessing the memory locations, outside the allocated space. An attacker can rewrite or erase all the important data stored in those memory locations. Whenever there arises such a case, an error must be generated at the compile time, and zero must be returned at run-time, not letting the program override the memory. A project WebCL Validator, was initiated by the Khronos Group on handling this vulnerability.
  2. Memory Initialization: This is done to prevent the applications to access the memory locations of previous applications. WebCL ensures that this doesn't happen by initializing all the buffers, variables used to zero before it runs the current application. OpenCL 1.2 has an extension ‘cl_khr_initialize_memory’, which enables this.
  3. Denial of Service: The most common attack on web applications cannot be totally eliminated by WebCL or the browser. OpenCL can be provided with watchdog timers and pre-emptive multitasking, which can be used by WebCL in order to detect and terminate the contexts that are taking too long or consume lot of resources. There is an extension of OpenCL 1.2 ‘cl_khr_terminate_context’ like for the previous one, which enables to terminate the process that might cause a denial of service attack.

    Related browser bugs

*