aboutsummaryrefslogtreecommitdiffhomepage
path: root/dm/DMQuiltTask.cpp
Commit message (Collapse)AuthorAge
* Don't test the old picture backend anymore.Gravatar mtklein2014-09-29
| | | | | | | | | | | This saves a bunch of CPU time in DM, and even better, lets us tear it down! BUG=skia: R=robertphillips@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/612603002
* 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
* Change SkPicture::draw to playbackGravatar robertphillips2014-09-04
| | | | | | | | R=reed@google.com Author: robertphillips@google.com Review URL: https://codereview.chromium.org/540963002
* SkThreadPool ~~> SkTaskGroupGravatar mtklein2014-09-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SkTaskGroup is like SkThreadPool except the threads stay in one global pool. Each SkTaskGroup itself is tiny (4 bytes) and its wait() method applies only to tasks add()ed to that instance, not the whole thread pool. This means we don't need to bring up new thread pools when tests themselves want to use multithreading (e.g. pathops, quilt). We just create a new SkTaskGroup and wait for that to complete. This should be more efficient, and allow us to expand where we use threads to really latency sensitive places. E.g. we can probably now use these in nanobench for CPU .skp rendering. Now that all threads are sharing the same pool, I think we can remove most of the custom mechanism pathops tests use to control threading. They'll just ride on the global pool with all other tests now. This (temporarily?) removes the GPU multithreading feature from DM, which we don't use. On my desktop, DM runs a little faster (57s -> 55s) in Debug, and a lot faster in Release (36s -> 24s). The bots show speedups of similar proportions, cutting more than a minute off the N4/Release and Win7/Debug runtimes. BUG=skia: Committed: https://skia.googlesource.com/skia/+/9c7207b5dc71dc5a96a2eb107d401133333d5b6f R=caryclark@google.com, bsalomon@google.com, bungeman@google.com, mtklein@google.com, reed@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/531653002
* Revert of SkThreadPool ~~> SkTaskGroup (patchset #4 id:60001 of ↵Gravatar mtklein2014-09-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/531653002/) Reason for revert: Leaks, leaks, leaks. Original issue's description: > SkThreadPool ~~> SkTaskGroup > > SkTaskGroup is like SkThreadPool except the threads stay in > one global pool. Each SkTaskGroup itself is tiny (4 bytes) > and its wait() method applies only to tasks add()ed to that > instance, not the whole thread pool. > > This means we don't need to bring up new thread pools when > tests themselves want to use multithreading (e.g. pathops, > quilt). We just create a new SkTaskGroup and wait for that > to complete. This should be more efficient, and allow us > to expand where we use threads to really latency sensitive > places. E.g. we can probably now use these in nanobench > for CPU .skp rendering. > > Now that all threads are sharing the same pool, I think we > can remove most of the custom mechanism pathops tests use > to control threading. They'll just ride on the global pool > with all other tests now. > > This (temporarily?) removes the GPU multithreading feature > from DM, which we don't use. > > On my desktop, DM runs a little faster (57s -> 55s) in > Debug, and a lot faster in Release (36s -> 24s). The bots > show speedups of similar proportions, cutting more than a > minute off the N4/Release and Win7/Debug runtimes. > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/9c7207b5dc71dc5a96a2eb107d401133333d5b6f R=caryclark@google.com, bsalomon@google.com, bungeman@google.com, reed@google.com, mtklein@chromium.org TBR=bsalomon@google.com, bungeman@google.com, caryclark@google.com, mtklein@chromium.org, reed@google.com NOTREECHECKS=true NOTRY=true BUG=skia: Author: mtklein@google.com Review URL: https://codereview.chromium.org/533393002
* SkThreadPool ~~> SkTaskGroupGravatar mtklein2014-09-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SkTaskGroup is like SkThreadPool except the threads stay in one global pool. Each SkTaskGroup itself is tiny (4 bytes) and its wait() method applies only to tasks add()ed to that instance, not the whole thread pool. This means we don't need to bring up new thread pools when tests themselves want to use multithreading (e.g. pathops, quilt). We just create a new SkTaskGroup and wait for that to complete. This should be more efficient, and allow us to expand where we use threads to really latency sensitive places. E.g. we can probably now use these in nanobench for CPU .skp rendering. Now that all threads are sharing the same pool, I think we can remove most of the custom mechanism pathops tests use to control threading. They'll just ride on the global pool with all other tests now. This (temporarily?) removes the GPU multithreading feature from DM, which we don't use. On my desktop, DM runs a little faster (57s -> 55s) in Debug, and a lot faster in Release (36s -> 24s). The bots show speedups of similar proportions, cutting more than a minute off the N4/Release and Win7/Debug runtimes. BUG=skia: R=caryclark@google.com, bsalomon@google.com, bungeman@google.com, mtklein@google.com, reed@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/531653002
* Remove SkQuadTree.Gravatar mtklein2014-08-26
| | | | | | | | | | | | | | We're not testing it to the same degree we do RTree and TileGrid. Any changes we'll make to BBH APIs become 33% easier without it. If find we want it again, we can always resurrect it. BUG=skia:1021,skia:2834 R=robertphillips@google.com, mtklein@google.com TBR=reed Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/500373005
* Plumbing for using a BBH in SkRecordDraw.Gravatar mtklein2014-08-11
| | | | | | | | | | | | | | | | For now this only creates a degenerate bounding box hierarchy where all ops just have maximal bounds. I will flesh out FillBounds in future CL(s). Not quite sure why QuadTree and TileGrid aren't drawing right---haven't even looked at the diffs yet---so I've disabled those test modes for now. RTree seems fine, so that'll at least get us coverage for all this new plumbing. BUG=skia: R=robertphillips@google.com, mtklein@google.com, reed@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/454123003
* Merge Replay and Quilt tasks, adding in all BBH implementations.Gravatar mtklein2014-07-09
| | | | | | | | | | | | | | | | | | | | | | | | Replay isn't that helpful of a test any more now that we have the more stringent Quilt tests. Quilt was missing bounding box hierarchies, though, while Replay was sort of testing RTree (pointlessly, as it was drawing without any clip). Now Quilt does everything, testing RTree, QuadTree, and TileGrid. Quilt mode now falls back to drawing all at once (i.e. Replay) for GMs that don't tile perfectly. Still a TODO to make this check more flexible than exact pixel matches. Two GMs fail when using a BBH: - imageresizetiled - resizeimagefilter We think we're not adjusting the bounds of save layers by their paint. This is probably a bug, but one to be fixed separately from adding new tests. BUG=skia: R=robertphillips@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/377373003
* Turn on threaded DMQuiltTask drawing for old-format SkPictures too.Gravatar mtklein2014-07-07
| | | | | | | | | | | This required the same SkBitmap copying that we added today to SkRecord. BUG=skia: R=reed@android.com, robertphillips@google.com, mtklein@google.com, reed@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/375703002
* Add always-threaded SkRecord quilt tests.Gravatar mtklein2014-07-07
| | | | | | | | | | | | | | | | | | | | | Now that we're drawing tiles threaded like implside painting, remove the checks that those lock counts are balanced. They're just not right for anyone anymore. SkBitmaps themselves are not threadsafe (even const ones), so shallow copy them on playback of an SkRecord. (The underlying SkPixelRefs are threadsafe.) Simplify quilt drawing by using SkBitmap::extractSubset. No need for locking. Bump up to 256x256 tiles. 16x16 tiles just murders performance (way too much contention). This has the nice side effect of letting us enable a bunch more GMs for quilt mode; they drew wrong with small tiles but exactly right with large. BUG=171776 R=reed@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/371023005
* Add multithreaded mode to quilt mode in DM.Gravatar mtklein2014-07-01
| | | | | | | | | | | Default off for now. Something to work toward. BUG=skia: R=robertphillips@google.com, tomhudson@chromium.org, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/360793002
* refactor DM::SetupBitmapGravatar commit-bot@chromium.org2014-05-15
| | | | | | | | | | | | | Seemed sort of repetitive. BUG=skia: R=reed@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/286993005 git-svn-id: http://skia.googlecode.com/svn/trunk@14752 2bbb7eff-a529-9590-31e7-b0007b416f81
* Turn on quilt mode in DM.Gravatar commit-bot@chromium.org2014-04-30
- Rename TileGrid -> Quilt to avoid the name overload. - Tag all failing GMs with kSkipTiled_Flag. You may be wondering, do any GMs pass? Yes, some do! And that trends towards all of them as we increase --quiltTile. Two GMs only fail in --quilt mode in 565. Otherwise all GMs which fail are skipped, and those which don't fail aren't. (The 8888 variants of those two GMs are skipped even though they pass.) BUG=skia:2477 R=reed@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/256373002 git-svn-id: http://skia.googlecode.com/svn/trunk@14457 2bbb7eff-a529-9590-31e7-b0007b416f81
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-31 00:26:21 +0000