This logic that any GCE CPU *SAN bot is implicitly
a BonusConfigs bot is confusing... make it explicit.
This also means we can make BonusConfigs CPU bots
run disjoint work like the BonusConfigs GPU bots do.
No need to run the default configs redundantly.
Change-Id: I1219091f065a3d1135973bffea7c8774a8ca1ad6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262085
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
As they are a significant chunk of code, this reduces the size of the
release executable.
Change-Id: Ib764b3ec6244629e50941b0101a540e49d56c320
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261955
Reviewed-by: Greg Daniel <egdaniel@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
While staring at this code snippet for too long,
I realized it's possible to set a crazy color on
a paint and trick the code at head into thinking
that it's normalized, using the fast sRGB curves
erroneously. Might as well fix it.
Change-Id: If16c1476dbfc913adc8ba079bdb48cab374b681d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262029
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
cbbfa2f28a..1fdf6ca514
git log cbbfa2f28a0e..1fdf6ca5141d --date=short --first-parent --format='%ad %ae %s'
2020-01-02 xinghua.cao@intel.com D3D11: Restrict to translate uniform block to StructuredBuffer
Created with:
gclient setdep -r third_party/externals/angle2@1fdf6ca5141d
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/angle-skia-autoroll
Please CC nifong@google.com on the revert to ensure that a human
is aware of the problem.
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
Cq-Include-Trybots: skia/skia.primary:Build-Debian9-Clang-x86_64-Release-ANGLE;skia/skia.primary:Test-Win10-Clang-AlphaR2-GPU-RadeonR9M470X-x86_64-Debug-All-ANGLE;skia/skia.primary:Test-Win10-Clang-Golo-GPU-QuadroP400-x86_64-Debug-All-ANGLE;skia/skia.primary:Test-Win10-Clang-NUC5i7RYH-GPU-IntelIris6100-x86_64-Debug-All-ANGLE;skia/skia.primary:Test-Win10-Clang-NUC6i5SYK-GPU-IntelIris540-x86_64-Debug-All-ANGLE;skia/skia.primary:Test-Win10-Clang-NUC8i5BEK-GPU-IntelIris655-x86_64-Debug-All-ANGLE;skia/skia.primary:Test-Win10-Clang-NUCD34010WYKH-GPU-IntelHD4400-x86_64-Debug-All-ANGLE
Bug: None
Tbr: nifong@google.com
Change-Id: If1806bb2ef4155b1e9692d0fecf7b9a08cd2b076
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262027
Reviewed-by: skia-autoroll <skia-autoroll@skia-public.iam.gserviceaccount.com>
Commit-Queue: skia-autoroll <skia-autoroll@skia-public.iam.gserviceaccount.com>
I _think_ I've sorted out everything that went wrong the first time:
- Since we're not always kPremul by the time we clamp, we now
need to clamp to [0,1] when either fClampAsIfUnpremul is set
or... we're actually unpremul! That's the first diff we couldn't
figure out.
- This was not the only use of apply(pipeline, SkColorType),
and removing it made things fall back on apply(pipeline, bool),
which was making us think everything was normalized. I think
that'll get the layout tests.
So I think this is now everything we'd want, uncompromised.
Change-Id: I46f3cd1cc79358e55f5c46a425bacb1de6932c7b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262022
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This makes the Housekeeper-PerCommit-InfraTests_Win task less broken.
Change-Id: Icd82b172dede83b69ed415fb03c3c47b54b5df5d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261997
Auto-Submit: Ben Wagner aka dogben <benjaminwagner@google.com>
Reviewed-by: Ravi Mistry <rmistry@google.com>
Commit-Queue: Ravi Mistry <rmistry@google.com>
Followup to https://skia-review.googlesource.com/c/skia/+/261933; Pixel
bots don't have enough capacity.
Change-Id: I3b3413c32170a31ba25a53cbbdc15b65b9c66f33
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261996
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Commit-Queue: Ben Wagner aka dogben <benjaminwagner@google.com>
Auto-Submit: Ben Wagner aka dogben <benjaminwagner@google.com>
fBrokenRun indicates if the atlas became full at any
glyph other than the first glyph of the SubRun.
* Remove getter and setters for fAtlasGeneration.
Change-Id: I603f15e7a2b3b632e184a985f0143d6a711f25e9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/262000
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Herb Derby <herb@google.com>
We've realized we'd like to have a few more Debug Perf bots, and it
seems like maybe a good way to satisfy that is to backfill anywhere
we've got a Release Perf ASAN bot but not a Debug one.
In net, this adds:
1) some Android ASAN Debug Build bots, both 32- and 64-bit ARM
2) some Android ASAN Debug _Test_ bots using those new builds
3) one CPU and one GPU Debug ASAN Perf bot
This CL originally was intended just to fulfill 3); I didn't anticipate
finding those testing gaps filled by 1) and 2), and if we find those new
bots to be a bother we can revert them. They seemed like glaring enough
holes to try to fix now.
Change-Id: I5714522db52bb5bde458b724091a227229e55fea
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261933
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Otherwise it falls back on a 64K table.
Change-Id: I871fdfd9ef22ba7f3df758272b7dc557f217d5e0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261942
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Change-Id: I0b11d4210c6e663cfb4854fc33e1396fd79fe9a4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261780
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
The interpreter doesn't (yet) support all GPU intrinsics, so adjust the
code to avoid 'max' and 'saturate'.
The interpreter is more picky about uniform blocks being the correct
size, so don't pass the color matrix data to the "None" effect, which
has no uniforms.
Change-Id: I4609f913eaa762ca171b2875eb25d23141a0646c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261931
Auto-Submit: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
This is a reland of 4f275cfe0e
Original change's description:
> pass more information to shaders
>
> If we're going to write an image shader, we're going to need to know the
> matrix and some bits of the paint.
>
> Instead of all possible information, I decided to pass just what the
> image shader needs for now, and will pass along more as I go.
>
> I've added a stub implementation of SkImageFilter as a way to make sure
> I'm threading everything it'll need through.
>
> Change-Id: I98de1724056dbc0902a34fc31da8ec6bdf38dc34
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261801
> Commit-Queue: Mike Klein <mtklein@google.com>
> Reviewed-by: Mike Reed <reed@google.com>
Change-Id: I2541903ad559fe8b584e46b1e9d68ec804b7a15d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261779
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Updated internal usage of SkRuntimeColorFilterFactory to use this
instead. Once this lands, we can update SkiaRenderer in Chrome to
use it, and remove SkRuntimeColorFilterFactory.
This doesn't support a CPU callback function in the runtime color
filter - I don't think we're going to support that in the long term.
Change-Id: I714413bd590cf5cf4416ef62809a6e1d92211688
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261681
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Use the original alpha in the unpremul color.
Bug: chromium:1024935
Change-Id: I6a721431781f0ef42a3f162d39f8bbac924a2c30
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261680
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
make profile can be used with bloaty [1] and twiggy [2]
Some example commands for investigating code size:
bloaty ./canvaskit/bin/canvaskit.wasm -d symbols
bloaty ./canvaskit/bin/canvaskit.wasm -d sections
twiggy top -n 50 --retained ./canvaskit/bin/canvaskit.wasm
twiggy monos ./canvaskit/bin/canvaskit.wasm -g -m 40
# Let's pretend we have a symbol called
# AddIntersectTs(SkOpContour*, SkOpContour*, SkOpCoincidence*)
# that we want to investigate further
twiggy dominators --regex ./canvaskit/bin/canvaskit.wasm AddIntersectTs.+
twiggy paths --regex ./canvaskit/bin/canvaskit.wasm AddIntersectTs.+
[1] https://github.com/google/bloaty
[2] https://rustwasm.github.io/book/reference/code-size.html#the-twiggy-code-size-profiler
Bug: skia:9733
Change-Id: I4a665fe2c750da552fee1dbf804ce0028a06c6c3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261903
Reviewed-by: Kevin Lubick <kjlubick@google.com>
An error from addr2line (e.g. unknown binary type) can truncate the
output, hiding the remainder of the stack trace. Instead print the
original line.
Change-Id: I563aae4333a79a17560378e399e79b60c79f9ac7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261288
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Auto-Submit: Ben Wagner aka dogben <benjaminwagner@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
942d91520a..cbbfa2f28a
git log 942d91520aa8..cbbfa2f28a0e --date=short --first-parent --format='%ad %ae %s'
2019-12-31 angle-autoroll@skia-public.iam.gserviceaccount.com Roll third_party/SwiftShader 59465799210b..10a900e5ffaf (1 commits)
Created with:
gclient setdep -r third_party/externals/angle2@cbbfa2f28a0e
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/angle-skia-autoroll
Please CC nifong@google.com on the revert to ensure that a human
is aware of the problem.
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
Cq-Include-Trybots: skia/skia.primary:Build-Debian9-Clang-x86_64-Release-ANGLE;skia/skia.primary:Test-Win10-Clang-AlphaR2-GPU-RadeonR9M470X-x86_64-Debug-All-ANGLE;skia/skia.primary:Test-Win10-Clang-Golo-GPU-QuadroP400-x86_64-Debug-All-ANGLE;skia/skia.primary:Test-Win10-Clang-NUC5i7RYH-GPU-IntelIris6100-x86_64-Debug-All-ANGLE;skia/skia.primary:Test-Win10-Clang-NUC6i5SYK-GPU-IntelIris540-x86_64-Debug-All-ANGLE;skia/skia.primary:Test-Win10-Clang-NUC8i5BEK-GPU-IntelIris655-x86_64-Debug-All-ANGLE;skia/skia.primary:Test-Win10-Clang-NUCD34010WYKH-GPU-IntelHD4400-x86_64-Debug-All-ANGLE
Bug: None
Tbr: nifong@google.com
Change-Id: I2ae44734f5501c21ebefc3574896d23d3863f438
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261876
Reviewed-by: skia-autoroll <skia-autoroll@skia-public.iam.gserviceaccount.com>
Commit-Queue: skia-autoroll <skia-autoroll@skia-public.iam.gserviceaccount.com>
fca5a005aa..942d91520a
git log fca5a005aa88..942d91520aa8 --date=short --first-parent --format='%ad %ae %s'
2019-12-30 m.maiya@samsung.com EGL: Add support for EGL_KHR_gl_colorspace extension
2019-12-30 angle-autoroll@skia-public.iam.gserviceaccount.com Roll third_party/vulkan-headers/src 0e57fc1cfa56..f63dd5c9d874 (1 commits)
2019-12-30 syoussefi@chromium.org Vulkan: clean up arguments to glslang wrapper
2019-12-30 syoussefi@chromium.org Avoid vector copy in BinaryOutputStream::writeIntVector
2019-12-30 angle-autoroll@skia-public.iam.gserviceaccount.com Roll third_party/glslang/src 5de15a256eb0..6334d594f68c (4 commits)
Created with:
gclient setdep -r third_party/externals/angle2@942d91520aa8
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/angle-skia-autoroll
Please CC nifong@google.com on the revert to ensure that a human
is aware of the problem.
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
Cq-Include-Trybots: skia/skia.primary:Build-Debian9-Clang-x86_64-Release-ANGLE;skia/skia.primary:Test-Win10-Clang-AlphaR2-GPU-RadeonR9M470X-x86_64-Debug-All-ANGLE;skia/skia.primary:Test-Win10-Clang-Golo-GPU-QuadroP400-x86_64-Debug-All-ANGLE;skia/skia.primary:Test-Win10-Clang-NUC5i7RYH-GPU-IntelIris6100-x86_64-Debug-All-ANGLE;skia/skia.primary:Test-Win10-Clang-NUC6i5SYK-GPU-IntelIris540-x86_64-Debug-All-ANGLE;skia/skia.primary:Test-Win10-Clang-NUC8i5BEK-GPU-IntelIris655-x86_64-Debug-All-ANGLE;skia/skia.primary:Test-Win10-Clang-NUCD34010WYKH-GPU-IntelHD4400-x86_64-Debug-All-ANGLE
Bug: None
Tbr: nifong@google.com
Change-Id: I8fde6ff7a14b6cf920adc3a622685a46615dc173
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261823
Reviewed-by: skia-autoroll <skia-autoroll@skia-public.iam.gserviceaccount.com>
Commit-Queue: skia-autoroll <skia-autoroll@skia-public.iam.gserviceaccount.com>
This reverts commit 4311f19158.
Reason for revert: layout test failures seemingly not having to do with bicubic+clamping+sRGB
Original change's description:
> refresh image shader cs/at logic
>
> Was working on SkVM versions of these when I noticed the existing
> SkRasterPipeline code wasn't terribly tidy. The main gist here is that
> we can let SkColorSpaceXformSteps::apply() handle almost all the
> final transformation on the way out of the shader.
>
> I remain a little puzzled why I got a few significant diffs when I tried
> leaving the A8 color unpremul, letting the steps handle matching the
> alpha types instead of me manually with SkRasterPipeline::premul. For
> now I've left that as-is.
>
> Similarly I think we could transform that A8 color ahead of time rather
> than doing that over and over at runtime. This is something I've left
> as a TODO, largely because I don't care enough about coloring A8 to
> investigate right now.
>
> I've inlined all the logic of explaining src-is-normalized into this
> shader (which is its only user). That makes it clearer that we can
> always set that bit when bicubic sampling, since we're clamping anyway.
> This causes some invisible diffs when switching to the optimized sRGB
> transfer function stages, which we may or may not be able to get away
> with without guarding...
>
> Change-Id: Ie6670c6ca5c69958f41aac88324341a10eb3bee1
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261763
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Mike Klein <mtklein@google.com>
TBR=mtklein@google.com,brianosman@google.com,reed@google.com
Change-Id: I9c414cb751d9e51219b18dc3d4f54c92d06664ce
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261815
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This reverts commit 60b69ecc8d.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> clarify that there's no kMedium here
>
> Reword to make it clearer we're only handling kNone, kLow, and kHigh;
> kMedium has been transformed into kLow or kHigh already at this point.
>
> I think it's particularly easy to be confused by the line
>
> if (quality > kLow_SkFilterQuality) { ... }
>
> Change-Id: If78cb6e946e26d08f5acd807d32e0446c69061b1
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261765
> Auto-Submit: Mike Klein <mtklein@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
> Commit-Queue: Mike Klein <mtklein@google.com>
TBR=mtklein@google.com,brianosman@google.com
Change-Id: Ifb639ce76ec8e533ed6af7ddcb2d2fe8c66a6558
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261814
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This reverts commit 4f275cfe0e.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> pass more information to shaders
>
> If we're going to write an image shader, we're going to need to know the
> matrix and some bits of the paint.
>
> Instead of all possible information, I decided to pass just what the
> image shader needs for now, and will pass along more as I go.
>
> I've added a stub implementation of SkImageFilter as a way to make sure
> I'm threading everything it'll need through.
>
> Change-Id: I98de1724056dbc0902a34fc31da8ec6bdf38dc34
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261801
> Commit-Queue: Mike Klein <mtklein@google.com>
> Reviewed-by: Mike Reed <reed@google.com>
TBR=mtklein@google.com,reed@google.com
Change-Id: I660846f55a6fd9d118a6b58ea7d853b91d708aee
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261813
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
There was never a need to distinguish between "all" and "default".
We can just use kDefalut everywhere. And as we add new path renderers,
we can exclude them from kDefault until they are ready to ship.
Change-Id: I378aa1e195d40daef6a2c54f9c8e829208780ebe
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261714
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
If we're going to write an image shader, we're going to need to know the
matrix and some bits of the paint.
Instead of all possible information, I decided to pass just what the
image shader needs for now, and will pass along more as I go.
I've added a stub implementation of SkImageFilter as a way to make sure
I'm threading everything it'll need through.
Change-Id: I98de1724056dbc0902a34fc31da8ec6bdf38dc34
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261801
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Bundling the pipeline stage arguments also simplifies the code in
several spots.
Change-Id: I85e81b436a39378f753cc9404b6eeb27fe055525
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261778
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reword to make it clearer we're only handling kNone, kLow, and kHigh;
kMedium has been transformed into kLow or kHigh already at this point.
I think it's particularly easy to be confused by the line
if (quality > kLow_SkFilterQuality) { ... }
Change-Id: If78cb6e946e26d08f5acd807d32e0446c69061b1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261765
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Was working on SkVM versions of these when I noticed the existing
SkRasterPipeline code wasn't terribly tidy. The main gist here is that
we can let SkColorSpaceXformSteps::apply() handle almost all the
final transformation on the way out of the shader.
I remain a little puzzled why I got a few significant diffs when I tried
leaving the A8 color unpremul, letting the steps handle matching the
alpha types instead of me manually with SkRasterPipeline::premul. For
now I've left that as-is.
Similarly I think we could transform that A8 color ahead of time rather
than doing that over and over at runtime. This is something I've left
as a TODO, largely because I don't care enough about coloring A8 to
investigate right now.
I've inlined all the logic of explaining src-is-normalized into this
shader (which is its only user). That makes it clearer that we can
always set that bit when bicubic sampling, since we're clamping anyway.
This causes some invisible diffs when switching to the optimized sRGB
transfer function stages, which we may or may not be able to get away
with without guarding...
Change-Id: Ie6670c6ca5c69958f41aac88324341a10eb3bee1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261763
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
- 'in' variables can't be arrays (applies to all SkSL)
- 'in' and 'uniform' variables are restricted to a fixed
list of types.
Change-Id: I957ce1ad33aaf6b5970ca7204c568bb533bc86d6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261436
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Inlining SkPicturePlayback::ReadOpAndSize() simplifies it, as does
removing support for the old op encoding, which was the "old format"
even back in 2014.
Change-Id: I304a777618403667b7b6c11110e3a781a5a29df3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261594
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Bug: oss-fuzz:19583
Change-Id: I656e8ddd5699cfc4998f3f424a1a46380f310c63
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261591
Commit-Queue: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Reed <reed@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Reed <reed@google.com>
This workaround has not stopped long shaders from randomly failing
to compile on TecnoSpark Pro 3. It just stops us from generating some
shaders that fail to compile in unit tests.
Also, it reveals rendering issue when framebuffer fetch is used with
MSAA on this device (instead of adv. blending).
Change-Id: I8026ded6d0d75743dc2c508df5c4ffc207d8b5a9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261736
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This was a workaround for older MSVC that didn't suppress that
particular warning as part of "/w". Bots are using a newer compiler that
fixes the issue.
Change-Id: If8582a688294286c2b307970415cd1d929b184b1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/261738
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
