aboutsummaryrefslogtreecommitdiffhomepage
path: root/bench/nanobench.cpp
Commit message (Collapse)AuthorAge
* Adding new benchmark to test image decoding performance.Gravatar msarett2015-02-13
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/918673002
* Revert of nanobench: lazily decode bitmaps in .skps. (patchset #1 id:1 of ↵Gravatar mtklein2015-02-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/743613005/) Reason for revert: Well, it still crashes. Original issue's description: > nanobench: lazily decode bitmaps in .skps. > > This cuts down on tool overhead when running something like recording only, > $ out/Release/nanobench --match skp --config nonrendering > which doesn't usually ever need to decode the images. > > The actual measurements for recording don't change, as the decode is not in the timed section. It just skips irrelevant code, removing it from the profile and making the tool run faster. > > This does, however, make a significant difference for playback speed. Most skps draw faster with this patch, some slower. I don't really have a good intuition for what's going on here. There is a fixed clip acting as a viewport, so there are probably lots of images that don't ever need to be decoded. Ideas? Is this perhaps because we're now blitting from smaller, partially decoded source images? > > ~/skia (clean) $ compare clean.log lazy-decode-bitmaps.log > tabl_slashdot.skp_1 2.76ms -> 4.33ms 1.57x > tabl_slashdot.skp_1_mpd 2.79ms -> 4.07ms 1.46x > tabl_sahadan.skp_1 3.41ms -> 4.87ms 1.43x > tabl_googleblog.skp_1 1.52ms -> 2.05ms 1.35x > tabl_techmeme.skp_1_mpd 1.14ms -> 1.51ms 1.32x > tabl_transformice.skp_1 2.61ms -> 3.43ms 1.31x > tabl_sahadan.skp_1_mpd 3.54ms -> 4.48ms 1.26x > tabl_techmeme.skp_1 1.01ms -> 1.27ms 1.26x > tabl_nytimes.skp_1_mpd 1ms -> 1.23ms 1.23x > tabl_worldjournal.skp_1_mpd 1.98ms -> 2.43ms 1.23x > tabl_pravda.skp_1_mpd 2.05ms -> 2.51ms 1.22x > tabl_transformice.skp_1_mpd 2.75ms -> 3.19ms 1.16x > tabl_nytimes.skp_1 874us -> 1.01ms 1.15x > tabl_pravda.skp_1 1.83ms -> 1.99ms 1.09x > tabl_worldjournal.skp_1 1.76ms -> 1.91ms 1.09x > desk_wowwiki.skp_1_mpd 3.7ms -> 3.9ms 1.05x > tabl_digg.skp_1 3.99ms -> 4.16ms 1.04x > tabl_ukwsj.skp_1_mpd 3ms -> 3.12ms 1.04x > desk_booking.skp_1 3.74ms -> 3.81ms 1.02x > desk_googlespreadsheetdashed.skp_1 10.6ms -> 10.6ms 1x > tabl_ukwsj.skp_1 2.88ms -> 2.89ms 1x > desk_googlespreadsheetdashed.skp_1_mpd 11.8ms -> 11.8ms 1x > desk_jsfiddlehumperclip.skp_1_mpd 891us -> 888us 1x > desk_googlespreadsheet.skp_1 4.65ms -> 4.62ms 0.99x > tabl_gspro.skp_1_mpd 1.97ms -> 1.94ms 0.99x > desk_booking.skp_1_mpd 4.1ms -> 4ms 0.98x > desk_carsvg.skp_1 18.2ms -> 17.7ms 0.97x > desk_gmailthread.skp_1_mpd 2.81ms -> 2.73ms 0.97x > desk_tigersvg.skp_1_mpd 19.5ms -> 18.9ms 0.97x > desk_mapsvg.skp_1 88.4ms -> 85.6ms 0.97x > tabl_cnet.skp_1_mpd 1.43ms -> 1.38ms 0.97x > desk_jsfiddlebigcar.skp_1 1.26ms -> 1.22ms 0.96x > desk_gws.skp_1 1.87ms -> 1.8ms 0.96x > desk_linkedin.skp_1 2.07ms -> 1.98ms 0.96x > tabl_deviantart.skp_1_mpd 118ms -> 113ms 0.96x > tabl_cnet.skp_1 1.2ms -> 1.14ms 0.95x > tabl_androidpolice.skp_1_mpd 5.95ms -> 5.63ms 0.95x > desk_sfgate.skp_1 1.75ms -> 1.64ms 0.94x > desk_twitter.skp_1 74ms -> 69.6ms 0.94x > desk_youtube.skp_1_mpd 3.17ms -> 2.96ms 0.93x > desk_gmailthread.skp_1 2.73ms -> 2.54ms 0.93x > desk_silkfinance.skp_1_mpd 1.71ms -> 1.59ms 0.93x > desk_jsfiddlebigcar.skp_1_mpd 1.45ms -> 1.35ms 0.93x > desk_pokemonwiki.skp_1_mpd 2.72ms -> 2.51ms 0.92x > desk_gws.skp_1_mpd 2.14ms -> 1.98ms 0.92x > desk_googlehome.skp_1 563us -> 517us 0.92x > desk_espn.skp_1 4.24ms -> 3.89ms 0.92x > tabl_culturalsolutions.skp_1 12.7ms -> 11.6ms 0.91x > desk_sfgate.skp_1_mpd 1.91ms -> 1.74ms 0.91x > tabl_hsfi.skp_1 1.06ms -> 966us 0.91x > desk_samoasvg.skp_1_mpd 10.5ms -> 9.47ms 0.91x > desk_facebook.skp_1_mpd 3.8ms -> 3.43ms 0.9x > desk_youtube.skp_1 3.52ms -> 3.14ms 0.89x > desk_ebay.skp_1_mpd 2.95ms -> 2.62ms 0.89x > desk_samoasvg.skp_1 10.9ms -> 9.66ms 0.89x > desk_googlespreadsheet.skp_1_mpd 5.59ms -> 4.94ms 0.88x > desk_mapsvg.skp_1_mpd 100ms -> 87.9ms 0.88x > desk_espn.skp_1_mpd 4.7ms -> 4.12ms 0.88x > desk_wordpress.skp_1_mpd 1.92ms -> 1.68ms 0.87x > tabl_deviantart.skp_1 140ms -> 122ms 0.87x > tabl_cuteoverload.skp_1_mpd 4.41ms -> 3.83ms 0.87x > desk_tigersvg.skp_1 19.6ms -> 17ms 0.87x > tabl_googlecalendar.skp_1 4.01ms -> 3.44ms 0.86x > desk_blogger.skp_1 2.49ms -> 2.14ms 0.86x > desk_chalkboard.skp_1_mpd 52.7ms -> 45ms 0.85x > desk_weather.skp_1 2.88ms -> 2.46ms 0.85x > desk_chalkboard.skp_1 51ms -> 43.4ms 0.85x > desk_yahooanswers.skp_1 2.74ms -> 2.32ms 0.85x > desk_forecastio.skp_1_mpd 1.26ms -> 1.07ms 0.85x > tabl_androidpolice.skp_1 5.18ms -> 4.34ms 0.84x > desk_yahooanswers.skp_1_mpd 3.44ms -> 2.85ms 0.83x > tabl_cnn.skp_1_mpd 2.59ms -> 2.15ms 0.83x > desk_pinterest.skp_1 2.69ms -> 2.22ms 0.83x > tabl_hsfi.skp_1_mpd 1.6ms -> 1.32ms 0.82x > tabl_culturalsolutions.skp_1_mpd 13.8ms -> 11.3ms 0.82x > desk_twitter.skp_1_mpd 76.6ms -> 63ms 0.82x > desk_ebay.skp_1 3.11ms -> 2.51ms 0.81x > tabl_mlb.skp_1_mpd 3.17ms -> 2.53ms 0.8x > tabl_mozilla.skp_1 2.42ms -> 1.91ms 0.79x > desk_pokemonwiki.skp_1 2.84ms -> 2.22ms 0.78x > desk_carsvg.skp_1_mpd 23.3ms -> 17.8ms 0.77x > desk_wowwiki.skp_1 4.21ms -> 3.21ms 0.76x > desk_amazon.skp_1 963us -> 728us 0.76x > desk_css3gradients.skp_1 2.58ms -> 1.92ms 0.74x > tabl_cuteoverload.skp_1 4.55ms -> 3.38ms 0.74x > tabl_cnn.skp_1 3.13ms -> 2.29ms 0.73x > tabl_googleblog.skp_1_mpd 2.32ms -> 1.7ms 0.73x > desk_mobilenews.skp_1 3.65ms -> 2.61ms 0.71x > desk_googleplus.skp_1 3.76ms -> 2.66ms 0.71x > tabl_mozilla.skp_1_mpd 2.88ms -> 2.03ms 0.71x > desk_pinterest.skp_1_mpd 3.17ms -> 2.21ms 0.7x > desk_css3gradients.skp_1_mpd 2.98ms -> 2.07ms 0.69x > desk_silkfinance.skp_1 2.06ms -> 1.42ms 0.69x > desk_facebook.skp_1 4.5ms -> 3.07ms 0.68x > desk_mobilenews.skp_1_mpd 4.05ms -> 2.73ms 0.68x > desk_baidu.skp_1_mpd 2.73ms -> 1.81ms 0.66x > desk_weather.skp_1_mpd 3.93ms -> 2.5ms 0.64x > desk_wordpress.skp_1 2.15ms -> 1.36ms 0.63x > desk_googlehome.skp_1_mpd 1.02ms -> 605us 0.59x > desk_fontwipe.skp_1 722us -> 402us 0.56x > desk_fontwipe.skp_1_mpd 897us -> 486us 0.54x > desk_baidu.skp_1 3.02ms -> 1.6ms 0.53x > desk_forecastio.skp_1 2.01ms -> 999us 0.5x > desk_amazon.skp_1_mpd 1.77ms -> 860us 0.49x > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/7e225bdb1f00ae4aed524ff8d0a61df3d3abb109 > > Committed: https://skia.googlesource.com/skia/+/1b6b626f9bc0deebe4fe2e63f422d6b122419205 TBR=reed@google.com,robertphillips@google.com,scroggo@google.com,mtklein@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/902783005
* nanobench: lazily decode bitmaps in .skps.Gravatar mtklein2015-02-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This cuts down on tool overhead when running something like recording only, $ out/Release/nanobench --match skp --config nonrendering which doesn't usually ever need to decode the images. The actual measurements for recording don't change, as the decode is not in the timed section. It just skips irrelevant code, removing it from the profile and making the tool run faster. This does, however, make a significant difference for playback speed. Most skps draw faster with this patch, some slower. I don't really have a good intuition for what's going on here. There is a fixed clip acting as a viewport, so there are probably lots of images that don't ever need to be decoded. Ideas? Is this perhaps because we're now blitting from smaller, partially decoded source images? ~/skia (clean) $ compare clean.log lazy-decode-bitmaps.log tabl_slashdot.skp_1 2.76ms -> 4.33ms 1.57x tabl_slashdot.skp_1_mpd 2.79ms -> 4.07ms 1.46x tabl_sahadan.skp_1 3.41ms -> 4.87ms 1.43x tabl_googleblog.skp_1 1.52ms -> 2.05ms 1.35x tabl_techmeme.skp_1_mpd 1.14ms -> 1.51ms 1.32x tabl_transformice.skp_1 2.61ms -> 3.43ms 1.31x tabl_sahadan.skp_1_mpd 3.54ms -> 4.48ms 1.26x tabl_techmeme.skp_1 1.01ms -> 1.27ms 1.26x tabl_nytimes.skp_1_mpd 1ms -> 1.23ms 1.23x tabl_worldjournal.skp_1_mpd 1.98ms -> 2.43ms 1.23x tabl_pravda.skp_1_mpd 2.05ms -> 2.51ms 1.22x tabl_transformice.skp_1_mpd 2.75ms -> 3.19ms 1.16x tabl_nytimes.skp_1 874us -> 1.01ms 1.15x tabl_pravda.skp_1 1.83ms -> 1.99ms 1.09x tabl_worldjournal.skp_1 1.76ms -> 1.91ms 1.09x desk_wowwiki.skp_1_mpd 3.7ms -> 3.9ms 1.05x tabl_digg.skp_1 3.99ms -> 4.16ms 1.04x tabl_ukwsj.skp_1_mpd 3ms -> 3.12ms 1.04x desk_booking.skp_1 3.74ms -> 3.81ms 1.02x desk_googlespreadsheetdashed.skp_1 10.6ms -> 10.6ms 1x tabl_ukwsj.skp_1 2.88ms -> 2.89ms 1x desk_googlespreadsheetdashed.skp_1_mpd 11.8ms -> 11.8ms 1x desk_jsfiddlehumperclip.skp_1_mpd 891us -> 888us 1x desk_googlespreadsheet.skp_1 4.65ms -> 4.62ms 0.99x tabl_gspro.skp_1_mpd 1.97ms -> 1.94ms 0.99x desk_booking.skp_1_mpd 4.1ms -> 4ms 0.98x desk_carsvg.skp_1 18.2ms -> 17.7ms 0.97x desk_gmailthread.skp_1_mpd 2.81ms -> 2.73ms 0.97x desk_tigersvg.skp_1_mpd 19.5ms -> 18.9ms 0.97x desk_mapsvg.skp_1 88.4ms -> 85.6ms 0.97x tabl_cnet.skp_1_mpd 1.43ms -> 1.38ms 0.97x desk_jsfiddlebigcar.skp_1 1.26ms -> 1.22ms 0.96x desk_gws.skp_1 1.87ms -> 1.8ms 0.96x desk_linkedin.skp_1 2.07ms -> 1.98ms 0.96x tabl_deviantart.skp_1_mpd 118ms -> 113ms 0.96x tabl_cnet.skp_1 1.2ms -> 1.14ms 0.95x tabl_androidpolice.skp_1_mpd 5.95ms -> 5.63ms 0.95x desk_sfgate.skp_1 1.75ms -> 1.64ms 0.94x desk_twitter.skp_1 74ms -> 69.6ms 0.94x desk_youtube.skp_1_mpd 3.17ms -> 2.96ms 0.93x desk_gmailthread.skp_1 2.73ms -> 2.54ms 0.93x desk_silkfinance.skp_1_mpd 1.71ms -> 1.59ms 0.93x desk_jsfiddlebigcar.skp_1_mpd 1.45ms -> 1.35ms 0.93x desk_pokemonwiki.skp_1_mpd 2.72ms -> 2.51ms 0.92x desk_gws.skp_1_mpd 2.14ms -> 1.98ms 0.92x desk_googlehome.skp_1 563us -> 517us 0.92x desk_espn.skp_1 4.24ms -> 3.89ms 0.92x tabl_culturalsolutions.skp_1 12.7ms -> 11.6ms 0.91x desk_sfgate.skp_1_mpd 1.91ms -> 1.74ms 0.91x tabl_hsfi.skp_1 1.06ms -> 966us 0.91x desk_samoasvg.skp_1_mpd 10.5ms -> 9.47ms 0.91x desk_facebook.skp_1_mpd 3.8ms -> 3.43ms 0.9x desk_youtube.skp_1 3.52ms -> 3.14ms 0.89x desk_ebay.skp_1_mpd 2.95ms -> 2.62ms 0.89x desk_samoasvg.skp_1 10.9ms -> 9.66ms 0.89x desk_googlespreadsheet.skp_1_mpd 5.59ms -> 4.94ms 0.88x desk_mapsvg.skp_1_mpd 100ms -> 87.9ms 0.88x desk_espn.skp_1_mpd 4.7ms -> 4.12ms 0.88x desk_wordpress.skp_1_mpd 1.92ms -> 1.68ms 0.87x tabl_deviantart.skp_1 140ms -> 122ms 0.87x tabl_cuteoverload.skp_1_mpd 4.41ms -> 3.83ms 0.87x desk_tigersvg.skp_1 19.6ms -> 17ms 0.87x tabl_googlecalendar.skp_1 4.01ms -> 3.44ms 0.86x desk_blogger.skp_1 2.49ms -> 2.14ms 0.86x desk_chalkboard.skp_1_mpd 52.7ms -> 45ms 0.85x desk_weather.skp_1 2.88ms -> 2.46ms 0.85x desk_chalkboard.skp_1 51ms -> 43.4ms 0.85x desk_yahooanswers.skp_1 2.74ms -> 2.32ms 0.85x desk_forecastio.skp_1_mpd 1.26ms -> 1.07ms 0.85x tabl_androidpolice.skp_1 5.18ms -> 4.34ms 0.84x desk_yahooanswers.skp_1_mpd 3.44ms -> 2.85ms 0.83x tabl_cnn.skp_1_mpd 2.59ms -> 2.15ms 0.83x desk_pinterest.skp_1 2.69ms -> 2.22ms 0.83x tabl_hsfi.skp_1_mpd 1.6ms -> 1.32ms 0.82x tabl_culturalsolutions.skp_1_mpd 13.8ms -> 11.3ms 0.82x desk_twitter.skp_1_mpd 76.6ms -> 63ms 0.82x desk_ebay.skp_1 3.11ms -> 2.51ms 0.81x tabl_mlb.skp_1_mpd 3.17ms -> 2.53ms 0.8x tabl_mozilla.skp_1 2.42ms -> 1.91ms 0.79x desk_pokemonwiki.skp_1 2.84ms -> 2.22ms 0.78x desk_carsvg.skp_1_mpd 23.3ms -> 17.8ms 0.77x desk_wowwiki.skp_1 4.21ms -> 3.21ms 0.76x desk_amazon.skp_1 963us -> 728us 0.76x desk_css3gradients.skp_1 2.58ms -> 1.92ms 0.74x tabl_cuteoverload.skp_1 4.55ms -> 3.38ms 0.74x tabl_cnn.skp_1 3.13ms -> 2.29ms 0.73x tabl_googleblog.skp_1_mpd 2.32ms -> 1.7ms 0.73x desk_mobilenews.skp_1 3.65ms -> 2.61ms 0.71x desk_googleplus.skp_1 3.76ms -> 2.66ms 0.71x tabl_mozilla.skp_1_mpd 2.88ms -> 2.03ms 0.71x desk_pinterest.skp_1_mpd 3.17ms -> 2.21ms 0.7x desk_css3gradients.skp_1_mpd 2.98ms -> 2.07ms 0.69x desk_silkfinance.skp_1 2.06ms -> 1.42ms 0.69x desk_facebook.skp_1 4.5ms -> 3.07ms 0.68x desk_mobilenews.skp_1_mpd 4.05ms -> 2.73ms 0.68x desk_baidu.skp_1_mpd 2.73ms -> 1.81ms 0.66x desk_weather.skp_1_mpd 3.93ms -> 2.5ms 0.64x desk_wordpress.skp_1 2.15ms -> 1.36ms 0.63x desk_googlehome.skp_1_mpd 1.02ms -> 605us 0.59x desk_fontwipe.skp_1 722us -> 402us 0.56x desk_fontwipe.skp_1_mpd 897us -> 486us 0.54x desk_baidu.skp_1 3.02ms -> 1.6ms 0.53x desk_forecastio.skp_1 2.01ms -> 999us 0.5x desk_amazon.skp_1_mpd 1.77ms -> 860us 0.49x BUG=skia: Committed: https://skia.googlesource.com/skia/+/7e225bdb1f00ae4aed524ff8d0a61df3d3abb109 Review URL: https://codereview.chromium.org/743613005
* Add texture create/upload stats and make nanobench have explicit gpu stats flagGravatar bsalomon2015-02-02
| | | | Review URL: https://codereview.chromium.org/891973002
* Spin off GM::runAsBench() from flags.Gravatar mtklein2015-01-23
| | | | | | | | This will let us kill flags. BUG=skia: Review URL: https://codereview.chromium.org/873753002
* More natural way to serialize GPU tasks and tests.Gravatar mtklein2015-01-21
| | | | | | | | | | | | | This basically takes out the Windows-only hacks and promotes them to cross-platform behavior driven by --gpu_threading. - When --gpu_threading is false (the default), this puts GPU tasks and tests together in the same GPU enclave. They all run serially. - When --gpu_threading is true, both the tests and the tasks run totally independently, just like the thread-safe CPU-bound work. BUG=skia:3255 Review URL: https://codereview.chromium.org/847273005
* Make SkStream *not* ref counted.Gravatar scroggo2015-01-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SkStream is a stateful object, so it does not make sense for it to have multiple owners. Make SkStream inherit directly from SkNoncopyable. Update methods which previously called SkStream::ref() (e.g. SkImageDecoder::buildTileIndex() and SkFrontBufferedStream::Create(), which required the existing owners to call SkStream::unref()) to take ownership of their SkStream parameters and delete when done (including on failure). Switch all SkAutoTUnref<SkStream>s to SkAutoTDelete<SkStream>s. In some cases this means heap allocating streams that were previously stack allocated. Respect ownership rules of SkTypeface::CreateFromStream() and SkImageDecoder::buildTileIndex(). Update the comments for exceptional methods which do not affect the ownership of their SkStream parameters (e.g. SkPicture::CreateFromStream() and SkTypeface::Deserialize()) to be explicit about ownership. Remove test_stream_life, which tested that buildTileIndex() behaved correctly when SkStream was a ref counted object. The test does not make sense now that it is not. In SkPDFStream, remove the SkMemoryStream member. Instead of using it, create a new SkMemoryStream to pass to fDataStream (which is now an SkAutoTDelete). Make other pdf rasterizers behave like SkPDFDocumentToBitmap. SkPDFDocumentToBitmap delete the SkStream, so do the same in the following pdf rasterizers: SkPopplerRasterizePDF SkNativeRasterizePDF SkNoRasterizePDF Requires a change to Android, which currently treats SkStreams as ref counted objects. Review URL: https://codereview.chromium.org/849103004
* Require budget decision when creating a RenderTarget SkSurface.Gravatar bsalomon2015-01-16
| | | | | | | | | Restructure SkGpuDevice creation: *SkSurfaceProps are optional. *Use SkSurfaceProps to communicate DF text rather than a flag. *Tell SkGpuDevice::Create whether RT comes from cache or not. Review URL: https://codereview.chromium.org/848903004
* Sketch DM refactor.Gravatar mtklein2015-01-15
| | | | | | | | | | | | | | | | | | | BUG=skia:3255 I think this supports everything DM used to, but has completely refactored how it works to fit the design in the bug. Configs like "tiles-gpu" are automatically wired up. I wouldn't suggest looking at this as a diff. There's just a bunch of deleted files, a few new files, and one new file that shares a name with a deleted file (DM.cpp). NOTREECHECKS=true Committed: https://skia.googlesource.com/skia/+/709d2c3e5062c5b57f91273bfc11a751f5b2bb88 Review URL: https://codereview.chromium.org/788243008
* Revert of Sketch DM refactor. (patchset #45 id:850001 of ↵Gravatar mtklein2015-01-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/788243008/) Reason for revert: plenty of data Original issue's description: > Sketch DM refactor. > > BUG=skia:3255 > > > I think this supports everything DM used to, but has completely refactored how > it works to fit the design in the bug. > > Configs like "tiles-gpu" are automatically wired up. > > I wouldn't suggest looking at this as a diff. There's just a bunch of deleted > files, a few new files, and one new file that shares a name with a deleted file > (DM.cpp). > > NOTREECHECKS=true > > Committed: https://skia.googlesource.com/skia/+/709d2c3e5062c5b57f91273bfc11a751f5b2bb88 TBR=bsalomon@google.com,mtklein@chromium.org NOTREECHECKS=true NOTRY=true BUG=skia:3255 Review URL: https://codereview.chromium.org/853883004
* Sketch DM refactor.Gravatar mtklein2015-01-15
| | | | | | | | | | | | | | | | | BUG=skia:3255 I think this supports everything DM used to, but has completely refactored how it works to fit the design in the bug. Configs like "tiles-gpu" are automatically wired up. I wouldn't suggest looking at this as a diff. There's just a bunch of deleted files, a few new files, and one new file that shares a name with a deleted file (DM.cpp). NOTREECHECKS=true Review URL: https://codereview.chromium.org/788243008
* fix last warnings on w64 and turn on w.a.e.Gravatar bsalomon2014-12-15
| | | | Review URL: https://codereview.chromium.org/801413002
* Update nanobench so the non-MPD path doesn't permit layer hoistingGravatar robertphillips2014-12-09
| | | | Review URL: https://codereview.chromium.org/787923002
* Don't upload metrics we don't want to track.Gravatar mtklein2014-12-05
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/758853004
* nanobench: upload peak memory usage as its own trace.Gravatar mtklein2014-12-04
| | | | | | | | | | | | | We'll end up with a result like this: "memory_usage" : { "meta" : { "max_rss_mb" : 57 } } BUG=skia: Review URL: https://codereview.chromium.org/780013002
* Upload picture byte size and op count metrics for SKP recording.Gravatar mtklein2014-12-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Look okay? { "results" : { "desk_amazon.skp_1264_3999" : { "nonrendering" : { "bytes" : 75656, "max_ms" : 1.150187, "mean_ms" : 1.150187, "median_ms" : 1.150187, "min_ms" : 1.150187, "ops" : 659, "options" : { "bench_type" : "recording", "clip" : "0 0 1000 1000", "name" : "desk_amazon.skp", "scale" : "1", "source_type" : "skp" } } }, ... BUG=skia: Review URL: https://codereview.chromium.org/773323002
* Turn on MPD threading in nanobench.Gravatar mtklein2014-12-03
| | | | | | | | | | Seems okay after this small patch to skip lockPixels() / unlockPixels(). BUG=skia:3149 CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu13.10-GCE-NoGPU-x86_64-Release-TSAN-Trybot Review URL: https://codereview.chromium.org/773203003
* Revert of nanobench: lazily decode bitmaps in .skps. (patchset #1 id:1 of ↵Gravatar mtklein2014-11-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/743613005/) Reason for revert: Some bots crashing. Original issue's description: > nanobench: lazily decode bitmaps in .skps. > > This cuts down on tool overhead when running something like recording only, > $ out/Release/nanobench --match skp --config nonrendering > which doesn't usually ever need to decode the images. > > The actual measurements for recording don't change, as the decode is not in the timed section. It just skips irrelevant code, removing it from the profile and making the tool run faster. > > This does, however, make a significant difference for playback speed. Most skps draw faster with this patch, some slower. I don't really have a good intuition for what's going on here. There is a fixed clip acting as a viewport, so there are probably lots of images that don't ever need to be decoded. Ideas? Is this perhaps because we're now blitting from smaller, partially decoded source images? > > ~/skia (clean) $ compare clean.log lazy-decode-bitmaps.log > tabl_slashdot.skp_1 2.76ms -> 4.33ms 1.57x > tabl_slashdot.skp_1_mpd 2.79ms -> 4.07ms 1.46x > tabl_sahadan.skp_1 3.41ms -> 4.87ms 1.43x > tabl_googleblog.skp_1 1.52ms -> 2.05ms 1.35x > tabl_techmeme.skp_1_mpd 1.14ms -> 1.51ms 1.32x > tabl_transformice.skp_1 2.61ms -> 3.43ms 1.31x > tabl_sahadan.skp_1_mpd 3.54ms -> 4.48ms 1.26x > tabl_techmeme.skp_1 1.01ms -> 1.27ms 1.26x > tabl_nytimes.skp_1_mpd 1ms -> 1.23ms 1.23x > tabl_worldjournal.skp_1_mpd 1.98ms -> 2.43ms 1.23x > tabl_pravda.skp_1_mpd 2.05ms -> 2.51ms 1.22x > tabl_transformice.skp_1_mpd 2.75ms -> 3.19ms 1.16x > tabl_nytimes.skp_1 874us -> 1.01ms 1.15x > tabl_pravda.skp_1 1.83ms -> 1.99ms 1.09x > tabl_worldjournal.skp_1 1.76ms -> 1.91ms 1.09x > desk_wowwiki.skp_1_mpd 3.7ms -> 3.9ms 1.05x > tabl_digg.skp_1 3.99ms -> 4.16ms 1.04x > tabl_ukwsj.skp_1_mpd 3ms -> 3.12ms 1.04x > desk_booking.skp_1 3.74ms -> 3.81ms 1.02x > desk_googlespreadsheetdashed.skp_1 10.6ms -> 10.6ms 1x > tabl_ukwsj.skp_1 2.88ms -> 2.89ms 1x > desk_googlespreadsheetdashed.skp_1_mpd 11.8ms -> 11.8ms 1x > desk_jsfiddlehumperclip.skp_1_mpd 891us -> 888us 1x > desk_googlespreadsheet.skp_1 4.65ms -> 4.62ms 0.99x > tabl_gspro.skp_1_mpd 1.97ms -> 1.94ms 0.99x > desk_booking.skp_1_mpd 4.1ms -> 4ms 0.98x > desk_carsvg.skp_1 18.2ms -> 17.7ms 0.97x > desk_gmailthread.skp_1_mpd 2.81ms -> 2.73ms 0.97x > desk_tigersvg.skp_1_mpd 19.5ms -> 18.9ms 0.97x > desk_mapsvg.skp_1 88.4ms -> 85.6ms 0.97x > tabl_cnet.skp_1_mpd 1.43ms -> 1.38ms 0.97x > desk_jsfiddlebigcar.skp_1 1.26ms -> 1.22ms 0.96x > desk_gws.skp_1 1.87ms -> 1.8ms 0.96x > desk_linkedin.skp_1 2.07ms -> 1.98ms 0.96x > tabl_deviantart.skp_1_mpd 118ms -> 113ms 0.96x > tabl_cnet.skp_1 1.2ms -> 1.14ms 0.95x > tabl_androidpolice.skp_1_mpd 5.95ms -> 5.63ms 0.95x > desk_sfgate.skp_1 1.75ms -> 1.64ms 0.94x > desk_twitter.skp_1 74ms -> 69.6ms 0.94x > desk_youtube.skp_1_mpd 3.17ms -> 2.96ms 0.93x > desk_gmailthread.skp_1 2.73ms -> 2.54ms 0.93x > desk_silkfinance.skp_1_mpd 1.71ms -> 1.59ms 0.93x > desk_jsfiddlebigcar.skp_1_mpd 1.45ms -> 1.35ms 0.93x > desk_pokemonwiki.skp_1_mpd 2.72ms -> 2.51ms 0.92x > desk_gws.skp_1_mpd 2.14ms -> 1.98ms 0.92x > desk_googlehome.skp_1 563us -> 517us 0.92x > desk_espn.skp_1 4.24ms -> 3.89ms 0.92x > tabl_culturalsolutions.skp_1 12.7ms -> 11.6ms 0.91x > desk_sfgate.skp_1_mpd 1.91ms -> 1.74ms 0.91x > tabl_hsfi.skp_1 1.06ms -> 966us 0.91x > desk_samoasvg.skp_1_mpd 10.5ms -> 9.47ms 0.91x > desk_facebook.skp_1_mpd 3.8ms -> 3.43ms 0.9x > desk_youtube.skp_1 3.52ms -> 3.14ms 0.89x > desk_ebay.skp_1_mpd 2.95ms -> 2.62ms 0.89x > desk_samoasvg.skp_1 10.9ms -> 9.66ms 0.89x > desk_googlespreadsheet.skp_1_mpd 5.59ms -> 4.94ms 0.88x > desk_mapsvg.skp_1_mpd 100ms -> 87.9ms 0.88x > desk_espn.skp_1_mpd 4.7ms -> 4.12ms 0.88x > desk_wordpress.skp_1_mpd 1.92ms -> 1.68ms 0.87x > tabl_deviantart.skp_1 140ms -> 122ms 0.87x > tabl_cuteoverload.skp_1_mpd 4.41ms -> 3.83ms 0.87x > desk_tigersvg.skp_1 19.6ms -> 17ms 0.87x > tabl_googlecalendar.skp_1 4.01ms -> 3.44ms 0.86x > desk_blogger.skp_1 2.49ms -> 2.14ms 0.86x > desk_chalkboard.skp_1_mpd 52.7ms -> 45ms 0.85x > desk_weather.skp_1 2.88ms -> 2.46ms 0.85x > desk_chalkboard.skp_1 51ms -> 43.4ms 0.85x > desk_yahooanswers.skp_1 2.74ms -> 2.32ms 0.85x > desk_forecastio.skp_1_mpd 1.26ms -> 1.07ms 0.85x > tabl_androidpolice.skp_1 5.18ms -> 4.34ms 0.84x > desk_yahooanswers.skp_1_mpd 3.44ms -> 2.85ms 0.83x > tabl_cnn.skp_1_mpd 2.59ms -> 2.15ms 0.83x > desk_pinterest.skp_1 2.69ms -> 2.22ms 0.83x > tabl_hsfi.skp_1_mpd 1.6ms -> 1.32ms 0.82x > tabl_culturalsolutions.skp_1_mpd 13.8ms -> 11.3ms 0.82x > desk_twitter.skp_1_mpd 76.6ms -> 63ms 0.82x > desk_ebay.skp_1 3.11ms -> 2.51ms 0.81x > tabl_mlb.skp_1_mpd 3.17ms -> 2.53ms 0.8x > tabl_mozilla.skp_1 2.42ms -> 1.91ms 0.79x > desk_pokemonwiki.skp_1 2.84ms -> 2.22ms 0.78x > desk_carsvg.skp_1_mpd 23.3ms -> 17.8ms 0.77x > desk_wowwiki.skp_1 4.21ms -> 3.21ms 0.76x > desk_amazon.skp_1 963us -> 728us 0.76x > desk_css3gradients.skp_1 2.58ms -> 1.92ms 0.74x > tabl_cuteoverload.skp_1 4.55ms -> 3.38ms 0.74x > tabl_cnn.skp_1 3.13ms -> 2.29ms 0.73x > tabl_googleblog.skp_1_mpd 2.32ms -> 1.7ms 0.73x > desk_mobilenews.skp_1 3.65ms -> 2.61ms 0.71x > desk_googleplus.skp_1 3.76ms -> 2.66ms 0.71x > tabl_mozilla.skp_1_mpd 2.88ms -> 2.03ms 0.71x > desk_pinterest.skp_1_mpd 3.17ms -> 2.21ms 0.7x > desk_css3gradients.skp_1_mpd 2.98ms -> 2.07ms 0.69x > desk_silkfinance.skp_1 2.06ms -> 1.42ms 0.69x > desk_facebook.skp_1 4.5ms -> 3.07ms 0.68x > desk_mobilenews.skp_1_mpd 4.05ms -> 2.73ms 0.68x > desk_baidu.skp_1_mpd 2.73ms -> 1.81ms 0.66x > desk_weather.skp_1_mpd 3.93ms -> 2.5ms 0.64x > desk_wordpress.skp_1 2.15ms -> 1.36ms 0.63x > desk_googlehome.skp_1_mpd 1.02ms -> 605us 0.59x > desk_fontwipe.skp_1 722us -> 402us 0.56x > desk_fontwipe.skp_1_mpd 897us -> 486us 0.54x > desk_baidu.skp_1 3.02ms -> 1.6ms 0.53x > desk_forecastio.skp_1 2.01ms -> 999us 0.5x > desk_amazon.skp_1_mpd 1.77ms -> 860us 0.49x > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/7e225bdb1f00ae4aed524ff8d0a61df3d3abb109 TBR=reed@google.com,robertphillips@google.com,scroggo@google.com,mtklein@chromium.org NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/759753004
* nanobench: lazily decode bitmaps in .skps.Gravatar mtklein2014-11-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This cuts down on tool overhead when running something like recording only, $ out/Release/nanobench --match skp --config nonrendering which doesn't usually ever need to decode the images. The actual measurements for recording don't change, as the decode is not in the timed section. It just skips irrelevant code, removing it from the profile and making the tool run faster. This does, however, make a significant difference for playback speed. Most skps draw faster with this patch, some slower. I don't really have a good intuition for what's going on here. There is a fixed clip acting as a viewport, so there are probably lots of images that don't ever need to be decoded. Ideas? Is this perhaps because we're now blitting from smaller, partially decoded source images? ~/skia (clean) $ compare clean.log lazy-decode-bitmaps.log tabl_slashdot.skp_1 2.76ms -> 4.33ms 1.57x tabl_slashdot.skp_1_mpd 2.79ms -> 4.07ms 1.46x tabl_sahadan.skp_1 3.41ms -> 4.87ms 1.43x tabl_googleblog.skp_1 1.52ms -> 2.05ms 1.35x tabl_techmeme.skp_1_mpd 1.14ms -> 1.51ms 1.32x tabl_transformice.skp_1 2.61ms -> 3.43ms 1.31x tabl_sahadan.skp_1_mpd 3.54ms -> 4.48ms 1.26x tabl_techmeme.skp_1 1.01ms -> 1.27ms 1.26x tabl_nytimes.skp_1_mpd 1ms -> 1.23ms 1.23x tabl_worldjournal.skp_1_mpd 1.98ms -> 2.43ms 1.23x tabl_pravda.skp_1_mpd 2.05ms -> 2.51ms 1.22x tabl_transformice.skp_1_mpd 2.75ms -> 3.19ms 1.16x tabl_nytimes.skp_1 874us -> 1.01ms 1.15x tabl_pravda.skp_1 1.83ms -> 1.99ms 1.09x tabl_worldjournal.skp_1 1.76ms -> 1.91ms 1.09x desk_wowwiki.skp_1_mpd 3.7ms -> 3.9ms 1.05x tabl_digg.skp_1 3.99ms -> 4.16ms 1.04x tabl_ukwsj.skp_1_mpd 3ms -> 3.12ms 1.04x desk_booking.skp_1 3.74ms -> 3.81ms 1.02x desk_googlespreadsheetdashed.skp_1 10.6ms -> 10.6ms 1x tabl_ukwsj.skp_1 2.88ms -> 2.89ms 1x desk_googlespreadsheetdashed.skp_1_mpd 11.8ms -> 11.8ms 1x desk_jsfiddlehumperclip.skp_1_mpd 891us -> 888us 1x desk_googlespreadsheet.skp_1 4.65ms -> 4.62ms 0.99x tabl_gspro.skp_1_mpd 1.97ms -> 1.94ms 0.99x desk_booking.skp_1_mpd 4.1ms -> 4ms 0.98x desk_carsvg.skp_1 18.2ms -> 17.7ms 0.97x desk_gmailthread.skp_1_mpd 2.81ms -> 2.73ms 0.97x desk_tigersvg.skp_1_mpd 19.5ms -> 18.9ms 0.97x desk_mapsvg.skp_1 88.4ms -> 85.6ms 0.97x tabl_cnet.skp_1_mpd 1.43ms -> 1.38ms 0.97x desk_jsfiddlebigcar.skp_1 1.26ms -> 1.22ms 0.96x desk_gws.skp_1 1.87ms -> 1.8ms 0.96x desk_linkedin.skp_1 2.07ms -> 1.98ms 0.96x tabl_deviantart.skp_1_mpd 118ms -> 113ms 0.96x tabl_cnet.skp_1 1.2ms -> 1.14ms 0.95x tabl_androidpolice.skp_1_mpd 5.95ms -> 5.63ms 0.95x desk_sfgate.skp_1 1.75ms -> 1.64ms 0.94x desk_twitter.skp_1 74ms -> 69.6ms 0.94x desk_youtube.skp_1_mpd 3.17ms -> 2.96ms 0.93x desk_gmailthread.skp_1 2.73ms -> 2.54ms 0.93x desk_silkfinance.skp_1_mpd 1.71ms -> 1.59ms 0.93x desk_jsfiddlebigcar.skp_1_mpd 1.45ms -> 1.35ms 0.93x desk_pokemonwiki.skp_1_mpd 2.72ms -> 2.51ms 0.92x desk_gws.skp_1_mpd 2.14ms -> 1.98ms 0.92x desk_googlehome.skp_1 563us -> 517us 0.92x desk_espn.skp_1 4.24ms -> 3.89ms 0.92x tabl_culturalsolutions.skp_1 12.7ms -> 11.6ms 0.91x desk_sfgate.skp_1_mpd 1.91ms -> 1.74ms 0.91x tabl_hsfi.skp_1 1.06ms -> 966us 0.91x desk_samoasvg.skp_1_mpd 10.5ms -> 9.47ms 0.91x desk_facebook.skp_1_mpd 3.8ms -> 3.43ms 0.9x desk_youtube.skp_1 3.52ms -> 3.14ms 0.89x desk_ebay.skp_1_mpd 2.95ms -> 2.62ms 0.89x desk_samoasvg.skp_1 10.9ms -> 9.66ms 0.89x desk_googlespreadsheet.skp_1_mpd 5.59ms -> 4.94ms 0.88x desk_mapsvg.skp_1_mpd 100ms -> 87.9ms 0.88x desk_espn.skp_1_mpd 4.7ms -> 4.12ms 0.88x desk_wordpress.skp_1_mpd 1.92ms -> 1.68ms 0.87x tabl_deviantart.skp_1 140ms -> 122ms 0.87x tabl_cuteoverload.skp_1_mpd 4.41ms -> 3.83ms 0.87x desk_tigersvg.skp_1 19.6ms -> 17ms 0.87x tabl_googlecalendar.skp_1 4.01ms -> 3.44ms 0.86x desk_blogger.skp_1 2.49ms -> 2.14ms 0.86x desk_chalkboard.skp_1_mpd 52.7ms -> 45ms 0.85x desk_weather.skp_1 2.88ms -> 2.46ms 0.85x desk_chalkboard.skp_1 51ms -> 43.4ms 0.85x desk_yahooanswers.skp_1 2.74ms -> 2.32ms 0.85x desk_forecastio.skp_1_mpd 1.26ms -> 1.07ms 0.85x tabl_androidpolice.skp_1 5.18ms -> 4.34ms 0.84x desk_yahooanswers.skp_1_mpd 3.44ms -> 2.85ms 0.83x tabl_cnn.skp_1_mpd 2.59ms -> 2.15ms 0.83x desk_pinterest.skp_1 2.69ms -> 2.22ms 0.83x tabl_hsfi.skp_1_mpd 1.6ms -> 1.32ms 0.82x tabl_culturalsolutions.skp_1_mpd 13.8ms -> 11.3ms 0.82x desk_twitter.skp_1_mpd 76.6ms -> 63ms 0.82x desk_ebay.skp_1 3.11ms -> 2.51ms 0.81x tabl_mlb.skp_1_mpd 3.17ms -> 2.53ms 0.8x tabl_mozilla.skp_1 2.42ms -> 1.91ms 0.79x desk_pokemonwiki.skp_1 2.84ms -> 2.22ms 0.78x desk_carsvg.skp_1_mpd 23.3ms -> 17.8ms 0.77x desk_wowwiki.skp_1 4.21ms -> 3.21ms 0.76x desk_amazon.skp_1 963us -> 728us 0.76x desk_css3gradients.skp_1 2.58ms -> 1.92ms 0.74x tabl_cuteoverload.skp_1 4.55ms -> 3.38ms 0.74x tabl_cnn.skp_1 3.13ms -> 2.29ms 0.73x tabl_googleblog.skp_1_mpd 2.32ms -> 1.7ms 0.73x desk_mobilenews.skp_1 3.65ms -> 2.61ms 0.71x desk_googleplus.skp_1 3.76ms -> 2.66ms 0.71x tabl_mozilla.skp_1_mpd 2.88ms -> 2.03ms 0.71x desk_pinterest.skp_1_mpd 3.17ms -> 2.21ms 0.7x desk_css3gradients.skp_1_mpd 2.98ms -> 2.07ms 0.69x desk_silkfinance.skp_1 2.06ms -> 1.42ms 0.69x desk_facebook.skp_1 4.5ms -> 3.07ms 0.68x desk_mobilenews.skp_1_mpd 4.05ms -> 2.73ms 0.68x desk_baidu.skp_1_mpd 2.73ms -> 1.81ms 0.66x desk_weather.skp_1_mpd 3.93ms -> 2.5ms 0.64x desk_wordpress.skp_1 2.15ms -> 1.36ms 0.63x desk_googlehome.skp_1_mpd 1.02ms -> 605us 0.59x desk_fontwipe.skp_1 722us -> 402us 0.56x desk_fontwipe.skp_1_mpd 897us -> 486us 0.54x desk_baidu.skp_1 3.02ms -> 1.6ms 0.53x desk_forecastio.skp_1 2.01ms -> 999us 0.5x desk_amazon.skp_1_mpd 1.77ms -> 860us 0.49x BUG=skia: Review URL: https://codereview.chromium.org/743613005
* Add MultiPictureDraw to nanobenchGravatar robertphillips2014-11-21
| | | | | | | | | | I would like some guard against performance regressions on our side before turning layer hoisting on in Chromium. TBR=bsalomon@google.com Committed: https://skia.googlesource.com/skia/+/0ddad31012dabfc1267effc8071d37f7d606efbe Review URL: https://codereview.chromium.org/731973005
* Revert of Add MultiPictureDraw to nanobench (patchset #7 id:120001 of ↵Gravatar robertphillips2014-11-21
| | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/731973005/) Reason for revert: Needs more work Original issue's description: > Add MultiPictureDraw to nanobench > > I would like some guard against performance regressions on our side before turning layer hoisting on in Chromium. > > TBR=bsalomon@google.com > > Committed: https://skia.googlesource.com/skia/+/0ddad31012dabfc1267effc8071d37f7d606efbe TBR=mtklein@google.com,bsalomon@google.com NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/750583002
* Add MultiPictureDraw to nanobenchGravatar robertphillips2014-11-21
| | | | | | | | I would like some guard against performance regressions on our side before turning layer hoisting on in Chromium. TBR=bsalomon@google.com Review URL: https://codereview.chromium.org/731973005
* Revert of Make nanobench and dm be usable from Chromium build (patchset #5 ↵Gravatar jcgregorio2014-11-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | id:80001 of https://codereview.chromium.org/657373002/) Reason for revert: Causing breakages on Mac build. Original issue's description: > Make nanobench and dm be usable from Chromium build > > Move the app logic for each app as follows: > > <app>.cpp -- the file which contains main(). Embedders that compile > their own apps, such as ios shell, upcoming Chromium dm etc, do not use this. > > <app>_main.cpp -- the main logic of the Skia test application. This will be > used by Skia -compiled apps as well as embedder -compiled apps. > > <app>_main.h -- the API for the main logic. This will be > used by Skia -compiled apps as well as embedder -compiled apps. > > This way (the upcoming) Chromium dm can setup its Chromium-specific setup > in custom main(), and then call dm_main(), without the need of any > SK_BUILD_FOR_XXXX defines controlling whether the tool defines main or not. > > BUG=skia:2992 > > Committed: https://skia.googlesource.com/skia/+/c092d3bdab5f723576cc0346cea3ee282a9cb444 TBR=mtklein@chromium.org,mtklein@google.com,borenet@google.com,kkinnunen@nvidia.com NOTREECHECKS=true NOTRY=true BUG=skia:2992 Review URL: https://codereview.chromium.org/724073002
* Make nanobench and dm be usable from Chromium buildGravatar kkinnunen2014-11-13
| | | | | | | | | | | | | | | | | | | | | Move the app logic for each app as follows: <app>.cpp -- the file which contains main(). Embedders that compile their own apps, such as ios shell, upcoming Chromium dm etc, do not use this. <app>_main.cpp -- the main logic of the Skia test application. This will be used by Skia -compiled apps as well as embedder -compiled apps. <app>_main.h -- the API for the main logic. This will be used by Skia -compiled apps as well as embedder -compiled apps. This way (the upcoming) Chromium dm can setup its Chromium-specific setup in custom main(), and then call dm_main(), without the need of any SK_BUILD_FOR_XXXX defines controlling whether the tool defines main or not. BUG=skia:2992 Review URL: https://codereview.chromium.org/657373002
* Get gpudft support working in dm, gm, nanobench and bench_picturesGravatar jvanverth2014-11-07
| | | | | | | | | | | | Adds a new config to test distance field text. Clean up some flags and #defines to read "distance field text", not "distance field fonts" to be consistent with Chromium NOTREECHECKS=true Committed: https://skia.googlesource.com/skia/+/06ba179838ba4fe187cf290750aeeb4a02a2960b Review URL: https://codereview.chromium.org/699453005
* Revert of Get gpudft support working in dm, gm, nanobench and bench_pictures ↵Gravatar jvanverth2014-11-06
| | | | | | | | | | | | | | | | | | | | | | | | (patchset #2 id:20001 of https://codereview.chromium.org/699453005/) Reason for revert: Not compiling in ANGLE build Original issue's description: > Get gpudft support working in dm, gm, nanobench and bench_pictures > > Adds a new config to test distance field text. > Clean up some flags and #defines to read "distance field text", > not "distance field fonts" to be consistent with Chromium > > NOTREECHECKS=true > > Committed: https://skia.googlesource.com/skia/+/06ba179838ba4fe187cf290750aeeb4a02a2960b TBR=bsalomon@google.com,mtklein@google.com,reed@google.com NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/707723005
* Get gpudft support working in dm, gm, nanobench and bench_picturesGravatar jvanverth2014-11-06
| | | | | | | | | | Adds a new config to test distance field text. Clean up some flags and #defines to read "distance field text", not "distance field fonts" to be consistent with Chromium NOTREECHECKS=true Review URL: https://codereview.chromium.org/699453005
* Detect loops overflow for gpu benches.Gravatar mtklein2014-11-06
| | | | | | | | NOTREECHECKS=true BUG=skia: Review URL: https://codereview.chromium.org/709473002
* Try out SkTree in nanobench.Gravatar mtklein2014-10-29
| | | | | | | | Looks like a fairly large recording speed win with no playback cost. BUG=skia: Review URL: https://codereview.chromium.org/653023003
* Print GPU cache stats in nanobench/dm with veryVerboseGravatar bsalomon2014-10-24
| | | | Review URL: https://codereview.chromium.org/680553002
* Draw SKPs in 256x256 tiles in nanobench.Gravatar mtklein2014-10-21
| | | | | | | | (This CL will certainly trigger performance regression alerts. Tiled drawing is slower than non-tiled drawing.) BUG=skia: Review URL: https://codereview.chromium.org/669983002
* nanobench: flush after recording every Nth data point.Gravatar mtklein2014-10-14
| | | | | | | | | | Got to keep our precious data in event of a crash. With --flushEvery 10 I'm not seeing this cost any wall time. BUG=skia: Review URL: https://codereview.chromium.org/653083003
* detect --loops is < 0 and interpret that as running forever (mostly)Gravatar reed2014-10-10
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/643143002
* Make the Sk GL context class an abstract base classGravatar kkinnunen2014-10-09
| | | | | | | | | | | | | | | | | | | | | | | Make the Sk GL context class, SkGLNativeContext, an abstract base class. Before, it depended on ifdefs to implement the platform dependent polymorphism. Move the logic to subclasses of the various platform implementations. This a step to enable Skia embedders to compile dm and bench_pictures. The concrete goal is to support running these test apps with Chromium command buffer. With this change, Chromium can implement its own version of SkGLNativeContext that uses command buffer, and host the implementation in its own repository. Implements the above by renaming the SkGLContextHelper to SkGLContext and removing the unneeded SkGLNativeContext. Also removes SkGLNativeContext::AutoRestoreContext functionality, it appeared to be unused: no use in Skia code, and no tests. BUG=skia:2992 Committed: https://skia.googlesource.com/skia/+/a90ed4e83897b45d6331ee4c54e1edd4054de9a8 Review URL: https://codereview.chromium.org/630843002
* Revert of Make the Sk GL context class an abstract base class (patchset #4 ↵Gravatar bsalomon2014-10-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | id:60001 of https://codereview.chromium.org/630843002/) Reason for revert: nanobech failing on Android Original issue's description: > Make the Sk GL context class an abstract base class > > Make the Sk GL context class, SkGLNativeContext, an abstract base class. Before, > it depended on ifdefs to implement the platform dependent polymorphism. Move > the logic to subclasses of the various platform implementations. > > This a step to enable Skia embedders to compile dm and bench_pictures. The > concrete goal is to support running these test apps with Chromium command buffer. > > With this change, Chromium can implement its own version of SkGLNativeContext > that uses command buffer, and host the implementation in its own repository. > > Implements the above by renaming the SkGLContextHelper to SkGLContext and > removing the unneeded SkGLNativeContext. Also removes > SkGLNativeContext::AutoRestoreContext functionality, it appeared to be unused: > no use in Skia code, and no tests. > > BUG=skia:2992 > > Committed: https://skia.googlesource.com/skia/+/a90ed4e83897b45d6331ee4c54e1edd4054de9a8 TBR=kkinnunen@nvidia.com NOTREECHECKS=true NOTRY=true BUG=skia:2992 Review URL: https://codereview.chromium.org/639793002
* Make the Sk GL context class an abstract base classGravatar kkinnunen2014-10-08
| | | | | | | | | | | | | | | | | | | | | Make the Sk GL context class, SkGLNativeContext, an abstract base class. Before, it depended on ifdefs to implement the platform dependent polymorphism. Move the logic to subclasses of the various platform implementations. This a step to enable Skia embedders to compile dm and bench_pictures. The concrete goal is to support running these test apps with Chromium command buffer. With this change, Chromium can implement its own version of SkGLNativeContext that uses command buffer, and host the implementation in its own repository. Implements the above by renaming the SkGLContextHelper to SkGLContext and removing the unneeded SkGLNativeContext. Also removes SkGLNativeContext::AutoRestoreContext functionality, it appeared to be unused: no use in Skia code, and no tests. BUG=skia:2992 Review URL: https://codereview.chromium.org/630843002
* Have nanobench --verbose mode always just print integer nanoseconds.Gravatar mtklein2014-09-24
| | | | | | | | | | | | | Don't know that anyone but me is using this. Speak up now! BUG=skia: NOTREECHECKS=true R=mtklein@google.com, tfarina@chromium.org Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/599913002
* nanobench: print max RSS in debug mode too.Gravatar mtklein2014-09-18
| | | | | | | | | BUG=skia:2949 R=mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/581083002
* Revert of nanobench: lazily decode bitmaps from SKPs (patchset #1 id:1 of ↵Gravatar mtklein2014-09-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/572933006/) Reason for revert: skia:2944 Original issue's description: > nanobench: lazily decode bitmaps from SKPs > > This makes it considerably cheaper to run SKP recording benchmarks, without > affecting their measurements and without really affecting SKP playback > benchmarks at all. > > On my machine, running out/Release/nanobench --match skp --config nondrendering > drops in run time from 6.7s to 2.5s, and the peak RAM usage drops from 129M to 50M. > > I'm strongly considering making this lazy decoding the default. > > BUG=skia:2944 > > Committed: https://skia.googlesource.com/skia/+/d664c21a38de98d8db210c46f7a8c4187f1534da R=robertphillips@google.com, mtklein@chromium.org TBR=mtklein@chromium.org, robertphillips@google.com NOTREECHECKS=true NOTRY=true BUG=skia:2944 Author: mtklein@google.com Review URL: https://codereview.chromium.org/554583004
* nanobench: lazily decode bitmaps from SKPsGravatar mtklein2014-09-16
| | | | | | | | | | | | | | | | | | This makes it considerably cheaper to run SKP recording benchmarks, without affecting their measurements and without really affecting SKP playback benchmarks at all. On my machine, running out/Release/nanobench --match skp --config nondrendering drops in run time from 6.7s to 2.5s, and the peak RAM usage drops from 129M to 50M. I'm strongly considering making this lazy decoding the default. BUG=skia: R=robertphillips@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/572933006
* Measure picture recording speed in nanobench.Gravatar mtklein2014-09-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Today we measure SkPicture playback speed, but not the time it takes to record the SkPicture. This fixes that by reading SKPs from disk and re-recording them. On the console, recording shows up first as the nonrendering skp benches, followed later by the usual playback benches: maxrss loops min median mean max stddev samples config bench 51M 2 165µs 168µs 169µs 178µs 3% ▆▄▃█▂▄▁▂▁▁ nonrendering tabl_slashdot.skp 57M 1 9.72ms 9.77ms 9.79ms 9.97ms 1% █▂▂▅▃▂▁▄▂▁ nonrendering desk_pokemonwiki.skp 57M 32 2.92µs 2.96µs 3.03µs 3.46µs 6% ▅▁▁▁▁▁▁█▂▁ nonrendering desk_yahoosports.skp ... 147M 1 3.86ms 3.87ms 3.97ms 4.81ms 7% █▁▁▁▁▁▁▁▁▁ 8888 tabl_slashdot.skp_1 147M 1 4.54ms 4.56ms 4.55ms 4.56ms 0% █▅▇▅█▅▂▁▅▁ 565 tabl_slashdot.skp_1 147M 2 3.08ms 3.24ms 4.17ms 8.18ms 50% █▁▁█▁▁▁▁▁▁ gpu tabl_slashdot.skp_1 147M 1 1.61ms 1.62ms 1.69ms 2.33ms 13% █▁▁▁▁▁▁▁▁▁ 8888 desk_pokemonwiki.skp_1 147M 1 1.44ms 1.44ms 1.45ms 1.47ms 1% ▅▂█▂▂▅▁▁▂▁ 565 desk_pokemonwiki.skp_1 ... On skiaperf.com, they'll also be separated out from playback benches by bench_type. BUG=skia: R=reed@google.com, mtklein@google.com, jcgregorio@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/559153002
* Distinguish common and unique names for skiaperf.com.Gravatar mtklein2014-09-10
| | | | | | | | | | | | Turns out we tack on the size post-facto in ResultsWriter::bench(), so the only place we need getUniqueName() to differ from getName() is SKPBench. BUG=skia: R=jcgregorio@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/552303004
* Fix format of nanobench resultGravatar qiankun.miao2014-09-09
| | | | | | | | | | | | | Column of samples is too wide. This makes config is not align with the 'config' title. Pad 'samples' tilte with some whitespaces to fix this issue. BUG=skia: R=mtklein@google.com Author: qiankun.miao@intel.com Review URL: https://codereview.chromium.org/549153005
* Update DM JSON format.Gravatar mtklein2014-09-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ex. dm --match patch -w bad --key arch x86 gpu nvidia model z620 --properties git_hash abcd build_number 20 -> { "build_number" : "20", "git_hash" : "abcd", "key" : { "arch" : "x86", "gpu" : "nvidia", "model" : "z620" }, "results" : [ { "key" : { "config" : "565", "name" : "ninepatch-stretch" }, "md5" : "f78cfafcbabaf815f3dfcf61fb59acc7", "options" : { "source_type" : "GM" } }, { "key" : { "config" : "8888", "name" : "ninepatch-stretch" }, "md5" : "3e8a42f35a1e76f00caa191e6310d789", "options" : { "source_type" : "GM" } }, ... This breaks -r, but that's okay. Going to follow up this CL with one that removes that entirely. BUG=skia: R=stephana@google.com, jcgregorio@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/551873003
* "NULL !=" = NULLGravatar bsalomon2014-09-05
| | | | | | | | R=reed@google.com Author: bsalomon@google.com Review URL: https://codereview.chromium.org/544233002
* Change SkPicture::draw to playbackGravatar robertphillips2014-09-04
| | | | | | | | R=reed@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/540963002
* Hide fields in SkImageInfoGravatar reed2014-09-03
| | | | | | | | | R=rmistry@google.com TBR=bsalomon Author: reed@google.com Review URL: https://codereview.chromium.org/536003002
* Try out scalar picture sizesGravatar robertphillips2014-08-29
| | | | | | | | | | This paves the way for removing the 'fTile' parameter from SkPictureShader (although that should be a different CL). If we like this we could also move to providing an entire cull SkRect. R=reed@google.com, mtklein@google.com, fmalita@google.com, fmalita@chromium.org Author: robertphillips@google.com Review URL: https://codereview.chromium.org/513983002
* fix numerical overflows in 565 blendsGravatar reed2014-08-22
| | | | | | | | | BUG=skia:2797 R=mtklein@google.com Author: reed@google.com Review URL: https://codereview.chromium.org/474983007
* Add --bbh (default true) to nanobench.Gravatar mtklein2014-08-21
| | | | | | | | | | | | | | | | | | | | | | | | | Chrome's using a bounding box, so it's a good idea for our bots to do so too. When set, we'll create an SkTileGrid to match the parameters of --clip, and so should always hit its fast path. This will impose a small overhead (querying the BBH) on all SKPs, but make large SKPs render more quickly. E.g. on GPU desk_pokemonwiki should show about a 30% improvement, tabl_mozilla about 40%, and one very long page from my personal suite, askmefast.com, gets 5x faster. (The performance changes are not the point of the CL, but something we should be aware of.) BUG= R=bsalomon@google.com, mtklein@google.com, robertphillips@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/497493003
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-06 21:17:00 +0000