MetalKit was introduced in iOS 9 and contains utilities for building
applications with Metal. None of these utilities actually seem to be in use.
However, linking against MetalKit means Flutter cannot deploy a unified binary
to iOS 8. This patch removes the unused dependency and unblocks Flutter.
Fixes https://github.com/flutter/flutter/issues/64017
Change-Id: I2cf54a1c95b4c3cda96300861598f2cb23f583d6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/314539
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Xiao Yu <xster@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Turns out Clang's a lot better at auto-vectorizing "obvious" scalar code
into obvious vector code when it's written out the long way, e.g.
F32x4 x = ...;
x = { sqrtf(x[0]), sqrtf(x[1]), sqrtf(x[2]), sqrtf(x[3]) };
vectorizes into sqrtps a lot more reliably than our recurse-onto-scalars
strategy, and also better than the other naive approach,
F32x4 x = ...;
for (int i = 0; i < 4; i++) { x[i] = sqrtf(x[i]); }
So here I've added a map(V, fn) -> V' using C++14 tricks to let the
compiler handle the expansion of x = { fn(x[0]), fn(x[1]), ...
fn(x[N-1]) } for any N, and implemented most skvx scalar fallback code
using that.
With these now vectorizing well at any N, we can remove any
specializations we'd written for particular N, really tidying up.
Over in the SkVM interpreter, this is a big improvement for ceil and
floor, which were being done 2 floats at a time instead of 8. They're
now slimmed way down to
shlq $6, %r13
vroundps $K, (%r12,%r13), %ymm0
vroundps $K, 32(%r12,%r13), %ymm1
jmp ...
where K is 9 or 10 depending on the op.
I haven't found a scalar function that Clang will vectorize to vcvtps2pd
(the rounding one, not truncating vcvttps2pd), so I've kept lrint()
written the long way, updated to the style I've been using lately with
specializations inline.
Change-Id: Ia97abe3c876008228bf62b1daacd6f6140408fc4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317375
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Change-Id: I41402dc04d4388217d7f7cd8de9aff8fbb4a3765
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317391
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
A handful of simplifications were made, but these hew very close to the
original tests and are intended to cover the exact same ground. The
remaining unconverted tests depend on non-default caps bits and will
be updated once caps handling in skslc is fully landed.
Change-Id: I3f3c29bf87f73e501561d7bfcdaabe8acc14b89f
Bug: skia:10694
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317390
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This doesn't affect the results, since the optimizer was already
stripping out identity swizzles, but it saves us from building a node
that we're just going to throw away later.
Change-Id: I61d0e23eafd4596fba4d6268f325c8939ef38dec
Bug: skia:10721
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317378
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Converts examples to use more idiomatic "user" SkSL,
without extra casts, and taking advantage of swizzle.
Change-Id: I4ad4e7b6563b4f09402855cb125546b015622ced
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317388
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This code is overly paranoid, but should be removed soon.
It is just double checking that we have no glyphs
inserted before we insert them from the Renderer
process.
Change-Id: Iaadb229ea034d3d127a9ed191d3fdd77c252a2b9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317387
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
This reverts commit f6e0f58b2e.
Reason for revert: benches and tests updated here: https://skia-review.googlesource.com/c/skia/+/317380
Original change's description:
> Revert "Enable novel GrClipStack on bots, disable elsewhere"
>
> This reverts commit e1ade2ac4a.
>
> Reason for revert: Need to remove benchmarks that use deprecated SkClipOps first.
>
> Original change's description:
> > Enable novel GrClipStack on bots, disable elsewhere
> >
> > As a result of this change, the new GrClipStack will run on all of our
> > default bots. However, the SK_DISABLE_NEW_GR_CLICK_STACK define is used
> > to explicitly disable the clip stack when we build for the Android
> > Framework, Google3, Flutter, and Fuchsia. These projects can have staging
> > controlled from within the skia repo. This CL in chromium also disables
> > the new clip stack: https://chromium-review.googlesource.com/c/chromium/src/+/2412768
> > and must land before this CL does in Skia.
> >
> > When GrClipStack originally landed, I had it disabled by checking the
> > value of the define SK_USE_NEW_GR_CLICK_STACK for 0 or 1. To be a little
> > simpler, and work with the flutter and fuchsia gn defines, this CL
> > switches GrClipStack control over to SK_DISABLE_NEW_GR_CLICK_STACK and
> > it just checks for whether or not it's defined.
> >
> > Bug: skia:10205
> > Change-Id: I6b8bd18290844c02839fe99fdf629b48ffd86f27
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317209
> > Reviewed-by: Robert Phillips <robertphillips@google.com>
> > Reviewed-by: Brian Salomon <bsalomon@google.com>
> > Commit-Queue: Michael Ludwig <michaelludwig@google.com>
>
> TBR=bsalomon@google.com,robertphillips@google.com,michaelludwig@google.com
>
> Change-Id: I14fddccfdea8e91ebad92e55193b0034f8bb28af
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: skia:10205
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317377
> Reviewed-by: Michael Ludwig <michaelludwig@google.com>
> Commit-Queue: Michael Ludwig <michaelludwig@google.com>
TBR=bsalomon@google.com,robertphillips@google.com,michaelludwig@google.com
# Not skipping CQ checks because this is a reland.
Bug: skia:10205
Change-Id: I1f26496437ed04a79e9c1058428cdc867ae3be39
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317385
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Change-Id: I7bc393239dbb66c08fbd24eccfc997adc78248c3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317103
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Bug: skia:10721
Change-Id: Ib9e51b736bafb6e4493db4f50e9835fbd86c415d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317247
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Just return the amount allocated during the merge.
Add TODO to simplify when I'm sure there are no
collisions during the merge.
Change-Id: Ieb568c4096fc547c54303689b232c68d78f3f36b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317382
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Herb Derby <herb@google.com>
This fixes the perf bot crashes from https://skia-review.googlesource.com/c/skia/+/317209
and removes a few other instances of kReplace_ClipOp that are equivalent to the
still supported SkClipOp::kIntersect op. Other than the benchmark case, the GPU
clip stack wasn't hitting these cases but they do need to be updated when the deprecated
ops are fully removed.
At this point, the remaining uses of deprecated clip ops are all in unit tests that
specifically test a clip stack (raster, conservative, or skclipstack) that specifically
supports expanded clip ops and the tests are testing those operations. They can remain
until we remove full support.
Bug: skia:10208
Change-Id: I5703bf43fd41b6addf329190a70c5429d5971240
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317380
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
This reverts commit efc8797880.
Reason for revert: breakage due to std::max initializer list
Original change's description:
> moved BinaryExpression's data into IRNode
>
> This is another step in the process of merging the various IRNodes' data
> into the base class.
>
> Change-Id: Ide39c240e6178e23bb6fe317dd56addf2ffefcbb
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317102
> Commit-Queue: John Stiles <johnstiles@google.com>
> Reviewed-by: John Stiles <johnstiles@google.com>
TBR=brianosman@google.com,ethannicholas@google.com,johnstiles@google.com
Change-Id: Ib8ef629ffa0ff8bb0aeddfa4f42b824e79ce72b6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317384
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
This simplifies life when revising the swizzle logic.
Change-Id: I7fc63c0cc845c4741c17c82b3078040264b61ba0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317379
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This compiles to...
...
vmovdqa (%r12,%r13), %ymm0
vmovdqa 32(%r12,%r13), %ymm1
vpmulhrsw (%r12,%r14), %ymm0, %ymm0
vpaddw %ymm0, %ymm0, %ymm0
vpmulhrsw 32(%r12,%r14), %ymm1, %ymm1
vpaddw %ymm1, %ymm1, %ymm1
...
...which looks perfect. Clever to use vpaddw instead of a shift,
probably saving a byte or two of code. I've followed suit in the JIT.
Change-Id: Id4b87d6034c8505db892eed0da0afd0ac4d46068
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317363
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Implement min and max using if_then_else(y<x,...) on vectors
rather than recursing to std::min/std::max applied to scalars.
But actually, factor out and use naive_if_then_else(), which Clang can
reason through better than it can our specialized if_then_else(). This
lets every min() or max() I've looked at compile down to ideal codegen,
vmaxps, vpminsw, etc, where if you use if_then_else() you'd see the
literal comparison and blend as written.
I've been looking at q14x2 codegen in the interpreter, and most things
were already good, unexpectedly even uavg_q14x2. The biggest surprise
was how bad the min/max codegen was, and looking back, even the min_f32
and max_f32 codegen is super bad. This CL fixes all that, leaving us
with the ideal codegen using the specific instruction you'd want,
replacing a giant mess of code that recursed down to scalars.
mul_q14x2 is still bad, but an easy follow up.
Change-Id: I77b5d7c9aa20a9a2f5ceb3e40f1e18ace2a1b5c1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317310
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This is another step in the process of merging the various IRNodes' data
into the base class.
Change-Id: Ide39c240e6178e23bb6fe317dd56addf2ffefcbb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317102
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
This reverts commit e1ade2ac4a.
Reason for revert: Need to remove benchmarks that use deprecated SkClipOps first.
Original change's description:
> Enable novel GrClipStack on bots, disable elsewhere
>
> As a result of this change, the new GrClipStack will run on all of our
> default bots. However, the SK_DISABLE_NEW_GR_CLICK_STACK define is used
> to explicitly disable the clip stack when we build for the Android
> Framework, Google3, Flutter, and Fuchsia. These projects can have staging
> controlled from within the skia repo. This CL in chromium also disables
> the new clip stack: https://chromium-review.googlesource.com/c/chromium/src/+/2412768
> and must land before this CL does in Skia.
>
> When GrClipStack originally landed, I had it disabled by checking the
> value of the define SK_USE_NEW_GR_CLICK_STACK for 0 or 1. To be a little
> simpler, and work with the flutter and fuchsia gn defines, this CL
> switches GrClipStack control over to SK_DISABLE_NEW_GR_CLICK_STACK and
> it just checks for whether or not it's defined.
>
> Bug: skia:10205
> Change-Id: I6b8bd18290844c02839fe99fdf629b48ffd86f27
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317209
> Reviewed-by: Robert Phillips <robertphillips@google.com>
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Michael Ludwig <michaelludwig@google.com>
TBR=bsalomon@google.com,robertphillips@google.com,michaelludwig@google.com
Change-Id: I14fddccfdea8e91ebad92e55193b0034f8bb28af
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:10205
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317377
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
We're not using -foo today to do anything but print a "sorry" error.
Might as well make it something productive.
In this case, it happens that Codec_PngRoundTrip is flaky on my laptop;
I'm guessing the blame belongs with CoreGraphics. Anyway, this lets me
skip it but run all other tests with a line like
tests -Codec_PngRoundTrip b=cpu
Change-Id: I479a71575eadfc1f870a3c48c130b2b57797ac54
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317316
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
As a result of this change, the new GrClipStack will run on all of our
default bots. However, the SK_DISABLE_NEW_GR_CLICK_STACK define is used
to explicitly disable the clip stack when we build for the Android
Framework, Google3, Flutter, and Fuchsia. These projects can have staging
controlled from within the skia repo. This CL in chromium also disables
the new clip stack: https://chromium-review.googlesource.com/c/chromium/src/+/2412768
and must land before this CL does in Skia.
When GrClipStack originally landed, I had it disabled by checking the
value of the define SK_USE_NEW_GR_CLICK_STACK for 0 or 1. To be a little
simpler, and work with the flutter and fuchsia gn defines, this CL
switches GrClipStack control over to SK_DISABLE_NEW_GR_CLICK_STACK and
it just checks for whether or not it's defined.
Bug: skia:10205
Change-Id: I6b8bd18290844c02839fe99fdf629b48ffd86f27
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317209
Reviewed-by: Robert Phillips <robertphillips@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
I suspected this wouldn't work, but turns out it's fine.
Change-Id: I91042d458804f3a6af29389de5e6622a39cf23e5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317309
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This is by no means perfect or complete but does break up the review.
Bug: 1108408
Change-Id: Ib1826cd40975c7e84b5fdfc16d1ecbec97dab237
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317201
Reviewed-by: Adlai Holler <adlai@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
SkSL::Swizzle objects never represent constant swizzles - they are
directly converted to IR that represents a small sub-tree, up to the
most complex case of:
Swizzle(Constructor(Swizzle(BaseVector), Literals, ...))
GLSL was the only backend that handled arbitrary complex swizzles
correctly in all cases - this change basically moves that logic into the
IR generator, subsumes the (similar) handling of scalar swizzles that
was there, and simplifies the algorithm so that it's all procedural (not
hard-coded based on bit-patterns).
Bug: skia:10721
Change-Id: Iac96a26da517a7b1bdc9905cc38ad727fb68af12
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317238
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
`fBuiltinFMASupport` is now true on both, and
`fUsesPrecisionModifiers` is now false. Other mismatching flags exist,
but they are non-trivial to synchronize as they are tied to extension
strings.
This will help our skslc-based unit tests generate the same results as
our C++ unit tests did, but should not affect real-world results as
these defaults will all be overwritten in a non-testing scenario.
In practice, the `fUsesPrecisionModifiers` change is responsible for all
of the diffs below. The other flags did not change the results of any of
the currently-ported tests.
Change-Id: Ieb056d852b027fa87c56fd89f971a77a10a8a124
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317204
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
In a followup CL, this will allow SkSL golden tests to control their
caps settings.
Change-Id: I2aace30e5567de8a52690c89b27bbab0c2d766e3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317177
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This will help with not getting the index type confused
with other number types. In the future, I'm going to
add information about the glyphs in other parts to
avoid having to actually lookup the glyph.
Change-Id: I8569b8fa1b07e215080dbf5c5783435c35f60388
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317203
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Change-Id: Ib10215e1e5a86bf78cc34f9dca670417bb217b73
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317271
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Change-Id: I41b18bc37ee4eace8512023c64cea7e7975b6167
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317259
Commit-Queue: Herb Derby <herb@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
It shifts a negative number left,
which UBSAN reminds us is not allowed in C++.
Cq-Include-Trybots: luci.skia.skia.primary:Test-Debian10-Clang-GCE-CPU-AVX2-x86_64-Debug-All-SkVM_ASAN
Change-Id: I955d53b677f605b3a0f6e2bd31b16e2cc2f64ac5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317260
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
These tests cover all the new Q14x2 ops.
As usual, left myself a few TODOs...
While working on this, I uncovered a little subtly about the blend
instructions we use to implement Op::select... unlike the platonic
(cond & true_val) | (~cond & false_val)
the hardware istructions are not bitwise! Each of the fancy blend
instructions like vblendvps or vpblendvb has a fundamental granularity
larger than a bit (4 bytes for vblendvps, 1 byte for vpblendvb). If
you're using a mask with a granularity of say, 2 bytes, you need to be
using something with equally fine granularity --- bitwise is ok,
bytewise is ok, 2-byte-wise is ok, but 4-byte-wise isn't.
Took a quick survey, and the Op::select we're using for x86 and ARM
JITs are both bytewise, so I think they're fine. Would have to think
a bit about LLVM, but these unit tests should at least fire if it were
wrong. The skvx if_then_else() I've been using in the interpreter has
been 4-byte-wise, but I'm refining that down to 1-byte-wise with
https://skia-review.googlesource.com/c/skia/+/317170.
Change-Id: I09cbc8b91cdb9e50088ee4f6ddf202faa1bf2cb1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317159
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
The default implementation of if_then_else is logically bitwise,
(cond & true_val) | (~cond & false_val)
The existing skvx specializations work only for 32-bit lanes, but we can
easily make them work for any type where the whole vector is the right
size by reducing the granularity down to byte level.
Existing code using 32-bit values and 0xffff'ffff or 0x0000'0000 masks
will continue to work the same. But this now lets us use, e.g. 16-bit
values with 0xffff and 0x0000 masks, or even things like 32-bit values
and a mask like 0xff00ff00, selecting byte by byte.
We can't go any lower without falling back on the generic bitwise
implementation, so we'll have to settle for not getting to use a mask
like 0x0f0f0f0f.
Change-Id: I8518cb3cafc7f6e1480b4ae8af50daad2d28c5df
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317170
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
If CCPR was enabled on the CLI, it would still be seen for the unit
test. This makes sure CCPR is fully disabled, in addition to the old
setting for disabling other path renderers.
The unit test needs CCPR disabled so that it tests SW mask generation
when CCPR is not available.
Change-Id: I3f728705238121fc179ffd9985f14edad3f8d96e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317236
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
Auto-Submit: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Avoids uninit memory down the line. This wouldn't have cause incorrect
rendering but potentially could have eliminated a batching opportunity.
Change-Id: I5494f13f4a56418f6686d956db4b44ce239f2533
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317205
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Ignores the miter limit if the join type is not kMiter.
Bug: skia:10419
Change-Id: Ib05895cf90c7bb0e25e9e8c3e26c13fef32f2e97
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317163
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Overview doc: https://docs.google.com/document/d/1ddIk74A1rL5Kj5kGcnInOYKVAXs3J2IsSgU5BLit0Ng/edit?usp=sharing
This is the new clip stack that will replace GrClipStackClip. The doc
link in the CL description has a much more detailed overview of what the
strategy of the new clip stack is, but at a very high level:
1. Add a temporary #define that lets SkGpuDevice switch between the old
stack and the new stack. For the new GrClipStack, it extends SkBaseDevice
directly and has to implement all of the device clipping virtuals.
- If you look from patchset 5 and earlier, the define defaults to on
so I can test it on the bots, etc. but the plan will be for it to
default to off when this lands so it's only running on unit tests.
Then in a follow up, I'll turn it on for our bots but keep it off in
chrome and android. If everything looks good, chrome can then be
turned on. There is a more extensive migration plan for android
because of the expanding clip ops, but that is covered at the end of
the overview doc.
2. GrClipStack manages save/restore logic of the stack and extends GrClip,
so the cpp file also includes code to apply a GrAppliedClip. At the moment
the apply strategy is as close to that in GrReducedClip and
GrClipStackClip as I could make it. Down the road, I think we can explore
other analytic coverage options and a clip atlas that replaces the unified
SW mask.
- Once GrClipStack is enabled everywhere, it means GrReducedClip and
GrClipStackClip can be deleted, so I'm not too worried about sharing
code between the two. A lot is already shared through the use of
GrSWMaskHelper and GrStencilMaskHelper.
- SkClipStack and SkClipStackDevice are still used by the PDF and SVG
backends, so they aren't necessarily deletable.
3. The GrClipStack only handles intersect and difference ops. It
represents all geometric clip operations as an element. The stack itself
is controlled by the "save record", which tracks aggregate bounds, valid
elements, and the non-geometric clip shader.
- When a new save record is pushed on the stack, older elements are
inactive. This means they cannot be modified, since they may need to
be activated again when the current save is popped off the stack.
However, they can still affect the clip during application.
- When a new element is pushed on the stack, older elements may be
invalidated. This means they don't need to be considered any more
because they are redundant with the new clip shape (e.g. nested round
rect clips only have to keep the innermost valid).
Bug: skia:10205
Change-Id: I68ccfd414033aa9014b102efaee3ad50a806f793
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/308283
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
This feels pretty awkward, but it's the most straightforward way I see
to do this without Yet Another Canvas Subclass.
Passes at head, fails without
https://skia-review.googlesource.com/c/skia/+/317110.
Change-Id: I67931b5eb8396621aec1858f2d7c4aaadb1b9132
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317161
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This makes our behavior more consistent with drawRect (where we always
sort rects). It also makes it more consistent between CPU and GPU. (CPU
used a technique to implement rect clipping that allowed for unsorted
rects, but GPU's clip stack would reject them as empty).
Fixes https://github.com/flutter/flutter/issues/38753
Change-Id: Ib91ebaf13d08dfe34105b9ee59021ac491d67bc7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317110
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This is a 32-bit pair of Q14 (signed 1.14 fixed point) values.
Q14 * Q14 is (x*y + 0x2000)>>14 but we'll do it as
((x*y + 0x4000)>>15)<<1 to allow use of vpmulhrsw.
Somewhat awkwardly this approximate math does not preserve x*1.0 == x,
e.g. 0x0001 * 0x4000 = 0x0002, not 0x0001. I'm unsure if we'll care.
x*0.0 == 0.0 does always hold, and 1.0*1.0 == 1.0.
Most other operations are normal 16-bit operations.
TODO:
- implmement in interpreter
- unit test
- constant propgation and strength reduction
- implement in JIT
- effect/blitter hooks enough to demo
- thorough effect/blitter support
Change-Id: Ic714fc16b6530259b36300bd042bbfd5a57a663b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317149
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
fuzzers can't build there, but I don't really care.
Cq-Include-Trybots: luci.skia.skia.primary:Build-Debian10-Clang-x86-Debug
Change-Id: Icb729e8802ccd3cdd1e1384d006d46bd7dc2cd08
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317150
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Takes SkYUVAPixmaps. Still implemented in terms of SkYUVAIndex[4]
internally.
Replace all internal use cases except wacky_yuv_formats.
Takes GrRecordingContext rather than GrContext.
SkVideoDecoder updated to take GrRecordingContext.
Bug: skia:10632
Change-Id: I6e9b9b6a4f11333bce6f87c1ebff0acb297f6540
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/316837
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Adlai Holler <adlai@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
GN lists both the .cpp and the .h as generated outputs, so if they don't
exist, Ninja assumes we need to rebuild the tests every time we compile.
Change-Id: I37b8b3d9e7aef1b0cb8d5c70530c2542a6c0087a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317108
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
On Windows, the process output contains CRLF sequences. Calling
splitlines() recognizes those (Python universal line endings), so we get
a list of the output lines. Joining those with '\n' produces a string
that just has LF. (We add another one, so we still end the file with a
newline). Because we've opened the file in binary mode, the resulting
files now look the same, regardless of OS.
Change-Id: I1f032aa6e0f82057f593c25ce0676983733b9e56
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317105
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
