This (only?) affects ANGLE. Other ES platforms typically go through
EGLGLTestContext, which manually instantiates an EGLFenceSync.
In general, though, ES3 requires this API, so this is safe. Should give us
more accurate (and much less spammy) output from ES3 ANGLE performance
testing.
Bug: skia:
Change-Id: I10a608d21092aaffa4ab76e4b3d2f6e9c5cf09bb
Reviewed-on: https://skia-review.googlesource.com/14063
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Starting with the bug fix + test.
Broken off of:
https://skia-review.googlesource.com/c/13976
Bug: skia:
Change-Id: If6c28e2dfb0c5340c48e943d0313a9ea9515a6c3
Reviewed-on: https://skia-review.googlesource.com/14061
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Matt Sarett <msarett@google.com>
Change-Id: I5de3c8daae80e437b3553ab6afcee7120a1bb775
Reviewed-on: https://skia-review.googlesource.com/14038
Reviewed-by: Herb Derby <herb@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
I still plan to replace this more thoroughly with a different blitter,
but for now just implement it using callback.
This is the last stage not supported by SkJumper! Will follow up by
removing all of SkRasterPipeline_opts.h and anything that indicates
SkJumper might not work.
Change-Id: I96ba2bb0a26266f3b658e5f3153ec7d5bbd46799
Reviewed-on: https://skia-review.googlesource.com/14037
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
My main interest is getting rid of weird code, but it's also faster.
The new bench drops from 667 to 412.
Change-Id: Ibf889601284cf925780320c828394f79937dc705
Reviewed-on: https://skia-review.googlesource.com/14035
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Bug: skia:
Change-Id: I560eb00b4b19643346b038822869e5bc77ce1454
Reviewed-on: https://skia-review.googlesource.com/13652
Reviewed-by: Ben Wagner <benjaminwagner@google.com>
Commit-Queue: Eric Boren <borenet@google.com>
Bug: skia:
NOTRY=true
Change-Id: I19b8e8d126df7580aed689af9155a34781baa8d5
Reviewed-on: https://skia-review.googlesource.com/14032
Reviewed-by: Greg Daniel <egdaniel@google.com>
Reviewed-by: Eric Boren <borenet@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
I don't suppose you know any existing test coverage of this?
I can't seem to trigger any...
Change-Id: I7244053e2fb665888c9443d2bc52c5a23725ec53
Reviewed-on: https://skia-review.googlesource.com/13970
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
The new code path is triggered by SkImage::makeColorSpace()
when the image is picture backed.
Fixes 3 gms in gbr-8888 config.
Bug: skia:6516
Change-Id: I397903eb0f926834efd277f30265339518777920
Reviewed-on: https://skia-review.googlesource.com/14034
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Matt Sarett <msarett@google.com>
Looks like the color-space images have this well tested (even without
lab_to_xyz) and the diffs look like rounding/FMA.
The old plan to keep loads and stores outside callback was:
1) awkward, with too many pointers and pointers to pointers to track
2) misguided... load and store stages march ahead by x,
working at ptr+0, ptr+8, ptr+16, etc. while callback
always wants to be working at the same spot in the buffer.
I spent a frustrating day in lldb to understood 2). :/
So now the stage always store4's its pixels to a buffer in the context
before the callback, and when the callback returns it load4's them back
from a pointer in the context, defaulting to that same buffer.
Instead of passing a void* into the callback, we pass the context
itself. This lets us subclass the context and add our own data...
C-compatible object-oriented programming.
Change-Id: I7a03439b3abd2efb000a6973631a9336452e9a43
Reviewed-on: https://skia-review.googlesource.com/13985
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
* Fix spot shadow placement for SkSpotShadowMaskFilter.
* Make sure we don't try to render an oval as a plain RRect
due to floating point error.
* Use fast path for uncached circles.
* Make sure ShadowMaskFilters can handle near-circles.
Change-Id: Ia9967a00a6e1c980a1c0a7ba8248f09fde61a3b7
Reviewed-on: https://skia-review.googlesource.com/13969
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Addresses an issue with ovals transformed by a matrix with a reflection.
Also adds a further check for circles to ensure that teeny tiny ovals
(sizes < SK_ScalarNearlyZero) aren't treated as circles.
Change-Id: Ie50e4a98365eba7c23e53e68886ebac981ed1def
Reviewed-on: https://skia-review.googlesource.com/13989
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
This reverts commit 02242e82e4.
Reason for revert: Maybe breaking Chrome DEPS roll
Original change's description:
> Rm makeRenderTargetContext in favor of deferred version (take 2)
>
> This is a reland of: https://skia-review.googlesource.com/c/13001/ (Rm makeRenderTargetContext in favor of deferred version)
>
> Change-Id: Ife77b012d09c46895884a168fc5045bd92a4b919
> Reviewed-on: https://skia-review.googlesource.com/13196
> Reviewed-by: Greg Daniel <egdaniel@google.com>
> Commit-Queue: Robert Phillips <robertphillips@google.com>
>
TBR=egdaniel@google.com,bsalomon@google.com,robertphillips@google.com,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I2607116ed743f5d313da4a7b7f056776ed907702
Reviewed-on: https://skia-review.googlesource.com/14024
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Currently the Vulkan backend is set up to always treat the "resolve"
target as the main VkImage in a render target and the msaa is a side cart
image. This makes it difficult to just wrap an msaa image that we don't own.
However, unlike GL the equivalent FBO 0 will never be multisampled so there
isn't much use for the functionality. Once we find a need for it we can find
a way to refactor to make it work.
Bug: skia:
Change-Id: I121e9c72a70c2a6f1aaddba2dbae19d8bddc3998
Reviewed-on: https://skia-review.googlesource.com/13980
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Galaxy S6 was way quicker on average: 19 min vs 33 min
https://docs.google.com/spreadsheets/d/1tO1YA3RL36FBGgrfpV-cr1v9srFMowBtlwywSG0frYI/edit#gid=0
We'll only keep the Nexus 5 on for a few weeks, in case we decide to go back.
Bug: skia:
NOTRY=true
Change-Id: I36cc617d4ea274bfaf5b54e9c6d73715d40d65a8
Change-Id: I36cc617d4ea274bfaf5b54e9c6d73715d40d65a8
Reviewed-on: https://skia-review.googlesource.com/13982
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Ben Wagner <benjaminwagner@google.com>
Reviewed-by: Ravi Mistry <rmistry@google.com>
This removes a long-standing source of confusion: SkImage_Generator was an
image that wrapped an SkImageGenerator (with an SkImageCacherator stuck in
the middle). We could choose to rename either one, but SkImageGenerator is
public, so take the easy road and rename the private image subclass. Given
the existence of SkImage::isLazyGenerated, this name seems appropriate.
Bug: skia:
Change-Id: I061ece94f48538efb1dc5548010f6ca7d438a69b
Reviewed-on: https://skia-review.googlesource.com/13979
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
I'm guessing the crash is actually on the first 'fGpu' reference in createTextureProxy after the GPU context has been abandoned.
Bug: 712929
Change-Id: Ia6742da7073c2320e592b42fcf2d0e7c04eeefb9
Reviewed-on: https://skia-review.googlesource.com/13966
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This reverts commit edec99b640.
Reason for revert: should be good to try again.
Original change's description:
> jumper, disable u16 table load stages
>
> Bug: b/37433905
>
> Change-Id: I829d76967f9da162388bad3f6bc2484d2a28043d
> Reviewed-on: https://skia-review.googlesource.com/13771
> Commit-Queue: Mike Klein <mtklein@chromium.org>
> Reviewed-by: Matt Sarett <msarett@google.com>
>
TBR=mtklein@chromium.org,msarett@google.com,reviews@skia.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I173bc284f894eae969bf670735e3bd723605df80
Reviewed-on: https://skia-review.googlesource.com/13967
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This reverts commit 2c65d51612.
Reason for revert: Causing failures in Google3 (https://test.corp.google.com/ui#cl=153703311&flags=CAMQAg==&id=OCL:153703311:BASE:153703364:1492695824938:4db2240d&t=//chrome/skia/dm_wrapper:dm_wrapper) and differences in Gold. This change was not intended to change the output.
Original change's description:
> Make SkPngCodec only read as much of the stream as necessary
>
> Previously, SkPngCodec assumed that the stream only contained one
> image, which ended at the end of the stream. It read the stream in
> arbitrarily-sized chunks, and then passed that data to libpng for
> processing.
>
> If a stream contains more than one image, this may result in reading
> beyond the end of the image, making future reads read the wrong data.
>
> Now, SkPngCodec starts by reading 8 bytes at a time. After the
> signature, 8 bytes is enough to know which chunk is next and how many
> bytes are in the chunk.
>
> When decoding the size, we stop when we reach IDAT, and when decoding
> the image, we stop when we reach IEND.
>
> This manual parsing is necessary to support APNG, which is planned in
> the future. It also allows us to remove the SK_GOOGLE3_PNG_HACK, which
> was a workaround for reading more than necessary at the beginning of
> the image.
>
> Add a test that simulates the issue, by decoding a special stream that
> reports an error if the codec attempts to read beyond the end.
>
> Temporarily disable the partial decoding tests for png. A larger change
> will be necessary to get those working again, and no clients are
> currently relying on incrementally decoding PNGs (i.e. decode part of
> an image, then decode further with more data).
>
> Bug: skia:5368
> BUG:34073812
>
> Change-Id: If832f7b20565411226fb5be3c305a4d16bf9269d
> Reviewed-on: https://skia-review.googlesource.com/13900
> Commit-Queue: Leon Scroggins <scroggo@google.com>
> Reviewed-by: Matt Sarett <msarett@google.com>
>
TBR=msarett@google.com,scroggo@google.com,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I2f82e9960dda7bf5c646774df84320dadb7b930e
Reviewed-on: https://skia-review.googlesource.com/13971
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
On all GPUs where we can perfectly round-trip, this mode does so.
This mode fails on Mali 400 and Tegra 3, but nothing works there.
Bug: skia:
Change-Id: Ifb045fc772a5b1c03b51b5cb2ae039fe792d17bb
Reviewed-on: https://skia-review.googlesource.com/13271
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
This is the other half of https://skia-review.googlesource.com/c/7874/,
adding the cull-shrinking feature of SkBigPictures to SkMiniPictures.
Like SkBigPictures, shrink only when we're asked to build an R-tree.
(We don't actually build a tree for one rect, of course.)
We could do unconditionally, but SkPictureImageFilter uses the cull rect
as its crop. It's unclear to me what this image filter unit test I've
changed here was intending... had it had two draws we would have shrunk
its cull, but because it was hitting the 1-draw SkMiniPicture path it
kept the larger user-supplied cull.
As the test doesn't appear to have been written with cull shrinking in
mind, I've removed its SkRTreeFactory to keep that feature explicitly
disabled there.
BUG=skia:5974
Change-Id: I4118d2e85f2a69adef2e7a7fa9b9b8c17607a94f
Reviewed-on: https://skia-review.googlesource.com/12624
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Tweaks to make the parallels between from_half and to_half stand out.
We can logically do the `auto denorm = em < ...;` comparisons as either
U32 or I32. U32 would read more naturally, but we do I32 because some
instruction sets have direct signed comparison but must synthesize an
unsigned comparison.
CQ_INCLUDE_TRYBOTS=skia.primary:Test-Android-Clang-PixelC-CPU-TegraX1-arm64-Release-Android,Test-Android-Clang-Ci20-CPU-IngenicJZ4780-mipsel-Release-Android,Test-Android-Clang-Nexus10-CPU-Exynos5250-arm-Release-Android,Test-Mac-Clang-MacMini6.2-CPU-AVX-x86_64-Release,Test-Ubuntu-GCC-GCE-CPU-AVX2-x86-Debug,Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Debug
Change-Id: Ic74fe5b3b850f5bb7fd00fd4435bc32b8628eecd
Reviewed-on: https://skia-review.googlesource.com/13963
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Bug: skia:
Change-Id: I658a95576143d69656cd63aec44ff65d430d332f
Reviewed-on: https://skia-review.googlesource.com/13813
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
We only need to verify that we've tested the PM conversion if we're about
to use GrConfigConversionEffect. For the else case, no such guarantee is
made, so the assert is wrong.
Bug: chromium:713462
Change-Id: I5ffcc0c5f7de4e9614e9ccd83140acc9ab4f7283
Reviewed-on: https://skia-review.googlesource.com/13962
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Previously, SkPngCodec assumed that the stream only contained one
image, which ended at the end of the stream. It read the stream in
arbitrarily-sized chunks, and then passed that data to libpng for
processing.
If a stream contains more than one image, this may result in reading
beyond the end of the image, making future reads read the wrong data.
Now, SkPngCodec starts by reading 8 bytes at a time. After the
signature, 8 bytes is enough to know which chunk is next and how many
bytes are in the chunk.
When decoding the size, we stop when we reach IDAT, and when decoding
the image, we stop when we reach IEND.
This manual parsing is necessary to support APNG, which is planned in
the future. It also allows us to remove the SK_GOOGLE3_PNG_HACK, which
was a workaround for reading more than necessary at the beginning of
the image.
Add a test that simulates the issue, by decoding a special stream that
reports an error if the codec attempts to read beyond the end.
Temporarily disable the partial decoding tests for png. A larger change
will be necessary to get those working again, and no clients are
currently relying on incrementally decoding PNGs (i.e. decode part of
an image, then decode further with more data).
Bug: skia:5368
BUG:34073812
Change-Id: If832f7b20565411226fb5be3c305a4d16bf9269d
Reviewed-on: https://skia-review.googlesource.com/13900
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
This change is needed since once we start getting support for varrying of extensions
and newer version support in general, we need a common vulkan header to compile off of.
Otherwise we will run into problems if clients have older headers that don't include
functions/symbols we are trying to use.
Additionally it has the benefit of not needing to add if SK_VULKAN around code in
include which wants to use vulkan symbols.
This is a reland of the reverted cl: https://skia-review.googlesource.com/13804
Bug: skia:
Change-Id: I9023e80e60d2f2ebbdc8e794ec46d6f5c5c7c917
Reviewed-on: https://skia-review.googlesource.com/13874
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
This refactors from_half() and to_half() a bit, totally
reimplementing the non-hardware cases to be more clearly correct.
CQ_INCLUDE_TRYBOTS=skia.primary:Test-Android-Clang-PixelC-CPU-TegraX1-arm64-Release-Android,Test-Android-Clang-Ci20-CPU-IngenicJZ4780-mipsel-Release-Android,Test-Android-Clang-Nexus10-CPU-Exynos5250-arm-Release-Android,Test-Mac-Clang-MacMini6.2-CPU-AVX-x86_64-Release,Test-Ubuntu-GCC-GCE-CPU-AVX2-x86-Debug,Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Debug
Change-Id: I439463cf90935c5e8fe2369cbcf45e07f3af62c7
Reviewed-on: https://skia-review.googlesource.com/13921
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Matt Sarett <msarett@google.com>
- Move to SkJumper_vectors.h
- Fold the -127 and +2.774485010.
- approx_powf(F,F) instead of approx_powf(F,float) for consistency.
- A little layout reformatting.
Change-Id: If9cb3d62a097cb6ecf89f157a1dde672c1516371
Reviewed-on: https://skia-review.googlesource.com/13865
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Have the callsites of SkOpTAllocator call SkArenaAlloc directly.
Bug: skia:
Change-Id: Ic54e92c3e9a0abed038aa3ae40e8a195895af99d
Reviewed-on: https://skia-review.googlesource.com/13870
Reviewed-by: Cary Clark <caryclark@google.com>
Commit-Queue: Herb Derby <herb@google.com>
These are the remaining instances, and they're harder to deal with:
$ git grep pragma
recipe_modules/swarming/api.py: except self.m.step.StepFailure as e: # pragma: no cover
recipe_modules/swarming/api.py: if len(ids) > 1: # pragma: nocover
recipes/ct_skps.py: if api.path.exists(version_file): # pragma: nocover
recipes/ct_skps.py: if api.path.exists(blacklist_file): # pragma: nocover
recipes/upload_nano_results.py: if len(results) != 1: # pragma: nocover
Bug: skia:6473
Change-Id: If75e2ffcf39a944b513b9005bbc4bd9c4fb031f6
Reviewed-on: https://skia-review.googlesource.com/13867
Reviewed-by: Ravi Mistry <rmistry@google.com>
Commit-Queue: Eric Boren <borenet@google.com>
Bug: skia:6473
Change-Id: I90c1c3a3108ce583df60933150d97b426173a315
Reviewed-on: https://skia-review.googlesource.com/13840
Reviewed-by: Ravi Mistry <rmistry@google.com>
Commit-Queue: Eric Boren <borenet@google.com>
Bug: skia:
Change-Id: Ic0dcca7a5dd21f1bfd1e40c78f98ac4c9f7e9ee5
Reviewed-on: https://skia-review.googlesource.com/13815
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
I've tried a couple of ideas for approx_powf():
1) accumulate integer powers of x, then 4th roots, then 16th roots
2) continue 1) all the way to 256th roots
3) decompose into pow2 and log2, exploiting IEEE float layout
4) slightly tune constants used in 3)
5) accumulate integer powers of x, then 3+4) with different tuning
6) follow a source online, basically 5 with finesse
7) a new source quoting and improving on the method in 6).
7) seems perfect, enough that maybe we can explore improving its speed
at cost of precision. Might be nice to get rid of those divides. If we
allow a small tolerance (2-5) in our tests, we could use the very simple
fast forms from 3) (e.g. PS 5). I wish I had some images to look at!
Anything involving roots seems to be subverted by poor rsqrt precision.
This change of course affects the pipelines created by the tests for
exponential and full parametric gamma curves. What's less obvious is
that it also means SkJumper can now for the first time run the pipeline
created by the mixed gamma curves test. This means we now need to relax
our tolerance for the table-based channel, just like we did when
implementing table_{r,g,b,a}.
This took me an embarassingly long time to figure out. *face palm*
Change-Id: I451ee3c970a0a4a4e285f8aa8f6ef709a654d247
Reviewed-on: https://skia-review.googlesource.com/13656
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Matt Sarett <msarett@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Change-Id: I7fab6d1c7240c17f2cc8436e8c6e7c8d2df940bb
Reviewed-on: https://skia-review.googlesource.com/13814
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Test for degenerate values after computing the ratio, instead of
attempting to catch all tricky cases upfront.
BUG=skia:6511
Change-Id: I8e3421675994dd68a1eff1af3f1456917dd1f9e1
Reviewed-on: https://skia-review.googlesource.com/13726
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
This reverts commit 4dbc9cead9.
Reason for revert: flaky?
Original change's description:
> Recipes: Use strict coverage, part 2
>
> Bug: skia:6473
> Change-Id: Ia3a1587215a6a868c9577f2d864bc5c4e671a3fa
> Reviewed-on: https://skia-review.googlesource.com/13812
> Reviewed-by: Ravi Mistry <rmistry@google.com>
> Commit-Queue: Eric Boren <borenet@google.com>
>
TBR=borenet@google.com,rmistry@google.com,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: Id746de56609fbaf5ec8ecdd22b5e60bcb3c01fa2
Reviewed-on: https://skia-review.googlesource.com/13819
Reviewed-by: Eric Boren <borenet@google.com>
Commit-Queue: Eric Boren <borenet@google.com>
Just a refactor - reimplements the shader xforms with makeColorSpace().
11 gms have diffs. Some are down to floating precision. The old
implementation would go float->fixed->float in some cases. Others
are due to improvements with gradient shaders inside local matrix
shaders.
Bug: skia:6516
Change-Id: I424406990c5c58a47833cf4c9ef146cd3ea6c37e
Reviewed-on: https://skia-review.googlesource.com/13769
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Matt Sarett <msarett@google.com>
