disable GPU blur on small paths

disable GPU blur on small paths

The current criteria is height, width and radius are all no bigger than 64, I think it's quite a small rectangle, hopefully it won't hurt the performance for other use cases. The benchmark I'm using gets a great performance boost.


BUG=
TEST=http://www.kevs3d.co.uk/dev/asteroidsbench/  Test 3 has much better FPS with this CL (from 15FPS to 28FPS).

[guanqun, 2012-03-05 05:42:36]

Please review!

[guanqun, 2012-03-05 06:25:51]

A more aggressive approach is to enlarge the number from 64 to 128... But I
wonder whether you think it's too large?

[bsalomon, 2012-03-05 14:02:16]

On 2012/03/05 06:25:51, guanqun wrote:
> A more aggressive approach is to enlarge the number from 64 to 128... But I
> wonder whether you think it's too large?

Perhaps we should have several runs of the bench at different sizes so we can
determine what the cutoff should be (on at least some platform). Also, should
radius be part of the criteria?

[guanqun, 2012-03-06 06:29:02]

On 2012/03/05 14:02:16, bsalomon wrote:
> Perhaps we should have several runs of the bench at different sizes so we can
> determine what the cutoff should be (on at least some platform). Also, should
> radius be part of the criteria?

Nice idea. I modified the bench a little and then run the bench, the basic
configuration is as follows: the blur radius are set to 1, 2, 4, 8, 16, 32, 64,
128. (Because the max blur radius in code is set to 128) Then for each fixed
radius, the canvas size goes from 10 to 640 with the interval of 10. Note the
bounding height and width of path drawn are halves of canvas' height and width.

Here are the observations:

1. For radius less than 64, the cutoff is at about 512 canvas size (path
bounding size is then about 256).
2. For radius of 128, the cutoff is at about 280 canvas size (path bounding size
then is 140).
3. For a fixed blur radius, CPU blur time increases proportionally with canvas
size.
4. For a fixed blur radius, GPU blur time is not sensitive about the increased
canvas size, the line is very shallow.

So I got the following conclusion:

It's safe to fallback to blur via CPU when the size is less than 128, no matter
what the radius is. So I've update this CL to reflect this test, I enlarge the
size to 128 and make it only available on linux, because the platform I'm
running this test is on my SandyBridge desktop, Fedora Core 16, x86_64. If
resources are available, I'll try other platforms and then enable this on other
platforms.

If you find there's anything incorrect, I'll be happy to redo the tests.

Here's my modified bench program:
http://codereview.appspot.com/5753049

Here's the script I used to generate the following pictures:
https://gist.github.com/1983847

Here are the pictures I plotted (Mixing them together in one picture makes it
really hard to read, so I separted them into different radius. The number means
the radius value.)
http://printf.me/wp-content/uploads/2012/03/blur-time-1.png
http://printf.me/wp-content/uploads/2012/03/blur-time-2.png
http://printf.me/wp-content/uploads/2012/03/blur-time-4.png
http://printf.me/wp-content/uploads/2012/03/blur-time-8.png
http://printf.me/wp-content/uploads/2012/03/blur-time-16.png
http://printf.me/wp-content/uploads/2012/03/blur-time-32.png
http://printf.me/wp-content/uploads/2012/03/blur-time-64.png
http://printf.me/wp-content/uploads/2012/03/blur-time-128.png

[guanqun, 2012-03-06 13:52:32]

I tried this script on a low end MacBookPro. When the radius is 128, the time
for CPU is much larger than GPU. So I'm afraid I'd better choose a conservative
value.

Pictures for MBP are here:

http://printf.me/wp-content/uploads/2012/03/mbp-blur-time-1.png
http://printf.me/wp-content/uploads/2012/03/mbp-blur-time-2.png
http://printf.me/wp-content/uploads/2012/03/mbp-blur-time-4.png
http://printf.me/wp-content/uploads/2012/03/mbp-blur-time-8.png
http://printf.me/wp-content/uploads/2012/03/mbp-blur-time-16.png
http://printf.me/wp-content/uploads/2012/03/mbp-blur-time-32.png
http://printf.me/wp-content/uploads/2012/03/mbp-blur-time-64.png
http://printf.me/wp-content/uploads/2012/03/mbp-blur-time-128.png

[guanqun, 2012-03-07 02:44:43]

Tried on a netbook based on Intel Atom processor, it runs at about 1.6GHz.

For this test, CPU blur is always faster then GPU blur.

Here are the pictures:

http://printf.me/wp-content/uploads/2012/03/netbook-blur-time-1.png
http://printf.me/wp-content/uploads/2012/03/netbook-blur-time-2.png
http://printf.me/wp-content/uploads/2012/03/netbook-blur-time-4.png
http://printf.me/wp-content/uploads/2012/03/netbook-blur-time-8.png
http://printf.me/wp-content/uploads/2012/03/netbook-blur-time-16.png
http://printf.me/wp-content/uploads/2012/03/netbook-blur-time-32.png
http://printf.me/wp-content/uploads/2012/03/netbook-blur-time-64.png
http://printf.me/wp-content/uploads/2012/03/netbook-blur-time-128.png

[Stephen White, 2012-03-07 02:57:56]

On 2012/03/07 02:44:43, guanqun wrote:
> Tried on a netbook based on Intel Atom processor, it runs at about 1.6GHz.
> 
> For this test, CPU blur is always faster then GPU blur.
> 
> Here are the pictures:
> 
> http://printf.me/wp-content/uploads/2012/03/netbook-blur-time-1.png
> http://printf.me/wp-content/uploads/2012/03/netbook-blur-time-2.png
> http://printf.me/wp-content/uploads/2012/03/netbook-blur-time-4.png
> http://printf.me/wp-content/uploads/2012/03/netbook-blur-time-8.png
> http://printf.me/wp-content/uploads/2012/03/netbook-blur-time-16.png
> http://printf.me/wp-content/uploads/2012/03/netbook-blur-time-32.png
> http://printf.me/wp-content/uploads/2012/03/netbook-blur-time-64.png
> http://printf.me/wp-content/uploads/2012/03/netbook-blur-time-128.png

Thank you for the exhaustive testing!

Two things, though:

1)  I noticed you're not passing kHighQuality_BlurFlag to the SkBlurMaskFilter. 
Without this flag, the CPU blur is actually a box blur, not a Gaussian blur. 
The GPU blur is always high quality, so it actually ignores this parameter. 
What this means is that you're testing a low-quality CPU blur against a
high-quality GPU blur.

2)  It looks like the path you're drawing is concave.  Currently, the GPU path
actually draws antialiased concave paths on the CPU, and upload them to the GPU.
 This means the GPU has an extra penalty over the CPU path.  We have plans in
the works that will mitigate this overhead (and draw all paths on the GPU), so
optimizing for this case may be premature.

[guanqun, 2012-03-07 04:24:05]

On 2012/03/07 02:57:56, Stephen White wrote:
> Two things, though:
> 
> 1)  I noticed you're not passing kHighQuality_BlurFlag to the
SkBlurMaskFilter. 
> Without this flag, the CPU blur is actually a box blur, not a Gaussian blur. 
> The GPU blur is always high quality, so it actually ignores this parameter. 
> What this means is that you're testing a low-quality CPU blur against a
> high-quality GPU blur.

Ah, I missed this one. :( Thanks for pointing it out.

> 2)  It looks like the path you're drawing is concave.  Currently, the GPU path
> actually draws antialiased concave paths on the CPU, and upload them to the
GPU.
>  This means the GPU has an extra penalty over the CPU path.  We have plans in
> the works that will mitigate this overhead (and draw all paths on the GPU), so
> optimizing for this case may be premature.

Yes, I draw this concave paths intentionally, because the bench I'm using
(http://www.kevs3d.co.uk/dev/asteroidsbench/) draws concave paths, I want to
mimic the original bench.

It's nice to hear there are plans to draw all paths on GPU. For now, I'll change
it back to convex paths for this test.

[guanqun, 2012-03-07 06:38:17]

I've changed the bench to draw oval instead my original concave paths and add
the high quality blur parameter.

I've redone the tests on my sandybridge desktop and atom based netbook.

The results turns true that for small rects cpu blur is still somewhat faster.
Based on how we decide the "small", from the data, I think 64x64 with radius 32
is small enough.

Here is the picture for sandybridge test:

http://imgur.com/a/WAuWo#0

Here is the picture for atom based netbook:

http://imgur.com/a/FrwAX#0

I'll leave you guys to decide whether this patch is acceptable or not, yes, it
makes the logics a bit complicated...
If any other information is needed or more tests are needed, I'll be happy to
help. :)

Thanks!

[bsalomon, 2012-03-13 12:45:34]

On 2012/03/07 06:38:17, guanqun wrote:
> I've changed the bench to draw oval instead my original concave paths and add
> the high quality blur parameter.
> 
> I've redone the tests on my sandybridge desktop and atom based netbook.
> 
> The results turns true that for small rects cpu blur is still somewhat faster.
> Based on how we decide the "small", from the data, I think 64x64 with radius
32
> is small enough.
> 
> Here is the picture for sandybridge test:
> 
> http://imgur.com/a/WAuWo#0
> 
> Here is the picture for atom based netbook:
> 
> http://imgur.com/a/FrwAX#0
> 
> I'll leave you guys to decide whether this patch is acceptable or not, yes, it
> makes the logics a bit complicated...
> If any other information is needed or more tests are needed, I'll be happy to
> help. :)
> 
> Thanks!


It seems reasonable to me to use SW for small blurs with a conservative
threshold. Stephen what do you think?

I'd say remove the MAC / LINUX check unless we have some reason to believe that
relative performance is dramatically different there than other platforms.

[guanqun, 2012-03-14 02:10:41]

On 2012/03/13 12:45:34, bsalomon wrote:
> I'd say remove the MAC / LINUX check unless we have some reason to believe
that
> relative performance is dramatically different there than other platforms.

I was adding these flags because I only tested with these platforms. Now in
patchset 6, I've removed these flags.

Thanks!

[guanqun, 2012-03-22 02:58:55]

ping...