| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
DOCS_PREVIEW= https://skia.org/?cl=1316233002
Review URL: https://codereview.chromium.org/1316233002
|
| |
|
|
|
|
| |
DOCS_PREVIEW= https://skia.org/?cl=1316123003
Review URL: https://codereview.chromium.org/1316123003
|
| |
|
|
|
|
|
|
|
| |
See here for a similar change in Ninja. Wanna bet they just got Z840s too?
https://github.com/martine/ninja/commit/8c8834acffdc0da0d94119725929acc712c9dfad
BUG=skia:
Review URL: https://codereview.chromium.org/1213063011
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should be a drop-in replacement for most for-loops to make them run in parallel:
for (int i = 0; i < N; i++) { code... }
~~~>
sk_parallel_for(N, [&](int i) { code... });
This is just syntax sugar over SkTaskGroup to make this use case really easy to write.
There's no more overhead that we weren't already forced to add using an interface like batch(),
and no extra heap allocations.
I've replaced 3 uses of SkTaskGroup with sk_parallel_for:
1) My unit tests for SkOnce.
2) Cary's path fuzzer.
3) SkMultiPictureDraw.
Performance should be the same. Please compare left and right for readability. :)
BUG=skia:
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1184373003
|
| |
|
|
|
|
|
|
|
|
|
| |
This allows a faster implementation of our SkTaskGroup thread pool.
It also means we don't need SkCondVar (which, remember, isn't supported on XP.)
Doing some testing with SampleApp, this really cuts down on the overhead from SkTaskGroup, e.g. 30% to 10%.
BUG=skia:
Review URL: https://codereview.chromium.org/1192573003
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Use SkAtomic<int32_t> for pending work count so we're statically
forced to operate on it with atomic methods.
- Replacing old methods like sk_atomic_inc/dec gives us finer control
over which barriers we need for each operation.
No public API changes.
TBR=reed@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/1193493003
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Tested by running DM on XP. Before this patch, it fails at startup (even just out/Debug/dm --help). Now it asserts for other reasons later on in user code, which is just fine by me.
The net effect is that SkTaskGroups will always be synchronous on XP. That's not ideal, but a step up from crashing.
CQ_EXTRA_TRYBOTS=client.skia:Test-Win7-ShuttleA-HD2000-x86-Release-Trybot,Test-Win7-ShuttleA-HD2000-x86_64-Release-Trybot
BUG=skia:
Review URL: https://codereview.chromium.org/700683002
|
| |
|
|
|
|
|
|
| |
Porting QuiltTask isn't important in itself; this is mostly an API feeler.
BUG=skia:
Review URL: https://codereview.chromium.org/689673003
|
|
|
SampleApp is multipicturedraw aware.
BUG=skia:
Review URL: https://codereview.chromium.org/684923002
|
halcanary
mtklein
reed