Generally this was a performance win, even on devices without AVX due
to unrolling, but on ARM+NEON it looks like that unrolling hurt a bit.
while (...) { blend a pixel }
~~~>
while (...) { blend two pixels }
if (n % 2) { blend last pixel }
BUG=chromium:555278
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Review URL: https://codereview.chromium.org/1465483002
- Fold Or, Or3, Or4 into one flexible Or.
- Fold Pattern1...Pattern7 into one flexible Pattern.
- Rename Star Greedy
Still fighting with a flexible get<N>() method instead of first, second, third, etc.
BUG=skia:
Review URL: https://codereview.chromium.org/1465443002
In function void test_GLPrograms(skiatest::Reporter*, GrContextFactory*):
../../../src/gpu/GrAutoLocaleSetter.h:47:35: error:
als.GrAutoLocaleSetter::fOldLocale may be used uninitialized in this
function [-Werror=maybe-uninitialized]
From Build-Ubuntu-GCC-x86_64-Release-Trybot
Review URL: https://codereview.chromium.org/1456383002
For oval paths, GrPath ignores the point order and only uses the bounds
when building its key. This is problematic because
1) point order is important when dashing
2) GrStencilAndCoverPathRenderer asserts that the lookup SkPath is equal
to the cached SkPath - which is not the case for ovals with different
directions/different point order.
With this CL we no longer use the reduced oval key when dashing, and
instead fall through to the more general path cases. The assert is
adjusted to accommodate "equivalent" ovals (when not dashing).
Also re-enabled & updated the GpuDrawPath unit test (disabled in
https://codereview.chromium.org/1456463003/, presumably due to the use
of uninitialized SkRects).
R=bsalomon@google.com,robertphillips@google.com,cdalton@nvidia.com
Review URL: https://codereview.chromium.org/1457073002
SkPx has triggered a bunch of small (2-9%) regressions on NEON devices.
BUG=skia:
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Review URL: https://codereview.chromium.org/1462783002
Reason for revert:
Causes failures on Android and Win8:
...
( 137/1245MB 9) 73.9ms unit test GpuLayerCachec:\0\build\slave\workdir\build\skia\include\private\skuniqueptr.h:164: failed assertion "get() != pointer()"
Caught exception 2147483651 EXCEPTION_BREAKPOINT
...
Original issue's description:
> Fix NVPR assert for equivalent ovals
>
> For oval paths, GrPath ignores the point order and only uses the bounds
> when building its key. This is problematic because
>
> 1) point order is important when dashing
> 2) GrStencilAndCoverPathRenderer asserts that the lookup SkPath is equal
> to the cached SkPath - which is not the case for ovals with different
> directions/different point order.
>
> With this CL we no longer use the reduced oval key when dashing, and
> instead fall through to the more general path cases. The assert is
> adjusted to accommodate "equivalent" ovals (when not dashing).
>
> Also re-enabled & updated the GpuDrawPath unit test (disabled in
> https://codereview.chromium.org/1456463003/, presumably due to the use
> of uninitialized SkRects).
>
> R=bsalomon@google.com,robertphillips@google.com,cdalton@nvidia.com
>
> Committed: https://skia.googlesource.com/skia/+/f9b1577d763988ebc043ddabf80674f71571ecffTBR=bsalomon@google.com,cdalton@nvidia.com,robertphillips@google.com,fmalita@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1461913002
For oval paths, GrPath ignores the point order and only uses the bounds
when building its key. This is problematic because
1) point order is important when dashing
2) GrStencilAndCoverPathRenderer asserts that the lookup SkPath is equal
to the cached SkPath - which is not the case for ovals with different
directions/different point order.
With this CL we no longer use the reduced oval key when dashing, and
instead fall through to the more general path cases. The assert is
adjusted to accommodate "equivalent" ovals (when not dashing).
Also re-enabled & updated the GpuDrawPath unit test (disabled in
https://codereview.chromium.org/1456463003/, presumably due to the use
of uninitialized SkRects).
R=bsalomon@google.com,robertphillips@google.com,cdalton@nvidia.com
Review URL: https://codereview.chromium.org/1457073002
Reason for revert:
Need to reland with #define guards for tiny layout test changes. (Yikes!)
Original issue's description:
> Fix UB in SkDivBits
>
> DIVBITS_ITER was shifting bits up into the sign bit, which is a no-no.
> This turns numer into a uint32_t to make those defined, and adds a few notes.
>
> x >= 0 is always true for unsigned x, so we needed a few small logic refactors.
>
> BUG=skia:3562
>
> Committed: https://skia.googlesource.com/skia/+/988adddd48322bfa3e3cb0c017cfce71fbbf1123TBR=caryclark@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:3562
Review URL: https://codereview.chromium.org/1457863002
DebugWriteToStderr isn't defined for Android. I'm not sure if I just didn't test compiling for Android or if this is due to a change in the base library.
BUG=skia:
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1438773003
Move createFragmentProcessor to GrTextureProducer base class.
Make non-tiled sw-bitmap draws go through drawTextureProducer.
Review URL: https://codereview.chromium.org/1459433002
DIVBITS_ITER was shifting bits up into the sign bit, which is a no-no.
This turns numer into a uint32_t to make those defined, and adds a few notes.
x >= 0 is always true for unsigned x, so we needed a few small logic refactors.
BUG=skia:3562
Review URL: https://codereview.chromium.org/1455163004
The general SkImage features seem to be tested in
ImageTest instead of SurfaceTest.
Helps in reviewing further reformatting of SurfaceTest.
BUG=skia:2992
Review URL: https://codereview.chromium.org/1452123002
_mm_mulhi_epu16 makes the (...*257)>>16 part simple.
This seems to speed up every transfermode that uses div255(),
in the 7-25% range.
It even appears to obviate the need for approxMulDiv255() on SSE.
I'm not sure about NEON yet, so I'll keep approxMulDiv255() for now.
Should be no pixels change:
https://gold.skia.org/search2?issue=1452903004&unt=true&query=source_type%3Dgm&master=false
BUG=skia:
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Review URL: https://codereview.chromium.org/1452903004
- extract alpha from a pixel: 5 1-cycle ops to 4 1-cycle ops
- load alphas: drop 4 unnecessary ops
Should be no pixel diffs.
BUG=skia:
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Review URL: https://codereview.chromium.org/1447273004
