Add MSA optimized ARGB4444ToI420 and ARGB4444ToARGB functions

Add MSA optimized ARGB4444ToI420 and ARGB4444ToARGB functions

R=fbarchard@google.com
BUG=libyuv:634
Performance gains : (Auto-vectorized C vs MSA SIMD)

ARGB4444ToYRow_MSA        : ~3.0x
ARGB4444ToUVRow_MSA       : ~1.8x
ARGB4444ToARGBRow_MSA     : ~3.4x

ARGB4444ToYRow_Any_MSA    : ~2.8x
ARGB4444ToUVRow_Any_MSA   : ~1.7x
ARGB4444ToARGBRow_Any_MSA : ~3.2x

Committed: https://chromium.googlesource.com/libyuv/libyuv/+/78c58ab8aa66b87e9ae8944f56a696d1ac29edce

[manojkumar.bhosale, 2016-10-14 08:33:50]

Description was changed from

==========
Add MSA optimized ARGB4444ToI420 and ARGB4444ToARGB functions

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

to

==========
Add MSA optimized ARGB4444ToI420 and ARGB4444ToARGB functions

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


Performance gains : (Auto-vectorized C vs MSA SIMD)

ARGB4444ToYRow_MSA        : ~3.0x
ARGB4444ToUVRow_MSA       : ~1.8x
ARGB4444ToARGBRow_MSA     : ~3.4x

ARGB4444ToYRow_Any_MSA    : ~2.8x
ARGB4444ToUVRow_Any_MSA   : ~1.7x
ARGB4444ToARGBRow_Any_MSA : ~3.2x
==========

[manojkumar.bhosale, 2016-10-14 08:33:50]

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

[manojkumar.bhosale, 2016-10-14 08:35:35]

Updated with reviewers, cc list and performance gain numbers

[fbarchard1, 2016-10-14 21:35:16]

lgtm
mostly style concern.  I would have used the intel approach which takes less
assembler.

What was the performance win?

When doing 4444, the code for 565 and 1555 are similar and should be done the
same way.  565 is the most common for android 16 bpp screen formats.

These functions arent common/important.
Suggest doing I420ToARGB and ARGBToI420:
I420ToARGB has some variations for subsampling, colorspace and output RGB
formats.

https://codereview.chromium.org/2421843002/diff/1/include/libyuv/macros_msa.h
File include/libyuv/macros_msa.h (right):

https://codereview.chromium.org/2421843002/diff/1/include/libyuv/macros_msa.h...
include/libyuv/macros_msa.h:51: #define LD_H2(RTYPE, psrc, stride, out0, out1) {
 \
would it more clear in the calling code to do the 2 loads?

https://codereview.chromium.org/2421843002/diff/1/source/convert.cc
File source/convert.cc (right):

https://codereview.chromium.org/2421843002/diff/1/source/convert.cc#newcode1232
source/convert.cc:1232: #if (defined(HAS_ARGB4444TOYROW_NEON) ||
defined(HAS_ARGB4444TOYROW_MSA))
I'd have suggested taking the intel approach, which write a single function for
this function to convert ARGB4444 to ARGB.  A bit of calling overhead but much
less code.
On Neon the vector load instructions made it easy to write direct loaders for
many formats, but on Intel and Mips a lot of code is needed to read different
RGB formats.

https://codereview.chromium.org/2421843002/diff/1/source/row_msa.cc
File source/row_msa.cc (right):

https://codereview.chromium.org/2421843002/diff/1/source/row_msa.cc#newcode254
source/row_msa.cc:254: vec0 *= const_0x19;
FYI The YUV to RGB functions now take constants as a parameter.  We should do
that for RGB to YUV at some point too, allowing jpeg and bt.709 coefficients.

https://codereview.chromium.org/2421843002/diff/1/source/row_msa.cc#newcode341
source/row_msa.cc:341: vec5 |= (v8u16) __msa_srai_h((v8i16) vec5, 6);
I'm concerned that this is a lot of code for a format/function that is rarely
used.  
ABGRToI420 or ARGBToI420 comes up a bit on android for screen casting, but
screen casting doesnt happen on android much... its more for desktops.
To reduce the code I would
1. take the approach intel version do, which is just do ARGB4444ToARGBRow_MSA
and then use ARGBToY and ARGBToUV.
2. use macros for ARGB4444TOARGB and perhaps for RGBTOYUV

https://codereview.chromium.org/2421843002/diff/1/source/row_msa.cc#newcode373
source/row_msa.cc:373: src_argb4444_next += 64;
on other platforms I'd typically unroll less than this... doing same read as
ARGBTOY, then subsampling and storing less UV.  Allows macros to share for first
part, and should achieve nearly same performance with less code.

[manojkumar.bhosale, 2016-10-19 11:56:28]

Used Intel strategy and new performance as below,

ARGB4444ToARGBRow_MSA     : ~3.4x
ARGB4444ToARGBRow_Any_MSA : ~3.2x

ARGBToYRow_MSA            : ~2.1x
ARGBToYRow_Any_MSA        : ~2.0x

ARGBToUVRow_MSA           : ~2.7x
ARGBToUVRow_Any_MSA       : ~2.6x

Overall for ARGB4444 to Y/UV conversion:
ARGB4444ToYRow_MSA        : ~2.8x
ARGB4444ToUVRow_MSA       : ~3.0x

https://codereview.chromium.org/2421843002/diff/1/include/libyuv/macros_msa.h
File include/libyuv/macros_msa.h (right):

https://codereview.chromium.org/2421843002/diff/1/include/libyuv/macros_msa.h...
include/libyuv/macros_msa.h:51: #define LD_H2(RTYPE, psrc, stride, out0, out1) {
 \
On 2016/10/14 21:35:16, fbarchard1 wrote:
> would it more clear in the calling code to do the 2 loads?

Removed this macro

https://codereview.chromium.org/2421843002/diff/1/source/convert.cc
File source/convert.cc (right):

https://codereview.chromium.org/2421843002/diff/1/source/convert.cc#newcode1232
source/convert.cc:1232: #if (defined(HAS_ARGB4444TOYROW_NEON) ||
defined(HAS_ARGB4444TOYROW_MSA))
On 2016/10/14 21:35:16, fbarchard1 wrote:
> I'd have suggested taking the intel approach, which write a single function
for
> this function to convert ARGB4444 to ARGB.  A bit of calling overhead but much
> less code.
> On Neon the vector load instructions made it easy to write direct loaders for
> many formats, but on Intel and Mips a lot of code is needed to read different
> RGB formats.

Done.

https://codereview.chromium.org/2421843002/diff/1/source/row_msa.cc
File source/row_msa.cc (right):

https://codereview.chromium.org/2421843002/diff/1/source/row_msa.cc#newcode254
source/row_msa.cc:254: vec0 *= const_0x19;
On 2016/10/14 21:35:16, fbarchard1 wrote:
> FYI The YUV to RGB functions now take constants as a parameter.  We should do
> that for RGB to YUV at some point too, allowing jpeg and bt.709 coefficients.

OK. will then fix them when changes happens.

https://codereview.chromium.org/2421843002/diff/1/source/row_msa.cc#newcode341
source/row_msa.cc:341: vec5 |= (v8u16) __msa_srai_h((v8i16) vec5, 6);
On 2016/10/14 21:35:16, fbarchard1 wrote:
> I'm concerned that this is a lot of code for a format/function that is rarely
> used.  
> ABGRToI420 or ARGBToI420 comes up a bit on android for screen casting, but
> screen casting doesnt happen on android much... its more for desktops.
> To reduce the code I would
> 1. take the approach intel version do, which is just do ARGB4444ToARGBRow_MSA
> and then use ARGBToY and ARGBToUV.
> 2. use macros for ARGB4444TOARGB and perhaps for RGBTOYUV

Done.

[fbarchard1, 2016-10-19 18:10:33]

lgtm
nit about ARGBToUV being unrolled more than necessary.

Re
Overall for ARGB4444 to Y/UV conversion:
ARGB4444ToYRow_MSA        : ~2.8x
ARGB4444ToUVRow_MSA       : ~3.0x

When you quote performance (vs C vectorized?) how are you measuring row
functions?
I'm using the libyuv_unittest with parameters to measure 1280x720 1000
iterations calling the public function.
So for this CL I would try ARGB4444ToI420 with C vs MSA and compare the previous
Neon approach vs the Intel approach.  The Intel approach here is expected to be
a little slower, but take less code.  On Intel the difference is less than 10%
performance loss, but on Arm I found the overhead is higher, and the code is
simplier.  MSA architecture appears to be more similar to Intel, with a simple
vector loader.

So I would run with NEON and C and compare:

aarch64
NEON
ARGB4444ToI420_Opt (1622 ms)
ARGBToI420_Opt (1197 ms)

C vectorized to NEON
ARGB4444ToI420_Opt (3327 ms)
ARGBToI420_Opt (4071 ms)

armv7 32 bit
NEON
ARGB4444ToI420_Opt (1563 ms)
ARGBToI420_Opt (2377 ms)

C vectorized to NEON
ARGB4444ToI420_Opt (3068 ms)
ARGBToI420_Opt (2714 ms)

Hard to explain some of these numbers.  Vectorization (with optimize:max)
enabled is reducing the win.
armv7 is using thumb2 which is faster than aarch64 on qualcomm820.
argb4444 is sometimes faster than due to memory being a bottleneck.
Intel Ivybridge (SSE2)
SSE2
ARGB4444ToI420_Opt (527 ms)
ARGBToI420_Opt (395 ms)
C
ARGB4444ToI420_Opt (5071 ms)
ARGBToI420_Opt (2176 ms)

https://codereview.chromium.org/2421843002/diff/20001/source/row_msa.cc
File source/row_msa.cc (right):

https://codereview.chromium.org/2421843002/diff/20001/source/row_msa.cc#newco...
source/row_msa.cc:270: void ARGBToUVRow_MSA(const uint8* src_argb0, int
src_stride_argb,
this is kinda HUGE!  But I see it does a 16 byte store, so maybe ok.
There will be variations of this for different ARGB and UV subsampling, so I
suggest a future version should use a macro for the conversion from ARGB to UV
itself, with different loads or stores.

[fbarchard1, 2016-10-19 18:10:53]

Description was changed from

==========
Add MSA optimized ARGB4444ToI420 and ARGB4444ToARGB functions

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


Performance gains : (Auto-vectorized C vs MSA SIMD)

ARGB4444ToYRow_MSA        : ~3.0x
ARGB4444ToUVRow_MSA       : ~1.8x
ARGB4444ToARGBRow_MSA     : ~3.4x

ARGB4444ToYRow_Any_MSA    : ~2.8x
ARGB4444ToUVRow_Any_MSA   : ~1.7x
ARGB4444ToARGBRow_Any_MSA : ~3.2x
==========

to

==========
Add MSA optimized ARGB4444ToI420 and ARGB4444ToARGB functions

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


Performance gains : (Auto-vectorized C vs MSA SIMD)

ARGB4444ToYRow_MSA        : ~3.0x
ARGB4444ToUVRow_MSA       : ~1.8x
ARGB4444ToARGBRow_MSA     : ~3.4x

ARGB4444ToYRow_Any_MSA    : ~2.8x
ARGB4444ToUVRow_Any_MSA   : ~1.7x
ARGB4444ToARGBRow_Any_MSA : ~3.2x

Committed:
https://chromium.googlesource.com/libyuv/libyuv/+/78c58ab8aa66b87e9ae8944f56a...
==========

[fbarchard1, 2016-10-19 18:10:54]

Committed patchset #2 (id:20001) manually as
78c58ab8aa66b87e9ae8944f56a696d1ac29edce (presubmit successful).