aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/effects/SkPoint3.cpp
diff options
context:
space:
mode:
authorGravatar mtklein <mtklein@chromium.org>2015-07-31 10:46:50 -0700
committerGravatar Commit bot <commit-bot@chromium.org>2015-07-31 10:46:50 -0700
commit7eb0945af254d376df11475150d184623104cf93 (patch)
treef1eca7b5e83428fc5f728967fed41324d5186e66 /src/effects/SkPoint3.cpp
parent5119ac069e6cf70175b5581eedee7d07347b216a (diff)
Port SkUtils opts to SkOpts.
With this new arrangement, the benefits of inlining sk_memset16/32 have changed. On x86, they're not significantly different, except for small N<=10 where the inlined code is significantly slower. On ARMv7 with NEON, our custom code is still significantly faster for N>10 (up to 2x faster). For small N<=10 inlining is still significantly faster. On ARMv7 without NEON, our custom code is still ridiculously faster (up to 10x) than inlining for N>10, though for small N<=10 inlining is still a little faster. We were not using the NEON memset16 and memset32 procs on ARMv8. At first blush, that seems to be an oversight, but if so it's an extremely lucky one. The ARMv8 code generation for our memset16/32 procs is total garbage, leaving those methods ~8x slower than just inlining the memset, using the compiler's autovectorization. So, no need to inline any more on x86, and still inline for N<=10 on ARMv7. Always inline for ARMv8. BUG=skia:4117 Review URL: https://codereview.chromium.org/1270573002
Diffstat (limited to 'src/effects/SkPoint3.cpp')
0 files changed, 0 insertions, 0 deletions