| 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
|