Add MSA optimized ARGB scaling functions

Add MSA optimized ARGB scaling functions

R=fbarchard@google.com
BUG=libyuv:634
Performance Gain (vs C vectorized)
ScaleARGBRowDown2_MSA           - ~2.6x
ScaleARGBRowDown2Linear_MSA     - ~7.9x
ScaleARGBRowDown2Box_MSA        - ~3.7x
ScaleARGBRowDownEven_MSA        - ~1.2x
ScaleARGBRowDownEvenBox_MSA     - ~3.5x

ScaleARGBRowDown2_Any_MSA       - ~2.6x
ScaleARGBRowDown2Linear_Any_MSA - ~7.9x
ScaleARGBRowDown2Box_Any_MSA    - ~3.6x
ScaleARGBRowDownEven_Any_MSA    - ~1.2x
ScaleARGBRowDownEvenBox_Any_MSA - ~3.5x

Performance Gain (vs C non-vectorized)
ScaleARGBRowDown2_MSA           - 2.6x
ScaleARGBRowDown2Linear_MSA     - 13.5x
ScaleARGBRowDown2Box_MSA        - 5.8x
ScaleARGBRowDownEven_MSA        - 1.2x
ScaleARGBRowDownEvenBox_MSA     - 3.7x

ScaleARGBRowDown2_Any_MSA       - 2.6x
ScaleARGBRowDown2Linear_Any_MSA - 13.5x
ScaleARGBRowDown2Box_Any_MSA    - 5.3x
ScaleARGBRowDownEven_Any_MSA    - 1.2x
ScaleARGBRowDownEvenBox_Any_MSA - 3.7x

Committed: https://chromium.googlesource.com/libyuv/libyuv/+/56b5bbb0be6368c50dca5e120a3d72379e1ffbad

[manojkumar.bhosale, 2016-11-24 15:43:07]

Description was changed from

==========
Add MSA optimized ARGB scaling functions

R=fbarchard@google.com
BUG=libyuv:634
==========

to

==========
Add MSA optimized ARGB scaling functions

R=fbarchard@google.com
BUG=libyuv:634

Performance Gain (vs C vectorized)
ScaleARGBRowDown2_MSA           - ~2.6x
ScaleARGBRowDown2Linear_MSA     - ~7.9x
ScaleARGBRowDown2Box_MSA        - ~3.7x
ScaleARGBRowDownEven_MSA        - ~1.2x
ScaleARGBRowDownEvenBox_MSA     - ~3.5x

ScaleARGBRowDown2_Any_MSA       - ~2.6x
ScaleARGBRowDown2Linear_Any_MSA - ~7.9x
ScaleARGBRowDown2Box_Any_MSA    - ~3.6x
ScaleARGBRowDownEven_Any_MSA    - ~1.2x
ScaleARGBRowDownEvenBox_Any_MSA - ~3.5x

Performance Gain (vs C non-vectorized)
ScaleARGBRowDown2_MSA           - 2.6x
ScaleARGBRowDown2Linear_MSA     - 13.5x
ScaleARGBRowDown2Box_MSA        - 5.8x
ScaleARGBRowDownEven_MSA        - 1.2x
ScaleARGBRowDownEvenBox_MSA     - 3.7x

ScaleARGBRowDown2_Any_MSA       - 2.6x
ScaleARGBRowDown2Linear_Any_MSA - 13.5x
ScaleARGBRowDown2Box_Any_MSA    - 5.3x
ScaleARGBRowDownEven_Any_MSA    - 1.2x
ScaleARGBRowDownEvenBox_Any_MSA - 3.7x
==========

[manojkumar.bhosale, 2016-11-24 15:43:07]

manojkumar.bhosale@imgtec.com changed reviewers:
+ kjellander@chromium.org

[manojkumar.bhosale, 2016-11-24 15:44:00]

Updated with reviewers, cc list and performance gain numbers

[kjellander_chromium, 2016-11-24 19:23:08]

kjellander@chromium.org changed reviewers:
- kjellander@chromium.org

[fbarchard1, 2016-11-30 01:15:49]

lgtm but suggest doing 4 pixels for all loops and please confirm rounding shift
is used, or add 2 before shift.

note when I say lgtm, i'd prefer you make minor changes, but go ahead and
submit.

suggest doing follow up InterpolateRow() which is used for general purpose
scaling.

https://codereview.chromium.org/2527983002/diff/40001/source/scale_msa.cc
File source/scale_msa.cc (right):

https://codereview.chromium.org/2527983002/diff/40001/source/scale_msa.cc#new...
source/scale_msa.cc:22: void ScaleARGBRowDown2_MSA(const uint8_t* src_argb,
This function, and Linear, arent really used in production code much, so I would
keep this as similar to ScaleARGBRowDown2Linear_MSA as possible, which is 4 at a
time.  You should expect performance to be the same or slightly better than
Linear

https://codereview.chromium.org/2527983002/diff/40001/source/scale_msa.cc#new...
source/scale_msa.cc:66: const uint8_t* nxt_argb = src_argb + src_stride;
nit re nxt_argb

I havent used this variable name before.  I see why you did it
In the YUV C code I used s and t variables like this:

void ScaleRowDown2Box_C(const uint8* src_ptr,
                        ptrdiff_t src_stride,
                        uint8* dst,
                        int dst_width) {
  const uint8* s = src_ptr;
  const uint8* t = src_ptr + src_stride;
  int x;
  for (x = 0; x < dst_width - 1; x += 2) {
    dst[0] = (s[0] + s[1] + t[0] + t[1] + 2) >> 2;
    dst[1] = (s[2] + s[3] + t[2] + t[3] + 2) >> 2;
    dst += 2;
    s += 4;
    t += 4;
  }
  if (dst_width & 1) {
    dst[0] = (s[0] + s[1] + t[0] + t[1] + 2) >> 2;
  }
}

or sometimes I would number the pointers if there are several rows.

On Intel its often better to use stride in the addressing because you can
address with base, offset and index and then only increment 1 variable.
Is Mips like that?
I sometimes go out of my way to use a fixed offset between 2 variables even.
The simpliest example of that would be memcpy(s,d,len)
instead of
while(len--)
 *d++ = *s++;
you could use:
int offset = d-s;
while(len--) {
 d[offset] = s[0];
 ++s;
}
or for C code more readable would be
for (int i=0; i < len; ++i) {
  d[i] = s[i];
}
which increments 1 offset instead of 2 pointers.

https://codereview.chromium.org/2527983002/diff/40001/source/scale_msa.cc#new...
source/scale_msa.cc:71: src0 = (v16u8)__msa_ld_b((v16i8*)src_argb, 0);
This is pretty large/slow?
This is an important function, and YUV and some subsampling code will be
similar.

On intel I took the liberty of doing 2 averages, which has rounding error, but
is roughly the same as  ScaleARGBRowDown2Linear_MSA done twice.
But I think we should move away from that, and do correct rounding, though.

On ARM I would do code similar to ScaleARGBRowDown2Linear_MSA but instead of
average, do an add that expands to 16 bit values.  Do you have something like
that?
Then the code would be similar to Linear, but done twice, then results adds and
shifted/packed down.
So it would be 5 instructions per row * 2 rows = 10, add, narrow and store. 
Roughly 12 instructions.  Currently you have 22 instructions.
On Intel I might consider using vpmaddubsw because it does a horizontal add
(paired) and widens the result to 16 bits.  It does a multiply, which could be
1, but could be used to move the result to the upper 8 bits.  Its only 0.5
cycles.  I dont think MSA (or ARM) has an instruction like that.

https://codereview.chromium.org/2527983002/diff/40001/source/scale_msa.cc#new...
source/scale_msa.cc:90: reg1 = (v8u16)__msa_srari_h((v8i16)reg1, 2);
Does __msa_srari_h() do rounding?
Can you refer me to an instruction guide?

The C code does
dst_argb[0] = (src_argb[0] + src_argb[4] + src_argb[src_stride] +
                   src_argb[src_stride + 4] + 2) >>
                  2;

[manojkumar.bhosale, 2016-12-01 13:06:07]

https://codereview.chromium.org/2527983002/diff/40001/source/scale_msa.cc
File source/scale_msa.cc (right):

https://codereview.chromium.org/2527983002/diff/40001/source/scale_msa.cc#new...
source/scale_msa.cc:22: void ScaleARGBRowDown2_MSA(const uint8_t* src_argb,
On 2016/11/30 01:15:48, fbarchard1 wrote:
> This function, and Linear, arent really used in production code much, so I
would
> keep this as similar to ScaleARGBRowDown2Linear_MSA as possible, which is 4 at
a
> time.  You should expect performance to be the same or slightly better than
> Linear

Done. The performance is slightly degraded (2.6x to 2.3x) because of reduced
instructions to handle load latencies.

https://codereview.chromium.org/2527983002/diff/40001/source/scale_msa.cc#new...
source/scale_msa.cc:66: const uint8_t* nxt_argb = src_argb + src_stride;
On 2016/11/30 01:15:48, fbarchard1 wrote:
> nit re nxt_argb
> 
> I havent used this variable name before.  I see why you did it
> In the YUV C code I used s and t variables like this:
> 
> void ScaleRowDown2Box_C(const uint8* src_ptr,
>                         ptrdiff_t src_stride,
>                         uint8* dst,
>                         int dst_width) {
>   const uint8* s = src_ptr;
>   const uint8* t = src_ptr + src_stride;
>   int x;
>   for (x = 0; x < dst_width - 1; x += 2) {
>     dst[0] = (s[0] + s[1] + t[0] + t[1] + 2) >> 2;
>     dst[1] = (s[2] + s[3] + t[2] + t[3] + 2) >> 2;
>     dst += 2;
>     s += 4;
>     t += 4;
>   }
>   if (dst_width & 1) {
>     dst[0] = (s[0] + s[1] + t[0] + t[1] + 2) >> 2;
>   }
> }
> 
> or sometimes I would number the pointers if there are several rows.
> 
> On Intel its often better to use stride in the addressing because you can
> address with base, offset and index and then only increment 1 variable.
> Is Mips like that?
> I sometimes go out of my way to use a fixed offset between 2 variables even.
> The simpliest example of that would be memcpy(s,d,len)
> instead of
> while(len--)
>  *d++ = *s++;
> you could use:
> int offset = d-s;
> while(len--) {
>  d[offset] = s[0];
>  ++s;
> }
> or for C code more readable would be
> for (int i=0; i < len; ++i) {
>   d[i] = s[i];
> }
> which increments 1 offset instead of 2 pointers.

Done. Also, we avoided using stride in addressing (every time in loop) where
compiler may generate multiple pointer manipulation GP instructions impacting
core loop's performance.

https://codereview.chromium.org/2527983002/diff/40001/source/scale_msa.cc#new...
source/scale_msa.cc:71: src0 = (v16u8)__msa_ld_b((v16i8*)src_argb, 0);
On 2016/11/30 01:15:48, fbarchard1 wrote:
> This is pretty large/slow?
> This is an important function, and YUV and some subsampling code will be
> similar.
> 
> On intel I took the liberty of doing 2 averages, which has rounding error, but
> is roughly the same as  ScaleARGBRowDown2Linear_MSA done twice.
> But I think we should move away from that, and do correct rounding, though.
> 
> On ARM I would do code similar to ScaleARGBRowDown2Linear_MSA but instead of
> average, do an add that expands to 16 bit values.  Do you have something like
> that?
> Then the code would be similar to Linear, but done twice, then results adds
and
> shifted/packed down.
> So it would be 5 instructions per row * 2 rows = 10, add, narrow and store. 
> Roughly 12 instructions.  Currently you have 22 instructions.
> On Intel I might consider using vpmaddubsw because it does a horizontal add
> (paired) and widens the result to 16 bits.  It does a multiply, which could be
> 1, but could be used to move the result to the upper 8 bits.  Its only 0.5
> cycles.  I dont think MSA (or ARM) has an instruction like that.


Modified this function to replace interleave & pack operations with shuffle and
fitted in total 18 instructions.
Here, strategy of Linear can not be used as is because in Linear, we could do
add & rounding with single aver_u_b instruction and within 8 bits only, which is
not true here.
For MSA, we do not have add with expand.

https://codereview.chromium.org/2527983002/diff/40001/source/scale_msa.cc#new...
source/scale_msa.cc:90: reg1 = (v8u16)__msa_srari_h((v8i16)reg1, 2);
On 2016/11/30 01:15:48, fbarchard1 wrote:
> Does __msa_srari_h() do rounding?
> Can you refer me to an instruction guide?
> 
> The C code does
> dst_argb[0] = (src_argb[0] + src_argb[4] + src_argb[src_stride] +
>                    src_argb[src_stride + 4] + 2) >>
>                   2;
> 

Please refer to the MSA instruction set at,
https://imgtec.com/documentation/  ->  MIPS SIMD  -> The MIPS32 SIMD
Architecture Module

[fbarchard1, 2016-12-06 00:45:20]

lgtm

https://codereview.chromium.org/2527983002/diff/40001/source/scale_msa.cc
File source/scale_msa.cc (right):

https://codereview.chromium.org/2527983002/diff/40001/source/scale_msa.cc#new...
source/scale_msa.cc:90: reg1 = (v8u16)__msa_srari_h((v8i16)reg1, 2);
On 2016/12/01 13:06:06, manojkumar.bhosale wrote:
> On 2016/11/30 01:15:48, fbarchard1 wrote:
> > Does __msa_srari_h() do rounding?
> > Can you refer me to an instruction guide?
> > 
> > The C code does
> > dst_argb[0] = (src_argb[0] + src_argb[4] + src_argb[src_stride] +
> >                    src_argb[src_stride + 4] + 2) >>
> >                   2;
> > 
> 
> Please refer to the MSA instruction set at,
> https://imgtec.com/documentation/  ->  MIPS SIMD  -> The MIPS32 SIMD
> Architecture Module

Acknowledged.
srari is Immediate Shift Right Arithmetic Rounded

[manojkumar.bhosale, 2016-12-07 06:16:21]

Description was changed from

==========
Add MSA optimized ARGB scaling functions

R=fbarchard@google.com
BUG=libyuv:634

Performance Gain (vs C vectorized)
ScaleARGBRowDown2_MSA           - ~2.6x
ScaleARGBRowDown2Linear_MSA     - ~7.9x
ScaleARGBRowDown2Box_MSA        - ~3.7x
ScaleARGBRowDownEven_MSA        - ~1.2x
ScaleARGBRowDownEvenBox_MSA     - ~3.5x

ScaleARGBRowDown2_Any_MSA       - ~2.6x
ScaleARGBRowDown2Linear_Any_MSA - ~7.9x
ScaleARGBRowDown2Box_Any_MSA    - ~3.6x
ScaleARGBRowDownEven_Any_MSA    - ~1.2x
ScaleARGBRowDownEvenBox_Any_MSA - ~3.5x

Performance Gain (vs C non-vectorized)
ScaleARGBRowDown2_MSA           - 2.6x
ScaleARGBRowDown2Linear_MSA     - 13.5x
ScaleARGBRowDown2Box_MSA        - 5.8x
ScaleARGBRowDownEven_MSA        - 1.2x
ScaleARGBRowDownEvenBox_MSA     - 3.7x

ScaleARGBRowDown2_Any_MSA       - 2.6x
ScaleARGBRowDown2Linear_Any_MSA - 13.5x
ScaleARGBRowDown2Box_Any_MSA    - 5.3x
ScaleARGBRowDownEven_Any_MSA    - 1.2x
ScaleARGBRowDownEvenBox_Any_MSA - 3.7x
==========

to

==========
Add MSA optimized ARGB scaling functions

R=fbarchard@google.com
BUG=libyuv:634

Performance Gain (vs C vectorized)
ScaleARGBRowDown2_MSA           - ~2.6x
ScaleARGBRowDown2Linear_MSA     - ~7.9x
ScaleARGBRowDown2Box_MSA        - ~3.7x
ScaleARGBRowDownEven_MSA        - ~1.2x
ScaleARGBRowDownEvenBox_MSA     - ~3.5x

ScaleARGBRowDown2_Any_MSA       - ~2.6x
ScaleARGBRowDown2Linear_Any_MSA - ~7.9x
ScaleARGBRowDown2Box_Any_MSA    - ~3.6x
ScaleARGBRowDownEven_Any_MSA    - ~1.2x
ScaleARGBRowDownEvenBox_Any_MSA - ~3.5x

Performance Gain (vs C non-vectorized)
ScaleARGBRowDown2_MSA           - 2.6x
ScaleARGBRowDown2Linear_MSA     - 13.5x
ScaleARGBRowDown2Box_MSA        - 5.8x
ScaleARGBRowDownEven_MSA        - 1.2x
ScaleARGBRowDownEvenBox_MSA     - 3.7x

ScaleARGBRowDown2_Any_MSA       - 2.6x
ScaleARGBRowDown2Linear_Any_MSA - 13.5x
ScaleARGBRowDown2Box_Any_MSA    - 5.3x
ScaleARGBRowDownEven_Any_MSA    - 1.2x
ScaleARGBRowDownEvenBox_Any_MSA - 3.7x

Committed:
https://chromium.googlesource.com/libyuv/libyuv/+/56b5bbb0be6368c50dca5e120a3...
==========

[manojkumar.bhosale, 2016-12-07 06:16:25]

Committed patchset #4 (id:60001) manually as
56b5bbb0be6368c50dca5e120a3d72379e1ffbad (presubmit successful).