aboutsummaryrefslogtreecommitdiffhomepage
path: root/dm/DMTask.cpp
Commit message (Collapse)AuthorAge
* DM: --gpu and --cpu should only control top-level tasks.Gravatar mtklein2014-09-17
| | | | | | | | | | | | | | | | | This fixes a bug where we run some Android bots with --nocpu, and the current behavior disables the (CPU-bound) WriteTasks the GPU bound GM runs spawn off. The WriteTasks don't run and we end up with "null" in our .json files. Tested locally: out/Release/dm --nocpu -w /tmp/out; ls /tmp/out dm.json gpu/ BUG=skia:2938 R=jcgregorio@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/578033002
* 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
* Test abandoning GL context in dm/nanobench.Gravatar bsalomon2014-07-28
| | | | | | | | | | | | Rename GrContext::contextDestroyed to GrContext::abandonContext. Remove GrContext::resetContext. R=robertphillips@google.com Author: bsalomon@google.com Review URL: https://codereview.chromium.org/422903002
* share dm and command flagsGravatar caryclark2014-07-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Share command flags between dm and unit tests. Also, allow dm's core to be included by itself and iOSShell. Command line flags that are the same (or nearly the same) in DM and in skia_tests have been moved to common_flags. Authors, please check to see that the shared common flag is correct for the tool. For iOS, the 'tool_main' entry point has a wrapper to allow multiple tools to be statically linked in the iOSShell. Since SkCommandLineFlags::Parse can only be called once, these calls are disabled in the IOS build. Since the iOS app directory is dynamically assigned a name, use '@' to select it. (This is the same convention chosen by the Mobile Harness iOS file system utilities.) Move the heart of dm.gyp into dm.gypi so that it can be included by itself and iOSShell.gyp. Add tools/flags/SkCommonFlags.* to define and declare common command line flags. Add support for dm to iOSShell. BUG=skia: R=scroggo@google.com, mtklein@google.com, jvanverth@google.com, bsalomon@google.com Author: caryclark@google.com Review URL: https://codereview.chromium.org/389653004
* DM: destroy contexts after each GPU task instead of beforeGravatar Mike Klein2014-07-15
| | | | | | | | This is for consistency with bench/nanobench/GM. Haven't seen it make a difference. BUG=skia: Review URL: https://codereview.chromium.org/397743004
* Add --resetGpuContext to both DM and nanobench.Gravatar mtklein2014-07-15
| | | | | | | | | | | | | Defaulting to true to be conservative for now. BUG=skia: NOTREECHECKS=true R=mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/398483005
* add --dryRun flag to dmGravatar commit-bot@chromium.org2014-05-30
| | | | | | | | | | | BUG=2294 R=mtklein@google.com Author: humper@google.com Review URL: https://codereview.chromium.org/305963007 git-svn-id: http://skia.googlecode.com/svn/trunk@14999 2bbb7eff-a529-9590-31e7-b0007b416f81
* DM tweaksGravatar commit-bot@chromium.org2014-05-29
| | | | | | | | | | | | | | | | - Don't print status updates for skipped tasks or count them as pending tasks. - Refactor DMReporter a bit for better symmetry, be more explicit about how we read atomics (that is, approximately) in printStatus() (née finish()). - Remove mutex locking from printStatus(). BUG=skia: R=halcanary@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/309483003 git-svn-id: http://skia.googlecode.com/svn/trunk@14977 2bbb7eff-a529-9590-31e7-b0007b416f81
* DM: Push GPU-parent child tasks to the front of the queue.Gravatar commit-bot@chromium.org2014-05-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Like yesterday's change to run CPU-parent child tasks serially in thread, this reduces peak memory usage by improving the temporaly locality of the bitmaps we create. E.g. Let's say we start with tasks A B C and D Queue: [ A B C D ] Running A creates A' and A", which depend on a bitmap created by A. Queue: [ B C D A' A" * ] That bitmap now needs sit around in RAM while B C and D run pointlessly and can only be destroyed at *. If instead we do this and push dependent child tasks to the front of the queue, the queue and bitmap lifetime looks like this: Queue: [ A' A" * B C D ] This is much, much worse in practice because the queue is often several thousand tasks long. 100s of megs of bitmaps can pile up for 10s of seconds pointlessly. To make this work we add addNext() to SkThreadPool and its cousin DMTaskRunner. I also took the opportunity to swap head and tail in the threadpool implementation so it matches the comments and intuition better: we always pop the head, add() puts it at the tail, addNext() at the head. Before Debug: 49s, 1403352k peak Release: 16s, 2064008k peak After Debug: 49s, 1234788k peak Release: 15s, 1903424k peak BUG=skia:2478 R=bsalomon@google.com, borenet@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/263803003 git-svn-id: http://skia.googlecode.com/svn/trunk@14506 2bbb7eff-a529-9590-31e7-b0007b416f81
* DM: run child tasks that are already on the CPU threadpool seriallyGravatar commit-bot@chromium.org2014-04-30
| | | | | | | | | | | | | | | | | | | | | | | | | | These tasks tend to do similar things with similar sized bitmaps, so running them serially means we tend to hold 2x bitmaps at a time (golden and comparison) instead of (1+k)x bitmaps (golden and k concurrent comparisons). We still migrate GPU task's children over to the main CPU thread pool, because they'll run faster there and free up capacity on the GPU thread. Before Debug: 54s, 2.9G peak Release: 13s, 2.4G peak After Debug: 48s, 1.5G peak Release: 15s, 2.0G peak BUG=skia:2478 R=borenet@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/261593008 git-svn-id: http://skia.googlecode.com/svn/trunk@14486 2bbb7eff-a529-9590-31e7-b0007b416f81
* Make DM play nice with the plan to split CPU and GPU work.Gravatar commit-bot@chromium.org2014-03-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | --nocpu skips all CPU-bound work. --nogpu skips all GPU-bound work. /m/s/skia (dm) $ r dm --nogpu ninja: Entering directory `out/Release' [17/17] LINK dm (294 GMs, 620 benches) x 4 configs, 245 tests 0 tasks left 71.46user 12.40system 0:04.52elapsed 1854%CPU (0avgtext+0avgdata 16828656maxresident)k 0inputs+0outputs (0major+3252811minor)pagefaults 0swaps /m/s/skia (dm) $ r dm --nocpu ninja: Entering directory `out/Release' ninja: no work to do. (294 GMs, 620 benches) x 4 configs, 245 tests 926 tasks leftUnsupported vertex-color/texture xfer mode. Unsupported vertex-color/texture xfer mode. 0 tasks left 11.10user 2.38system 0:17.15elapsed 78%CPU (0avgtext+0avgdata 1310896maxresident)k 16inputs+4664outputs (0major+161322minor)pagefaults 0swaps BUG=skia:2074 R=halcanary@google.com, borenet@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/219403004 git-svn-id: http://skia.googlecode.com/svn/trunk@14001 2bbb7eff-a529-9590-31e7-b0007b416f81
* DM: tweak output.Gravatar commit-bot@chromium.org2014-03-03
| | | | | | | | | | | | | Show task name in verbose mode only, and add task runtime. BUG=skia: R=reed@google.com, bsalomon@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/185233004 git-svn-id: http://skia.googlecode.com/svn/trunk@13639 2bbb7eff-a529-9590-31e7-b0007b416f81
* DM: make GPU tasks multithreaded again. Big refactor.Gravatar commit-bot@chromium.org2014-02-28
| | | | | | | | | | | | | | | | | | | | | | The main meat of things is in SkThreadPool. We can now give SkThreadPool a type for each thread to create and destroy on its local stack. It's TLS without going through SkTLS. I've split the DM tasks into CpuTasks that run on threads with no TLS, and GpuTasks that run on threads with a thread local GrContextFactory. The old CpuTask and GpuTask have been renamed to CpuGMTask and GpuGMTask. Upshot: default run of out/Debug/dm goes from ~45 seconds to ~20 seconds. BUG=skia: R=bsalomon@google.com, mtklein@google.com, reed@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/179233005 git-svn-id: http://skia.googlecode.com/svn/trunk@13632 2bbb7eff-a529-9590-31e7-b0007b416f81
* DM: also run benches once.Gravatar commit-bot@chromium.org2014-02-26
| | | | | | | | | | | | | | | | | | Also: - make GrMemoryPoolBenches threadsafe - some tweaks to various DM code - rename GM::shortName() to getName() to match benches and tests On my desktop, (289 GMs, 617 benches) x 4 configs, 227 tests takes 46s in Debug, 14s in Release. (Still minutes faster than running tests && bench && gm.) GPU singlethreading is definitely the limiting factor again; going to reexamine whether that's helpful to thread it again. BUG=skia: R=reed@google.com, bsalomon@google.com, mtklein@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/178473006 git-svn-id: http://skia.googlecode.com/svn/trunk@13603 2bbb7eff-a529-9590-31e7-b0007b416f81
* Let DM run unit tests.Gravatar commit-bot@chromium.org2014-02-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | - refactor GYPs and a few flags - make GPU tests grab a thread-local GrContextFactory when needed as we do in DM for GMs - add a few more UI features to make DM more like tests I believe this makes the program 'tests' obsolete. It should be somewhat faster to run the two sets together than running the old binaries serially: - serial: tests 20s (3m18s CPU), dm 21s (3m01s CPU) - together: 27s (6m21s CPU) Next up is to incorporate benches. I'm only planning there on a single-pass sanity check, so that won't obsolete the program 'bench' just yet. Tested: out/Debug/tests && out/Debug/dm && echo ok BUG=skia: Committed: http://code.google.com/p/skia/source/detail?r=13586 R=reed@google.com, bsalomon@google.com, mtklein@google.com, tfarina@chromium.org Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/178273002 git-svn-id: http://skia.googlecode.com/svn/trunk@13592 2bbb7eff-a529-9590-31e7-b0007b416f81
* Revert of Let DM run unit tests. (https://codereview.chromium.org/178273002/)Gravatar commit-bot@chromium.org2014-02-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reason for revert: broke tests Original issue's description: > Let DM run unit tests. > - refactor GYPs and a few flags > - make GPU tests grab a thread-local GrContextFactory when needed as we do in DM for GMs > - add a few more UI features to make DM more like tests > > I believe this makes the program 'tests' obsolete. > > It should be somewhat faster to run the two sets together than running the old binaries serially: > - serial: tests 20s (3m18s CPU), dm 21s (3m01s CPU) > - together: 27s (6m21s CPU) > > Next up is to incorporate benches. I'm only planning there on a single-pass sanity check, so that won't obsolete the program 'bench' just yet. > > Tested: out/Debug/tests && out/Debug/dm && echo ok > BUG=skia: > > Committed: http://code.google.com/p/skia/source/detail?r=13586 R=bsalomon@google.com, mtklein@google.com, tfarina@chromium.org, mtklein@chromium.org TBR=bsalomon@google.com, mtklein@chromium.org, mtklein@google.com, tfarina@chromium.org NOTREECHECKS=true NOTRY=true BUG=skia: Author: reed@google.com Review URL: https://codereview.chromium.org/179403010 git-svn-id: http://skia.googlecode.com/svn/trunk@13587 2bbb7eff-a529-9590-31e7-b0007b416f81
* Let DM run unit tests.Gravatar commit-bot@chromium.org2014-02-25
| | | | | | | | | | | | | | | | | | | | | | | | - refactor GYPs and a few flags - make GPU tests grab a thread-local GrContextFactory when needed as we do in DM for GMs - add a few more UI features to make DM more like tests I believe this makes the program 'tests' obsolete. It should be somewhat faster to run the two sets together than running the old binaries serially: - serial: tests 20s (3m18s CPU), dm 21s (3m01s CPU) - together: 27s (6m21s CPU) Next up is to incorporate benches. I'm only planning there on a single-pass sanity check, so that won't obsolete the program 'bench' just yet. Tested: out/Debug/tests && out/Debug/dm && echo ok BUG=skia: R=reed@google.com, bsalomon@google.com, mtklein@google.com, tfarina@chromium.org Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/178273002 git-svn-id: http://skia.googlecode.com/svn/trunk@13586 2bbb7eff-a529-9590-31e7-b0007b416f81
* Reverting r12427Gravatar rmistry@google.com2013-12-02
| | | | git-svn-id: http://skia.googlecode.com/svn/trunk@12428 2bbb7eff-a529-9590-31e7-b0007b416f81
* Sanitizing source files in Housekeeper-NightlyGravatar skia.committer@gmail.com2013-12-02
| | | | git-svn-id: http://skia.googlecode.com/svn/trunk@12427 2bbb7eff-a529-9590-31e7-b0007b416f81
* DM: write failed comparison mode .pngs one more level deep in the tree.Gravatar mtklein@google.com2013-11-26
| | | | | | | | | | | | | | | | | | | | | | E.g. instead of having to compare /tmp/dm/565/optimizations.png vs. /tmp/dm/replay/optimizations_565.png it's now /tmp/dm/565/optimizations.png vs. /tmp/dm/replay/565/optimizations.png This lets working with skdiff go a lot more smoothly. BUG= R=bsalomon@google.com Review URL: https://codereview.chromium.org/88773002 git-svn-id: http://skia.googlecode.com/svn/trunk@12402 2bbb7eff-a529-9590-31e7-b0007b416f81
* Fix a warning building DM using ninja on Mac.Gravatar scroggo@google.com2013-11-20
| | | | | | | | | | | | | | Here is the warning: ../../dm/DMTask.cpp: In copy constructor ‘DM::Task::Task(const DM::Task&)’: ../../dm/DMTask.cpp:17: warning: base class ‘class SkRunnable’ should be explicitly initialized in the copy constructor Also add an SK_OVERRIDE. R=mtklein@google.com Review URL: https://codereview.chromium.org/76903002 git-svn-id: http://skia.googlecode.com/svn/trunk@12317 2bbb7eff-a529-9590-31e7-b0007b416f81
* dm is like gm, but faster and with fewer features.Gravatar mtklein@google.com2013-10-16
This is sort of the near-minimal proof-of-concept skeleton. - It can run existing GMs. - It supports most configs (just not PDF). - --replay is the only "fancy" feature it currently supports Hopefully you will be disturbed by its speed. BUG= R=epoger@google.com Review URL: https://codereview.chromium.org/22839016 git-svn-id: http://skia.googlecode.com/svn/trunk@11802 2bbb7eff-a529-9590-31e7-b0007b416f81
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-27 15:17:25 +0000