Re: [webkit-dev] OpenVG backend
On Tue, Apr 9, 2013 at 6:55 PM, Jeff Rogers jeffcrog...@gmail.com wrote: BlackBerry/RIM is no longer using the OpenVG backend and we are ok with removing it (we were the original contributors). Thanks for the reply. Patch posted here:https://bugs.webkit.org/show_bug.cgi?id=114881 --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Some thoughts on WebCL
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_we...@khronos.org) and invite your feedback. --Antonio ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Enabling Experimental Features
Hello WebKit, Recently, I've been thinking that it would be great to be able to enable experimental features in the WebKit nightlies. It seems like it would be valuable for folks using the nightlies to have the ability to opt-in and test-drive new features that are not yet shipping by default. For example, a couple folks at Adobe have been working on the CSS Exclusions and Shapes specification [1]. There is some experimental functionality that is currently turned off by default, and toggled on for testing via bindings/generic/RuntimeEnabledFeatures. What do folks think about adding a mechanism for users to toggle features like this on in WebKit nightlies? I don't have a definite approach yet, but wanted to float the idea for feedback. -Bear Travis [1] http://dev.w3.org/csswg/css-exclusions/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Enabling Experimental Features
On Apr 19, 2013, at 6:15 PM, Bear Travis betra...@adobe.com wrote: What do folks think about adding a mechanism for users to toggle features like this on in WebKit nightlies? I don't have a definite approach yet, but wanted to float the idea for feedback. I like the idea. Having things off for everyone but the engineers is a bad approach and misses out on testing. We could have WebKit modify Safari's Develop menu to provide additional items to toggle. Safari provides an Enable WebGL item, we could inject more items next to it. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Some thoughts on WebCL
On Apr 19, 2013, at 10:17 PM, Zoltan Herczeg zherc...@webkit.org 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
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
