| 39e8d93337c7e37d2b09dc710a05a9beefef5c2c |
|
29-May-2014 |
commit-bot@chromium.org <commit-bot@chromium.org@2bbb7eff-a529-9590-31e7-b0007b416f81> |
DM tweaks
- 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
/external/skia/dm/DMTask.h
|
| 3f032156c8b5d4decb0beccdc2cdbcf91867fa36 |
|
01-May-2014 |
commit-bot@chromium.org <commit-bot@chromium.org@2bbb7eff-a529-9590-31e7-b0007b416f81> |
DM: Push GPU-parent child tasks to the front of the queue.
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
/external/skia/dm/DMTask.h
|
| b0c7156d5be00509d0f80a8d223d5355122b6a3f |
|
30-Apr-2014 |
commit-bot@chromium.org <commit-bot@chromium.org@2bbb7eff-a529-9590-31e7-b0007b416f81> |
DM: run child tasks that are already on the CPU threadpool serially
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
/external/skia/dm/DMTask.h
|
| 787227d3560bd8021394b76ada2cb184ecf5c919 |
|
26-Mar-2014 |
commit-bot@chromium.org <commit-bot@chromium.org@2bbb7eff-a529-9590-31e7-b0007b416f81> |
Let DM work without a GPU.
Testing:
/m/s/skia (dm) $ d dm; and env GYP_DEFINES=skia_gpu=0 d dm
ninja: Entering directory `out/Debug'
ninja: no work to do.
(294 GMs, 620 benches) x 4 configs, 245 tests
4507 tasks leftUnsupported vertex-color/texture xfer mode.
Unsupported vertex-color/texture xfer mode.
0 tasks left
416.53user 9.86system 0:47.43elapsed 898%CPU (0avgtext+0avgdata
13353376maxresident)k
0inputs+0outputs (0major+3579906minor)pagefaults 0swaps
ninja: Entering directory `out/Debug'
[909/909] LINK dm
(287 GMs, 612 benches) x 4 configs, 227 tests
0 tasks left
365.24user 7.71system 0:14.55elapsed 2562%CPU (0avgtext+0avgdata
14718912maxresident)k
0inputs+0outputs (0major+3328269minor)pagefaults 0swaps
BUG=skia:
R=bsalomon@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/213093004
git-svn-id: http://skia.googlecode.com/svn/trunk@13960 2bbb7eff-a529-9590-31e7-b0007b416f81
/external/skia/dm/DMTask.h
|
| a39874b636f9954c6da335733fed646ba33dd614 |
|
03-Mar-2014 |
commit-bot@chromium.org <commit-bot@chromium.org@2bbb7eff-a529-9590-31e7-b0007b416f81> |
DM: tweak output.
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
/external/skia/dm/DMTask.h
|
| ef57b7e65330d5f794a513630517907500f1c1d0 |
|
28-Feb-2014 |
commit-bot@chromium.org <commit-bot@chromium.org@2bbb7eff-a529-9590-31e7-b0007b416f81> |
DM: make GPU tasks multithreaded again. Big refactor.
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
/external/skia/dm/DMTask.h
|
| 38aeb0fd7a2bdab5e44531d96045dffe25c8e2b0 |
|
27-Feb-2014 |
commit-bot@chromium.org <commit-bot@chromium.org@2bbb7eff-a529-9590-31e7-b0007b416f81> |
DM: also run benches once.
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
/external/skia/dm/DMTask.h
|
| 0dc5bd149a8b69e8dc6d3b4713b827659c9b0a6b |
|
26-Feb-2014 |
commit-bot@chromium.org <commit-bot@chromium.org@2bbb7eff-a529-9590-31e7-b0007b416f81> |
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=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
/external/skia/dm/DMTask.h
|
| 79e13260cf94427e6ccbfff8242bf85ed4c8187b |
|
25-Feb-2014 |
commit-bot@chromium.org <commit-bot@chromium.org@2bbb7eff-a529-9590-31e7-b0007b416f81> |
Revert of Let DM run unit tests. (https://codereview.chromium.org/178273002/)
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
/external/skia/dm/DMTask.h
|
| 6bd250a2a340348434b7b16bd4e4b5da0f598e3e |
|
25-Feb-2014 |
commit-bot@chromium.org <commit-bot@chromium.org@2bbb7eff-a529-9590-31e7-b0007b416f81> |
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:
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
/external/skia/dm/DMTask.h
|
| d6bab0238655dbab24dfe92bd0b16b464310a8c7 |
|
02-Dec-2013 |
rmistry@google.com <rmistry@google.com@2bbb7eff-a529-9590-31e7-b0007b416f81> |
Reverting r12427
git-svn-id: http://skia.googlecode.com/svn/trunk@12428 2bbb7eff-a529-9590-31e7-b0007b416f81
/external/skia/dm/DMTask.h
|
| 5b39f5ba9c339d1e4dae391fee9ec1396feec180 |
|
02-Dec-2013 |
skia.committer@gmail.com <skia.committer@gmail.com@2bbb7eff-a529-9590-31e7-b0007b416f81> |
Sanitizing source files in Housekeeper-Nightly
git-svn-id: http://skia.googlecode.com/svn/trunk@12427 2bbb7eff-a529-9590-31e7-b0007b416f81
/external/skia/dm/DMTask.h
|
| ca5bb87a31b8cfde73dfd7c554127ee9b3e1ab58 |
|
26-Nov-2013 |
mtklein@google.com <mtklein@google.com@2bbb7eff-a529-9590-31e7-b0007b416f81> |
DM: write failed comparison mode .pngs one more level deep in the tree.
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
/external/skia/dm/DMTask.h
|
| 1ecd9cf379312e72670e2aec313c850d422ce9c7 |
|
20-Nov-2013 |
scroggo@google.com <scroggo@google.com@2bbb7eff-a529-9590-31e7-b0007b416f81> |
Fix a warning building DM using ninja on Mac.
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
/external/skia/dm/DMTask.h
|
| d36522d12d3e71958e50683a7eef43dc2a47d96d |
|
16-Oct-2013 |
mtklein@google.com <mtklein@google.com@2bbb7eff-a529-9590-31e7-b0007b416f81> |
dm is like gm, but faster and with fewer features.
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
/external/skia/dm/DMTask.h
|