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

[bugzilla-daemon at webkit.org]

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





--- Comment #15 from Nikolas Zimmermann <zimmermann at kde.org>  2011-10-19 02:37:05 PST ---
(In reply to comment #1)
> Why use OpenCL rather than just using the existing WebGL backend (GraphicsContext3D) that already exists? What advantage would OpenCL give you?
I thought about this as well, and think we should start using what-we-already-have, and that is the shading functionality in GC3D, to get started with hw accelerating filters.

My view on this is:
1) Introduce a hardware "platformApplyOpenGL" code path to platform/graphics/filters/*
2) Separate the software rendering fallback into "platformApplySoftware"
3) Write FEGaussianBlurOpenGL.cpp, and let it directly use GC3D, create your shaders, transfer the start ImageData, process the sample, extract an ImageBuffer result.

It may sound awkward to use GC3D in platform/graphics/filters, though we can always refactor that existing code and extract eg. the shading stuff into a FilterOpenGL class, that both Filter and GC3D could use - but keep in mind, I'm just thinking about this, didn't try this nor did I know if its feasible to do so.

> Using GraphicsContext3D gives you several advantages:
> 
> 1) it's already there. OpenCL is far from universally available. And even though mobile hardware theoretically supports it, I know of no hardware yet that is shipping with it. WebGL runs on top of many platforms. It runs on desktop OpenGL implementations on Windows, OSX and Linux. It runs on OpenGL ES implementations on iOS and Android. And it runs on top of DirectX courtesy of ANGLE.
What we all want: get HW accelerated filters as fast as possible, now that the software fallback path can be considered complete. The likelihood to get this turned on in trunk is much higher, if we use proven existing code like GC3D is.

> 
> 2) GraphicsContext3D has already solved the "how do I get a buffer on the GPU" issue.
Agreed.

> 
> 3) The buffers GraphicsContext3D uses already has a path for compositing on the page.
Agreed.

> 
> 4) There is a new CSS Shaders proposal from Adobe which uses WebGL shaders to do its work. Since SVG and CSS filters are (at least in theory) sharing an implementation, the CSS Shaders implementation would be complicated by an OpenCL backend.
That's an important point, and deserves attention. As CSS Shaders will need WebGL shaders, it would be a step backward to introduce another new layer OpenCL at the moment.

CSS Shaders can use the existing GC3D code as well as SVG/CSS filters. As I said above, if it turns out to be awkward to use GC3D right in eg. CSS Shaders or SVG filters (too heavy class, does work we don't need for just using shaders, etc.) we can go and refactor the relevant bits out of GC3D.

Does that sound like a reasonable route?

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