The copy_constant function did not expect to see a prefix expression.
Change-Id: Id2beb64b8d65f6b35cd68306452104ba28f56f2b
Bug: skia:10734
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317616
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>
We were allowing these ops on floating point types. The resulting GLSL
would fail to compile. We also allowed >>= and <<= on vectors (but not
any of the other bitwise ops).
The newly added unit tests were failing (eg, not catching errors). New
results are correct.
Bug: skia:10707
Change-Id: I97b769f1ce59261361109a71061b42dc8ef3c74b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317393
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Change-Id: I83a38f2c953a560fea3483e95e31df532b90773e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317456
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
We now support building an SkSL golden output twice, once honoring the
custom #pragma settings, and once more ignoring the settings. This
allows us to see the output of the workaround technique, alongside the
"default-settings" output which should not contain a workaround.
To implement this, skslc now supports a flag: --[no]settings.
When it's set, /*#pragma settings*/ comments are honored. When it's not
set, skslc ignores the comments. compile_sksl_tests.py passes this flag
along to skslc.
This approach is not strictly limited to workarounds; the
"TypePrecision" GLSL test was also updated to use this technique.
Change-Id: I79204df047b024533ed6bc1f4c088e0e878d5bb1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317246
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This will allow us to write skslc-based golden tests that deviate from
the standalone skslc settings.
This CL provides six options; more will be added as necessary.
- Default (caps)
- UsesPrecisionModifiers (caps)
- Version110 (caps)
- Version450Core (caps)
- ForceHighPrecision (settings flag bit)
- Sharpen (settings flag bit)
Change-Id: I9b779e039b2f0c0ccf43dca226fb4844aff3526b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317237
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: 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>
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>
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 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>
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>
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>
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>
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>
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>
Our lack of proper caps-bits controls in skslc affects the outcome of
one test: "InlinerWrapsEarlyReturnsWithDoWhileBlock" does not actually
emit the do-while block because the standalone caps bits don't enable
do-while support. This will be fixed in a followup CL that adds caps-bit
support to our tests.
A few tests were renamed for consistency, a few were simplified slightly
and one test was removed because it was simply redundant (there was a
second test that covered the exact same ground as
`ForWithReturnInsideCannotBeInlined`).
Change-Id: I2e3b97cb3aea331b6d806bdb865aa78c35c7a6b9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/316997
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Add a slew of 16-bit instructions for experiments.
I want to try a fixed-point path through SkVMBlitter, continuing to
represent geometry with F32, but color channels in 16 bits, with several
possible representations:
- unorm8 lowp like SkRasterPipeline (0 -> 0.0, 0x00ff -> 1.0)
- 15-bit SkFixed15 fixed-point (0 -> 0.0, 0x8000 -> 1.0)
- 14-bit signed fixed-point (0 -> 0.0, ±0x4000 -> ±1.0)
I'm leaning towards the 14-bit version for being able to hold a good
range of temporary values in [-2,2), or perhaps even a 13-bit analog for
even a little more safety range. Mostly something new to try.
Most of these instructions are pretty obvious, with notes on a few:
vpavgw is an unsigned (x+y+1)>>1, and is useful for converting
unorm8 up to Q14. There are a couple ways to do this pretty well,
and using vpavgw is the best, and uses the fewest instructions:
A) (x << 6) + ( x >> 2) + (x == 255) // Ok approx.
B) (x << 6) + ((x+1) >> 2) // Better approx.
C) vpavgw(x << 7, x >> 1) // Perfect math!
The best good reverse math I've found is (x >> 6) - (x > 16319).
vpmulhrsw is the key to the whole thing as usual, letting us do
16x16->16-bit multiplies. An SkFixed15 multiply is vpmulhrsw
followed by vpabsw (also added here), and a Q14 multiply is
vpmulhrsw followed by a simple <<1.
I've added both signed and unsigned min and max. Not entirely
sure they'll all be used, but I do have my eye on vpminuw as a
single-instruction clamp to [0,0x4000] ~~> [0.0,1.0], treating
any negative Q14 as very large unsigned.
Change-Id: I0db7f3f943ef6c9a600821444cc5b003fe5f675d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317119
Commit-Queue: Herb Derby <herb@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
This reverts commit eaed918a1d.
Reason for revert: fix for skia:10722 at http://review.skia.org/316977
Original change's description:
> Disable whole-program inliner.
>
> This can be re-enabled once the Metal bug with fp_sample_chaining is
> diagnosed and fixed.
>
> A pure rollback led to a merge conflict; just commenting out the line
> that invokes the inliner serves the same purpose.
>
> Change-Id: I4df556ea8cd44349cbca2ea0ec9995dfffeb8aec
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/316937
> Commit-Queue: John Stiles <johnstiles@google.com>
> Auto-Submit: John Stiles <johnstiles@google.com>
> Reviewed-by: Greg Daniel <egdaniel@google.com>
TBR=egdaniel@google.com,johnstiles@google.com
Change-Id: If490609a9f5f0b0e87baf57638a3da865e173b03
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/316996
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Change-Id: I6097f50e7be1fa2f7772f6c454410ecbf3470eea
Bug: skia:10722
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/316977
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
The following conditions lead to the error:
- A pair of nested functions, both of which must be inlined.
- Both inlined functions create a variable with the same name.
- The outer function passes its variable to the inner function.
- The initialization of the inner variable uses the value from the outer
variable.
- The inner function does not mutate the variable, use it as an out-
parameter, or otherwise cause it to receive a temporary copy.
When all these conditions are met, both variable declarations are
inlined as-is without performing any name salting, because it's
seemingly safe to do so. The name overlap issue is not considered in the
safety checks. Inlined variable declarations are not subject to name
salting but they should be; I suspect other adversarial examples could
be crafted as well where unhandled name overlap leads to errors.
Change-Id: Ia754bee8e45c8a5c7548436594bbf04abc7a8396
Bug: skia:10722
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/316945
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
The new test files are intended to be identical to the unit tests in
every meaningful way. (Comments and formatting are not preserved
exactly.) In cases where a unit-test method contained more than one
test, multiple test files were created; in these cases, new names were
invented to match the apparent intent of each invocation.
Followup CLs will continue to migrate additional tests.
Change-Id: I785c6761ba7ee2b25b5ddc0108321734be23b77c
Bug: skia:10694
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/316678
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Change-Id: I56e19153597e2c4393c5821314b82937828c0d50
Bug: skia:10694
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/316569
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This can be re-enabled once the Metal bug with fp_sample_chaining is
diagnosed and fixed.
A pure rollback led to a merge conflict; just commenting out the line
that invokes the inliner serves the same purpose.
Change-Id: I4df556ea8cd44349cbca2ea0ec9995dfffeb8aec
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/316937
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Bug: skia:10679
Change-Id: If464c48b7c31d0d8440d1231d1983829d54ce598
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/315281
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
We still occasionally downcast, so this is not airtight,
but it (1) allows us to know where we are downcasting and
(2) lets us move away from GrContext (and hopefully remove
it sooner than later.)
All three canaries are currently broken =( so here we go!
Bug: skia:104662
Change-Id: I84efe132574690b62ea512e194e4f9e318e9c050
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/316218
Commit-Queue: Adlai Holler <adlai@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
separate step.
This ended up uncovering an optimization bug. SkSLNonConstantCase
started failing; it turns out that the optimizer was never being run on
this test, and so we hadn't noticed that it didn't actually work in the
presence of optimization.
Change-Id: Iff1d330be7534113b86f86b00c39f91282903ae3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/316568
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Golden SkSL outputs are intended to eventually replace the majority of
our unit tests, since they can automatically update themselves when we
change implementation details of the compiler.
If you change the compiler output without updating the Golden files, the
CheckGeneratedFiles housekeeper will be triggered. Set
`skia_compile_processors` or `skia_compile_sksl_tests` to true in your
GN args to regenerate them.
Almost all of the tests from SkSLFPTests.cpp and SkSLGLSLTests.cpp can
be migrated into separate unit-test .fp/.sksl files in a followup CL.
hcm@ has signed off on removing the copyright boilerplate preamble from
our unit test files.
Change-Id: I9e24a944bbac8f8efd62c92481b022a0b1ecdd0b
Bug: skia:10694
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/316336
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
In this CL, the IR generator still performs inlining as well; this will
be removed in a followup CL. However, the optimization pass is able to
find more inlining opportunities because it allows itself to exceed
the 50-IRNode limit when a function is only used once. In our test code
this is uncommon, but in SkSL generated from trees of fragment
processors, it is very common; any FP that is only sampled once tends
to qualify.
Change-Id: I8b2f653b2dd05d4de18bb15f3a4c1f034b8252ad
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/315639
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
We don't expect raw literals to ever appear here; this is a defensive
maneuver. See http://review.skia.org/316440 for an example case where
raw literals accidentally made it all the way to the inlining pass, due
to a missing `coerce`.
Change-Id: I80198f2f135791931aa53e0d6d92f1edfe4fb3b5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/315970
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This CL adds a new type GrDstSampleType to say how we will sample the dst.
We add tracking of the GrDstSampleType in the recording of GrOps and
then during execution passing the information along to the GrPipeline.
In general the tracking of GrDstSampleType is a global state of a GrOpsTask
so it is kept separate fro the DstProxyView which is more specific to a
single Op on the GrOpsTask.
Bug: skia:10409
Change-Id: Ie843c31f2e48a887daf96cee99ed159b196cb545
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/315645
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Constant propagation wasn't performing type coercions, so we'd end up
propagating a constant into its final location and using the constant's
type rather than the destination type. This allowed things like
$floatLiteral to sneak into final output.
Change-Id: I5b63c70370095e291dea6374e139329b695fa0b0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/316440
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Auto-Submit: Ethan Nicholas <ethannicholas@google.com>
Four of the first 12 cases in the new unit test previously failed (the
logic to reduce from vector to scalar type coercion didn't test the
reverse order, so (half * float4) would only test if (half * float) was
possible going right-to-left.
Also, the matrix multiplication logic was missing a check when doing *=,
allowing things like (matrix *= vector) to compile (then fail later in
GL, etc.)
Finally, we were never checking if the op was valid for vectors when
doing the vector/scalar combination. Added test cases to
BinaryTypeMismatch that previously failed, and now work.
Change-Id: I1e2709e3ba4df31f9300672189826151eabe017a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/315964
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
This will be especially important once more aggressive inlining is
enabled, as the optimizer will need to run dead-function elimination
passes after inlining.
Change-Id: I8ccd5d6a9a041ee2b0a3ec5ef305e5df875b6947
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/315738
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Inlining shift=8 is trivial for any compiler.
This eliminates the need to unit test the two functions are the same.
Change-Id: Icd181ff11eab73fba26755a9fbecd57260c38bbf
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/315887
Commit-Queue: Mike Reed <reed@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Encountered while debugging new GrClipStack.
Basically, with the old checks, if aCorner == bCorner but A was a rect,
we'd end up rejecting it as not a viable intersection (failing the
testCorner == aCorner checks), but wouldn't fall through to the
testCorner == bCorner checks.
Instead of splitting the if-elseif-else into separate ifs, I chose to
add an additional if case that lets the ellipse containment check match
a few more cases when we know the two ellipses share an anchor point.
Change-Id: I6c8bc9a30d19a56f25da7d9be7832ff72dde1765
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/315636
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Moved the actual field into the base class, changed all of the enums
into non-overlapping enum classes, and finally renamed Type::Kind to
fix the ambiguity there.
Change-Id: I4e6c24d2dbbc7b1d12b7b7bf12e77c651eea7ed9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/315318
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
These changes don't seem to add much value in isolation, but they will
smooth our transition to inline analysis during optimization.
- The passed-in FunctionCall no longer needs to be a unique_ptr.
- The fInlinedBody is guaranteed to be a Block now. (This change caused
a slight ripple effect in unit test output; in some cases it creates
an additional newline in the final code. This is harmless.)
- has_early_return is checked earlier, before we've made any mutations
to the FunctionCall. This should work around errors that can occur if
a function is trying to inline itself. (Ideally we wouldn't be trying
to do this at all, but either way, we shouldn't crash.)
Change-Id: I0a565d477f680c0ba061df2686a36e42aa75de95
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/315599
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 is a reland of ed63444587
Original change's description:
> Add idea of DataType to SkYUVAPixmapInfo.
>
> DataType describes the data type of YUVA channels
> independent of how they are grouped into planes.
>
> Adds mapping functions between SkColorType/channel count
> and DataType.
>
> SkYUVAPixmapInfo can be constructed from DataType and will
> choose appropriate SkColorTypes for each plane.
>
> Valid SkYUVAPixmapInfos now have the same DataType for each
> plane (could relax this in the future, esp for alpha plane).
>
> SkYUVAPixmapInfo::SupportedDataTypes specifies the supported
> combinations of SkYUVAInfo::PlanarConfig and
> kYUVAPixmapInfo::DataType supported by a GrContext (based on
> supported texture formats).
>
> SkImageGenerator/SkCodec YUVA query API now takes a
> SupportedDataTypes.
>
> Change-Id: I8791234638e6ba3396d1e7960b7bc210edc6dd57
> Bug: skia:10632
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/314276
> Reviewed-by: Leon Scroggins <scroggo@google.com>
> Reviewed-by: Robert Phillips <robertphillips@google.com>
> Commit-Queue: Brian Salomon <bsalomon@google.com>
Bug: skia:10632
Change-Id: I35b55b7477c11c822fdb3729a9f84acff1eb785d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/315284
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Mechanically updated via Xcode "Replace Regular Expression":
typedef (.*) INHERITED;
-->
using INHERITED = $1;
The ClangTidy approach generated an even larger CL which would have
required a significant amount of hand-tweaking to be usable.
Change-Id: I671dc9d9efdf6d60151325c8d4d13fad7e10a15b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/314999
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
All tests are now GLSL-based instead of .fp based, for ease of
readability. DEF_TESTs which called test() more than once have been
split up into a separate individual DEF_TEST for each test() call, to
simplify fixups going forward.
Change-Id: I9202e95e9cafff3efc0c32aa3f3ca2eea04719fe
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/314886
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This reverts commit ed63444587.
Reason for revert: trying to unblock android roller, which incorrectly thinks this has a merge conflict: https://b.corp.google.com/issues/167576324
Original change's description:
> Add idea of DataType to SkYUVAPixmapInfo.
>
> DataType describes the data type of YUVA channels
> independent of how they are grouped into planes.
>
> Adds mapping functions between SkColorType/channel count
> and DataType.
>
> SkYUVAPixmapInfo can be constructed from DataType and will
> choose appropriate SkColorTypes for each plane.
>
> Valid SkYUVAPixmapInfos now have the same DataType for each
> plane (could relax this in the future, esp for alpha plane).
>
> SkYUVAPixmapInfo::SupportedDataTypes specifies the supported
> combinations of SkYUVAInfo::PlanarConfig and
> kYUVAPixmapInfo::DataType supported by a GrContext (based on
> supported texture formats).
>
> SkImageGenerator/SkCodec YUVA query API now takes a
> SupportedDataTypes.
>
> Change-Id: I8791234638e6ba3396d1e7960b7bc210edc6dd57
> Bug: skia:10632
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/314276
> Reviewed-by: Leon Scroggins <scroggo@google.com>
> Reviewed-by: Robert Phillips <robertphillips@google.com>
> Commit-Queue: Brian Salomon <bsalomon@google.com>
TBR=bsalomon@google.com,robertphillips@google.com,scroggo@google.com
Change-Id: I72c39539a4766f10cac3ca3cdef6c503a8319ff1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:10632
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/314895
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
