New Morphology benchmarks, attempt to speed up GPU shader

We don't get any speedup from unrolling the GL loop on Linux, where we did seem to get speedup from unrolling convolution, so just proposing this as a benchmark.

Erode/Dilate are quite slow over a 400x400 circle, so this benchmark only repeats 3x. We might consider reducing the size of the circle, too - this is just cut & pasted from the blur benchmark.

If erode/dilate are commonly seen in the wild, we can probably SSE-accelerate them for large wins; more than 60% of the time in this benchmark is spent on:
  unpack an ARGB into 4 unsigned bytes
  take the max of each of the four components
If the memory->register penalty isn't too bad, pmaxub seems custom-made for this issue.

[Stephen White, 2012-06-11 18:43:15]

Note that morphology does not currently respect the texture instruction limit of
DX9SM2 (32), so a large radius very likely breaks on old GPUs.

I had planned to work around this by doing a multipass method, similar to the
convolution, essentially a divide-and-conquer with a threshold.  This may also
show some performance improvement on newer GPUs, since it can reduce the number
of overall reads (at a cost a few more writes).  If you feel like taking it on,
let me know.

[TomH, 2012-06-11 18:44:44]

On 2012/06/11 18:43:15, Stephen White wrote:
> Note that morphology does not currently respect the texture instruction limit
of
> DX9SM2 (32), so a large radius very likely breaks on old GPUs.
> 
> I had planned to work around this by doing a multipass method, similar to the
> convolution, essentially a divide-and-conquer with a threshold.  This may also
> show some performance improvement on newer GPUs, since it can reduce the
number
> of overall reads (at a cost a few more writes).  If you feel like taking it
on,
> let me know.

Is that a silent-LG? Or a "get rid of radius 10, let radius 1.5 & 2 suffice"? Or
... ?

FWIW, GPU is currently 3-5x faster than software on a Win/Linux dev box.

[Stephen White, 2012-06-11 18:45:45]

http://codereview.appspot.com/6299067/diff/2001/bench/MorphologyBench.cpp
File bench/MorphologyBench.cpp (right):

http://codereview.appspot.com/6299067/diff/2001/bench/MorphologyBench.cpp#new...
bench/MorphologyBench.cpp:3: * Copyright 2011 Google Inc.
2011 -> 2012

[Stephen White, 2012-06-11 18:47:34]

On 2012/06/11 18:44:44, TomH wrote:
> On 2012/06/11 18:43:15, Stephen White wrote:
> > Note that morphology does not currently respect the texture instruction
limit
> of
> > DX9SM2 (32), so a large radius very likely breaks on old GPUs.
> > 
> > I had planned to work around this by doing a multipass method, similar to
the
> > convolution, essentially a divide-and-conquer with a threshold.  This may
also
> > show some performance improvement on newer GPUs, since it can reduce the
> number
> > of overall reads (at a cost a few more writes).  If you feel like taking it
> on,
> > let me know.
> 
> Is that a silent-LG? Or a "get rid of radius 10, let radius 1.5 & 2 suffice"?
Or
> ... ?

That was a possible explanation for why the current GPU performance was slower
than it could be. "Erode/Dilate are quite slow over a 400x400 circle," .. unless
you meant for software performance, in which case, never mind.  :)

> 
> FWIW, GPU is currently 3-5x faster than software on a Win/Linux dev box.

[TomH, 2012-06-11 18:48:29]

http://codereview.appspot.com/6299067/diff/2001/bench/MorphologyBench.cpp
File bench/MorphologyBench.cpp (right):

http://codereview.appspot.com/6299067/diff/2001/bench/MorphologyBench.cpp#new...
bench/MorphologyBench.cpp:3: * Copyright 2011 Google Inc.
On 2012/06/11 18:45:45, Stephen White wrote:
> 2011 -> 2012

Done.

[Stephen White, 2012-06-11 19:18:28]

LGTM

[TomH, 2012-06-11 19:22:25]

Closed with r4230.

[TomH, 2012-06-11 20:49:14]

Broke buildbots due to poor performance of fixed point implementation; those
benchmarks disabled with r4231.