The bug is spotted by the new sink. I'd expect more bugs to be revealed
and fixed using the new sink.
Bug: skia:
Change-Id: I6b0c9267079fbd6149004f0ecd55ddb179702588
Reviewed-on: https://skia-review.googlesource.com/109720
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Yuqian Li <liyuqian@google.com>
This moves DMFontMgr and several related files which are tightly related
to fonts into tools/fonts, moves some flags around to prevent
duplication, and adds the nativeFonts handling to Viewer.
Change-Id: Id1bdad708a6b74319ac5ac9adfe21025db4ca0b2
Reviewed-on: https://skia-review.googlesource.com/108904
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Bug: skia:
Change-Id: I38736c5d49e3b281c2d23af3908575274ff97b5c
Reviewed-on: https://skia-review.googlesource.com/86282
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Adds the flag and a disables caching on the CCPR bots.
Bug: skia:
Change-Id: Icb85e77f89634dda1d419dacac5b8a93340723f0
Reviewed-on: https://skia-review.googlesource.com/59740
Reviewed-by: Eric Boren <borenet@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Allows benchmarks to override GrContextOptions.
Removes the ability to use the same GrContext for all benchmarks in a config.
Change-Id: I5ab9f6e81055451ac912a66537843d1a49f3b479
Reviewed-on: https://skia-review.googlesource.com/34080
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Chrome would like to perform cpu-side preprocessing for gpu draws in parallel.
They do not want to go through a picture (since they have their own display list format).
The general idea is that we add a new SkDeferredDisplayListRecorder class to
perform all of Ganesh's cpu-side preprocessing ahead of time and in parallel.
The SkDDLRecorder operates like SkPictureRecorder. The user can get an SkCanvas
from the SkDDLRecorder and feed it draw operations. Once finished, the user
calls 'detach' to get an SkDeferredDisplayList. All the work up to and
including the 'detach' call can be done in parallel and will not touch
the GPU. To actually get pixels the client must call SkSurface::draw(SkDDL)
on an SkSurface that is "compatible" with the surface characterization
initially given to the SkDDLMaker.
The surface characterization contains the minimum amount of information Ganesh needs
to know about the ultimate destination in order to perform its cpu-side work
(i.e., caps, width, height, config).
Change-Id: I75faa483ab5a6b779c8de56ea56b9d90b990f43a
Reviewed-on: https://skia-review.googlesource.com/30140
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
DAA is:
1. Much simpler than AAA.
SkScan_AAAPath.cpp is about 1700 lines.
SkScan_DAAPath.cpp is about 300 lines.
The whole DAA CL is only about 800 lines.
2. Much faster than AAA for complicated paths.
The speedup applies to GL backend (including ccpr)!
Here's the frame time of 'SampleApp --slide Chart' on macbook pro:
AAA-raster: 33ms
DAA-raster: 21ms
AAA-gl: 30ms
DAA-gl: 20ms
AAA-ccpr: 18ms
DAA-ccpr: 12ms
My linux desktop doesn't have SSE3 so the speedup is smaller
(~25% for Chart). I believe that DAA is so fast that I can enable
it for any paths (AAA is not enabled by default for complicated
paths because it is slow; hence our older supersampling scan
converter is used for stroking on Chart for AAA-xxx config.)
3. The SkCoverageDelta is suitable for threaded backend with
out-of-order concurrent scan conversion as commented in the source
code. Maybe we can also just send deltas to GPU.
4. Similar to most analytic path renderers, the quality is on the best
ground-truth level, unless there are intersections within a pixel.
The intersections look good to my eyes although theoretically that
could be arbitrary far from the ground truth (see my AAA slides).
5. For simple paths, such as circle, triangle, rrect, etc., DAA is
slower than AAA. But DAA is faster than our older supersampling
scan converter in most cases. As those simple paths usually don't
constitute the bottleneck of a picture (skp or svg), I strongly
recommend use DAA.
6. DAA also heavily favors blitMask so it may work quite well with
SkRasterPipeline and SkRasterPipelineBlitter.
Finally, please check https://skia-review.googlesource.com/c/22420/
which accelerate DAA by specializing blitCoverageDeltas for
SkARGB32_Blitter and SkARGB32_Black_Blitter. It brings a little(<5%)
speedup. But I couldn't figure out how to reduce the duplicate code
so I don't intend to land it.
Bug: skia:
Change-Id: I3b7ed6a727447922e645b1acb737a506e7c09a4c
Reviewed-on: https://skia-review.googlesource.com/19666
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Cary Clark <caryclark@google.com>
Commit-Queue: Yuqian Li <liyuqian@google.com>
Not yet thread safe (so it forces threading off).
Builds JSON on the fly, so overhead is certainly bad.
Plan to fix all of that, but this at least "works".
There is now one tracing flag: 'trace'.
- 'debugf' installs the SkDebugf tracer.
- 'atrace' installs the Android ATrace tracer.
- Any other value is interpreted as a filename, and
produces a JSON file for chrome://tracing.
All three modes work in DM, nanobench, and Viewer.
Bug: skia:
Change-Id: I3fbc22382b99418a508c670be2770195c0a1c364
Reviewed-on: https://skia-review.googlesource.com/24781
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Also adds more trace events to GPU backend.
Change-Id: Ifa5f0cd4b1fd582f0cc30d37d9e6414dc498c75d
Reviewed-on: https://skia-review.googlesource.com/24622
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
The only difference is that we now also put the guard flag
SK_SUPPORT_LEGACY_AAA in SkUserConfig.h. Previously, SkAnalyticEdge.cpp doesn't
get that flag from SkScan.h and that caused many problems.
BUG=skia:
TBR=reed@google.com,caryclark@google.com
Change-Id: I134bb76cebd6fffa712f438076668765321bba3b
Reviewed-on: https://skia-review.googlesource.com/6992
Reviewed-by: Yuqian Li <liyuqian@google.com>
Commit-Queue: Yuqian Li <liyuqian@google.com>
This reverts commit b46fff60bc.
Reason for revert: possible chromium cc unit tests failure
Change-Id: Ie174c55e4d0fc3ae45854b5897ba26b7ad5a9c13
Reviewed-on: https://skia-review.googlesource.com/6981
Commit-Queue: Yuqian Li <liyuqian@google.com>
Reviewed-by: Yuqian Li <liyuqian@google.com>
The only difference is that we now put the guard flag SK_SUPPORT_LEGACY_AAA in
SkUserConfig.h instead of SkScan.h. Previously, SkAnalyticEdge.cpp doesn't get
that flag from SkScan.h and that caused many problems.
BUG=skia:
TBR=reed@google.com,caryclark@google.com
Change-Id: I7b89d3cb64ad71715101d2a5e8e77be3a8a6fa16
Reviewed-on: https://skia-review.googlesource.com/6972
Reviewed-by: Yuqian Li <liyuqian@google.com>
Commit-Queue: Yuqian Li <liyuqian@google.com>
This reverts commit 89a0e72287.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> Implement Analytic AA for General Paths (with Guard against Chrome)
>
> I've set up a SK_SUPPORT_LEGACY_AAA flag to guard against Chromium layout tests. I also set that flag in this CL so theoretically this CL won't trigger any GM changes. I'll use this to verify my guard, and remove that flag and actually enables concave AAA in a future CL.
>
> When enabled, for most simple concave paths (e.g., rectangle stroke, rrect stroke, sawtooth, stars...), the Analytic AA achieves 1.3x-2x speedup, and they look much prettier. And they probably are the majority in our use cases by number. But they probably are not the majority by time cost; a single complicated path may cost 10x-100x more time to render than a rectangle stroke... For those complicated paths, we fall back to supersampling by default as we're likely to be 1.1-1.2x slower and the quality improvement is not visually significant. However, one can use gSkForceAnalyticAA to disable that fallback.
>
> BUG=skia:
>
> Change-Id: If9549a3acc4a187cfaf7eb51890c148da3083d31
> Reviewed-on: https://skia-review.googlesource.com/6091
> Reviewed-by: Mike Reed <reed@google.com>
> Commit-Queue: Yuqian Li <liyuqian@google.com>
>
TBR=caryclark@google.com,liyuqian@google.com,reed@google.com
BUG=skia:
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I13c05aaa1bcb14956bd0fe01bb404e41be75af22
Reviewed-on: https://skia-review.googlesource.com/6961
Commit-Queue: Yuqian Li <liyuqian@google.com>
Reviewed-by: Yuqian Li <liyuqian@google.com>
I've set up a SK_SUPPORT_LEGACY_AAA flag to guard against Chromium layout tests. I also set that flag in this CL so theoretically this CL won't trigger any GM changes. I'll use this to verify my guard, and remove that flag and actually enables concave AAA in a future CL.
When enabled, for most simple concave paths (e.g., rectangle stroke, rrect stroke, sawtooth, stars...), the Analytic AA achieves 1.3x-2x speedup, and they look much prettier. And they probably are the majority in our use cases by number. But they probably are not the majority by time cost; a single complicated path may cost 10x-100x more time to render than a rectangle stroke... For those complicated paths, we fall back to supersampling by default as we're likely to be 1.1-1.2x slower and the quality improvement is not visually significant. However, one can use gSkForceAnalyticAA to disable that fallback.
BUG=skia:
Change-Id: If9549a3acc4a187cfaf7eb51890c148da3083d31
Reviewed-on: https://skia-review.googlesource.com/6091
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Yuqian Li <liyuqian@google.com>
Reason for revert:
Speculative to fix windows bots
Original issue's description:
> Treat bad values passed to --images as a fatal error
>
> If an option is passed to --images that is either a non-existent path or
> a folder with no images matching the supported types, assume this is
> an error and exit, so they can supply a valid path instead.
>
> Share code between DM and nanobench in SkCommonFlags.
>
> nanobench now behaves more like DM - it will check a directory for
> images that match the supported extensions.
>
> Only consider image paths ending in RAW suffixes as images if
> SK_CODE_DECODES_RAW is defined. This prevents us from seeing failure
> to decode errors on platforms that cannot decode it.
>
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1611323004
>
> Committed: https://skia.googlesource.com/skia/+/7579786f3bd5a8fda84a1abc45b16213c3371f93TBR=mtklein@google.com,borenet@google.com,msarett@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
# Not skipping CQ checks because original CL landed more than 1 days ago.
Review URL: https://codereview.chromium.org/1653543002
If an option is passed to --images that is either a non-existent path or
a folder with no images matching the supported types, assume this is
an error and exit, so they can supply a valid path instead.
Share code between DM and nanobench in SkCommonFlags.
nanobench now behaves more like DM - it will check a directory for
images that match the supported extensions.
Only consider image paths ending in RAW suffixes as images if
SK_CODE_DECODES_RAW is defined. This prevents us from seeing failure
to decode errors on platforms that cannot decode it.
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1611323004
Review URL: https://codereview.chromium.org/1611323004
Add extended config specification form that can be used to run different
gpu backend with different APIs.
The configs can be specified with the form:
gpu(api=string,dit=bool,nvpr=bool,samples=int)
This replaces and removes the --gpuAPI flag.
All existing configs should still work.
Adds following documentation:
out/Debug/dm --help config
Flags:
--config: type: string default: 565 8888 gpu nonrendering
Options: 565 8888 debug gpu gpudebug gpudft gpunull msaa16 msaa4
nonrendering null nullgpu nvprmsaa16 nvprmsaa4 pdf pdf_poppler skp svg
xps or use extended form 'backend(option=value,...)'.
Extended form: 'backend(option=value,...)'
Possible backends and options:
gpu(api=string,dit=bool,nvpr=bool,samples=int) GPU backend
api type: string default: native.
Select graphics API to use with gpu backend.
Options:
native Use platform default OpenGL or OpenGL ES backend.
gl Use OpenGL.
gles Use OpenGL ES.
debug Use debug OpenGL.
null Use null OpenGL.
dit type: bool default: false.
Use device independent text.
nvpr type: bool default: false.
Use NV_path_rendering OpenGL and OpenGL ES extension.
samples type: int default: 0.
Use multisampling with N samples.
Predefined configs:
gpu = gpu()
msaa4 = gpu(samples=4)
msaa16 = gpu(samples=16)
nvprmsaa4 = gpu(nvpr=true,samples=4)
nvprmsaa16 = gpu(nvpr=true,samples=16)
gpudft = gpu(dit=true)
gpudebug = gpu(api=debug)
gpunull = gpu(api=null)
debug = gpu(api=debug)
nullgpu = gpu(api=null)
BUG=skia:2992
Committed: https://skia.googlesource.com/skia/+/e13ca329fca4c28cf4e078561f591ab27b743d23
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1490113005
Committed: https://skia.googlesource.com/skia/+/c8b4336444e7b90382e04e33665fb3b8490b825b
Committed: https://skia.googlesource.com/skia/+/9ebc3f0ee6db215dde461dc4777d85988cf272dd
Review URL: https://codereview.chromium.org/1490113005
Add extended config specification form that can be used to run different
gpu backend with different APIs.
The configs can be specified with the form:
gpu(api=string,dit=bool,nvpr=bool,samples=int)
This replaces and removes the --gpuAPI flag.
All existing configs should still work.
Adds following documentation:
out/Debug/dm --help config
Flags:
--config: type: string default: 565 8888 gpu nonrendering
Options: 565 8888 debug gpu gpudebug gpudft gpunull msaa16 msaa4
nonrendering null nullgpu nvprmsaa16 nvprmsaa4 pdf pdf_poppler skp svg
xps or use extended form 'backend(option=value,...)'.
Extended form: 'backend(option=value,...)'
Possible backends and options:
gpu(api=string,dit=bool,nvpr=bool,samples=int) GPU backend
api type: string default: native.
Select graphics API to use with gpu backend.
Options:
native Use platform default OpenGL or OpenGL ES backend.
gl Use OpenGL.
gles Use OpenGL ES.
debug Use debug OpenGL.
null Use null OpenGL.
dit type: bool default: false.
Use device independent text.
nvpr type: bool default: false.
Use NV_path_rendering OpenGL and OpenGL ES extension.
samples type: int default: 0.
Use multisampling with N samples.
Predefined configs:
gpu = gpu()
msaa4 = gpu(samples=4)
msaa16 = gpu(samples=16)
nvprmsaa4 = gpu(nvpr=true,samples=4)
nvprmsaa16 = gpu(nvpr=true,samples=16)
gpudft = gpu(dit=true)
gpudebug = gpu(api=debug)
gpunull = gpu(api=null)
debug = gpu(api=debug)
nullgpu = gpu(api=null)
BUG=skia:2992
Committed: https://skia.googlesource.com/skia/+/e13ca329fca4c28cf4e078561f591ab27b743d23
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1490113005
Committed: https://skia.googlesource.com/skia/+/c8b4336444e7b90382e04e33665fb3b8490b825b
Review URL: https://codereview.chromium.org/1490113005
Reason for revert:
This CL changed 1200 images on gold, when I wouldn't expect any diffs from the description.
Original issue's description:
> Add config options to run different GPU APIs to dm and nanobench
>
> Add extended config specification form that can be used to run different
> gpu backend with different APIs.
>
> The configs can be specified with the form:
> gpu(api=string,dit=bool,nvpr=bool,samples=int)
>
> This replaces and removes the --gpuAPI flag.
>
> All existing configs should still work.
>
> Adds following documentation:
>
> out/Debug/dm --help config
>
> Flags:
> --config: type: string default: 565 8888 gpu nonrendering
> Options: 565 8888 debug gpu gpudebug gpudft gpunull msaa16 msaa4
> nonrendering null nullgpu nvprmsaa16 nvprmsaa4 pdf pdf_poppler skp svg
> xps or use extended form 'backend(option=value,...)'.
>
> Extended form: 'backend(option=value,...)'
>
> Possible backends and options:
>
> gpu(api=string,dit=bool,nvpr=bool,samples=int) GPU backend
> api type: string default: native.
> Select graphics API to use with gpu backend.
> Options:
> native Use platform default OpenGL or OpenGL ES backend.
> gl Use OpenGL.
> gles Use OpenGL ES.
> debug Use debug OpenGL.
> null Use null OpenGL.
> dit type: bool default: false.
> Use device independent text.
> nvpr type: bool default: false.
> Use NV_path_rendering OpenGL and OpenGL ES extension.
> samples type: int default: 0.
> Use multisampling with N samples.
>
> Predefined configs:
>
> gpu = gpu()
> msaa4 = gpu(samples=4)
> msaa16 = gpu(samples=16)
> nvprmsaa4 = gpu(nvpr=true,samples=4)
> nvprmsaa16 = gpu(nvpr=true,samples=16)
> gpudft = gpu(dit=true)
> gpudebug = gpu(api=debug)
> gpunull = gpu(api=null)
> debug = gpu(api=debug)
> nullgpu = gpu(api=null)
>
> BUG=skia:2992
>
> Committed: https://skia.googlesource.com/skia/+/e13ca329fca4c28cf4e078561f591ab27b743d23
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1490113005
>
> Committed: https://skia.googlesource.com/skia/+/c8b4336444e7b90382e04e33665fb3b8490b825bTBR=mtklein@google.com,bsalomon@google.com,scroggo@google.com,kkinnunen@nvidia.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:2992
Review URL: https://codereview.chromium.org/1536963002
Add extended config specification form that can be used to run different
gpu backend with different APIs.
The configs can be specified with the form:
gpu(api=string,dit=bool,nvpr=bool,samples=int)
This replaces and removes the --gpuAPI flag.
All existing configs should still work.
Adds following documentation:
out/Debug/dm --help config
Flags:
--config: type: string default: 565 8888 gpu nonrendering
Options: 565 8888 debug gpu gpudebug gpudft gpunull msaa16 msaa4
nonrendering null nullgpu nvprmsaa16 nvprmsaa4 pdf pdf_poppler skp svg
xps or use extended form 'backend(option=value,...)'.
Extended form: 'backend(option=value,...)'
Possible backends and options:
gpu(api=string,dit=bool,nvpr=bool,samples=int) GPU backend
api type: string default: native.
Select graphics API to use with gpu backend.
Options:
native Use platform default OpenGL or OpenGL ES backend.
gl Use OpenGL.
gles Use OpenGL ES.
debug Use debug OpenGL.
null Use null OpenGL.
dit type: bool default: false.
Use device independent text.
nvpr type: bool default: false.
Use NV_path_rendering OpenGL and OpenGL ES extension.
samples type: int default: 0.
Use multisampling with N samples.
Predefined configs:
gpu = gpu()
msaa4 = gpu(samples=4)
msaa16 = gpu(samples=16)
nvprmsaa4 = gpu(nvpr=true,samples=4)
nvprmsaa16 = gpu(nvpr=true,samples=16)
gpudft = gpu(dit=true)
gpudebug = gpu(api=debug)
gpunull = gpu(api=null)
debug = gpu(api=debug)
nullgpu = gpu(api=null)
BUG=skia:2992
Committed: https://skia.googlesource.com/skia/+/e13ca329fca4c28cf4e078561f591ab27b743d23
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1490113005
Review URL: https://codereview.chromium.org/1490113005
Reason for revert:
speculative revert to see if it unblocks the DEPS roll
https://codereview.chromium.org/1529443002
Original issue's description:
> Add config options to run different GPU APIs to dm and nanobench
>
> Add extended config specification form that can be used to run different
> gpu backend with different APIs.
>
> The configs can be specified with the form:
> gpu(api=string,dit=bool,nvpr=bool,samples=int)
>
> This replaces and removes the --gpuAPI flag.
>
> All existing configs should still work.
>
> Adds following documentation:
>
> out/Debug/dm --help config
>
> Flags:
> --config: type: string default: 565 8888 gpu nonrendering
> Options: 565 8888 debug gpu gpudebug gpudft gpunull msaa16 msaa4
> nonrendering null nullgpu nvprmsaa16 nvprmsaa4 pdf pdf_poppler skp svg
> xps or use extended form 'backend(option=value,...)'.
>
> Extended form: 'backend(option=value,...)'
>
> Possible backends and options:
>
> gpu(api=string,dit=bool,nvpr=bool,samples=int) GPU backend
> api type: string default: native.
> Select graphics API to use with gpu backend.
> Options:
> native Use platform default OpenGL or OpenGL ES backend.
> gl Use OpenGL.
> gles Use OpenGL ES.
> debug Use debug OpenGL.
> null Use null OpenGL.
> dit type: bool default: false.
> Use device independent text.
> nvpr type: bool default: false.
> Use NV_path_rendering OpenGL and OpenGL ES extension.
> samples type: int default: 0.
> Use multisampling with N samples.
>
> Predefined configs:
>
> gpu = gpu()
> msaa4 = gpu(samples=4)
> msaa16 = gpu(samples=16)
> nvprmsaa4 = gpu(nvpr=true,samples=4)
> nvprmsaa16 = gpu(nvpr=true,samples=16)
> gpudft = gpu(dit=true)
> gpudebug = gpu(api=debug)
> gpunull = gpu(api=null)
> debug = gpu(api=debug)
> nullgpu = gpu(api=null)
>
> BUG=skia:2992
>
> Committed: https://skia.googlesource.com/skia/+/e13ca329fca4c28cf4e078561f591ab27b743d23TBR=bsalomon@google.com,scroggo@google.com,joshualitt@google.com,kkinnunen@nvidia.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:2992
Review URL: https://codereview.chromium.org/1528473002
Add extended config specification form that can be used to run different
gpu backend with different APIs.
The configs can be specified with the form:
gpu(api=string,dit=bool,nvpr=bool,samples=int)
This replaces and removes the --gpuAPI flag.
All existing configs should still work.
Adds following documentation:
out/Debug/dm --help config
Flags:
--config: type: string default: 565 8888 gpu nonrendering
Options: 565 8888 debug gpu gpudebug gpudft gpunull msaa16 msaa4
nonrendering null nullgpu nvprmsaa16 nvprmsaa4 pdf pdf_poppler skp svg
xps or use extended form 'backend(option=value,...)'.
Extended form: 'backend(option=value,...)'
Possible backends and options:
gpu(api=string,dit=bool,nvpr=bool,samples=int) GPU backend
api type: string default: native.
Select graphics API to use with gpu backend.
Options:
native Use platform default OpenGL or OpenGL ES backend.
gl Use OpenGL.
gles Use OpenGL ES.
debug Use debug OpenGL.
null Use null OpenGL.
dit type: bool default: false.
Use device independent text.
nvpr type: bool default: false.
Use NV_path_rendering OpenGL and OpenGL ES extension.
samples type: int default: 0.
Use multisampling with N samples.
Predefined configs:
gpu = gpu()
msaa4 = gpu(samples=4)
msaa16 = gpu(samples=16)
nvprmsaa4 = gpu(nvpr=true,samples=4)
nvprmsaa16 = gpu(nvpr=true,samples=16)
gpudft = gpu(dit=true)
gpudebug = gpu(api=debug)
gpunull = gpu(api=null)
debug = gpu(api=debug)
nullgpu = gpu(api=null)
BUG=skia:2992
Review URL: https://codereview.chromium.org/1490113005
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/+/9c7207b5dc71dc5a96a2eb107d401133333d5b6fR=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
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/+/9c7207b5dc71dc5a96a2eb107d401133333d5b6fR=caryclark@google.com, bsalomon@google.com, bungeman@google.com, reed@google.com, mtklein@chromium.orgTBR=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
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
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
