Optimizing Gaussian blurs on a mobile GPU • Hacker News Board

Re: Optimizing Gaussian blurs on a mobile GPU

#21

Post by lcrs » Tue, Oct 22, 2013, 9:26 PM UTC

FreeFull wrote: post #17

Are there other blurs that are cheaper than the Gaussian but look good enough to replace it for this sort of purpose?

I've used a triangular ("conical"?) kernel when in a hurry and it looked reasonable. Vastly better than a box blur, at least. They're actually not separable but one can pretend and just do horizontal and vertical passes without much damage.

Amusingly Autodesk ship a GLSL shader with Flame which uses a triangular kernel under the hood but labels the button in the interface "Gaussian", the cheeky swines...

The nicest option to imitate lens blur is a circular kernel but that's quite aggressively non-separable. The other thing that really helps is blurring linear-light values instead of the usual gamma-encoded images. The blurs in Windows 7's Aero themes very clearly don't do this, to my eye - dark lines spread out too much and look generally muddy.

VFX guy who loves to blur things here :)

Re: Optimizing Gaussian blurs on a mobile GPU

#22

Post by tlarkworthy » Wed, Oct 23, 2013, 1:24 AM UTC

backprojection wrote: post #13

tlarkworthy wrote: post #9

FFTs where designed for this http://en.m.wikipedia.org/wiki/Convolution_theorem

I'm surprised this isn't even mentioned in the article. I guess there are issues with boundary effects, but those can be overcome in a variety of ways. Also, if your convolution kernel is short enough, you can beat an FFT. So, in 2D with an NxN image, an FFT filter will have a complexity of about (N^2 + N^2 Log N). If your kernel is KxK, then direct convolution will be (N^2 K^2), so you have to compare Log N with K^2…

Yeah I imagine an fft solution is not the best due to non-mathmatical reasons. Kinda annoying as it was all worked out decades ago

Re: Optimizing Gaussian blurs on a mobile GPU

#23

Post by xenonite » Wed, Oct 23, 2013, 8:55 AM UTC

sliverstorm wrote: post #19

xenonite wrote: post #15

Earlier quoted context omitted.

On the contrary. Consider that the memory is the bottleneck when performing the blur. I understand you would create five instances of the images (50%, 12.5% Left, R, Top, B). This would worsen the bottleneck even more. Additionally, the advantage of computing pixel by pixel is that the shader can operate massively parallel.

I would think it is going to depend on your cache size. Piecewise will be better if the image can't all fit in the cache, but if the image is small enough you can fit everything in the cache. Or, do you mean that memory is the bottleneck as in, shipping the image to the GPU's memory space?

Yes, it really depends on your cache size.

And the problem with that is, you can't guess the cache size. You can help yourself with profiling, but this leads to a local optimization for only some GPUs.

If you wish to run your code optimized for any GPU, the pixel-by-pixel approach usually works best. Then, the GPU scheduler can run as many neighboring threads as possible in subprocessors. Note that every subprocessor has another local cache which is really quick.

Re: Optimizing Gaussian blurs on a mobile GPU

#24

Post by jerf » Wed, Oct 23, 2013, 8:48 PM UTC

xenonite wrote: post #15

jerf wrote: post #2

In addition to what was already there, I'd suggest looking at trying to operate on the whole image at a time rather than pixel-by-pixel. To take a simple blur example, a blur that samples the local pixel at 50%, and each of the top, bottom, left, and right by 12.5% is equivalent to drawing the entire image half darkened, then drawing it in each of one pixel to the left, right, up, and down at 12.5% of the original br…

On the contrary. Consider that the memory is the bottleneck when performing the blur. I understand you would create five instances of the images (50%, 12.5% Left, R, Top, B). This would worsen the bottleneck even more. Additionally, the advantage of computing pixel by pixel is that the shader can operate massively parallel.

I think I wasn't clear. I mean, send 5 textured polygons to the 3D hardware, with various darkenings and offsets on one texture (which if nothing else can be done via lighting, but there's probably other easier ways), and let it do the blending en masse. Instead of using shaders and blinding it to what you're doing, it may be able to render the polygons much faster, on an optimized path. And it may not. But it's worth a try.