[webkit-dev] Some thoughts on WebCL

[Antonio Gomes]

Hi.

On Sat, Apr 20, 2013 at 1:20 AM, Filip Pizlo <fpizlo at apple.com> wrote:
On Apr 19, 2013, at 10:17 PM, Zoltan Herczeg <zherczeg at webkit.org> wrote:

> 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)); ?

This is a good idea. I have filed a bug against Khronos to discuss it:
https://www.khronos.org/bugzilla/show_bug.cgi?id=855

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

The last parameter in WebCLContext.createImage is where 'pixels' should be
specified. It is optional though, as the 'pixels' content can be lazily
filled by calling WebCLCommandQueue.enqueueWriteImage. In this case, you
caught a flaw in this slide, I would say.

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

This is the same way WebGL works currently. I agree it is not nice.

> What about error handling?

Error handling happens through JS Exceptions.

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

> +1

+2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130422/fe65423b/attachment.html>