I plan to use OpenCL to HW accelerate SVG and CSS Filters [1]. I'm targeting OpenCL 1.1 which consists of two profiles: 'full' for the Desktop and 'embedded' for embedded devices like mobile phones. For filters I'll use OpenCLs facilities for image processing from the 'full' profile. The most graphic chip manufactures like Imagination [2],[3] support even this part that is optional for the 'embedded' profile. Right now I plan to reuse the current structure of our filters implementation as much as possible. So we can continue to calculate and use the smallest intermediate image buffers. I'll make sure that we don't have unnecessary data transfers between host and computing device. Just the data transfer for the source image to the device and the data transfer of the result to the host will be used. Therefore I'll propose to proceed with the following steps: 1. Make FilterEffect::apply() independent from any imageBuffer / imageData management (this will be a benefit for other HW acceleration implementations like CIFilters or OpenGL ES as well). 2. Add a compiler flag to disable/enable OpenCL 3. Implement basic FilterOpenCL object that manages the image processing, the kernels, the memory objects and the devices. 4. Create kernels for filter effects. This will be done for every single filter effect in followup patches. At the beginning every filter effect just allocates empty memory on the device to not block already implemented effects. I'll start with implementing SourceGraphic, feOffset and feColorMatrix. 5. Implement fallback to the existing software rendering (or other HW accelerated rendering) if no OpenCL capable device was found. I opened the master bug "OpenCL implementation of W3C Filter Effects Master Bug" to track all these steps. Dirk [1] https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html [2] http://www.imgtec.com/news/Release/index.asp?NewsID=516 [3] http://www.khronos.org/conformance/adopters/conformant-products/