Quantcast

Some thoughts on WebCL

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 JavaScript library 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. WebCL uses "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 WebKit community. 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 WebCL implementations 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 ( [hidden email]) and invite your feedback. 

--Antonio


_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Some thoughts on WebCL

Zoltan Herczeg-2
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


_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Some thoughts on WebCL

Filip Pizlo-3


On Apr 19, 2013, at 10:17 PM, Zoltan Herczeg <[hidden email]> wrote:

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

+1

>
> Regards,
> Zoltan
>
>
> _______________________________________________
> webkit-dev mailing list
> [hidden email]
> https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Some thoughts on WebCL

Antonio Gomes
Hi.

On Sat, Apr 20, 2013 at 1:20 AM, Filip Pizlo <[hidden email]> wrote:
On Apr 19, 2013, at 10:17 PM, Zoltan Herczeg <[hidden email]> 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


_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Loading...