Add a hook for CPU-optimized sRGB-sRGB srcover.

Add a hook for CPU-optimized sRGB-sRGB srcover.

Herb's really starting to get serious about tweaking this, which becomes
a lot easier when you've got SkOpts' runtime CPU detection. We should be 
able to optimize this usefully for SSSE3, SSE4.1, AVX, AVX2, or NEON.
(We can of course implement a subset.)

This function takes two counts to give us flexibility to write src patterns:
   nsrc >= ndst -> the usual srcover function
   nsrc <  ndst -> repeat src until it fills dst
   nsrc << ndst -> possibly preprocess src into registers
   nsrc == 1    -> equivalent of blitrow_color32, srcover_1, etc.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1939783003

Committed: https://skia.googlesource.com/skia/+/c5091b5b6c4b8a7aef8c12db9ea2a85e907b01c4

[mtklein_C, 2016-05-02 17:38:09]

Description was changed from

==========
Add a hook for CPU-optimized sRGB-sRGB srcover.

We should be able to optimize this usefully for SSSE3, SSE4.1, AVX, AVX2,
and NEON.

Two counts give us the flexibility to write src patterns:
   nsrc >= ndst -> the usual srcover function
   nsrc <  ndst -> repeat src until it fills dst
   nsrc << ndst -> possibly build up src as a pattern in registers
   nsrc == 1    -> equivalent of blitrow_color32, srcover_1, etc.

BUG=skia:
==========

to

==========
Add a hook for CPU-optimized sRGB-sRGB srcover.

We should be able to optimize this usefully for SSSE3, SSE4.1, AVX, AVX2,
and NEON.

Two counts give us the flexibility to write src patterns:
   nsrc >= ndst -> the usual srcover function
   nsrc <  ndst -> repeat src until it fills dst
   nsrc << ndst -> possibly build up src as a pattern in registers
   nsrc == 1    -> equivalent of blitrow_color32, srcover_1, etc.

BUG=skia:
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
==========

[mtklein_C, 2016-05-02 18:02:43]

Description was changed from

==========
Add a hook for CPU-optimized sRGB-sRGB srcover.

We should be able to optimize this usefully for SSSE3, SSE4.1, AVX, AVX2,
and NEON.

Two counts give us the flexibility to write src patterns:
   nsrc >= ndst -> the usual srcover function
   nsrc <  ndst -> repeat src until it fills dst
   nsrc << ndst -> possibly build up src as a pattern in registers
   nsrc == 1    -> equivalent of blitrow_color32, srcover_1, etc.

BUG=skia:
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
==========

to

==========
Add a hook for CPU-optimized sRGB-sRGB srcover.

Herb's really starting to get serious about tweaking this, which becomes
a lot easier when you've got SkOpts' runtime CPU detection. We should be 
able to optimize this usefully for SSSE3, SSE4.1, AVX, AVX2, or NEON.
(We can of course implement a subset.)

This function takes two counts to give us flexibility to write src patterns:
   nsrc >= ndst -> the usual srcover function
   nsrc <  ndst -> repeat src until it fills dst
   nsrc << ndst -> possibly preprocess src into registers
   nsrc == 1    -> equivalent of blitrow_color32, srcover_1, etc.

BUG=skia:
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
==========

[mtklein_C, 2016-05-02 18:04:11]

mtklein@chromium.org changed reviewers:
+ fmalita@chromium.org, herb@google.com

[mtklein_C, 2016-05-02 18:04:12]

The CQ bit was checked by mtklein@chromium.org

[commit-bot: I haz the power, 2016-05-02 18:04:15]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1939783003/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1939783003/40001

[commit-bot: I haz the power, 2016-05-02 18:04:16]

Note for Reviewers:
The CQ is waiting for an approval.
If you believe that the CL is not ready yet, or if you would like to L-G-T-M
with comments then please uncheck the CQ checkbox.

Waiting for LGTM from valid reviewer(s) till 2016-05-03 00:04 UTC

[f(malita), 2016-05-02 18:19:27]

https://codereview.chromium.org/1939783003/diff/40001/src/opts/SkBlend_opts.h
File src/opts/SkBlend_opts.h (right):

https://codereview.chromium.org/1939783003/diff/40001/src/opts/SkBlend_opts.h...
src/opts/SkBlend_opts.h:18: switch (src >> 24) {
Should dst/src be SkPMColor to make the swizzle explicit?

Maybe use SK_A32_SHIFT, SK_AlphaTRANSPARENT, SK_AlphaOPAQUE?

[mtklein, 2016-05-02 18:25:20]

On 2016/05/02 at 18:19:27, fmalita wrote:
> https://codereview.chromium.org/1939783003/diff/40001/src/opts/SkBlend_opts.h
> File src/opts/SkBlend_opts.h (right):
> 
>
https://codereview.chromium.org/1939783003/diff/40001/src/opts/SkBlend_opts.h...
> src/opts/SkBlend_opts.h:18: switch (src >> 24) {
> Should dst/src be SkPMColor to make the swizzle explicit?
> 
> Maybe use SK_A32_SHIFT, SK_AlphaTRANSPARENT, SK_AlphaOPAQUE?

Does "... where both src and dst point to sRGB pixels (RGBA or BGRA)" in the
header not make this explicit enough?

This portable Sk4f version of the code can function for any values of
SK_A32_SHIFT, SK_AlphaTRANSPARENT, SK_AlphaOPAQUE, sure, but we'll find
ourselves assuming or hard-coding these values almost immediately when
specializing for different instruction sets.

[f(malita), 2016-05-02 18:46:34]

On 2016/05/02 18:25:20, mtklein wrote:
> On 2016/05/02 at 18:19:27, fmalita wrote:
> >
https://codereview.chromium.org/1939783003/diff/40001/src/opts/SkBlend_opts.h
> > File src/opts/SkBlend_opts.h (right):
> > 
> >
>
https://codereview.chromium.org/1939783003/diff/40001/src/opts/SkBlend_opts.h...
> > src/opts/SkBlend_opts.h:18: switch (src >> 24) {
> > Should dst/src be SkPMColor to make the swizzle explicit?
> > 
> > Maybe use SK_A32_SHIFT, SK_AlphaTRANSPARENT, SK_AlphaOPAQUE?
> 
> Does "... where both src and dst point to sRGB pixels (RGBA or BGRA)" in the
> header not make this explicit enough?

It says nothing about the colors being premul :)

If SkPMColor is the natural storage/input type, is there any downside to
documenting it in the actual signature?

(Maybe I'm missing something and the clients don't always operate on SkPMColor
inputs/output; this is a minor nit, LGTM either way)

[commit-bot: I haz the power, 2016-05-02 18:48:44]

Description was changed from

==========
Add a hook for CPU-optimized sRGB-sRGB srcover.

Herb's really starting to get serious about tweaking this, which becomes
a lot easier when you've got SkOpts' runtime CPU detection. We should be 
able to optimize this usefully for SSSE3, SSE4.1, AVX, AVX2, or NEON.
(We can of course implement a subset.)

This function takes two counts to give us flexibility to write src patterns:
   nsrc >= ndst -> the usual srcover function
   nsrc <  ndst -> repeat src until it fills dst
   nsrc << ndst -> possibly preprocess src into registers
   nsrc == 1    -> equivalent of blitrow_color32, srcover_1, etc.

BUG=skia:
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
==========

to

==========
Add a hook for CPU-optimized sRGB-sRGB srcover.

Herb's really starting to get serious about tweaking this, which becomes
a lot easier when you've got SkOpts' runtime CPU detection. We should be 
able to optimize this usefully for SSSE3, SSE4.1, AVX, AVX2, or NEON.
(We can of course implement a subset.)

This function takes two counts to give us flexibility to write src patterns:
   nsrc >= ndst -> the usual srcover function
   nsrc <  ndst -> repeat src until it fills dst
   nsrc << ndst -> possibly preprocess src into registers
   nsrc == 1    -> equivalent of blitrow_color32, srcover_1, etc.

BUG=skia:
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...

Committed:
https://skia.googlesource.com/skia/+/c5091b5b6c4b8a7aef8c12db9ea2a85e907b01c4
==========

[commit-bot: I haz the power, 2016-05-02 18:48:45]

Committed patchset #3 (id:40001) as
https://skia.googlesource.com/skia/+/c5091b5b6c4b8a7aef8c12db9ea2a85e907b01c4

[mtklein, 2016-05-02 21:08:29]

> If SkPMColor is the natural storage/input type, is there any downside to
documenting it in the actual signature?
> 
> (Maybe I'm missing something and the clients don't always operate on SkPMColor
inputs/output; this is a minor nit, LGTM either way)

I guess I always think of SkPMColor == broken 8888.