[webkit-dev] Some thoughts on WebCL

[Zoltan Herczeg]

Hi,

> 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.

I think this is the key part of the announcement. WebCL can solve problems
which has no efficient JS based solutions. Not at least in the foreseeable
future.

> 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.

Yes, you can easily read the whole GPU memory.

I hoped WebCL improves the syntax of OpenCL. E.g using array references
instead of pointers. If I understand correctly, the "WebCL Kernel
Validator" re-compiles all kernels, so you could also enhance the syntax.

Especially in the JS side. An example for your slides:

kernel.setKernelArg(0, inputBuf);
kernel.setKernelArg(1, outputBuf);
kernel.setKernelArg(2, count, WebCL.KERNEL_ARG_INT);

This is OK in C, but really ugly in JS.

Why not:
kernel.setKernelArg(inputBuf, outputBuf, WebCL.asInt(count)); ?

Both NULL and null is used in various examples. This is not nice as well.

Or this example:

<script>
var bpp = 4;
// bytes per pixel
var pixels = new Uint8Array(width * height * bpp);
var pitch = width * bpp;
var clImage = context.createImage(WebCL.MEM_READ_ONLY, {channelOrder:
WebCL.RGBA, channelType:WebCL.UNORM_INT8, width:width, height:height,
pitch:pitch } );
</script>

I don't see a binding between the pixels and the clImage variables. Would
be better to define only the clImage, which would be an Uint8Array in the
same time.

What about error handling?

> 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.

This is also a key thought. OpenCL is designed for highly parallel, but
otherwise very simple tasks. Its primary use case is extending WebGL.

However, we still need a parallel JS based solution, which can access the
GUI in some way.

Regards,
Zoltan