aboutsummaryrefslogtreecommitdiffhomepage
path: root/bench
Commit message (Collapse)AuthorAge
* Change to add zoom animations to nanobenchGravatar joshualitt2015-04-27
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1061323003
* Do not crash nanobench in debug modeGravatar msarett2015-04-24
| | | | | | | | Instead print an error message BUG=skia: Review URL: https://codereview.chromium.org/1102083002
* Revert of Revert of remove unused (by clients) SkPathUtils (patchset #1 id:1 ↵Gravatar reed2015-04-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | of https://codereview.chromium.org/1060703003/) Reason for revert: fix (removal from gypi/gn files) has landed in chrome. Original issue's description: > Revert of remove unused (by clients) SkPathUtils (patchset #1 id:1 of https://codereview.chromium.org/1088383003/) > > Reason for revert: > This change is causing the DEPS roll to fail: > > > http://build.chromium.org/p/tryserver.chromium.linux/builders/android_chromium_gn_compile_rel/builds/78771/steps/gn/logs/stdio > > Original issue's description: > > remove unused (by clients) SkPathUtils > > > > BUG=skia: > > > > Committed: https://skia.googlesource.com/skia/+/aab35d91b8b80acd1902594bbf542083fdfa4bb7 > > TBR=scroggo@google.com,reed@chromium.org > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/bdb0bf5f8858043878d8a4fa8130c6c87bef3fd4 TBR=scroggo@google.com,jcgregorio@google.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1091963002
* Revert of remove unused (by clients) SkPathUtils (patchset #1 id:1 of ↵Gravatar jcgregorio2015-04-16
| | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/1088383003/) Reason for revert: This change is causing the DEPS roll to fail: http://build.chromium.org/p/tryserver.chromium.linux/builders/android_chromium_gn_compile_rel/builds/78771/steps/gn/logs/stdio Original issue's description: > remove unused (by clients) SkPathUtils > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/aab35d91b8b80acd1902594bbf542083fdfa4bb7 TBR=scroggo@google.com,reed@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1060703003
* remove unused (by clients) SkPathUtilsGravatar reed2015-04-16
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1088383003
* crank up innerloop to make hairlinebench more usable/reliableGravatar reed2015-04-13
| | | | | | | BUG=skia: TBR= Review URL: https://codereview.chromium.org/1087583002
* Rewrite memset benches, then use results to add a small-N optimization.Gravatar mtklein2015-04-09
| | | | | | | | | | | | | | | The benches for N <= 10 get around 2x faster on my N7 and N9. I believe this is because of the reduced function-call-then-function-pointer-call overhead on the N7, and additionally because it seems autovectorization beats our NEON code for small N on the N9. My desktop is unchanged, though that's probably because N=10 lies well within a region where memset's performance is essentially constant: N=100 takes only about 2x as long as N=1 and N=10, which perform nearly identically. BUG=skia: Review URL: https://codereview.chromium.org/1073863002
* Expand bench to cover no-draw SkPictures too.Gravatar mtklein2015-04-06
| | | | | | | | This looks a lot closer to what Chromium's profiling is showing. BUG=chromium:470553 Review URL: https://codereview.chromium.org/1063723002
* Add a bench to measure SkPictureRecorder constant overhead.Gravatar mtklein2015-04-03
| | | | | | BUG=chromium:470553 Review URL: https://codereview.chromium.org/1061633002
* BUG=skia:Gravatar joshualitt2015-04-03
| | | | Review URL: https://codereview.chromium.org/1031423002
* New names for SkPMFloat methods.Gravatar mtklein2015-04-03
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1055123002
* remove useless benchesGravatar reed2015-04-02
| | | | | | | | | | The colorfilter is applied to a single (paint's) color, so the bench does not measure the filter at all, but simply the blit of a color. BUG=skia: TBR= Review URL: https://codereview.chromium.org/1055383002
* Test SkCodec to kIndex8 in nanobench.Gravatar scroggo2015-04-02
| | | | | | | BUG=skia:3257 BUG=skia:3475 Review URL: https://codereview.chromium.org/1051973002
* experimental speedup some xfermodes with Sk4fGravatar reed2015-04-02
| | | | | | | | | | | | | | | | | | | | | | Old: 7M 1 11.1ms 11.3ms 11.3ms 11.6ms 1% ▅▄▂▂▁▁▄▄█▇ 8888 Xfermode_Screen 7M 1 10.7ms 10.9ms 10.9ms 11.1ms 1% ▄▄▄▇▃▁█▄▂▅ 8888 Xfermode_Modulate 7M 1 7.86ms 8.03ms 8ms 8.18ms 1% █▇▅▁▃▃▂▃▆▅ 8888 Xfermode_Plus 7M 1 14.6ms 14.8ms 14.8ms 15.1ms 1% ▄█▆▅▄▁▁▆▄▆ 8888 Xfermode_Xor 7M 1 13ms 13.5ms 13.4ms 13.8ms 2% ▅▃▇▁█▂▃▅▃▅ 8888 Xfermode_DstATop 7M 1 13.1ms 13.4ms 13.3ms 13.6ms 1% ▄▁▁▆▅▄▇▆█▂ 8888 Xfermode_SrcATop New: 7M 1 6.99ms 7.19ms 7.4ms 8.98ms 8% ▁▂▁▃▂█▁▂▂▂ 8888 Xfermode_Screen 7M 1 5.27ms 5.46ms 5.46ms 5.89ms 3% ▁▁▅▁▂█▄▃▄▃ 8888 Xfermode_Modulate 7M 1 6.8ms 7.04ms 7.27ms 8.53ms 8% ▂▁█▁▁▂▂▂▂▇ 8888 Xfermode_Plus 7M 1 9ms 9.2ms 9.33ms 10.5ms 5% ▁█▃▁▂▁▁▁▅▂ 8888 Xfermode_Xor 7M 1 8.34ms 8.57ms 8.73ms 10.6ms 8% ▁▁▁▂▂▂▂▂▂█ 8888 Xfermode_DstATop 7M 1 8.38ms 8.62ms 8.91ms 10.3ms 8% ▁▃▁▂▇▂▁▂▁█ 8888 Xfermode_SrcATop Need to define SK_SUPPORT_LEGACY_SCALAR_XFERMODES in chrome to suppress change (see https://codereview.chromium.org/1054083002/) Review URL: https://codereview.chromium.org/1043413002
* nanobench does not need to handle failed rewind.Gravatar scroggo2015-04-01
| | | | | | | | | | | Now that all SkCodecs can rewind (assuming the stream is rewindable), we do not need to special case it. Pointed out by Derek in the code review that added this. TBR=djsollen Review URL: https://codereview.chromium.org/1058633002
* Add timing SkCodec to nanobench.Gravatar scroggo2015-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CodecBench: Add new class for timing using SkCodec. DecodingBench: Include creating a decoder inside the loop. This is to have a better comparison against SkCodec. SkCodec's factory function does not necessarily read the same amount as SkImageDecoder's, so in order to have a meaningful comparison, read the entire stream from the beginning. Also for comparison, create a new SkStream from the SkData each time. Add a debugging check to make sure we have an SkImageDecoder. Add include guards. nanobench.cpp: Decode using SkCodec. When decoding using SkImageDecoder, exclude benches where we decoded to a different color type than requested. SkImageDecoder may decide to decode to a different type, in which case the name is misleading. TODOs: Now that we ignore color types that do not match the desired color type, we should add Index8. This also means calling the more complex version of getPixels so CodecBench can support kIndex8. BUG=skia:3257 Review URL: https://codereview.chromium.org/1044363002
* 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
* use Sk4f for matrix mathGravatar reed2015-03-29
| | | | | | | | | Need to land SK_SUPPORT_LEGACY_SCALAR_MAPPOINTS in chrome to suppress Affine version which causes slight differences (which will need to be rebaselined) BUG=skia: Review URL: https://codereview.chromium.org/1045493002
* use table of procs (and unrolling) to speed up mapPtsGravatar reed2015-03-27
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1040783002
* Move HWUI boilerplate into utils/androidGravatar tomhudson2015-03-27
| | | | | | | | | | | | | | | Duplicate code from the HWUI backends for DM and nanobench moves into a single place, saving a hundred lines or more of cut-and-paste. There's some indication that this increases the incidence of SkCanvas "Unable to find device for layer." warnings, but no clear degradation in test results. R=djsollen@google.com,mtklein@google.com BUG=skia:3589 Review URL: https://codereview.chromium.org/1036303002
* Minor cleanup in nanobenchGravatar tomhudson2015-03-27
| | | | | | | | | | | Simplify time() by removing conditionals; reduce the amount of parameter passing. Add a convenience function to Target. R=mtklein@google.com BUG=skia:3595 Review URL: https://codereview.chromium.org/1039253002
* Add matrix constructing helpers to SkMatrixGravatar robertphillips2015-03-26
| | | | Review URL: https://codereview.chromium.org/1034273002
* 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
* Android HWUI backend NanobenchGravatar tomhudson2015-03-26
| | | | | | | | | Uses filtering canvas from utils/android, shared with DM. Follow-up plans in https://skbug.com/3589, https://skbug.com/3595 R=djsollen@google.com Review URL: https://codereview.chromium.org/1029423010
* small fix for nanobench segfault when not running any testsGravatar joshualitt2015-03-26
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1030353004
* use new faster/vector impl for chopping conicsGravatar reed2015-03-26
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1035943002
* remove slower scalar code in favor of vectorsGravatar reed2015-03-26
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1001833006
* 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
* hack on linear gradientGravatar mtklein2015-03-25
| | | | | | | | | | Am I going nuts or can we get this down to just adds and converts in the loop? #floats #n9 BUG=skia:3592 CQ_INCLUDE_TRYBOTS=client.skia.android:Test-Android-Nexus9-TegraK1-Arm64-Release-Trybot Review URL: https://codereview.chromium.org/1008973004
* Use Sk4x to speed-up bounds of an array of pointsGravatar reed2015-03-25
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1015633004
* 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
* SkChopCubicAt2 using Sk2s -- 2x fasterGravatar reed2015-03-24
| | | | | | | BUG=skia: TBR= Review URL: https://codereview.chromium.org/1036753002
* remove meaningless matrix benches, add mapPts() and add new benchesGravatar reed2015-03-23
| | | | | | | | | | mapPts definitely faster than mapPoints (identity and perspective same speed). Up to 3x for large values of N. cloned from https://codereview.chromium.org/1031443002/ BUG=skia: Review URL: https://codereview.chromium.org/1030653002
* Get rid of excess cleverness in benchmarkGravatar tomhudson2015-03-23
| | | | | | | | | | | | RotatedRectBench was asking for its base layer size, which may not be what it expects with odd canvas modes (particularly proxies). Most benchmarks are not so sophisticated; they hard-wire their size and just use that (expected) value. R=mtklein@google.com,djsollen@google.com BUG=skia:3566 Review URL: https://codereview.chromium.org/1015013004
* use Sk2s for conicsGravatar reed2015-03-20
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1025033002
* Only use 256x256 tiles on hd2000 nanobench botsGravatar egdaniel2015-03-20
| | | | | | | | | | | Initial experiments did show that the 256 tile size fixed the hd2000 win7 nanobot failures. However it did not have any effect on other bots, so this change is to move back to the larger tile size on all bots expect for the hd2000. BUG=skia: Review URL: https://codereview.chromium.org/1022083002
* use Sk2s for EvalQuadTangent and ChopQuadAtGravatar reed2015-03-20
| | | | | | | | cloned from https://codereview.chromium.org/1026633002/ BUG=skia: Review URL: https://codereview.chromium.org/1024873003
* Move skp nanobench tile size back to 256x256 to see if it fixes nanobench ↵Gravatar egdaniel2015-03-19
| | | | | | | | | | | | | | crashes Going back to old nanobench tile size to see if the increase to tile is what has been causing recent nanobench crashes. The crashes seem very nondeterministic and hard to debug manually. 256x256 is too small of a tile to give accurate gpu results but if this fixes we can try some compromise in the middle BUG=skia: Review URL: https://codereview.chromium.org/1022823003
* alt SkEvalQuadAt that returns its answer, using Sk2fGravatar reed2015-03-19
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1011493003
* Revert of replace SkFixedDiv impl with native 64bit math (patchset #2 ↵Gravatar reed2015-03-19
| | | | | | | | | | | | | | | | | | | | | | | | | id:20001 of https://codereview.chromium.org/1022543003/) Reason for revert: http://build.chromium.org/p/tryserver.blink/builders/linux_blink_rel/builds/53096 layouttests failures Original issue's description: > replace SkFixedDiv impl with native 64bit math > > BUG=skia: > TBR= > > Committed: https://skia.googlesource.com/skia/+/7c44ca926bf42b3b2e56131f250c0fd58f87ac71 TBR= NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1018523008
* replace SkFixedDiv impl with native 64bit mathGravatar reed2015-03-18
| | | | | | | BUG=skia: TBR= Review URL: https://codereview.chromium.org/1022543003
* Remove uniqueID from all filter serialization.Gravatar senorblanco2015-03-18
| | | | | | | | | | | | (This is essentially a revert of https://codereview.chromium.org/503833002/.) This was necessary back when SkPaint was flattened even for in-process use. Now that we only flatten SkPaint for cross-process use, there's no need to serialize UniqueIDs. Note: SkDropShadowImageFilter is being constructed with a croprect and UniqueID (of 0) in Blink. I've made the uniqueID param default to 0 temporarily, until this rolls in and Blink can be changed. (Blink can't be changed first, since unlike the other filters, there's no constructor that takes a cropRect but not a uniqueID.) BUG=skia: Review URL: https://codereview.chromium.org/1019493002
* 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
* DM: display current memory usage (instead of peak) when available.Gravatar mtklein2015-03-12
| | | | | | | | | | | | | | | Seems strictly more useful. This implements Mac and Windows, which seemed easy. Don't know how to do this on Linux yet. BUG=skia: CQ_EXTRA_TRYBOTS=client.skia:Test-Mac10.9-MacMini6.2-HD4000-x86_64-Debug-Trybot NOTREECHECKS=true TBR=halcanary@google.com Review URL: https://codereview.chromium.org/990723002
* Increase default tile sizes in nanobenchGravatar bsalomon2015-03-05
| | | | | | R=mtklein@google.com Review URL: https://codereview.chromium.org/982863003
* 4-at-a-time SkPMColor -> SkPMFloat API.Gravatar mtklein2015-03-05
| | | | | | | | | | | | Please see if this looks usable. It may even give a perf boost if you use it, even without custom implementations for each instruction set. I've been trying this morning to beat this naive loop implementation, but so far no luck with either _SSE2.h or _SSSE3.h. It's possible this is an artifact of the microbenchmark, because we're not doing anything between the conversions. I'd like to see how this fits into real code, what assembly's generated, what the hot spots are, etc. I've updated the tests to test these new APIs, and splintered off a pair of new benchmarks that use the new APIs. This required some minor rejiggering in the benches. BUG=skia: Review URL: https://codereview.chromium.org/978213003
* 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
* Trim the fat off SkPMFloat bench.Gravatar mtklein2015-03-03
| | | | | | | | | | | | This bench was ~75% overhead, ~25% good bench. It is now just about the opposite: about 30% of the runtime is loop and random number overhead, and about 70% of the time is spent doing SkPMColor <-> SkPMFloat work. BUG=skia: NOPRESUBMIT=true Review URL: https://codereview.chromium.org/968133005
* Notify resource caches when pixelref genID goes staleGravatar reed2015-02-24
| | | | | | | | patch from issue 954443002 at patchset 40001 (http://crrev.com/954443002#ps40001) BUG=skia: Review URL: https://codereview.chromium.org/950363002