This is an automated CL created by the recipe roller. This CL rolls recipe
changes from upstream projects (e.g. depot_tools) into downstream projects
(e.g. tools/build).
More info is at https://goo.gl/zkKdpD. Use https://goo.gl/noib3a to file a bug.
recipe_engine:
https://crrev.com/6bb449da37f04e02e60a27c910d491c851050191 [stream/luci] Combine stdout/stderr for now. (iannucci@chromium.org)
TBR=borenet@google.com
Recipe-Tryjob-Bypass-Reason: Autoroller
Bugdroid-Send-Email: False
Change-Id: I440b0fef9581fb88607336542b48912e34293146
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223835
Reviewed-by: Recipe Roller <recipe-mega-autoroller@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: Recipe Roller <recipe-mega-autoroller@chops-service-accounts.iam.gserviceaccount.com>
This is an automated CL created by the recipe roller. This CL rolls recipe
changes from upstream projects (e.g. depot_tools) into downstream projects
(e.g. tools/build).
More info is at https://goo.gl/zkKdpD. Use https://goo.gl/noib3a to file a bug.
recipe_engine:
https://crrev.com/d13e90544ecc6da9fb394c5c61e927c0fe03ec65 [step_runner/subproc] Fix obvious regression from previous CL. (iannucci@chromium.org)
TBR=borenet@google.com
Recipe-Tryjob-Bypass-Reason: Autoroller
Bugdroid-Send-Email: False
Change-Id: I7d9d9656a96917deaf35c2a3fea1f5c2ee49bd75
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223830
Reviewed-by: Recipe Roller <recipe-mega-autoroller@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: Recipe Roller <recipe-mega-autoroller@chops-service-accounts.iam.gserviceaccount.com>
So it can be used for SKP serialization.
Bug: 9203
Change-Id: I094d5222f220bb79c7f61fd5ebebf48e23e97b0b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223705
Commit-Queue: Nathaniel Nifong <nifong@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
This is part of bridging the explicit backend surface API and making SkSurfaces
This is pulled out of:
https://skia-review.googlesource.com/c/skia/+/222781/ (Add bridge between GrContext::createBackendTexture and SkSurface::MakeFromBackendTexture)
Change-Id: Ib55bcd8a0d1a049f230314a8f8ba7a3951b06d5c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223707
Reviewed-by: Greg Daniel <egdaniel@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Because it mutates the glyph.
Change-Id: Ic7ce320350764454d7a76335828d398f19b149d6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223797
Commit-Queue: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Change-Id: I5dee0f9646b3ede65fcde5c246f48c5b742f00e8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223702
Reviewed-by: Eric Boren <borenet@google.com>
Commit-Queue: Joe Gregorio <jcgregorio@google.com>
This is largely redundant with GrPixelConfig. However, we intend to
remove GrPixelConfig.
Bug: skia:7580
Change-Id: I03d92303be832711f7821f8a97d36387c9b04a9f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/222883
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
On Mac, Metal will trigger an xpc to a process to compile shaders and
link pipeline programs. Sometimes that process can crash or hang. By using
an asynchronous call with a timeout we can at least recover in this case.
Bug: chromium:974219
Change-Id: I179daa86979b1217458e7be210fccd5edcbffdd0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/222884
Reviewed-by: Christopher Cameron <ccameron@chromium.org>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
So far this is just as easy as I had hoped.
Change-Id: I5f69a900b32d9bf70156b55e334233d7376b820f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223340
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This call maintains image invariants while merging in
an image. It replaces much dubious code.
Change-Id: Id57fa1169f8944b2d10063fde983cd9d8256b598
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223303
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Herb Derby <herb@google.com>
This is an automated CL created by the recipe roller. This CL rolls recipe
changes from upstream projects (e.g. depot_tools) into downstream projects
(e.g. tools/build).
Please review the expectation changes, and LGTM+CQ.
More info is at https://goo.gl/zkKdpD. Use https://goo.gl/noib3a to file a bug.
recipe_engine:
https://crrev.com/4b7e794e4dbf7abefd1732b76ff9539570d0be7f [file] Record written data in step presentation. (joshuaseaton@google.com)
R=kjlubick@google.com
Recipe-Tryjob-Bypass-Reason: Autoroller
Bugdroid-Send-Email: False
Change-Id: Ic59ac87f9de5f6abe73e03feb5a94ce4b0dd35f1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/222573
Commit-Queue: Eric Boren <borenet@google.com>
Reviewed-by: Robbie Iannucci <iannucci@google.com>
Reviewed-by: Eric Boren <borenet@google.com>
dfd7600551..3b2255975f
git log dfd760055152..3b2255975f37 --date=short --no-merges --format='%ad %ae %s'
2019-06-25 jiajia.qin@intel.com Fix the DispatchCompute error
2019-06-24 tiborg@chromium.org Move uses-sdk to GN.
2019-06-24 angle-autoroll@skia-public.iam.gserviceaccount.com Roll ./third_party/spirv-tools/src 7c294608ca19..df86bb44fe47 (1 commits)
Created with:
gclient setdep -r third_party/externals/angle2@3b2255975f37
The AutoRoll server is located here: https://autoroll.skia.org/r/angle-skia-autoroll
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.
CQ_INCLUDE_TRYBOTS=skia.primary:Build-Debian9-Clang-x86_64-Release-ANGLE;skia.primary:Perf-Win10-Clang-AlphaR2-GPU-RadeonR9M470X-x86_64-Debug-All-ANGLE;skia.primary:Perf-Win10-Clang-NUC5i7RYH-GPU-IntelIris6100-x86_64-Debug-All-ANGLE;skia.primary:Perf-Win10-Clang-NUC6i5SYK-GPU-IntelIris540-x86_64-Debug-All-ANGLE;skia.primary:Perf-Win10-Clang-NUCD34010WYKH-GPU-IntelHD4400-x86_64-Debug-All-ANGLE;skia.primary:Perf-Win10-Clang-ShuttleC-GPU-GTX960-x86_64-Debug-All-ANGLE;skia.primary:Test-Win10-Clang-AlphaR2-GPU-RadeonR9M470X-x86_64-Debug-All-ANGLE;skia.primary:Test-Win10-Clang-NUC6i5SYK-GPU-IntelIris540-x86_64-Debug-All-ANGLE;skia.primary:Test-Win10-Clang-NUCD34010WYKH-GPU-IntelHD4400-x86_64-Debug-All-ANGLE;skia.primary:Test-Win10-Clang-ShuttleC-GPU-GTX960-x86_64-Debug-All-ANGLE
TBR=djsollen@google.com
Change-Id: If99e8aecf4afc7e2ff6803af2a9665642615d418
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223557
Reviewed-by: skia-autoroll <skia-autoroll@skia-public.iam.gserviceaccount.com>
Commit-Queue: skia-autoroll <skia-autoroll@skia-public.iam.gserviceaccount.com>
91f69e5c58..aab9fad644
Created with:
gclient setdep -r ../src@aab9fad644
The AutoRoll server is located here: https://autoroll.skia.org/r/chromium-skia-autoroll
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.
CQ_INCLUDE_TRYBOTS=skia.primary:Perf-Mac10.13-Clang-MacBookPro11.5-GPU-RadeonHD8870M-x86_64-Release-All-CommandBuffer;skia.primary:Test-Mac10.13-Clang-MacBookPro11.5-GPU-RadeonHD8870M-x86_64-Debug-All-CommandBuffer
TBR=djsollen@google.com
Change-Id: I7d78a328aa2ab2b4f0f41143adb82aab4604d4a4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223558
Reviewed-by: skia-autoroll <skia-autoroll@skia-public.iam.gserviceaccount.com>
Commit-Queue: skia-autoroll <skia-autoroll@skia-public.iam.gserviceaccount.com>
Instead of allocating into a std::vector, we do one quick first pass to
measure how much memory we need to allocate, mmap enough pages for that,
then another real writing pass.
This cuts a microsecond or so off the profile. There's another
microsecond left to cut if we could eliminate that first measuring pass,
but I'm no longer sure it's easy to come up with a good upper limit on
the program size now that I'm thinking about the data part of the
program as well.
vpshufb is our current max instruction at 9 bytes of code, but that also
implies another 32 bytes of control data. I'm not sure I feel very
clever allocating 41 * |instructions| bytes to be conservatively safe...
it seems like ridiculous overkill.
Ultimately I found it easier to just measure twice, cut once.
Change-Id: I16ccdafbc789711837b41b3d5a557808798eb1b4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223305
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Use float* to match the ByteCode run API (and make the sizing of data
clearer). Add a lane index to all external value calls. My upcoming
overhaul of the particle code needs this, but I wanted to break that
(large) CL up.
Change-Id: I0588cd7769a1dced9f088de5756947bb744c146b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223178
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Make existing trace events in GrGpu go direct to TRACE_EVENT0.
Bug: chromium:919885
Change-Id: Ica270125eb614a31860fd3ad4b78178e7bd24296
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223336
Auto-Submit: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Looks like ~50ns overhead for RP vs ~14,000ns for SkVM.
Change-Id: I85ef73d3387657b14615fcfa5cfd9df5c2325343
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223302
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This is a reland of 731454a085
Original change's description:
> Prefer using GrOvalOpFactory over GrFillRRect for circles and
> axis-aligned circular roundrects.
>
> Bug: chromium:971936
> Change-Id: I4cd0cd9047b9b06d657826820ba5a937547f87c3
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/221000
> Commit-Queue: Jim Van Verth <jvanverth@google.com>
> Reviewed-by: Khushal Sagar <khushalsagar@chromium.org>
Bug: chromium:971936
Change-Id: I8a61cff3e065177a5b2320072b45c1a619970ff6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/222794
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Change-Id: I5428be31367fc85fb1fe4f98f4e7536f17c93f10
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223301
Commit-Queue: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Converting to glyph() style calls that return SkGlyph*. This is mainly preparation
for removing converting findImage(const SkGlyph&) to prepareImage(SkGlyph*).
+ Misc cleanups mainly fWidth -> width() type things.
Change-Id: Id5c9b0ba5856b3ea54353ece4d05fa495cc5a640
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223187
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
* Take 25 evenly distributed sample points.
* Fix bug where goToAndStop was not seeking to a frame.
* Make sure it draws to 1000x1000.
NoTry: true
Bug: skia:9195
Change-Id: I73139e41542d22329bb9e3383059ac50011a9882
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223300
Commit-Queue: Ravi Mistry <rmistry@google.com>
Reviewed-by: Joe Gregorio <jcgregorio@google.com>
By itself this CL isn't all that compelling but I believe we need some intermediate path to wean ourselves off of GrPixelConfig. In particular, I believe isFormatTexturable will not need an SkColorType parameter in the future.
This is pulled out of:
https://skia-review.googlesource.com/c/skia/+/222781/ (Add bridge between GrContext::createBackendTexture and SkSurface::MakeFromBackendTexture)
which adds SkSurface::isCompatible - so the SkSurface_Gpu::isCompatible calls have been removed from this CL.
Change-Id: I6c2b8a2c4af98c1437b92c58513f34014e551b2e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223188
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
From local testing, this does get invoked and supply a useful error
number to know which rule we broke. It doesn't have any useful location
information (linenumber is always 0, filename is always empty).
Change-Id: I297e5b1d4aac0ba00d9c231550df3ab29e983628
Bug: skia:9197
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223189
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
This means GrSurfaceContext's know their alpha type.
All GrRenderTargetSurfaceContexts are kPremul.
Make GrTextureProducer store GrColorSpaceInfo.
Bug: skia:7580
Change-Id: I5ff321ef52c0edd32e5fac99dff95d44aa66f592
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223184
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Change-Id: I5cd133f9de490340a958403c06ab1c8c44017001
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223186
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Ben Wagner aka dogben <benjaminwagner@google.com>
I was just reading the ARM docs and realized that their BIC ("BIt
Clear") is the same as SSE's ANDN ("AND Not") instruction. It's kind of
a neat little tool to have laying around... comes up more than you'd
think, and it's sometimes the clearest way to express what you're doing,
as in the changed program here where the comment is "mask away the low
bits". That's a bit_clear with a mask for what you want to clear away!
And the real reason to write this up is that I want to have a CL to
point to that shows how to add an instruction top to bottom.
Change-Id: I99690ed9c1009427b3986955e7ae6264de4d215c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223120
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Run the Skottie tests checked under resources/skottie/ on Lottie bots.
Bug: skia:8925
Change-Id: I240608f1cbc70440cd1a35af52f98a7ef250ec31
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223182
Reviewed-by: Eric Boren <borenet@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
This CL allows user to indicate that they have a protected content in
GrVkBackendContext creation which results in protected CommandPool and Queue
usage.
Bug: skia:9016
Change-Id: I6a478d688b6988c2c5e5e98f18f58fb21f9d26ae
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/210067
Commit-Queue: Greg Daniel <egdaniel@google.com>
Auto-Submit: Emircan Uysaler <emircan@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Instruction is the fundamental data, and Analysis derived from it.
The fields in Analysis are only* needed in Builder::done(), and this
split seems to help clarify what done() can tweak (Analysis) and what
it cannot (fProgram, Instructions). done() is now const.
No speed change as far as I can tell.
* As you may notice looking at the test expectations, making analysis
ephemeral means that dump() can no longer print the skull for dead code
or the arrow for hoisted. The register program that's also in the
expectation file still reflects both of these optimizations, so we're
not really losing any information. Just maybe less demo-friendly.
Change-Id: I79feb57558525591baf3faadeb59c418c12793f3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223119
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Each one of these Instructions has its own register assignment,
so instead of allocating them in a little temporary side vector,
allocate them along with the main Program entries, just like
the other metadata, hoist and life.
No noticeable change in perf.
Change-Id: I3db8c1520d52f5787111b227e6becfef49e5a892
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223118
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
This cuts the overhead bench from about 19µs to about 15µs.
The key insight here is that the only registers that might become
available after any given instruction are the ones that hold that
instruction's inputs. We can check when they become available
directly from the original Builder::Program, without needing a
side death schedule data structure.
Marking hoisted instructions as having life == program size
helps make this logic a little simpler to reason through.
Change-Id: Ifb9957f2d0e323e0e5d07996a2cc988f7c8b4c3f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223117
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
This splits the ID namespace into Reg and Val types, hopefully making it
a little easier to follow what's going on, and if we want, allowing us
to size them differently (e.g. val at i32 or i16, reg at i16 or u8). I
didn't notice any speed change when shrinking either, so I've left them
both at i32 for maximum flexibility.
I played with making these strong typedefs with both structs and enum
classes, but both felt a little awkward. I'm still open to the idea.
Change-Id: Ie0adf6944ed6254eb21dfdfb59894c4e30476443
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223077
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
