Add MSA optimized YUY2ToI422, YUY2ToI420, UYVYToI422, UYVYToI420 functions

Add MSA optimized YUY2ToI422, YUY2ToI420, UYVYToI422, UYVYToI420 functions

R=fbarchard@google.com
BUG=libyuv:634
Performance gains as below,

YUY2ToI422, YUY2ToI420 :-

YUY2ToYRow_MSA          : ~10x
YUY2ToUVRow_MSA         : ~11x
YUY2ToUV422Row_MSA      : ~9x
YUY2ToYRow_Any_MSA      : ~6x
YUY2ToUVRow_Any_MSA     : ~5x
YUY2ToUV422Row_Any_MSA  : ~4x


UYVYToI422, UYVYToI420 :-

UYVYToYRow_MSA          : ~10x
UYVYToUVRow_MSA         : ~11x
UYVYToUV422Row_MSA      : ~9x
UYVYToYRow_Any_MSA      : ~6x
UYVYToUVRow_Any_MSA     : ~5x
UYVYToUV422Row_Any_MSA  : ~4x

Committed: https://chromium.googlesource.com/libyuv/libyuv/+/a2891ec77c183ec265af8278eee821e4d9715c12

[manojkumar.bhosale, 2016-10-05 09:16:48]

Description was changed from

==========
Add MSA optimized YUY2ToI422, YUY2ToI420, UYVYToI422, UYVYToI420 functions

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

to

==========
Add MSA optimized YUY2ToI422, YUY2ToI420, UYVYToI422, UYVYToI420 functions

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


Performance gains as below,

YUY2ToI422, YUY2ToI420 :-

YUY2ToYRow_MSA          : ~10x
YUY2ToUVRow_MSA         : ~11x
YUY2ToUV422Row_MSA      : ~9x
YUY2ToYRow_Any_MSA      : ~6x
YUY2ToUVRow_Any_MSA     : ~5x
YUY2ToUV422Row_Any_MSA  : ~4x


UYVYToI422, UYVYToI420 :-

UYVYToYRow_MSA          : ~10x
UYVYToUVRow_MSA         : ~11x
UYVYToUV422Row_MSA      : ~9x
UYVYToYRow_Any_MSA      : ~6x
UYVYToUVRow_Any_MSA     : ~5x
UYVYToUV422Row_Any_MSA  : ~4x
==========

[manojkumar.bhosale, 2016-10-05 09:16:48]

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

[manojkumar.bhosale, 2016-10-05 09:19:14]

Updated with reviewers, cc list and performance gain numbers

[fbarchard1, 2016-10-05 22:03:59]

mostly nits... code looks functional.

prefer less unrolling.  If youre loading and storing full 16 byte vectors,
you're achieving most of the performance, or even loosing performance by
unrolling more.

prefer avoid macros unless they save a lot of code size and reduce
complexity/maintainence.  Here its 1 to 1... you're creating a macro for each
instruction.

prefer less casting

I'll see if I can make the Any versions of these support Any width instead of
requiring 16 (for YUV411 remainder code).

Ive updated the documentation for getting started, including mips, to show GN
mostly, but also benchmarking.
When youre benchmarking, are you using 1280x720 with 1000 iterations?
Are you running a release build for the C code?

Youre improvements are seem high (10x) for simple function, indicating the C
code is producing poor performance.
On arm64 I'm seeing clang vectoring, reducing the benefit of SIMD.  Are you
getting MSA from C code vectorization?
Ive turned on optimize:max for GN builds which helped arm64.  Scrutenize you C
code generatoin to see if its doing a reasonable job.

Your any performance is alot lower than opt.  Normally it shouldnt be much
different.  Whats going on there?
Perhaps its your unrolling is requiring more code to run thru that 'any' path
but its still SIMD, but with a memcpy.  Is memcpy/memset slow?  The memset isnt
really needed... its for msan.  Its not high in profiles on other platforms. 
Can you run perf record/perf report to ensure you're running the code you
expect?

https://codereview.chromium.org/2397693002/diff/1/source/planar_functions.cc
File source/planar_functions.cc (right):

https://codereview.chromium.org/2397693002/diff/1/source/planar_functions.cc#...
source/planar_functions.cc:486: if (width >= 16) {
todo - make Any handle remainder better so this test is not necessary.

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

https://codereview.chromium.org/2397693002/diff/1/source/row_msa.cc#newcode109
source/row_msa.cc:109: for (x = 0; x < width; x += 64) {
suggest 32 at a time... or 16.  4 of everything requires a lot of alignment (any
will be used more) and code size/icache goes up, hurting performance.
On many cpus, too many of 1 instruction causes execution unittest to saturate. 
e.g. you can often do 2 of the same instruction, but few cpus have 4 execution
units that can run in parallel for the same instruction.  2 of everything is
usually a good compromise.

https://codereview.chromium.org/2397693002/diff/1/source/row_msa.cc#newcode115
source/row_msa.cc:115: dst_y += 64;
this is unrolled quite alot.  other platforms are doing 16 pixels?

https://codereview.chromium.org/2397693002/diff/1/source/row_msa.cc#newcode132
source/row_msa.cc:132: dst0 = (v16u8) __msa_pckev_b((v16i8) vec1, (v16i8) vec0);
style nit - i like seeing the intrinisics (or inline asm) used directly and
would prefer avoid the macros, except for large blocks of reusable code, such as
YUVToRGB

https://codereview.chromium.org/2397693002/diff/1/source/row_msa.cc#newcode143
source/row_msa.cc:143: void YUY2ToUV422Row_MSA(const uint8* src_yuy2, uint8*
dst_u, uint8* dst_v,
prefer this be same as YUY2TToUV and do 32 at a time.
Code should be almost the same, but with averaging removed.

https://codereview.chromium.org/2397693002/diff/1/source/row_msa.cc#newcode192
source/row_msa.cc:192: dst1 = (v16u8) __msa_pckod_b((v16i8) vec1, (v16i8) vec0);
the i8 version of vectors seems to be preferred?  use those types instead to
reduce casting?

[kjellander_chromium, 2016-10-06 09:32:44]

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

[manojkumar.bhosale, 2016-10-07 10:42:09]

Incorporated review comments

Enabling auto-vectorization for C code reduced SIMD benefit and new MSA
performance gains vs C are as below,

YUY2ToI422, YUY2ToI420 :-

YUY2ToYRow_MSA          : ~1.5x  
YUY2ToUVRow_MSA         : ~5.7x  
YUY2ToUV422Row_MSA      : ~1.7x  
YUY2ToYRow_Any_MSA      : ~1.3x  
YUY2ToUVRow_Any_MSA     : ~4.7x  
YUY2ToUV422Row_Any_MSA  : ~1.5x  


UYVYToI422, UYVYToI420 :-

UYVYToYRow_MSA          : ~1.9x  
UYVYToUVRow_MSA         : ~5.7x  
UYVYToUV422Row_MSA      : ~1.3x  
UYVYToYRow_Any_MSA      : ~1.7x  
UYVYToUVRow_Any_MSA     : ~4.7x  
UYVYToUV422Row_Any_MSA  : ~1.2x 

Also verified that memsets from any functions are not impacting much.

Modified getting started to remove un-necessary "

https://codereview.chromium.org/2397693002/diff/1/source/planar_functions.cc
File source/planar_functions.cc (right):

https://codereview.chromium.org/2397693002/diff/1/source/planar_functions.cc#...
source/planar_functions.cc:486: if (width >= 16) {
On 2016/10/05 22:03:58, fbarchard1 wrote:
> todo - make Any handle remainder better so this test is not necessary.

Done.

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

https://codereview.chromium.org/2397693002/diff/1/source/row_msa.cc#newcode109
source/row_msa.cc:109: for (x = 0; x < width; x += 64) {
On 2016/10/05 22:03:58, fbarchard1 wrote:
> suggest 32 at a time... or 16.  4 of everything requires a lot of alignment
(any
> will be used more) and code size/icache goes up, hurting performance.
> On many cpus, too many of 1 instruction causes execution unittest to saturate.

> e.g. you can often do 2 of the same instruction, but few cpus have 4 execution
> units that can run in parallel for the same instruction.  2 of everything is
> usually a good compromise.

We have done loop unrolling considering the load latency of 8-10 cycles and to
avoid un-necessary stalls. However, agreed that any will be used more impacting
performance so processing 32 at a time will be a good compromise. Modified for
32.

https://codereview.chromium.org/2397693002/diff/1/source/row_msa.cc#newcode115
source/row_msa.cc:115: dst_y += 64;
On 2016/10/05 22:03:58, fbarchard1 wrote:
> this is unrolled quite alot.  other platforms are doing 16 pixels?

Done.

https://codereview.chromium.org/2397693002/diff/1/source/row_msa.cc#newcode132
source/row_msa.cc:132: dst0 = (v16u8) __msa_pckev_b((v16i8) vec1, (v16i8) vec0);
On 2016/10/05 22:03:58, fbarchard1 wrote:
> style nit - i like seeing the intrinisics (or inline asm) used directly and
> would prefer avoid the macros, except for large blocks of reusable code, such
as
> YUVToRGB

Acknowledged.

https://codereview.chromium.org/2397693002/diff/1/source/row_msa.cc#newcode143
source/row_msa.cc:143: void YUY2ToUV422Row_MSA(const uint8* src_yuy2, uint8*
dst_u, uint8* dst_v,
On 2016/10/05 22:03:58, fbarchard1 wrote:
> prefer this be same as YUY2TToUV and do 32 at a time.
> Code should be almost the same, but with averaging removed.

Done.

https://codereview.chromium.org/2397693002/diff/1/source/row_msa.cc#newcode192
source/row_msa.cc:192: dst1 = (v16u8) __msa_pckod_b((v16i8) vec1, (v16i8) vec0);
On 2016/10/05 22:03:58, fbarchard1 wrote:
> the i8 version of vectors seems to be preferred?  use those types instead to
> reduce casting?

As we are operating on pixel data (u8), we have used all u8 vector types. The i8
version of vectors can be used but then all the intrinsic have to be used for i8
operations except aver as it is sign dependent intrinsic and then it will need
u8 casting.

The type casting here can be removed using -flax-vector-conversions gcc flag
however we have avoided its use as per gcc recommendation at below link,
https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html

Considering pckev_b/od_b intrinsic currently accepting i8 operands & returning
i8 result, keeping the casting as is.

[fbarchard1, 2016-10-07 17:32:44]

lgtm

[fbarchard1, 2016-10-07 17:34:43]

fbarchard@google.com changed reviewers:
+ kjellander@chromium.org

[fbarchard1, 2016-10-07 17:37:11]

On 2016/10/07 17:32:44, fbarchard1 wrote:
> lgtm

note I dont currently have a way to test, but visual inspection of instructions
looks correct.
caveat my benchmarks on arm are currently not working as expected.  intel seems
ok.
My expectation is a function like YUY2ToI420 would be similar speed to
YUY2ToNV12, and SIMD should be faster than C, usually in the 2x - 4x range for a
simple function like this.

[fbarchard1, 2016-10-07 17:37:24]

Description was changed from

==========
Add MSA optimized YUY2ToI422, YUY2ToI420, UYVYToI422, UYVYToI420 functions

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


Performance gains as below,

YUY2ToI422, YUY2ToI420 :-

YUY2ToYRow_MSA          : ~10x
YUY2ToUVRow_MSA         : ~11x
YUY2ToUV422Row_MSA      : ~9x
YUY2ToYRow_Any_MSA      : ~6x
YUY2ToUVRow_Any_MSA     : ~5x
YUY2ToUV422Row_Any_MSA  : ~4x


UYVYToI422, UYVYToI420 :-

UYVYToYRow_MSA          : ~10x
UYVYToUVRow_MSA         : ~11x
UYVYToUV422Row_MSA      : ~9x
UYVYToYRow_Any_MSA      : ~6x
UYVYToUVRow_Any_MSA     : ~5x
UYVYToUV422Row_Any_MSA  : ~4x
==========

to

==========
Add MSA optimized YUY2ToI422, YUY2ToI420, UYVYToI422, UYVYToI420 functions

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


Performance gains as below,

YUY2ToI422, YUY2ToI420 :-

YUY2ToYRow_MSA          : ~10x
YUY2ToUVRow_MSA         : ~11x
YUY2ToUV422Row_MSA      : ~9x
YUY2ToYRow_Any_MSA      : ~6x
YUY2ToUVRow_Any_MSA     : ~5x
YUY2ToUV422Row_Any_MSA  : ~4x


UYVYToI422, UYVYToI420 :-

UYVYToYRow_MSA          : ~10x
UYVYToUVRow_MSA         : ~11x
UYVYToUV422Row_MSA      : ~9x
UYVYToYRow_Any_MSA      : ~6x
UYVYToUVRow_Any_MSA     : ~5x
UYVYToUV422Row_Any_MSA  : ~4x

Committed:
https://chromium.googlesource.com/libyuv/libyuv/+/a2891ec77c183ec265af8278eee...
==========

[fbarchard1, 2016-10-07 17:37:25]

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

[fbarchard1, 2016-10-10 18:38:06]

I looked into performance of these functions for Intel and Arm.
YUY2ToI422 was affected by row coalesce, so it is now only done on small images.

On Arm for comparison, using 1280x720 1000 iterations on Qualcomm 820,
performance is:

Neon
YUY2ToI420_Opt (555 ms)
UYVYToI420_Opt (509 ms)
YUY2ToI422_Opt (402 ms)
UYVYToI422_Opt (517 ms)
YUY2ToNV12_Opt (545 ms)
UYVYToNV12_Opt (525 ms)

C (vectorized to Neon)
YUY2ToI420_Opt (1443 ms)
UYVYToI420_Opt (948 ms)
YUY2ToI422_Opt (778 ms)
UYVYToI422_Opt (753 ms)
YUY2ToNV12_Opt (561 ms)
UYVYToNV12_Opt (554 ms)

Reducing size to 640x360, increasing iterations to 4000, performance is:
Neon
YUY2ToI420_Opt (312 ms)
UYVYToI420_Opt (247 ms)
YUY2ToI422_Opt (239 ms)
UYVYToI422_Opt (400 ms)
YUY2ToNV12_Opt (327 ms)
UYVYToNV12_Opt (287 ms)

C
YUY2ToI420_Opt (998 ms)
UYVYToI420_Opt (917 ms)
YUY2ToI422_Opt (648 ms)
UYVYToI422_Opt (646 ms)
YUY2ToNV12_Opt (545 ms)
UYVYToNV12_Opt (559 ms)

YUY2ToI420_Opt 3.19x
UYVYToI420_Opt 3.71x
YUY2ToI422_Opt 2.71x
UYVYToI422_Opt 1.62x
YUY2ToNV12_Opt 1.66x
UYVYToNV12_Opt 1.94x

Turning off vectorization, -Os is used

NEON
YUY2ToI420_Opt (300 ms)
UYVYToI420_Opt (344 ms)
YUY2ToI422_Opt (286 ms)
UYVYToI422_Opt (291 ms)
YUY2ToNV12_Opt (293 ms)
UYVYToNV12_Opt (209 ms)

C
YUY2ToI420_Opt (7952 ms)
UYVYToI420_Opt (8918 ms)
YUY2ToI422_Opt (12732 ms)
UYVYToI422_Opt (18621 ms)
YUY2ToNV12_Opt (22344 ms)
UYVYToNV12_Opt (20779 ms)

YUY2ToI420_Opt 26.5x
UYVYToI420_Opt 25.9x
YUY2ToI422_Opt 44.5x
UYVYToI422_Opt 63.9x
YUY2ToNV12_Opt 76.2x
UYVYToNV12_Opt 99.4x

[fbarchard1, 2016-10-12 21:01:54]

note that I'm seeing ongoing performance issues with these on arm.  Functions
that have 1 read and multiple writes are much slower than the inverse.
The unittest now allocates the U and V plane as a side by side buffer, reducing
page misses.