[Webkit-unassigned] [Bug 70099] OpenCL implementation of W3C Filter Effects Master Bug

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Dec 2 11:19:12 PST 2011


https://bugs.webkit.org/show_bug.cgi?id=70099





--- Comment #36 from Chris Marrin <cmarrin at apple.com>  2011-12-02 11:19:12 PST ---
(In reply to comment #18)
> If this behavior is based on doing a readback for every element I can't imagine it performing well since it will destroy any frame overlap and parallelism that you would normally get between the GPU and CPU.  Please guard this with a new #ifdef at least so we can evaluate it independently from other features.

I want to second James' comment about the rationale behind this approach. Uploading an image to the CPU, running an OpenCL shader on it, and then reading the resullt back into the CPU will have a big enough performance impact, that I would be willing to bet that for many filters, just doing it in software would be faster, especially if vector instructions were employed.

WebKit has an architecture for hardware accelerating bitmap layers. Any use of the GPU should go through that mechanism. I don' think it's in the best interest of the WebKit project to embed this sort of functionality throughout the high-level filter logic.

There are system level filter changes currently underway. In https://bugs.webkit.org/show_bug.cgi?id=68479 I will be adding logic to the RenderLayer level to create layers when an element has a filter. I will also add API to GraphicsLayer to pass in info about adding a filter to the layer and animating that filter. There are implementations of GraphicsLayer that use OpenGL contexts for rendering, so it should not be hard to incorporate OpenCL based filter rendering into that.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list