[webkit-dev] Some thoughts on WebCL

[Antonio Gomes]

Hi.

Over the past year and a half Khronos has been working on a specification
for WebCL - a JavaScript API that exposes GPUs and multi-core processors
for computational tasks.

Samsung and others have developed various prototype implementations.
Recently we have been updating our WebKit-based implementation to reflect
the latest draft spec and to be more consistent with WebKit design. Our new
version is located here:
https://github.com/SRA-SiliconValley/webkit-webcl

The WebCL working draft itself has evolved, and the feedback received by
the community has been discussed and addressed where applicable. The latest
version is available here:
https://cvs.khronos.org/svn/repos/registry/trunk/public/webcl/spec/latest/index.html


There has been some discussion about WebCL and parallel computing in the
mailing list and we'd like to express our views on the role of WebCL.

First, we think of WebCL more like a specialized toolbox for
JavaScriptlibrary providers, specifically those targeting compute
intensive use
cases. Areas such as image/photo editing, video and audio processing,
physical simulation, data visualization are natural candidates. That said,
it is unrealistic to expect every web developer to take WebCL and create,
say, a new vision library. Nonetheless, libraries using WebCL would be of
interest to large groups of developers simply because of the performance
gains.

Another issue that has been mentioned are potential security concerns.
WebCLuses "compute kernels", which like
WebGL shaders, are written in a C-like language. WebCL kernels can use
pointers to potentially access memory that should not be visible to the
application. This could compromise the browser or even the host device.
Protecting against out-of-bounds memory access, and other vulnerabilities,
such as denial-of-service, has been a priority in the design of WebCL since
its inception. Khronos has defined a series of security extensions designed
to harden the OpenCL drivers on which WebCL is based. Two OpenCL extensions
proposed by the WebCL Working Group (WG), have been ratified and are
currently part of the OpenCL extension specification. The "Context
Termination" extension provides protection against denial-of-service, and
the "Memory Initialization" extension enforces protection against memory
leakage. In addition, the WebCL WG has started a project for a "WebCL
Kernel Validator". The validator will enforce out-of-bounds memory
protection, and will provide syntax validation for WebCL kernels. As GPU
vendors start to implement the context termination and memory
initialization extensions in their respective OpenCL drivers, the broader
browser community has an opportunity to provide feedback to this process.

Some alternatives to WebCL have been mentioned in the mailing list. These
include Intel's ParallelArray and some form of beefed-up web workers. These
other approaches do not necessarily conflict with WebCL since their focus
is not really GPU compute. We do see some definite benefits for WebCL.
First WebCL gives flexibility in specifying GPU computation through its
compute kernels - kernels can be written for media processing, physical
simulation etc. Secondly, it dovetails nicely with WebGL - WebCL supports
sharing GPU objects with WebGL. For example, a VBO created by WebGL could
be passed to WebCL for manipulation. This type of exchange can be done
completely on the GPU, no need to read the potentially large objects back
into host memory.

Our current WebCL prototype is mature and open for review by the
WebKitcommunity. In addition to our efforts, others are also working
on
WebCL implementations. Nokia has contributed a WebCL prototype which can be
accessed through a special Firefox build. Additional details on other
WebCLimplementations can be found here:

https://www.khronos.org/assets/uploads/developers/library/2013-march-meetup-WebCL/WebCL-March-Meetup-2013.pdf


We encourage the WebKit community to participate in the WebCL discussions (
public_webcl at khronos.org) and invite your feedback.

--Antonio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130419/d7e20c29/attachment.html>