History log of /external/skia/tests/SkNxTest.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
7c249e531900929c2fe2cdde76619fa6d2538c49 21-Feb-2016 mtklein <mtklein@chromium.org> SkNx: kth<...>() -> [...]

Just some syntax cleanup. No real change: kth<...>() was calling [...] already.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1714363002
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot

Review URL: https://codereview.chromium.org/1714363002
/external/skia/tests/SkNxTest.cpp
0cf795fd1135babe0ee0b3585f3ad49a02fe1387 17-Feb-2016 mtklein <mtklein@chromium.org> fast sk4f <-> sk4i SSE methods

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1707673002
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot

Review URL: https://codereview.chromium.org/1707673002
/external/skia/tests/SkNxTest.cpp
126626e52310b39429ad5eaa8e68e0caa24e6202 10-Feb-2016 mtklein <mtklein@chromium.org> Sk4f: add floor()

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1685773002
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot

Committed: https://skia.googlesource.com/skia/+/86c6c4935171a1d2d6a9ffbff37ec6dac1326614

CQ_EXTRA_TRYBOTS=client.skia.android:Test-Android-GCC-Nexus7-GPU-Tegra3-Arm7-Release-Trybot,Test-Android-GCC-Nexus9-GPU-TegraK1-Arm64-Release-Trybot

Review URL: https://codereview.chromium.org/1685773002
/external/skia/tests/SkNxTest.cpp
c023210893da7ca407bad8c9f07c8339ee81854c 10-Feb-2016 mtklein <mtklein@google.com> Revert of Sk4f: add floor() (patchset #3 id:40001 of https://codereview.chromium.org/1685773002/ )

Reason for revert:
build break must be this, right?

Original issue's description:
> Sk4f: add floor()
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1685773002
> CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
>
> Committed: https://skia.googlesource.com/skia/+/86c6c4935171a1d2d6a9ffbff37ec6dac1326614

TBR=herb@google.com,mtklein@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:

Review URL: https://codereview.chromium.org/1679343004
/external/skia/tests/SkNxTest.cpp
86c6c4935171a1d2d6a9ffbff37ec6dac1326614 09-Feb-2016 mtklein <mtklein@chromium.org> Sk4f: add floor()

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1685773002
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot

Review URL: https://codereview.chromium.org/1685773002
/external/skia/tests/SkNxTest.cpp
e4c0beed744d09dae4757c1893d8caa64ee09cd2 09-Feb-2016 mtklein <mtklein@chromium.org> sknx refactoring

- trim unused specializations (Sk4i, Sk2d) and apis (SkNx_dup)
- expand apis a little
* v[0] == v.kth<0>()
* SkNx_shuffle can now convert to different-sized vectors, e.g. Sk2f <-> Sk4f
- remove anonymous namespace

I believe it's safe to remove the anonymous namespace right now.
We're worried about violating the One Definition Rule; the anonymous namespace protected us from that.

In Release builds, this is mostly moot, as everything tends to inline completely.
In Debug builds, violating the ODR is at worst an inconvenience, time spent trying to figure out why the bot is broken.

Now that we're building with SSE2/NEON everywhere, very few bots have even a chance about getting confused by two definitions of the same type or function. Where we do compile variants depending on, e.g., SSSE3, we do so in static inline functions. These are not subject to the ODR.

I plan to follow up with a tedious .kth<...>() -> [...] auto-replace.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1683543002
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot

Review URL: https://codereview.chromium.org/1683543002
/external/skia/tests/SkNxTest.cpp
629f25a7ef229d97e22530eae043882b20cd8d8c 08-Feb-2016 mtklein <mtklein@chromium.org> fix float <---> uint16_t conversion, with Mike's tests.

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

patch from issue 1679713002 at patchset 1 (http://crrev.com/1679713002#ps1)
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot

Review URL: https://codereview.chromium.org/1676893002
/external/skia/tests/SkNxTest.cpp
c33065a93ad0874672c4c66b9711aa0b3ef7b7e7 15-Jan-2016 mtklein <mtklein@chromium.org> add SkNx::abs(), for now only implemented for Sk4f

There's no reason we couldn't implement this for all ints and floats;
just don't want to land unused code.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1590843003
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot

Review URL: https://codereview.chromium.org/1590843003
/external/skia/tests/SkNxTest.cpp
6f37b4a4757ea3eb00c76162cc37f8a56c3b8bdb 14-Dec-2015 mtklein <mtklein@chromium.org> Unify some SkNx code

- one base case and one N=1 case instead of two each (or three with doubles)
- use SkNx_cast instead of FromBytes/toBytes
- 4-at-a-time Sk4f::ToBytes becomes a special standalone Sk4f_ToBytes

If I did everything right, this'll be perf- and pixel- neutral.

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

BUG=skia:
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot

Review URL: https://codereview.chromium.org/1526523003
/external/skia/tests/SkNxTest.cpp
6c221b40680ff933c7b8f2ac3dfa76b5732aee3e 20-Nov-2015 mtklein <mtklein@chromium.org> Add SkNx_cast().

SkNx_cast() can cast between any of our vector types,
provided they have the same number of elements.

Any types should work with the default implementation,
and we can drop in specializations as needed, like the
SSE and NEON Sk4f -> Sk4i I included here as an example.

To make this work, I made some internal name changes:
SkNi<N,T> -> SkNx<N, T>
SkNf<N> -> SkNx<N, float>
User aliases (Sk4f, Sk16b, etc.) stay the same.
We can land this first (it's PS1) if that makes things easier.

BUG=skia:
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot

Review URL: https://codereview.chromium.org/1464623002
/external/skia/tests/SkNxTest.cpp
6f797092d2054f79374fb98fc1d57ca3554c7db4 09-Nov-2015 mtklein <mtklein@chromium.org> prune unused SkNx features

- remove float -> int conversion, keeping float -> byte
- remove support for doubles

I was thinking of specializing Sk8f for AVX. This will help keep the complexity down.

This may cause minor diffs in radial gradients: toBytes() rounds where castTrunc() truncated. But I don't see any diffs in Gold.
https://gold.skia.org/search2?issue=1411563008&unt=true&query=source_type%3Dgm&master=false

BUG=skia:4117
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot

Review URL: https://codereview.chromium.org/1411563008
/external/skia/tests/SkNxTest.cpp
a508f3c62d726867ad9f722623fbf0ab5d06e440 01-Sep-2015 mtklein <mtklein@chromium.org> Require Sk4f::toBytes() clamps

BUG=skia:4117

CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot;client.skia.android:Test-Android-GCC-Nexus9-CPU-Denver-Arm64-Release-Trybot

Review URL: https://codereview.chromium.org/1312053004
/external/skia/tests/SkNxTest.cpp
4be181e304d2b280c6801bd13369cfba236d1a66 14-Jul-2015 mtklein <mtklein@chromium.org> 3-15% speedup to HardLight / Overlay xfermodes.

While investigating my bug (skia:4052) I saw this TODO and figured
it'd make me feel better about an otherwise unsuccessful investigation.

This speeds up HardLight and Overlay (same code) by about 15% with SSE, mostly
by rewriting the logic from 1 cheap comparison and 2 expensive div255() calls
to 2 cheap comparisons and 1 expensive div255().

NEON speeds up by a more modest ~3%.

BUG=skia:

Review URL: https://codereview.chromium.org/1230663005
/external/skia/tests/SkNxTest.cpp
e20633ed26d211e8d2b4b407c7e968944c7e60bb 13-Jul-2015 mtklein <mtklein@chromium.org> Add a GM that reproduces layout test failures with my new xfermode code.

Inspired by https://storage.googleapis.com/chromium-layout-test-archives/linux_blink_rel/69169/layout-test-results/results.html

I think the root cause is overflow.

Also, adds tests for Sk16b::operator<(). It wasn't wrong, but it was suspect
(used in all three of these xfermode implementations) and so it's best to have
tests.

BUG=skia:

Review URL: https://codereview.chromium.org/1228393006
/external/skia/tests/SkNxTest.cpp
059ac00446404506a46cd303db15239c7aae49d5 22-Jun-2015 mtklein <mtklein@chromium.org> Update some Sk4px APIs.

Mostly this is about ergonomics, making it easier to do good operations and hard / impossible to do bad ones.

- SkAlpha / SkPMColor constructors become static factories.
- Remove div255TruncNarrow(), rename div255RoundNarrow() to div255(). In practice we always want to round, and the narrowing to 8-bit is contextually obvious.
- Rename fastMulDiv255Round() approxMulDiv255() to stress it's approximate-ness over its speed. Drop Round for the same reason as above... we should always round.
- Add operator overloads so we don't have to keep throwing in seemingly-random Sk4px() or Sk4px::Wide() casts.
- use operator*() for 8-bit x 8-bit -> 16-bit math. It's always what we want, and there's generally no 8x8->8 alternative.
- MapFoo can take a const Func&. Don't think it makes a big difference, but nice to do.

BUG=skia:

Review URL: https://codereview.chromium.org/1202013002
/external/skia/tests/SkNxTest.cpp
374787534147f3a616925d297bce74ff575d8911 15-Jun-2015 mtklein <mtklein@chromium.org> Thorough tests for saturatedAdd and mulDiv255Round.

BUG=skia:3951

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

CQ_EXTRA_TRYBOTS=client.skia.android:Test-Android-GCC-Nexus5-CPU-NEON-Arm7-Release-Trybot

Review URL: https://codereview.chromium.org/1184113003
/external/skia/tests/SkNxTest.cpp
b1bbca80492dc71f4a2c026a78d00d6f084c7e47 15-Jun-2015 mtklein <mtklein@google.com> Revert of Thorough tests for saturatedAdd and mulDiv255Round. (patchset #1 id:1 of https://codereview.chromium.org/1184113003/)

Reason for revert:
https://code.google.com/p/skia/issues/detail?id=3951

Original issue's description:
> Thorough tests for saturatedAdd and mulDiv255Round.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/ce9d11189a5924b47c3629063b72bae9d466c2c7

TBR=fmalita@chromium.org,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:

Review URL: https://codereview.chromium.org/1177123004
/external/skia/tests/SkNxTest.cpp
ce9d11189a5924b47c3629063b72bae9d466c2c7 15-Jun-2015 mtklein <mtklein@chromium.org> Thorough tests for saturatedAdd and mulDiv255Round.

BUG=skia:

Review URL: https://codereview.chromium.org/1184113003
/external/skia/tests/SkNxTest.cpp
f2fe0e03205c4d7f70496ec8c6bea9a82ae88329 10-Jun-2015 mtklein <mtklein@chromium.org> Remove overly-promiscuous SkNx syntax sugar.

I haven't figured out a pithy way to have these apply to only classes
originating from SkNx, so let's just remove them. There aren't too
many use cases, and it's not really any less readable without them.

Semantically, this is a no-op.

BUG=skia:

Review URL: https://codereview.chromium.org/1167153002
/external/skia/tests/SkNxTest.cpp
27e517ae533775889c98c65fa2f07b98357ecbc2 15-May-2015 mtklein <mtklein@chromium.org> add Min to SkNi, specialized for u8 and u16 on SSE and NEON

0x8001 / 0x7fff don't seem to work, but we were close: 0x8000 does.

I plan to use this to implement the Difference xfermode,
and it seems generally handy.

BUG=skia:

Review URL: https://codereview.chromium.org/1133933004
/external/skia/tests/SkNxTest.cpp
d7c014ff03d44d3ed7a6a2ddca59621a7e98f739 27-Apr-2015 mtklein <mtklein@chromium.org> Split rsqrt into rsqrt{0,1,2}, with increasing cost and precision on ARM

This is a logical no-op. Everything was using the equivalent of rsqrt1() before, and is now after.

BUG=skia:

Committed: https://skia.googlesource.com/skia/+/9de16283fdc8cc0d31a84f503578d0ecea4e8297

CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Ubuntu-GCC-Arm64-Debug-Android-Trybot

Review URL: https://codereview.chromium.org/1109913002
/external/skia/tests/SkNxTest.cpp
9a22f489e8722dd83c65f33fb886019d9f60e479 27-Apr-2015 mtklein <mtklein@google.com> Revert of Split rsqrt into rsqrt{0,1,2}, with increasing cost and precision on ARM (patchset #2 id:20001 of https://codereview.chromium.org/1109913002/)

Reason for revert:
arm64 typos

Original issue's description:
> Split rsqrt into rsqrt{0,1,2}, with increasing cost and precision on ARM
>
> This is a logical no-op. Everything was using the equivalent of rsqrt1() before, and is now after.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/9de16283fdc8cc0d31a84f503578d0ecea4e8297

TBR=reed@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:

Review URL: https://codereview.chromium.org/1105233003
/external/skia/tests/SkNxTest.cpp
9de16283fdc8cc0d31a84f503578d0ecea4e8297 27-Apr-2015 mtklein <mtklein@chromium.org> Split rsqrt into rsqrt{0,1,2}, with increasing cost and precision on ARM

This is a logical no-op. Everything was using the equivalent of rsqrt1() before, and is now after.

BUG=skia:

Review URL: https://codereview.chromium.org/1109913002
/external/skia/tests/SkNxTest.cpp
1113da72eced20480491bb87ade0ffcff4eb8ea7 27-Apr-2015 mtklein <mtklein@chromium.org> Mike's radial gradient CL with better float -> int.

patch from issue 1072303005 at patchset 40001 (http://crrev.com/1072303005#ps40001)

This looks quite launchable. radial_gradient3, min of 100 samples:
N5: 985µs -> 946µs
MBP: 395µs -> 279µs

On my MBP, most of the meat looks like it's now in reading the cache and writing to dst one color at a time. Is that something we could do in float math rather than with a lookup table?

BUG=skia:

CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Mac10.8-Clang-Arm7-Debug-Android-Trybot,Build-Ubuntu-GCC-Arm7-Release-Android_NoNeon-Trybot

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

Review URL: https://codereview.chromium.org/1109643002
/external/skia/tests/SkNxTest.cpp
8d3e9dff3f3db3fa77c383e4cd6c47b9898a8fcd 27-Apr-2015 mtklein <mtklein@google.com> Revert of Mike's radial gradient CL with better float -> int. (patchset #7 id:120001 of https://codereview.chromium.org/1109643002/)

Reason for revert:
compile failures.

Original issue's description:
> Mike's radial gradient CL with better float -> int.
>
> patch from issue 1072303005 at patchset 40001 (http://crrev.com/1072303005#ps40001)
>
> This looks quite launchable. radial_gradient3, min of 100 samples:
> N5: 985µs -> 946µs
> MBP: 395µs -> 279µs
>
> On my MBP, most of the meat looks like it's now in reading the cache and writing to dst one color at a time. Is that something we could do in float math rather than with a lookup table?
>
> BUG=skia:
>
> CQ_EXTRA_TRYBOTS=client.skia.android:Test-Android-GCC-Nexus5-CPU-NEON-Arm7-Debug-Trybot,Test-Android-GCC-Nexus9-CPU-Denver-Arm64-Debug-Trybot
>
> Committed: https://skia.googlesource.com/skia/+/abf6c5cf95e921fae59efb487480e5b5081cf0ec

TBR=reed@google.com,robertphillips@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:

Review URL: https://codereview.chromium.org/1109883003
/external/skia/tests/SkNxTest.cpp
abf6c5cf95e921fae59efb487480e5b5081cf0ec 27-Apr-2015 mtklein <mtklein@chromium.org> Mike's radial gradient CL with better float -> int.

patch from issue 1072303005 at patchset 40001 (http://crrev.com/1072303005#ps40001)

This looks quite launchable. radial_gradient3, min of 100 samples:
N5: 985µs -> 946µs
MBP: 395µs -> 279µs

On my MBP, most of the meat looks like it's now in reading the cache and writing to dst one color at a time. Is that something we could do in float math rather than with a lookup table?

BUG=skia:

CQ_EXTRA_TRYBOTS=client.skia.android:Test-Android-GCC-Nexus5-CPU-NEON-Arm7-Debug-Trybot,Test-Android-GCC-Nexus9-CPU-Denver-Arm64-Debug-Trybot

Review URL: https://codereview.chromium.org/1109643002
/external/skia/tests/SkNxTest.cpp
115acee9386e685f9a5938fb2cf13fd5a475012a 14-Apr-2015 mtklein <mtklein@chromium.org> Sk4h and Sk8h for SSE

These will underly the SkPMFloat-like class for uint16_t components.

Sk4h will back a single-pixel version, and Sk8h any larger number than that.

BUG=skia:

Review URL: https://codereview.chromium.org/1088883005
/external/skia/tests/SkNxTest.cpp
a156a8ffbe1342a9c329e66ad1438934ac309d70 03-Apr-2015 mtklein <mtklein@chromium.org> Use switch operator[](int) to kth<int>() so we can use vget_lane.
#floats

BUG=skia:
BUG=skia:3592

Review URL: https://codereview.chromium.org/1059743002
/external/skia/tests/SkNxTest.cpp
c9adb05b64fa0bfadf9d1a782afcda470da68c9e 30-Mar-2015 mtklein <mtklein@chromium.org> Refactor Sk2x<T> + Sk4x<T> into SkNf<N,T> and SkNi<N,T>

The primary feature this delivers is SkNf and SkNd for arbitrary power-of-two N. Non-specialized types or types larger than 128 bits should now Just Work (and we can drop in a specialization to make them faster). Sk4s is now just a typedef for SkNf<4, SkScalar>; Sk4d is SkNf<4, double>, Sk2f SkNf<2, float>, etc.

This also makes implementing new specializations easier and more encapsulated. We're now using template specialization, which means the specialized versions don't have to leak out so much from SkNx_sse.h and SkNx_neon.h.

This design leaves us room to grow up, e.g to SkNf<8, SkScalar> == Sk8s, and to grown down too, to things like SkNi<8, uint16_t> == Sk8h.

To simplify things, I've stripped away most APIs (swizzles, casts, reinterpret_casts) that no one's using yet. I will happily add them back if they seem useful.

You shouldn't feel bad about using any of the typedef Sk4s, Sk4f, Sk4d, Sk2s, Sk2f, Sk2d, Sk4i, etc. Here's how you should feel:
- Sk4f, Sk4s, Sk2d: feel awesome
- Sk2f, Sk2s, Sk4d: feel pretty good

No public API changes.
TBR=reed@google.com

BUG=skia:3592

Review URL: https://codereview.chromium.org/1048593002
/external/skia/tests/SkNxTest.cpp