Added shaderproc for 1xN repeatX/repeatY BitmapProcShader

This handles a special case seen in the mlb skp. The new shaderproc is just a simplification of Repeat_S32_D32_nofilter_trans_shaderproc.


BEFORE:

running bench [1257 3085] tabl_mlb.skp   tile_256x256: cmsecs =  46.02

running bench [640 480] constXRepeat  8888: cmsecs =  44.93   GPU: cmsecs =   8.42 gmsecs =   8.59


AFTER:

running bench [1257 3085] tabl_mlb.skp   tile_256x256: cmsecs =  36.66

running bench [640 480] constXRepeat  8888: cmsecs =   1.40   GPU: cmsecs =   8.27 gmsecs =   8.63

[TomH, 2013-01-09 15:24:07]

Driveby LGTM and YAY

[robertphillips, 2013-01-16 23:06:32]

The generalization does cost us some time but this is a big win for the filtered
cases:

BEFORE:

running bench [640 480]   constXTile_MM_filter_trans  8888: msecs =  97.77   
running bench [640 480]   constXTile_CC_filter_trans  8888: msecs =  39.95   
running bench [640 480]   constXTile_RR_filter_trans  8888: msecs =  53.01   
running bench [640 480]          constXTile_MM_trans  8888: msecs =   6.67   
running bench [640 480]          constXTile_CC_trans  8888: msecs =   6.77   
running bench [640 480]          constXTile_RR_trans  8888: msecs =   6.67   
running bench [640 480]         constXTile_MM_filter  8888: msecs =  92.58   
running bench [640 480]         constXTile_CC_filter  8888: msecs =  34.43   
running bench [640 480]         constXTile_RR_filter  8888: msecs =  48.22   
running bench [640 480]                constXTile_MM  8888: msecs =   3.35   
running bench [640 480]                constXTile_CC  8888: msecs =   2.64   
running bench [640 480]                constXTile_RR  8888: msecs =  46.77   

AFTER:

running bench [640 480]   constXTile_MM_filter_trans  8888: msecs =   6.33   
running bench [640 480]   constXTile_CC_filter_trans  8888: msecs =   6.07   
running bench [640 480]   constXTile_RR_filter_trans  8888: msecs =   6.08  
running bench [640 480]          constXTile_MM_trans  8888: msecs =   5.95   
running bench [640 480]          constXTile_CC_trans  8888: msecs =   5.85   
running bench [640 480]          constXTile_RR_trans  8888: msecs =   5.83   
running bench [640 480]         constXTile_MM_filter  8888: msecs =   3.10  
running bench [640 480]         constXTile_CC_filter  8888: msecs =   2.84   
running bench [640 480]         constXTile_RR_filter  8888: msecs =   2.91   
running bench [640 480]                constXTile_MM  8888: msecs =   2.75   
running bench [640 480]                constXTile_CC  8888: msecs =   2.74   
running bench [640 480]                constXTile_RR  8888: msecs =   2.75   

The GPU is consistently ~5.4ms for all these cases both before and after.

[TomH, 2013-01-17 09:23:12]

On 2013/01/16 23:06:32, robertphillips wrote:
> The generalization does cost us some time but this is a big win for the
filtered
> cases:

You say it costs us some time, but only one of the tests in your suite got
worse, and that's about 3% (probably noise)?

[robertphillips, 2013-01-17 13:59:46]

I was comparing the original reduced functionality time (constXRepeat 1.4) to
the new version (constXTile_RR 2.75) 
but (on the way home) realized I had changed the bench test significantly so I
really needed to run the reduced
functionality version on the new bench (revised-constXRepeat 2.72). So ... the
extra code to handle the additional cases
doesn't really slow things down.

I forgot to add these stats in the prior message:

BEFORE:

running bench [1257 3085] tabl_mlb.skp   tile_256x256: cmsecs =  47.32

AFTER:

running bench [1257 3085] tabl_mlb.skp   tile_256x256: cmsecs =  35.36

[robertphillips, 2013-01-17 14:13:56]

Note also that I completely ignored 565 in all of this:

   constXTile_MM_filter_trans  8888: msecs =   7.31   565: msecs = 161.92
   constXTile_CC_filter_trans  8888: msecs =   6.17   565: msecs =  98.65
   constXTile_RR_filter_trans  8888: msecs =   6.15   565: msecs = 112.67
          constXTile_MM_trans  8888: msecs =   5.93   565: msecs =  20.19
          constXTile_CC_trans  8888: msecs =   5.92   565: msecs =  20.09
          constXTile_RR_trans  8888: msecs =   5.79   565: msecs =  20.05
         constXTile_MM_filter  8888: msecs =   3.09   565: msecs = 141.89
         constXTile_CC_filter  8888: msecs =   2.83   565: msecs =  82.55
         constXTile_RR_filter  8888: msecs =   3.02   565: msecs =  95.77
                constXTile_MM  8888: msecs =   2.86   565: msecs =   2.75
                constXTile_CC  8888: msecs =   2.87   565: msecs =   2.62
                constXTile_RR  8888: msecs =   2.82   565: msecs =   2.75

[reed1, 2013-01-17 15:10:58]

Can we land the new bench(s) first?  (not required, but might be faster if there
are more edits to the CL)

https://codereview.appspot.com/7063054/diff/6001/bench/RepeatTileBench.cpp
File bench/RepeatTileBench.cpp (right):

https://codereview.appspot.com/7063054/diff/6001/bench/RepeatTileBench.cpp#ne...
bench/RepeatTileBench.cpp:153: // filtering and the different tiling modes
Should this really be called Repeat, given that its tile mode(s) are variable?

https://codereview.appspot.com/7063054/diff/6001/src/core/SkBitmapProcState.cpp
File src/core/SkBitmapProcState.cpp (right):

https://codereview.appspot.com/7063054/diff/6001/src/core/SkBitmapProcState.c...
src/core/SkBitmapProcState.cpp:561: 
does it help (or hurt) to declare mask static?

https://codereview.appspot.com/7063054/diff/6001/src/core/SkBitmapProcState_f...
File src/core/SkBitmapProcState_filter.h (right):

https://codereview.appspot.com/7063054/diff/6001/src/core/SkBitmapProcState_f...
src/core/SkBitmapProcState_filter.h:81: 
Aren't these already defined in SkBitmapProcState_filter[.h, _neon.h] ?

[robertphillips, 2013-01-17 19:30:38]

https://codereview.appspot.com/7063054/diff/6001/bench/RepeatTileBench.cpp
File bench/RepeatTileBench.cpp (right):

https://codereview.appspot.com/7063054/diff/6001/bench/RepeatTileBench.cpp#ne...
bench/RepeatTileBench.cpp:153: // filtering and the different tiling modes
On 2013/01/17 15:10:58, reed1 wrote:
> Should this really be called Repeat, given that its tile mode(s) are variable?

Done.

https://codereview.appspot.com/7063054/diff/6001/src/core/SkBitmapProcState.cpp
File src/core/SkBitmapProcState.cpp (right):

https://codereview.appspot.com/7063054/diff/6001/src/core/SkBitmapProcState.c...
src/core/SkBitmapProcState.cpp:561: 
It shouldn't make a difference

https://codereview.appspot.com/7063054/diff/6001/src/core/SkBitmapProcState_f...
File src/core/SkBitmapProcState_filter.h (right):

https://codereview.appspot.com/7063054/diff/6001/src/core/SkBitmapProcState_f...
src/core/SkBitmapProcState_filter.h:81: 
The full four input versions are defined about. These new versions only take two
colors. It appears that the compiler was able to optimize for the case where 'x'
is zero in the four input cases since I didn't see a huge improvement when I
added these.

[reed1, 2013-01-17 19:53:48]

Hurray for the optimized simpler version. Suggest adding a comment to that
effect.

lgtm

https://codereview.appspot.com/7063054/diff/8002/src/core/SkBitmapProcState_f...
File src/core/SkBitmapProcState_filter.h (right):

https://codereview.appspot.com/7063054/diff/8002/src/core/SkBitmapProcState_f...
src/core/SkBitmapProcState_filter.h:81: 
// Two color version, where we filter only along 1 axis

https://codereview.appspot.com/7063054/diff/8002/src/core/SkBitmapProcState_f...
src/core/SkBitmapProcState_filter.h:100: 
// Two color version, where we filter only along 1 axis

[robertphillips, 2013-01-18 16:39:12]

committed as r7273

https://codereview.appspot.com/7063054/diff/8002/src/core/SkBitmapProcState_f...
File src/core/SkBitmapProcState_filter.h (right):

https://codereview.appspot.com/7063054/diff/8002/src/core/SkBitmapProcState_f...
src/core/SkBitmapProcState_filter.h:81: 
On 2013/01/17 19:53:48, reed1 wrote:
> // Two color version, where we filter only along 1 axis

Done.

https://codereview.appspot.com/7063054/diff/8002/src/core/SkBitmapProcState_f...
src/core/SkBitmapProcState_filter.h:100: 
On 2013/01/17 19:53:48, reed1 wrote:
> // Two color version, where we filter only along 1 axis

Done.