diff options
author | mtklein <mtklein@chromium.org> | 2015-07-22 10:52:53 -0700 |
---|---|---|
committer | Commit bot <commit-bot@chromium.org> | 2015-07-22 10:52:53 -0700 |
commit | ced1585149d4ac8a68efd80e11dbc23bca6620d4 (patch) | |
tree | ca42ea0d7f2d818dbf15a0cb83a9a934a032664d /src/core/Sk4px.h | |
parent | 651c920d2f8671756968366c7ed9b455fc1a096c (diff) |
565 support for SIMD xfermodes
This uses the most basic approach possible:
- to load an Sk4px from 565, convert to SkPMColors on the stack serially then load those SkPMColors.
- to store an Sk4px to 565, store to SkPMColors on the stack then convert to 565 serially.
Clearly, we can optimize these loads and stores. That's a TODO.
The code using SkPMFloat is the same idea but a little more long-term viable, as we're only operating on one pixel at a time anyway. We could probably write 565 <-> SkPMFloat methods, but I'd rather not until it's really compelling.
The speedups are varied but similar across SSE and NEON: a few uninteresting, many 50% faster, some 2x faster, and SoftLight ~4x faster.
This will cause minor GM diffs, but I don't think any layout test changes.
BUG=skia:
Committed: https://skia.googlesource.com/skia/+/942930dcaa51f66d82cdaf46ae62efebd16c8cd0
Committed: https://skia.googlesource.com/skia/+/860dcaa2ddfdadc050af4f943a84a9d499315066
Review URL: https://codereview.chromium.org/1245673002
Diffstat (limited to 'src/core/Sk4px.h')
-rw-r--r-- | src/core/Sk4px.h | 21 |
1 files changed, 15 insertions, 6 deletions
diff --git a/src/core/Sk4px.h b/src/core/Sk4px.h index e1d4dc1244..24a21c66c1 100644 --- a/src/core/Sk4px.h +++ b/src/core/Sk4px.h @@ -10,6 +10,7 @@ #include "SkNx.h" #include "SkColor.h" +#include "SkColorPriv.h" // This file may be included multiple times by .cpp files with different flags, leading // to different definitions. Usually that doesn't matter because it's all inlined, but @@ -47,6 +48,14 @@ public: void store2(SkPMColor[2]) const; void store1(SkPMColor[1]) const; + // Same as above for 565. + static Sk4px Load4(const SkPMColor16 src[4]); + static Sk4px Load2(const SkPMColor16 src[2]); + static Sk4px Load1(const SkPMColor16 src[1]); + void store4(SkPMColor16 dst[4]) const; + void store2(SkPMColor16 dst[2]) const; + void store1(SkPMColor16 dst[1]) const; + // 1, 2, or 4 SkPMColors with 16-bit components. // This is most useful as the result of a multiply, e.g. from mulWiden(). class Wide : public Sk16h { @@ -99,8 +108,8 @@ public: // A generic driver that maps fn over a src array into a dst array. // fn should take an Sk4px (4 src pixels) and return an Sk4px (4 dst pixels). - template <typename Fn> - static void MapSrc(int n, SkPMColor* dst, const SkPMColor* src, const Fn& fn) { + template <typename Fn, typename Dst> + static void MapSrc(int n, Dst* dst, const SkPMColor* src, const Fn& fn) { // This looks a bit odd, but it helps loop-invariant hoisting across different calls to fn. // Basically, we need to make sure we keep things inside a single loop. while (n > 0) { @@ -129,8 +138,8 @@ public: } // As above, but with dst4' = fn(dst4, src4). - template <typename Fn> - static void MapDstSrc(int n, SkPMColor* dst, const SkPMColor* src, const Fn& fn) { + template <typename Fn, typename Dst> + static void MapDstSrc(int n, Dst* dst, const SkPMColor* src, const Fn& fn) { while (n > 0) { if (n >= 8) { Sk4px dst0 = fn(Load4(dst+0), Load4(src+0)), @@ -157,8 +166,8 @@ public: } // As above, but with dst4' = fn(dst4, src4, alpha4). - template <typename Fn> - static void MapDstSrcAlpha(int n, SkPMColor* dst, const SkPMColor* src, const SkAlpha* a, + template <typename Fn, typename Dst> + static void MapDstSrcAlpha(int n, Dst* dst, const SkPMColor* src, const SkAlpha* a, const Fn& fn) { while (n > 0) { if (n >= 8) { |