aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/opts
Commit message (Collapse)AuthorAge
* back to Sk4f for SkPMColorGravatar mtklein2015-03-31
| | | | | | | | | #floats BUG=skia: BUG=skia:3592 Review URL: https://codereview.chromium.org/1047823002
* Refactor Sk2x<T> + Sk4x<T> into SkNf<N,T> and SkNi<N,T>Gravatar mtklein2015-03-30
| | | | | | | | | | | | | | | | | | | | | 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
* SkPMFloat::trunc()Gravatar mtklein2015-03-26
| | | | | | | | | | | | | Add and test trunc(), which is what get() used to be before rounding. Using trunc() is a ~40% speedup on our linear gradient bench. #neon #floats BUG=skia:3592 #n5 #n9 CQ_INCLUDE_TRYBOTS=client.skia.android:Test-Android-Nexus5-Adreno330-Arm7-Debug-Trybot;client.skia.android:Test-Android-Nexus9-TegraK1-Arm64-Release-Trybot Review URL: https://codereview.chromium.org/1032243002
* C++11 override should now be supported by all of {bots,Chrome,Android,Mozilla}Gravatar mtklein2015-03-25
| | | | | | | | | NOPRESUBMIT=true BUG=skia: DOCS_PREVIEW= https://skia.org/?cl=1037793002 Review URL: https://codereview.chromium.org/1037793002
* Update 4-at-a-time APIs.Gravatar mtklein2015-03-25
| | | | | | | | | | | There is no reason to require the 4 SkPMFloats (registers) to be adjacent. The only potential win in loads and stores comes from the SkPMColors being adjacent. Makes no difference to existing bench. BUG=skia: Review URL: https://codereview.chromium.org/1035583002
* aacc + bbddGravatar mtklein2015-03-24
| | | | | | | | | | | | | | SkMatrix::mapPts() using aacc/bbdd was always worse than using badc(): - On Intel, it was faster than exisiting swizzle, but badc() is 10% faster still (one pshufd instead of two). - On ARM, existing swizzle < badc() < aacc()+bbdd(), even though aacc() then bbdd() is really a single vtrn instruction. I will revert SkMatrix.cpp before submitting. Just thought you might like to look. Will think more and try to gear up Instruments on ARM. BUG=skia: Review URL: https://codereview.chromium.org/1012573003
* Start fresh on swizzlesGravatar mtklein2015-03-23
| | | | | | | | | This removes all the existing Sk4x swizzles and adds badc(), which is both fast on all implementations and currently useful. BUG=skia: Review URL: https://codereview.chromium.org/997353005
* Replace _mm_cvtps_epi32(x) with _mm_cvttps_epi32(_mm_add_ps(0.5f), x).Gravatar mtklein2015-03-23
| | | | | | | | | | | | | We don't have control over which way _mm_cvtps_epi32 rounds. - This makes the SSE SkPMFloat rounding consistent with _neon and _none. - Sk4f::cast<Sk4i>() is closer to (int)float's behavior. (Correct when >=0). Add tests that would fail at head. BUG=skia: Review URL: https://codereview.chromium.org/1029163002
* Sk2x::invert() and Sk2x::approxInvert()Gravatar mtklein2015-03-20
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1024993002
* Add divide to Sk2x, use native vdiv and vsqrt on ARM 64.Gravatar mtklein2015-03-20
| | | | | | | | | | Tests pass on N7 + N9. BUG=skia: CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Mac10.7-Clang-Arm7-Debug-iOS-Trybot,Build-Ubuntu-GCC-Arm64-Release-Android-Trybot Review URL: https://codereview.chromium.org/1027753003
* Specialize Sk2d for ARM64Gravatar mtklein2015-03-20
| | | | | | | | | | | | | | | | | | | The implementation is nearly identical to Sk2f, with these changes: - float32x2_t -> float64x2_t - vfoo -> vfooq - one extra Newton's method step in sqrt(). Also, generally fix NEON detection to be defined(SK_ARM_HAS_NEON). SK_ARM_HAS_NEON is not being set on ARM64 bots right now (nor does the compiler seem to set __ARM_NEON__), so this CL fixes everything up. BUG=skia: Committed: https://skia.googlesource.com/skia/+/e57b5cab261a243dcbefa74c91c896c28959bf09 CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Mac10.7-Clang-Arm7-Debug-iOS-Trybot,Build-Ubuntu-GCC-Arm64-Release-Android-Trybot Review URL: https://codereview.chromium.org/1020963002
* Replace SSE optimization of Color32A_D565Gravatar henrik.smiding2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | Adds an SSE2 version of the Color32A_D565 function, to replace the existing SSE4 version. Also does some minor cleanup. Performance improvement in the following Skia benchmarks. Measured on Atom Silvermont: Xfermode_SrcOver - x3 luma_colorfilter_large - x4.6 luma_colorfilter_small - x2 tablebench - ~15% chart_bw - ~10% Measured on Corei7 Haswell: luma_colorfilter_large running SSE2 - x2 luma_colorfilter_large running SSE4 - x2.3 Also improves performance in WPS Office application and 2D subtest of 0xbenchmark on Android. Signed-off-by: Henrik Smiding <henrik.smiding@intel.com> Review URL: https://codereview.chromium.org/923523002
* Revert of Specialize Sk2d for ARM64 (patchset #3 id:40001 of ↵Gravatar mtklein2015-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/1020963002/) Reason for revert: https://uberchromegw.corp.google.com/i/client.skia.compile/builders/Build-Mac10.7-Clang-Arm7-Debug-iOS/builds/2441/steps/build%20most/logs/stdio https://uberchromegw.corp.google.com/i/client.skia.compile/builders/Build-Mac10.7-Clang-Arm7-Release-iOS/builds/2424/steps/build%20most/logs/stdio https://uberchromegw.corp.google.com/i/client.skia.compile/builders/Build-Ubuntu-GCC-Arm64-Release-Android/builds/8/steps/build%20most/logs/stdio Original issue's description: > Specialize Sk2d for ARM64 > > The implementation is nearly identical to Sk2f, with these changes: > - float32x2_t -> float64x2_t > - vfoo -> vfooq > - one extra Newton's method step in sqrt(). > > Also, generally fix NEON detection to be defined(SK_ARM_HAS_NEON). > SK_ARM_HAS_NEON is not being set on ARM64 bots right now (nor does the compiler > seem to set __ARM_NEON__), so this CL fixes everything up. > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/e57b5cab261a243dcbefa74c91c896c28959bf09 TBR=msarett@google.com,reed@google.com,mtklein@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1028523003
* Specialize Sk2d for ARM64Gravatar mtklein2015-03-20
| | | | | | | | | | | | | | | The implementation is nearly identical to Sk2f, with these changes: - float32x2_t -> float64x2_t - vfoo -> vfooq - one extra Newton's method step in sqrt(). Also, generally fix NEON detection to be defined(SK_ARM_HAS_NEON). SK_ARM_HAS_NEON is not being set on ARM64 bots right now (nor does the compiler seem to set __ARM_NEON__), so this CL fixes everything up. BUG=skia: Review URL: https://codereview.chromium.org/1020963002
* Sk2x for NEONGravatar mtklein2015-03-19
| | | | | | | | | | | Also decreases the precision of Sk4f::rsqrt() for speed, keeping Sk4f::sqrt() the same: instead of doing two estimation steps in rsqrt(), do one there and one more in sqrt(). Tests pass on my Nexus 7. float64x2_t is still a TODO for when I get a hold of a Nexus 9. BUG=skia: Review URL: https://codereview.chromium.org/1018423003
* Sk2xGravatar mtklein2015-03-19
| | | | | | | | This adds an API, an SSE impl, a portable impl, and some tests for Sk2f/Sk2d/Sk2s. BUG=skia: Review URL: https://codereview.chromium.org/1025463002
* Reorg Sk4x to match the pattern of SkPMFloat.Gravatar mtklein2015-03-19
| | | | | | | | | | No real changes here, just moving files around: - move impl files into src/opts - rename _portable _none BUG=skia: Review URL: https://codereview.chromium.org/1021713004
* extend neon table as well for gray8Gravatar reed2015-03-18
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1021583002
* Update to identically match the sources used on AndroidGravatar djsollen2015-03-18
| | | | Review URL: https://codereview.chromium.org/1020563002
* SkPMFloat: avoid loads and stores where possible.Gravatar mtklein2015-03-18
| | | | | | | | | | | | | | | | | | | | | | | | | | A store/load pair like this is a redundant no-op: store simd_register_a, memory_address load memory_address, simd_register_a Everyone seems to be good at removing those when using SSE, but GCC and Clang are pretty terrible at this for NEON. We end up issuing both redundant commands, usually to and from the stack. That's slow. Let's not do that. This CL unions in the native SIMD register type into SkPMFloat, so that we can assign to and from it directly, which is generating a lot better NEON code. On my Nexus 5, the benchmarks improve from 36ns to 23ns. SSE is just as fast either way, but I paralleled the NEON code for consistency. It's a little terser. And because it needed the platform headers anyway, I moved all includes into SkPMFloat.h, again only for consistency. I'd union in Sk4f too to make its conversion methods a little clearer, but MSVC won't let me (it has a copy constructor... they're apparently not up to speed with C++11 unrestricted unions). BUG=skia: Review URL: https://codereview.chromium.org/1015083004
* SkPaint::FilterLevel -> SkFilterQualityGravatar reed2015-03-16
| | | | | | | | | clone (+rebase) of https://codereview.chromium.org/1009183002/ BUG=skia: TBR=scroggo@google.com Review URL: https://codereview.chromium.org/1014533004
* SKPMFloat: we can beat the naive loops when clampingGravatar mtklein2015-03-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clamping 4 at a time is now about 15% faster than 1 at a time with SSSE3. Clamping 4 at a time is now about 20% faster with SSE2, and this applies to non-clamping too (we still just clamp there). In all cases, 4 at a time is never worse than 1 at a time, and not clamping is never slower than clamping. Here's all the bench results, with the numbers for portable code as a fun point of reference: SSSE3: maxrss loops min median mean max stddev samples config bench 10M 2291 4.66ns 4.66ns 4.66ns 4.68ns 0% ▆█▁▁▁▇▁▇▁▃ nonrendering SkPMFloat_get_1x 10M 2040 5.29ns 5.3ns 5.3ns 5.32ns 0% ▃▆▃▃▁▁▆▃▃█ nonrendering SkPMFloat_clamp_1x 10M 7175 4.62ns 4.62ns 4.62ns 4.63ns 0% ▁▄▃████▃▄▇ nonrendering SkPMFloat_get_4x 10M 5801 4.89ns 4.89ns 4.89ns 4.91ns 0% █▂▄▃▁▃▄█▁▁ nonrendering SkPMFloat_clamp_4x SSE2: maxrss loops min median mean max stddev samples config bench 10M 1601 6.02ns 6.05ns 6.04ns 6.08ns 0% █▅▄▅▄▂▁▂▂▂ nonrendering SkPMFloat_get_1x 10M 2918 6.05ns 6.06ns 6.05ns 6.06ns 0% ▂▇▁▇▇▁▇█▇▂ nonrendering SkPMFloat_clamp_1x 10M 3569 5.43ns 5.45ns 5.44ns 5.45ns 0% ▄█▂██▇▁▁▇▇ nonrendering SkPMFloat_get_4x 10M 4168 5.43ns 5.43ns 5.43ns 5.44ns 0% █▄▇▁▇▄▁▁▁▁ nonrendering SkPMFloat_clamp_4x Portable: maxrss loops min median mean max stddev samples config bench 10M 500 27.8ns 28.1ns 28ns 28.2ns 0% ▃█▆▃▇▃▆▁▇▂ nonrendering SkPMFloat_get_1x 10M 770 40.1ns 40.2ns 40.2ns 40.3ns 0% ▅▁▃▂▆▄█▂▅▂ nonrendering SkPMFloat_clamp_1x 10M 1269 28.4ns 28.8ns 29.1ns 32.7ns 4% ▂▂▂█▂▁▁▂▁▁ nonrendering SkPMFloat_get_4x 10M 1439 40.2ns 40.4ns 40.4ns 40.5ns 0% ▆▆▆█▁▆▅█▅▆ nonrendering SkPMFloat_clamp_4x SkPMFloat_neon.h is still one big TODO as far as 4-at-a-time APIs go. BUG=skia: Review URL: https://codereview.chromium.org/982123002
* Update SkPMFloat API a bit.Gravatar mtklein2015-03-04
| | | | | | | | | | | Instead of set(SkPMColor), add a constructor SkPMFloat(SkPMColor). Replace setA(), setR(), etc. with a 4 float constructor. And, promise to stick to SkPMColor order. BUG=skia: Review URL: https://codereview.chromium.org/977773002
* Add SSSE3 implementation for SkPMFloat, with faster get() and set().Gravatar mtklein2015-03-04
| | | | | | | | | | | | | | | | With SSSE3, we can use the Swiss Army Knife byte shuffler pshufb, a.k.a. _mm_shuffle_epi8(), to jump directly between 32 and 128 bits. In microbench isolation, this looks like an additional 10-15% speedup: SkPMFloat_get: 2.35ns -> 1.98ns SkPMFloat_clamp: 2.35ns -> 2.18ns Before this CL, get() and clamp() were identical code. The _get benchmark improves because both set() and get() become faster; the _clamp benchmark shows the improvement from set() getting faster with clamp() staying the same. BUG=skia: Review URL: https://codereview.chromium.org/976493002
* Test and fix SkPMFloat rounding.Gravatar mtklein2015-03-03
| | | | | | | | | | | SSE rounds for free (that was a happy accident: they also have a truncating version). NEON does not, nor obviously the portable code, so they add 0.5 before truncating. NOPRESUBMIT=true BUG=skia: Review URL: https://codereview.chromium.org/974643002
* Make SkPMFloats store floats in [0,255] instead of [0,1].Gravatar mtklein2015-03-03
| | | | | | | | | | | | | This pushes the cost of the *255 and *1/255 conversions onto only those code paths that need it. We're not doing it any more efficiently than can be done with Sk4f. In microbenchmark isolation, this is about a 15% speedup. BUG=skia: NOPRESUBMIT=true Review URL: https://codereview.chromium.org/973603002
* Spin off some fixes to land right away.Gravatar mtklein2015-02-26
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/960023002
* Clean up ColorRectProc plumbing.Gravatar mtklein2015-02-25
| | | | | | | | | | | | | | | | | | | We've always been using the portable ColorRect32, so we don't need the ColorRectProc plumbing. Furthermore, ColorRect32 doesn't seem to be very important (we're only using it in the opaque case, which our row-by-row procs already specialize for). Remove that too. If we find we want specialization for really narrow rects again, let's put it in blitRect() directly. It's pretty unlikely we're going to get platform-specific speedup for blits to non-contiguous memory. My local SKP comparison is +- 3%... most neutral I've ever seen. BUG=skia: Review URL: https://codereview.chromium.org/959873002
* Remove SSE2 ColorRect32 code/filesGravatar henrik.smiding2015-02-25
| | | | | | | | | | | | | | Removes the disabled SSE2 optimization of ColorRect32 and deletes the two files containing the code. Measured on both Core Haswell and Atom Silvermont, and only got some miniscule improvement compared to the default implementation. Also tried to write a new, ultimate, version of this optimization, but only got ~5% improvement on ColorRect32-heavy tests. Signed-off-by: Henrik Smiding <henrik.smiding@intel.com> Review URL: https://codereview.chromium.org/957433002
* Sketch SkPMFloatGravatar mtklein2015-02-23
| | | | | | | | | | | | BUG=skia: Committed: https://skia.googlesource.com/skia/+/50d2b3114b3e59dc84811881591bf25b2c1ecb9f CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Ubuntu13.10-GCC4.8-Arm7-Release-Android_Neon-Trybot http://build.chromium.org/p/client.skia.compile/builders/Build-Ubuntu13.10-GCC4.8-Arm7-Release-Android_Neon/builds/2120/steps/build%20most/logs/stdio Review URL: https://codereview.chromium.org/936633002
* Revert of Sketch SkPMFloat (patchset #15 id:270001 of ↵Gravatar mtklein2015-02-23
| | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/936633002/) Reason for revert: http://build.chromium.org/p/client.skia.compile/builders/Build-Ubuntu13.10-GCC4.8-Arm7-Release-Android_Neon/builds/2120/steps/build%20most/logs/stdio Original issue's description: > Sketch SkPMFloat > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/50d2b3114b3e59dc84811881591bf25b2c1ecb9f TBR=reed@google.com,msarrett@google.com,mtklein@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/952453004
* Sketch SkPMFloatGravatar mtklein2015-02-23
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/936633002
* Fix skia bug 2845Gravatar kui.zheng2015-02-17
| | | | | | | | | | Shouldn't call Fast Blur path(DoubleRowBoxBlur_NEON) when kernelsize is 1. Or, uint16x8_t resultPixels will be overflow. BUG=skia:2845 R=senorblanco@chromium.org Review URL: https://codereview.chromium.org/587543003
* Fix up a couple includes that are using <> instead of "".Gravatar mtklein2015-02-11
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/916713003
* Revert of add dummy avx file so xcode will build (patchset #1 id:1 of ↵Gravatar mtklein2015-02-10
| | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/916563002/) Reason for revert: Going to punt on 16-bit float support for now. Can't figure out ARM 64. Original issue's description: > add dummy avx file so xcode will build > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/a0921f2563701d54e4e022de99f2705f4ada8a6e TBR=reed@google.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/912213002
* add dummy avx file so xcode will buildGravatar reed2015-02-10
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/916563002
* Add SSE optimization of Color32A_D565Gravatar henrik.smiding2015-02-10
| | | | | | | | | | | | | | | | Adds an SSE4.1 version of the Color32A_D565 function. Performance improvement in the following benchmarks: Xfermode_SrcOver - ~100% luma_colorfilter_large - ~150% luma_colorfilter_small - ~60% tablebench - ~10% chart_bw - ~10% (Measured on a Atom Silvermont core) Signed-off-by: Henrik Smiding <henrik.smiding@intel.com> Review URL: https://codereview.chromium.org/892623002
* Remove opaque versions of Color32_D565Gravatar henrik.smiding2015-02-08
| | | | | | | | | | Removes the opaque-only versions of this function from the factory since they will never be used. Opaque source colors are handled in SkRGB16_Opaque_Blitter instead, which doesn't use the factory function. Signed-off-by: Henrik Smiding <henrik.smiding@intel.com> Review URL: https://codereview.chromium.org/901593002
* Revert of Revert of SSE4 opaque blend using intrinsics instead of assembly. ↵Gravatar stephana2015-02-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (patchset #1 id:1 of https://codereview.chromium.org/873553003/) Reason for revert: Reverted the wrong CL. Original issue's description: > Revert of SSE4 opaque blend using intrinsics instead of assembly. (patchset #16 id:300001 of https://codereview.chromium.org/874863002/) > > Reason for revert: > This causes a bug on the 'hittestpath' GM on MacMini 4,1 > > See: > > https://gold.skia.org/#/triage/hittestpath?head=0 > > for details. > > Original issue's description: > > SSE4 opaque blend using intrinsics instead of assembly. > > > > Since we had such a hard time with the assembly versions of this blit (to the > > point that we have them completely disabled everywhere), I thought I'd take > > a shot at writing a version of the blit using intrinsics. > > > > The key feature of SSE4 we're exploiting is that we can use ptest (_mm_test*) > > to skip the blend when the 16 src pixels we consider each loop are all opaque > > or all transparent. _mm_shuffle_epi8 from SSSE3 also lends a hand to extract > > all those alphas. > > > > It's worth looking to see if we can backport this type of logic to SSE2 using > > _mm_movemask_epi8, or up to 32 pixels at a time using AVX. > > > > My local performance testing doesn't show this to be an unambiguous win > > (there are probably microbenchmarks and SKPs where we'd be better off just > > powering through the blend rather than looking at alphas), but the potential > > does seem tantalizing enough to let skiaperf vet it on the bots. (< 1.0x is a win.) > > > > DM says it draws pixel perfect compare to the old code. > > > > Microbenchmarks: > > bitmap_RGBA_8888_A_source_stripes_two 14us -> 14.4us 1.03x > > bitmap_RGBA_8888_A_source_stripes_three 14.3us -> 14.5us 1.01x > > bitmap_RGBA_8888_scale_bilerp 61.9us -> 62.2us 1.01x > > bitmap_RGBA_8888_update_volatile_scale_rotate_bilerp 102us -> 101us 0.99x > > bitmap_RGBA_8888_scale_rotate_bilerp 103us -> 101us 0.99x > > bitmap_RGBA_8888_scale 18.4us -> 18.2us 0.99x > > bitmap_RGBA_8888_A_scale_rotate_bicubic 71us -> 70us 0.99x > > bitmap_RGBA_8888_update_scale_rotate_bilerp 103us -> 101us 0.99x > > bitmap_RGBA_8888_A_scale_rotate_bilerp 112us -> 109us 0.98x > > bitmap_RGBA_8888_update_volatile 5.72us -> 5.58us 0.98x > > bitmap_RGBA_8888 5.73us -> 5.58us 0.97x > > bitmap_RGBA_8888_update 5.78us -> 5.6us 0.97x > > bitmap_RGBA_8888_A_scale_bilerp 70.7us -> 68us 0.96x > > bitmap_RGBA_8888_A_scale_bicubic 23.7us -> 21.8us 0.92x > > bitmap_RGBA_8888_A 13.9us -> 10.9us 0.78x > > bitmap_RGBA_8888_A_source_opaque 14us -> 6.29us 0.45x > > bitmap_RGBA_8888_A_source_transparent 14us -> 3.65us 0.26x > > > > Running over our ~70 SKP web page captures, this looks like we spend 0.7x > > the time in S32A_Opaque_BlitRow compared to the SSE2 version, which should > > be a decent predictor of real-world impact. > > > > BUG=chromium:399842 > > > > Committed: https://skia.googlesource.com/skia/+/04bc91b972417038fecfa87c484771eac2b9b785 > > > > CQ_EXTRA_TRYBOTS=client.skia:Test-Mac10.6-MacMini4.1-GeForce320M-x86_64-Release-Trybot > > > > Committed: https://skia.googlesource.com/skia/+/6dbfb21a6c88af6d94e8c823c3ad559f1a41b493 > > TBR=henrik.smiding@intel.com,mtklein@google.com,herb@google.com,reed@google.com,thakis@chromium.org,mtklein@chromium.org > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=chromium:399842 > > Committed: https://skia.googlesource.com/skia/+/4988891a1173cd405bf1c1dd3a3668c451f45e4c TBR=henrik.smiding@intel.com,mtklein@google.com,herb@google.com,reed@google.com,thakis@chromium.org,mtklein@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:399842 Review URL: https://codereview.chromium.org/894083002
* Revert of SSE4 opaque blend using intrinsics instead of assembly. (patchset ↵Gravatar stephana2015-02-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | #16 id:300001 of https://codereview.chromium.org/874863002/) Reason for revert: This causes a bug on the 'hittestpath' GM on MacMini 4,1 See: https://gold.skia.org/#/triage/hittestpath?head=0 for details. Original issue's description: > SSE4 opaque blend using intrinsics instead of assembly. > > Since we had such a hard time with the assembly versions of this blit (to the > point that we have them completely disabled everywhere), I thought I'd take > a shot at writing a version of the blit using intrinsics. > > The key feature of SSE4 we're exploiting is that we can use ptest (_mm_test*) > to skip the blend when the 16 src pixels we consider each loop are all opaque > or all transparent. _mm_shuffle_epi8 from SSSE3 also lends a hand to extract > all those alphas. > > It's worth looking to see if we can backport this type of logic to SSE2 using > _mm_movemask_epi8, or up to 32 pixels at a time using AVX. > > My local performance testing doesn't show this to be an unambiguous win > (there are probably microbenchmarks and SKPs where we'd be better off just > powering through the blend rather than looking at alphas), but the potential > does seem tantalizing enough to let skiaperf vet it on the bots. (< 1.0x is a win.) > > DM says it draws pixel perfect compare to the old code. > > Microbenchmarks: > bitmap_RGBA_8888_A_source_stripes_two 14us -> 14.4us 1.03x > bitmap_RGBA_8888_A_source_stripes_three 14.3us -> 14.5us 1.01x > bitmap_RGBA_8888_scale_bilerp 61.9us -> 62.2us 1.01x > bitmap_RGBA_8888_update_volatile_scale_rotate_bilerp 102us -> 101us 0.99x > bitmap_RGBA_8888_scale_rotate_bilerp 103us -> 101us 0.99x > bitmap_RGBA_8888_scale 18.4us -> 18.2us 0.99x > bitmap_RGBA_8888_A_scale_rotate_bicubic 71us -> 70us 0.99x > bitmap_RGBA_8888_update_scale_rotate_bilerp 103us -> 101us 0.99x > bitmap_RGBA_8888_A_scale_rotate_bilerp 112us -> 109us 0.98x > bitmap_RGBA_8888_update_volatile 5.72us -> 5.58us 0.98x > bitmap_RGBA_8888 5.73us -> 5.58us 0.97x > bitmap_RGBA_8888_update 5.78us -> 5.6us 0.97x > bitmap_RGBA_8888_A_scale_bilerp 70.7us -> 68us 0.96x > bitmap_RGBA_8888_A_scale_bicubic 23.7us -> 21.8us 0.92x > bitmap_RGBA_8888_A 13.9us -> 10.9us 0.78x > bitmap_RGBA_8888_A_source_opaque 14us -> 6.29us 0.45x > bitmap_RGBA_8888_A_source_transparent 14us -> 3.65us 0.26x > > Running over our ~70 SKP web page captures, this looks like we spend 0.7x > the time in S32A_Opaque_BlitRow compared to the SSE2 version, which should > be a decent predictor of real-world impact. > > BUG=chromium:399842 > > Committed: https://skia.googlesource.com/skia/+/04bc91b972417038fecfa87c484771eac2b9b785 > > CQ_EXTRA_TRYBOTS=client.skia:Test-Mac10.6-MacMini4.1-GeForce320M-x86_64-Release-Trybot > > Committed: https://skia.googlesource.com/skia/+/6dbfb21a6c88af6d94e8c823c3ad559f1a41b493 TBR=henrik.smiding@intel.com,mtklein@google.com,herb@google.com,reed@google.com,thakis@chromium.org,mtklein@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:399842 Review URL: https://codereview.chromium.org/873553003
* Optimize SSE2 opaque blendGravatar qiankun.miao2015-02-02
| | | | | | | | | | | | | | | | | | | | | | | | | Backport optimization from https://codereview.chromium.org/874863002/. Microbenchmarks data compared to previous SSE2 implementation: bitmap_BGRA_8888_A_source_stripes_three 7.52us -> 8.67us 1.15x bitmap_BGRA_8888_A_source_stripes_two 7.48us -> 8.56us 1.15x bitmap_BGRA_8888_update_scale_rotate_bilerp 63.4us -> 64us 1.01x bitmap_BGRA_8888_update_volatile 3.31us -> 3.33us 1.01x bitmap_BGRA_8888_scale 11.1us -> 11.2us 1x bitmap_BGRA_8888_scale_bilerp 35.8us -> 35.9us 1x bitmap_BGRA_8888 3.33us -> 3.33us 1x bitmap_BGRA_8888_A_scale_rotate_bicubic 66.7us -> 66.5us 1x bitmap_BGRA_8888_update_volatile_scale_rotate_bilerp 65.1us -> 64us 0.98x bitmap_BGRA_8888_scale_rotate_bilerp 65.1us -> 64us 0.98x bitmap_BGRA_8888_A_scale_bicubic 30.6us -> 29.9us 0.98x bitmap_BGRA_8888_A_scale_bilerp 42.7us -> 41.4us 0.97x bitmap_BGRA_8888_A_scale_rotate_bilerp 71us -> 67.7us 0.95x bitmap_BGRA_8888_A 7.44us -> 5.7us 0.77x bitmap_BGRA_8888_A_source_opaque 7.46us -> 3.72us 0.5x bitmap_BGRA_8888_A_source_transparent 7.46us -> 1.96us 0.26x BUG=skia: Review URL: https://codereview.chromium.org/886403002
* skia: blend32_16_row for neon versionGravatar mlee2015-01-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This includes blend32_16_row neon implementation for aarch32 and aarch64. For performance, blend32_16_row is called in following tests in nanobench. - Xfermode_SrcOver - tablebench - rotated_rects_bw_alternating_transparent_and_opaque_srcover - rotated_rects_bw_changing_transparent_srcover - rotated_rects_bw_same_transparent_srcover - luma_colorfilter_large - luma_colorfilter_small - chart_bw I can see perf increase in following two tests, especially. For others, looks similar. For each, I tried to run two times. 1) Xfermode_SrcOver <org> - D/skia ( 2000): 3M 57 17.3µs 17.4µs 17.4µs 17.7µs 1% █▃▂▃▂▂▂▁▃▂ 565 Xfermode_SrcOver - D/skia ( 1915): 3M 70 13.5µs 16.9µs 16.7µs 18.8µs 9% ▆█▄▅█▁▅▅▆▄ 565 Xfermode_SrcOver <new> - D/skia ( 2000): 3M 8 11.6µs 11.8µs 12.1µs 14.4µs 7% ▃█▁▁▂▁▁▁▂▂ 565 Xfermode_SrcOver - D/skia ( 2004): 3M 62 10.3µs 12.9µs 13µs 15.2µs 11% █▅▅▆▁▅▅▅▇▃ 565 Xfermode_SrcOver 2) luma_colorfilter_large <org> - D/skia ( 2000): 159M 8 136µs 136µs 136µs 139µs 1% █▃▁▂▁▁▁▁▁▁ 565 luma_colorfilter_large - D/skia ( 1915): 158M 2 135µs 177µs 182µs 269µs 22% ▆▃█▁▁▃▃▃▃▃ 565 luma_colorfilter_large <new> - D/skia ( 2000): 157M 5 84.2µs 85.3µs 87.5µs 110µs 9% █▁▂▁▁▁▁▁▁▁ 565 luma_colorfilter_large - D/skia ( 2004): 159M 6 84.7µs 110µs 112µs 144µs 18% █▄▇▁▁▄▃▄▄▆ 565 luma_colorfilter_large Review URL: https://codereview.chromium.org/847363002
* add a paranoid assertGravatar mtklein2015-01-28
| | | | | | | | NOTREECHECKS=true BUG=chromium:399842 Review URL: https://codereview.chromium.org/881253003
* SSE4 opaque blend using intrinsics instead of assembly.Gravatar mtklein2015-01-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since we had such a hard time with the assembly versions of this blit (to the point that we have them completely disabled everywhere), I thought I'd take a shot at writing a version of the blit using intrinsics. The key feature of SSE4 we're exploiting is that we can use ptest (_mm_test*) to skip the blend when the 16 src pixels we consider each loop are all opaque or all transparent. _mm_shuffle_epi8 from SSSE3 also lends a hand to extract all those alphas. It's worth looking to see if we can backport this type of logic to SSE2 using _mm_movemask_epi8, or up to 32 pixels at a time using AVX. My local performance testing doesn't show this to be an unambiguous win (there are probably microbenchmarks and SKPs where we'd be better off just powering through the blend rather than looking at alphas), but the potential does seem tantalizing enough to let skiaperf vet it on the bots. (< 1.0x is a win.) DM says it draws pixel perfect compare to the old code. Microbenchmarks: bitmap_RGBA_8888_A_source_stripes_two 14us -> 14.4us 1.03x bitmap_RGBA_8888_A_source_stripes_three 14.3us -> 14.5us 1.01x bitmap_RGBA_8888_scale_bilerp 61.9us -> 62.2us 1.01x bitmap_RGBA_8888_update_volatile_scale_rotate_bilerp 102us -> 101us 0.99x bitmap_RGBA_8888_scale_rotate_bilerp 103us -> 101us 0.99x bitmap_RGBA_8888_scale 18.4us -> 18.2us 0.99x bitmap_RGBA_8888_A_scale_rotate_bicubic 71us -> 70us 0.99x bitmap_RGBA_8888_update_scale_rotate_bilerp 103us -> 101us 0.99x bitmap_RGBA_8888_A_scale_rotate_bilerp 112us -> 109us 0.98x bitmap_RGBA_8888_update_volatile 5.72us -> 5.58us 0.98x bitmap_RGBA_8888 5.73us -> 5.58us 0.97x bitmap_RGBA_8888_update 5.78us -> 5.6us 0.97x bitmap_RGBA_8888_A_scale_bilerp 70.7us -> 68us 0.96x bitmap_RGBA_8888_A_scale_bicubic 23.7us -> 21.8us 0.92x bitmap_RGBA_8888_A 13.9us -> 10.9us 0.78x bitmap_RGBA_8888_A_source_opaque 14us -> 6.29us 0.45x bitmap_RGBA_8888_A_source_transparent 14us -> 3.65us 0.26x Running over our ~70 SKP web page captures, this looks like we spend 0.7x the time in S32A_Opaque_BlitRow compared to the SSE2 version, which should be a decent predictor of real-world impact. BUG=chromium:399842 Committed: https://skia.googlesource.com/skia/+/04bc91b972417038fecfa87c484771eac2b9b785 CQ_EXTRA_TRYBOTS=client.skia:Test-Mac10.6-MacMini4.1-GeForce320M-x86_64-Release-Trybot Review URL: https://codereview.chromium.org/874863002
* Revert of SSE4 opaque blend using intrinsics instead of assembly. (patchset ↵Gravatar bungeman2015-01-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | #14 id:260001 of https://codereview.chromium.org/874863002/) Reason for revert: This kills Mac 10.6 bots. FAILED: c++ -MMD -MF obj/src/opts/opts_sse4.SkBlitRow_opts_SSE4.o.d -DSK_INTERNAL -DSK_GAMMA_SRGB -DSK_GAMMA_APPLY_TO_A8 -DSK_SCALAR_TO_FLOAT_EXCLUDED -DSK_ALLOW_STATIC_GLOBAL_INITIALIZERS=1 -DSK_SUPPORT_GPU=1 -DSK_SUPPORT_OPENCL=0 -DSK_FORCE_DISTANCE_FIELD_TEXT=0 -DSK_BUILD_FOR_MAC -DSK_CRASH_HANDLER -DSK_DEVELOPER=1 -I../../src/core -I../../src/utils -I../../include/c -I../../include/config -I../../include/core -I../../include/pathops -I../../include/pipe -I../../include/utils/mac -I../../include/effects -O0 -gdwarf-2 -mmacosx-version-min=10.6 -arch x86_64 -mssse3 -Wall -Wextra -Winit-self -Wpointer-arith -Wsign-compare -Wno-unused-parameter -Wno-invalid-offsetof -msse4.1 -c ../../src/opts/SkBlitRow_opts_SSE4.cpp -o obj/src/opts/opts_sse4.SkBlitRow_opts_SSE4.o ../../src/opts/SkBlitRow_opts_SSE4.cpp:15:27: warning: x86intrin.h: No such file or directory ../../src/opts/SkBlitRow_opts_SSE4.cpp: In function 'void S32A_Opaque_BlitRow32_SSE4(SkPMColor*, const SkPMColor*, int, U8CPU)': ../../src/opts/SkBlitRow_opts_SSE4.cpp:40: error: '_mm_testz_si128' was not declared in this scope ../../src/opts/SkBlitRow_opts_SSE4.cpp:45: error: '_mm_testc_si128' was not declared in this scope Original issue's description: > SSE4 opaque blend using intrinsics instead of assembly. > > Since we had such a hard time with the assembly versions of this blit (to the > point that we have them completely disabled everywhere), I thought I'd take > a shot at writing a version of the blit using intrinsics. > > The key feature of SSE4 we're exploiting is that we can use ptest (_mm_test*) > to skip the blend when the 16 src pixels we consider each loop are all opaque > or all transparent. _mm_shuffle_epi8 from SSSE3 also lends a hand to extract > all those alphas. > > It's worth looking to see if we can backport this type of logic to SSE2 using > _mm_movemask_epi8, or up to 32 pixels at a time using AVX. > > My local performance testing doesn't show this to be an unambiguous win > (there are probably microbenchmarks and SKPs where we'd be better off just > powering through the blend rather than looking at alphas), but the potential > does seem tantalizing enough to let skiaperf vet it on the bots. (< 1.0x is a win.) > > DM says it draws pixel perfect compare to the old code. > > Microbenchmarks: > bitmap_RGBA_8888_A_source_stripes_two 14us -> 14.4us 1.03x > bitmap_RGBA_8888_A_source_stripes_three 14.3us -> 14.5us 1.01x > bitmap_RGBA_8888_scale_bilerp 61.9us -> 62.2us 1.01x > bitmap_RGBA_8888_update_volatile_scale_rotate_bilerp 102us -> 101us 0.99x > bitmap_RGBA_8888_scale_rotate_bilerp 103us -> 101us 0.99x > bitmap_RGBA_8888_scale 18.4us -> 18.2us 0.99x > bitmap_RGBA_8888_A_scale_rotate_bicubic 71us -> 70us 0.99x > bitmap_RGBA_8888_update_scale_rotate_bilerp 103us -> 101us 0.99x > bitmap_RGBA_8888_A_scale_rotate_bilerp 112us -> 109us 0.98x > bitmap_RGBA_8888_update_volatile 5.72us -> 5.58us 0.98x > bitmap_RGBA_8888 5.73us -> 5.58us 0.97x > bitmap_RGBA_8888_update 5.78us -> 5.6us 0.97x > bitmap_RGBA_8888_A_scale_bilerp 70.7us -> 68us 0.96x > bitmap_RGBA_8888_A_scale_bicubic 23.7us -> 21.8us 0.92x > bitmap_RGBA_8888_A 13.9us -> 10.9us 0.78x > bitmap_RGBA_8888_A_source_opaque 14us -> 6.29us 0.45x > bitmap_RGBA_8888_A_source_transparent 14us -> 3.65us 0.26x > > Running over our ~70 SKP web page captures, this looks like we spend 0.7x > the time in S32A_Opaque_BlitRow compared to the SSE2 version, which should > be a decent predictor of real-world impact. > > BUG=chromium:399842 > > Committed: https://skia.googlesource.com/skia/+/04bc91b972417038fecfa87c484771eac2b9b785 TBR=henrik.smiding@intel.com,mtklein@google.com,herb@google.com,reed@google.com,thakis@chromium.org,mtklein@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:399842 Review URL: https://codereview.chromium.org/874033004
* SSE4 opaque blend using intrinsics instead of assembly.Gravatar mtklein2015-01-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since we had such a hard time with the assembly versions of this blit (to the point that we have them completely disabled everywhere), I thought I'd take a shot at writing a version of the blit using intrinsics. The key feature of SSE4 we're exploiting is that we can use ptest (_mm_test*) to skip the blend when the 16 src pixels we consider each loop are all opaque or all transparent. _mm_shuffle_epi8 from SSSE3 also lends a hand to extract all those alphas. It's worth looking to see if we can backport this type of logic to SSE2 using _mm_movemask_epi8, or up to 32 pixels at a time using AVX. My local performance testing doesn't show this to be an unambiguous win (there are probably microbenchmarks and SKPs where we'd be better off just powering through the blend rather than looking at alphas), but the potential does seem tantalizing enough to let skiaperf vet it on the bots. (< 1.0x is a win.) DM says it draws pixel perfect compare to the old code. Microbenchmarks: bitmap_RGBA_8888_A_source_stripes_two 14us -> 14.4us 1.03x bitmap_RGBA_8888_A_source_stripes_three 14.3us -> 14.5us 1.01x bitmap_RGBA_8888_scale_bilerp 61.9us -> 62.2us 1.01x bitmap_RGBA_8888_update_volatile_scale_rotate_bilerp 102us -> 101us 0.99x bitmap_RGBA_8888_scale_rotate_bilerp 103us -> 101us 0.99x bitmap_RGBA_8888_scale 18.4us -> 18.2us 0.99x bitmap_RGBA_8888_A_scale_rotate_bicubic 71us -> 70us 0.99x bitmap_RGBA_8888_update_scale_rotate_bilerp 103us -> 101us 0.99x bitmap_RGBA_8888_A_scale_rotate_bilerp 112us -> 109us 0.98x bitmap_RGBA_8888_update_volatile 5.72us -> 5.58us 0.98x bitmap_RGBA_8888 5.73us -> 5.58us 0.97x bitmap_RGBA_8888_update 5.78us -> 5.6us 0.97x bitmap_RGBA_8888_A_scale_bilerp 70.7us -> 68us 0.96x bitmap_RGBA_8888_A_scale_bicubic 23.7us -> 21.8us 0.92x bitmap_RGBA_8888_A 13.9us -> 10.9us 0.78x bitmap_RGBA_8888_A_source_opaque 14us -> 6.29us 0.45x bitmap_RGBA_8888_A_source_transparent 14us -> 3.65us 0.26x Running over our ~70 SKP web page captures, this looks like we spend 0.7x the time in S32A_Opaque_BlitRow compared to the SSE2 version, which should be a decent predictor of real-world impact. BUG=chromium:399842 Review URL: https://codereview.chromium.org/874863002
* Don't do a pointless << 0.Gravatar mtklein2015-01-26
| | | | | | | | | | It's very common (universal?) that alpha is the top byte. You'd hope the compiler would remove the left shift then, but I've seen Clang just do a dumb left shift of zero. :( BUG=skia: Review URL: https://codereview.chromium.org/872243003
* remove dead code after HQ changeGravatar reed2015-01-20
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/845303005
* rename blitrow::proc and add (uncalled) hook for colorproc16Gravatar reed2015-01-13
| | | | | | BUG=skia:3302 Review URL: https://codereview.chromium.org/847443003
* Hide ARM assembly memset symbols.Gravatar torne2015-01-13
| | | | | | | | | | Prevent these symbols from being exported from any library which includes skia by marking them .hidden, as they are implementation details of skia. BUG=skia:3303 Review URL: https://codereview.chromium.org/831663004
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-03 19:55:38 +0000