aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/core/Sk4px.h
diff options
context:
space:
mode:
authorGravatar mtklein <mtklein@chromium.org>2015-07-22 10:52:53 -0700
committerGravatar Commit bot <commit-bot@chromium.org>2015-07-22 10:52:53 -0700
commitced1585149d4ac8a68efd80e11dbc23bca6620d4 (patch)
treeca42ea0d7f2d818dbf15a0cb83a9a934a032664d /src/core/Sk4px.h
parent651c920d2f8671756968366c7ed9b455fc1a096c (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.h21
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) {