[webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit

[Oliver Hunt]

On Apr 10, 2013, at 9:44 AM, Jarred Nicholls <jarred at webkit.org> wrote:

> On Wed, Apr 10, 2013 at 9:33 AM, Antonio Gomes <tonikitoo at webkit.org> wrote:
> Hi
> 
> On Wed, Apr 10, 2013 at 12:59 AM, Thibault Imbert <timbert at adobe.com> wrote:
> 
> Yes, leveraging multicore and the power of GPUs for general computations is great and very powerful but first, securing such kernels is hard, and authoring these would be pretty brutal to most web developers, I think this is what Benjamin was referring to.
> 
> With WebCL, you are basically writing C style kernels that you load and run to drive the computations, initiatives like RiverTrail are more restrictive but way more approachable and closer to the web, exposing higher level primitives on top of WebCL (ParallelArray for example) and integrated at the language level, which makes a lot of sense.
> 
> 
> Security is a primary goal of WebCL, and both WebCL and OpenCL working groups are working together to ensure a safe parallel programming environment to the Web, as you can see in [1]. If you have specific concerns, please raise it in the Khronos working group mailing list ([2]) or file a bug ([3]) against the draft spec.
> 
> Particularly in terms of security, WebCL is to OpenCL as WebGL is to OpenGL.  Introducing "OpenGL" (i.e. WebGL) to the web had similar security concerns, and yet…

OpenCL is fundamentally less safe than OpenGL+GLSL, so it not correct to say that the security concerns are similar.

There is no part of GLSL that is overtly operating on raw memory with arbitrary pointer access, whereas in OpenCL such functionality is a core primitive.  I am not saying that it will be impossible to make WebCL safe (after all OpenCL can trivially be kept on the cpu, which already has the assumption that it is running untrusted code), but whether you can keep it safe without completely compromising the programming and performance model remains to be seen.

--Oliver


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130410/34b21a29/attachment.html>