This removes the assert from the SPIR-V generator so the
tests compile. The generated SPIR-V is incorrect. The next
CL fixes the generator, and restores the assert.
Change-Id: I77b507cf7fb5eac481322887000bd1c73cd5c899
Bug: skia:13219
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530336
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This is a reland of commit 60ff0facbf
Structs are now deduplicated using a [Type*, SpvId] map.
Original change's description:
> Use op cache when emitting types.
>
> We no longer need to maintain a separate `fTypeMap` for mapping types
> to SpvIds, since the op cache handles this automatically.
>
> We also now support deduplicating instructions that don't have a result,
> such as decorations. (In particular, we needed to avoid emitting the
> SpvDecorationArrayStride op every time the array type was accessed, but
> this op doesn't have a result ID.)
>
> Change-Id: I779b8c8e3de5973b8f487b28c0a8ece9a1041845
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/529732
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: John Stiles <johnstiles@google.com>
> Auto-Submit: John Stiles <johnstiles@google.com>
Change-Id: I9f6a78d58e8af38a1fd690a8860d8b5aa3193be6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/529748
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Change-Id: I800fa2a1fb0e64ad478c76ea2d5cda176ea8f48b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/529746
Auto-Submit: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This reverts commit 60ff0facbf.
Reason for revert: Broke D3D bots
Original change's description:
> Use op cache when emitting types.
>
> We no longer need to maintain a separate `fTypeMap` for mapping types
> to SpvIds, since the op cache handles this automatically.
>
> We also now support deduplicating instructions that don't have a result,
> such as decorations. (In particular, we needed to avoid emitting the
> SpvDecorationArrayStride op every time the array type was accessed, but
> this op doesn't have a result ID.)
>
> Change-Id: I779b8c8e3de5973b8f487b28c0a8ece9a1041845
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/529732
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: John Stiles <johnstiles@google.com>
> Auto-Submit: John Stiles <johnstiles@google.com>
Change-Id: I0e2187f88f2a945fd6f88ce75ff815e03d2f7df5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/529747
Auto-Submit: Brian Osman <brianosman@google.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
We no longer need to maintain a separate `fTypeMap` for mapping types
to SpvIds, since the op cache handles this automatically.
We also now support deduplicating instructions that don't have a result,
such as decorations. (In particular, we needed to avoid emitting the
SpvDecorationArrayStride op every time the array type was accessed, but
this op doesn't have a result ID.)
Change-Id: I779b8c8e3de5973b8f487b28c0a8ece9a1041845
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/529732
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Previously, we stringized the types and put them into fTypeMap. Using
the op cache is a simpler mechanism that should work equally well.
Output diffs are almost all ID reorderings. In a few cases we
managed to deduplicate function types that stringize differently but
come out the same in SPIR-V (e.g. no float/half distinction).
Change-Id: If7de5b2dafa12d05c3c2c497a243e9e3908dfee7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/529805
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Change-Id: I3f6e25ec7b31339bfc9bd2435bc9226e6d9be06b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/529498
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Change-Id: Ic19d7591c90f75f04dd1c58b406f2b770f9780c7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/529351
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
If we start with an OpConstantComposite, then we do an
OpCompositeExtract from it, we can look up the result directly from op
cache and avoid doing any work. This helps our matrix code a lot.
Change-Id: Idfbdc0c69676b9c1e91cdc57bf0d6382b9b5d8d4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/529339
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Previously, we didn't usually generate OpConstantComposite ops for
matrices. Now, a matrix assembled from constants should come out as a
constant.
Change-Id: I458718901686dffb84e4079a81017d61195420d3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/529338
Reviewed-by: Arman Uguray <armansito@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
The output changes here are almost entirely a wash, because we already
had support for caching scalars and vectors. Almost all changes are just
inconsequential reorderings of IDs, and the removal of RelaxedPrecision
decorators on constants (which were not meaningful).
Change-Id: I45340c4a240cb504b7c4a934b3db178d2f39ec99
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528709
Reviewed-by: Arman Uguray <armansito@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
* Wire up the WGSLCodeGenerator to SkSLCompiler.
* Wire up build rules to generate WGSL from unit tests.
* Include HelloWorld.sksl as the first complete program.
Bug: skia:13092
Change-Id: I283cf5971b6856126b9fc23340afacff5cc54697
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/526760
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Arman Uguray <armansito@google.com>
Previously, we used unscoped blocks for two similar functions:
- Rewrite one statement as two simpler statements:
`int a, b;` -> `int a; int b;`
- Group together multiple statements without braces. e.g. the inliner
uses unscoped Blocks to rearrange statements.
Conceptually, these are different from the debugger's perspective. The
compound statements should be treated as one unit; the grouped
statements should be treated individually (and the enclosing Block
should be ignored). A Block now contains a BlockKind enum to
distinguish between these cases.
Change-Id: Ie14a570bb46992689fb96b8fd3b67f2ca6e5239f
Bug: skia:13189
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528655
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
`writeComposite` can write and deduplicate constants, so it's preferable
to manually emitting an OpCompositeConstruct opcode.
Change-Id: I0c4ac8f8a456c8561c0b6a90cd316934f20895e8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528638
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
`writeComposite` can write and deduplicate constants, so it's preferable
to manually emitting an OpCompositeConstruct opcode.
Change-Id: Ie5c23af76822da762eadac8ff0ab0c6cc0febd31
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528637
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Some GPUs (Adrenos in particular) perform noticeably better when we
use OpConstantComposite instead of OpCompositeConstruct. This also gives
us some deduplication of redundant ops.
Change-Id: I53b7a3e1cf61e51647a661a08ff4c7b53ee60f10
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528636
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This adopts a trick from SkVM to avoid sorting entirely.
Change-Id: I586c8a3613b48241842a7d8eba1c9d68a4717f83
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528368
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Blocks did not previously track their position, creating problems
reporting some errors (which will be improved in followup CLs). Fixing
block positions changed the reporting of do loop errors, requiring do
loop position tracking to be updated as part of this change.
Change-Id: I3bd048a62d912914edf679f42607de1b5eafc2b9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528045
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Caveat: on my machine, Nanobench doesn't detect any change (pro or con)
on this CL.
I'm working under the assumption that function calls have a non-zero
cost--they may be inlined (bloating code size), or not (incurring the
costs of a function call, register push/popping, etc). This CL avoids
making six calls to $blend_set_color_saturation by using two half3
variables. These half3s are used to swizzle the result--they contain two
zeros and a one, so multiplying them by a scalar will put the result in
the desired component. I've also made some very minor simplifications to
the math that were made possible by reordering.
Change-Id: I0c1ef88d165365376078846324be8bb723548512
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528043
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
A ternary of the form `anything ? value : value` can be reduced to a
comma-expression of the form `anything, value`. This seems like a rare
case in real code, but it's easy enough to detect with our existing
toolbox.
The `anything` test-expression will be eliminated from the expression
if it has no side effects, using our existing constant-folding rules
for the comma expression.
Change-Id: I1285b04cd6a08f1bed614aa1aa6f37ea2447de91
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528439
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Previously, when we vectorized scalars, we would not place them in the
constant buffer, so we could emit simple vectors like (0,0,0) or (1,1,1)
more than once. Now, we use `writeConstructorSplat` to vectorize, which
knows how to write constants.
Change-Id: Ic97c0ce5415fd46ff8c7fb7dac9205844633ef3a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/527921
Reviewed-by: Arman Uguray <armansito@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Today I learned that `mix(a, b, 1)` can reduce precision. Ternaries do
not suffer from this problem.
Change-Id: I58814d00193ccbff53960030d163d31c49234f6c
Bug: skia:9320
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528161
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
The inliner can do a better job with functions that only have a single
return by eliding a temp variable. In this case, it was simple to adapt.
Change-Id: I9a5ee26cf546db1b2647cdf95d4cdba6649ea19b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528160
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
SkSL errors now identify the specific range of code they are describing,
rather than just the line number.
Change-Id: Ifabb3148476f9b4cd8e532f23e5b38e1cf33a87e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528039
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
This reverts commit 2e6f60f423.
Reason for revert: draws black incorrectly in various iPhone 8 tests
Original change's description:
> Fix color fringes on blend_hue and blend_saturation.
>
> Previously, we checked for division against zero, but didn't do anything
> to prevent division against extraordinarily small values. Now, we only
> saturate if the delta between max and min is greater than 0.00001.
>
> Change-Id: I7d1df3430941c7e1a7f94e597d5449f9259612d6
> Bug: skia:9320
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/527498
> Auto-Submit: John Stiles <johnstiles@google.com>
> Reviewed-by: Greg Daniel <egdaniel@google.com>
> Commit-Queue: Greg Daniel <egdaniel@google.com>
Bug: skia:9320
Change-Id: Id83376080eed684577b3592c5e1bee3c80fc3fc9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528038
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Derek Sollenberger <djsollen@google.com>
This addresses (hopefully) all of the remaining suboptimal positions in
SkSL error reporting.
Change-Id: I5bc977b03d51153b841a89fa687e54e3e9cb6ec3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/527976
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
This cleans up a lot of positions produced by DSLParser to make them
actually match the ranges of the elements being parsed.
Change-Id: Ic3a9d62c99c4b5f92b84a597a2ceba386bbcc334
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/527501
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
We already performed a matching simplification for `0 - x`, so this
seemed like a straightforward improvement.
Performing this simplification causes the expressions in the test code
to match on both sides (e.g. `-one == -one`) which allows them to fold
away.
Change-Id: Idf87a98024dd6831b45d0384285ead2e2e039493
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/527656
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
We use multiplication by 1 or -1 to branchlessly choose one of `min` and
`max` in the same function.
Change-Id: I44cf747feeae75a9c3e00f36e112e0a429871e86
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/527596
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Hard-light is just overlay with the parameters reversed.
Change-Id: I6cf5963b1252cba3a7b71a56f4094a070188f8b2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/527503
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
These functions were functionally almost identical, except:
- Sometimes sda/dsa are flipped
- Sometimes the saturation is not updated
We now have one method (blend_hslc) which can do all four blend
operations. It takes two new parameters ("flip" and "saturate") to
handle these four variations.
This reduces our shader count on some of our most shader-heavy slides
(e.g. aaxfermodes, xfermodeimagefilter) at a pretty reasonable cost.
Change-Id: Ifa8a48399851a9badb5d50038de1e25e60d44ebd
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/527281
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This will allow expressions like `-x == -x` or `!y == !y` to be detected
as matching expressions (which enables various constant-folding paths).
(Also, migrated the analysis code into a separate cpp.)
Change-Id: I3e317fdaed3762f8fa19e684a5ed557fc9348c7c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/527617
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Followup CLs will improve their output.
Change-Id: I07059348f68cd6cd3154c31a41f81018b26a44e5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/527616
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Previously, we checked for division against zero, but didn't do anything
to prevent division against extraordinarily small values. Now, we only
saturate if the delta between max and min is greater than 0.00001.
Change-Id: I7d1df3430941c7e1a7f94e597d5449f9259612d6
Bug: skia:9320
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/527498
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Change-Id: Ibff49d1928d7f82d04930c8cfd9d574780732c0d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/527497
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
We were not propagating the position into a double-negated expression,
leading to an assertion failure in PrefixExpression.
Change-Id: I1970ff1a06d9631582626c68e151f12f6b3ef278
Bug: oss-fuzz:46381
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/527507
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
We didn't have any existing tests that exercised this path; it is
separate from most operators since it has no C++ equivalent.
Change-Id: I95b538dad01f8c8b122954fb5f66337371a398a8
Bug: oss-fuzz:46289
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/527196
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This is a reland of commit 1aedd5dc11
Original change's description:
> Always apply mipmap sharpening on GPU
>
> Bug: skia:13078
>
> Change-Id: If459a96eba09fb10e967bc364435f79b83fdc1ec
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/522099
> Reviewed-by: Michael Ludwig <michaelludwig@google.com>
> Commit-Queue: Brian Salomon <bsalomon@google.com>
Bug: skia:13078
Change-Id: Ic05b38fc07566f090d609431f2738d64dfdc8a66
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/524218
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This is a reland of commit 355f0f9fa2
Original change's description:
> Change GPU LOD bias to be just shy of -.5.
>
> We want to ensure that when a MIP level is 1:1 with device space
> that kNearest picks that level instead of a larger level.
>
> Bug: skia:13078
>
> Change-Id: I703d08ab394e1d39b31d16946067a2ead415c72a
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/524224
> Reviewed-by: Michael Ludwig <michaelludwig@google.com>
> Commit-Queue: Brian Salomon <bsalomon@google.com>
Bug: skia:13078
Change-Id: I7fc765a8718d770ebdac68adf9c59ff15d8c8451
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/526517
Commit-Queue: Brian Salomon <bsalomon@google.com>
Auto-Submit: Brian Salomon <bsalomon@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
This reverts commit 355f0f9fa2.
Reason for revert: blocking chrome roll, should be #if defined(...) for the guard
Original change's description:
> Change GPU LOD bias to be just shy of -.5.
>
> We want to ensure that when a MIP level is 1:1 with device space
> that kNearest picks that level instead of a larger level.
>
> Bug: skia:13078
>
> Change-Id: I703d08ab394e1d39b31d16946067a2ead415c72a
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/524224
> Reviewed-by: Michael Ludwig <michaelludwig@google.com>
> Commit-Queue: Brian Salomon <bsalomon@google.com>
Bug: skia:13078
Change-Id: I42d6e99509a87f0354f104f2c0177e78cf0d0e21
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/526462
Auto-Submit: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
We want to ensure that when a MIP level is 1:1 with device space
that kNearest picks that level instead of a larger level.
Bug: skia:13078
Change-Id: I703d08ab394e1d39b31d16946067a2ead415c72a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/524224
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
The builtin variable scanner did not check builtin code for the presence
of sk_FragColor, etc. We currently get away with this because none of
the existing builtin code uses a builtin variable.
Now FindAndDeclareBuiltinVariables checks shared program elements too.
Change-Id: Ifb3ee3857ef73b18d9e4f406970f0f67681dd4be
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/525042
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This closes one of the last gaps in SkSL's constant-folding abilities.
Change-Id: I65c0f2e5fe11a7d47ab2069b2992403fca78b8a7
Bug: skia:12819
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/524761
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Arman Uguray <armansito@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
The expression `!x ? y : z` can be optimized to `x ? z : y`, saving a
bit-not. SkVM now supports this optimization.
Change-Id: I06a0d2a716947de1021ba66b054b92e25568c641
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/524226
Reviewed-by: Arman Uguray <armansito@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
SkVM has a `bit_clear` opcode dedicated to the operation `x & ~y`, but
the optimizer was not smart enough to combine a bit-and with a bit-not
and replace it with a bit-clear. Now, it can.
Change-Id: Ida5345c3def0a4bf7afa08bb7f7835e1e2e37677
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/524225
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Arman Uguray <armansito@google.com>
Previously, our ID canonicalization was simply "lower ID numbers before
higher ID numbers" and was done separately at every opcode by taking
the min and max of (x.id, y.id).
Now, this logic is factored out into a helper function
`canonicalizeIdOrder` and has two rules:
- Immediate values go last; that is, "x + 1" instead of "1 + x".
- If both/neither are immediate, lower IDs before higher IDs (as
before)
This change lets us remove a lot of simplification logic. We no longer
need to check for both `x + 0` and `0 + x` when removing no-op
arithmetic; now we can be certain that the immediate will always come
last, so just checking for `x + 0` is sufficient.
Change-Id: I66cc5c23bba414041c0bc556521d3db57fac504d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/524222
Reviewed-by: Arman Uguray <armansito@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This is needed for accurate error reporting when we start reporting
ranges rather than line numbers.
Change-Id: If465317e04685e91ab7c408d29e82028b5d59d1a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/523425
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
A few tests were divided into a Runtime Effect-compatible .rts test, and
a Runtime Effect-incompatible .sksl test.
Change-Id: Ib52554892685bdc44fe3622ab314960ee0962b90
Bug: skia:13042
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/523377
Reviewed-by: Arman Uguray <armansito@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
In a few cases, this involved splitting a test into two (an ES2-
compatible portion and a ES3+ portion).
Change-Id: Ie6f18f787cf7c10696a2841ff538bbe2b95bf50d
Bug: skia:13042
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/523187
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Arman Uguray <armansito@google.com>
Commit-Queue: Arman Uguray <armansito@google.com>
A few tests received minor tweaks to make them Runtime Effect-friendly.
Change-Id: I9b4f66b0974c41d38324dfbb31ac9849338f600a
Bug: skia:13042
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/523186
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Arman Uguray <armansito@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
These are wrapped in an unscoped Block. Previously, we didn't assign any
position to the block, so it was implicitly given the position of its
enclosing statement.
Change-Id: Id320eb1db583acd6ae42deba2fbb0b61033c3936
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/522922
Reviewed-by: Arman Uguray <armansito@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
A few tests received minor tweaks to make them Runtime Effect-friendly.
Change-Id: Icbcedb84b7882e42f21425b2d40d7819705c359e
Bug: skia:13042
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/522918
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
The error was being reported at the position of the var declaration,
rather than the position of the reference. And since the declaration
was in a module, its position was both incorrect (with respect to the
program source) and could be past the end.
Change-Id: I443b9fbbe016c43b93d457abfefd17025e451d8a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/521522
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
This CL switches almost all instances of line tracking over to track
Positions instead. This does not yet add full range support - only the
start offsets will be correct currently. Followup CLs will extend the
ranges to fully cover their nodes.
Change-Id: Ie49aee02f35dcb30a3adb8a35f3e4914ba6939d2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/518137
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Moved the MatrixFoldingES2.sksl test case for matrix construction with
side-effects into a new PreserveSideEffects.sksl test and added new test
cases for various vector and matrix types and constructors. The new test
is written such that none of its contents should be folded away.
Note: This test does not pass on NVIDIA GPUs when using OpenGL as
discussed in skia:13035. Notably, NONE of the increments are executed on
those GPUs as ALL increment expressions seemingly get subjected to
constant-folding. The test is disabled on NVIDIA GPU bots.
This also means that the remaining MatrixFoldingES2.sksl tests now work
on NVIDIA GPUs when using OpenGL (with the exception of Tegra3 + OpenGL
ES).
Bug: skia:13035, skia:11919
Change-Id: I561bb62fe2b6b814ba80fbc492d3885bbcd6b65b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/518278
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Arman Uguray <armansito@google.com>
ES2 disallows opaque types in expressions (other than passing them to
their associated builtin functions). We now enforce a similar
restriction on SkSL opaque types.
While I was there, I added several other cases to the invalid-shader
test to make sure that they were all caught.
I needed to reorder some code to make sure that ternary expression error
messages didn't change. Ternary expressions now check for opaque types
before checking that the left-side type and right-side type are
compatible. This is because we check for "compatible" ternary
expressions by checking if `leftSide == rightSide` would be accepted.
`shader1 == shader2` used to be considered a valid expression for the
purposes of this test, but not anymore.
Change-Id: I62a0a31feca9dadd428da7d1b48d7693c4b6434d
Bug: skia:13026
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/516802
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
The fuzzer discovered that we allow == on void types (confusing the SkVM
backend).
Change-Id: Ia9494642faf67f3f86e3a365807be8bd4a7062e4
Bug: skia:13026
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/516796
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Previously, we would take the vector-folding path for all types. This
didn't cause any problem for scalars, but failed for "zero-size" types
like void. It isn't valid to compare zero-size values, but we currently
don't reject such code (see skia:13026), and the fuzzer noticed this.
It's safest to only run the vector-folding code when we actually have
multiple slots that need to be folded into one result.
Change-Id: I0bc88043d9a4aeea38ae24dc1a6d1a7430d3d7b0
Bug: oss-fuzz:45279, skia:13026
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/516676
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
The slot-assignment logic has been changed to associate slots with
function calls, instead of function definitions. In our test case, you
can now see that the calls to `get` are now mapped to $15, $17 and $18.
This change also jiggles some existing tests and improves their
register allocation slightly (!).
One minor hitch here is that there's no FunctionCall node associated
with main() (it's never explicitly called). However, our slot map key
can be any IRNode, and we know main() can't be called by anyone else,
so it's harmless to use the function definition as the key in this case.
(This entry could probably stay out the map entirely if it made a
difference, but I don't think it matters.)
Change-Id: I68a6ff24cbd3a2db77f24126502bd3d11e8c0962
Bug: skia:13011
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/514578
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
If a function is called multiple times on one line, stepping over that
line does not show all of the function-call results. It only shows the
last result.
e.g. in this example, I have just stepped over the first line which
calls "get" three times. We should see three results, but we only see
one: http://screen/3WfJoZWm77cSexM
In this test you can see that all three calls to `get` are assigned to
the same slot, $15.
Change-Id: Id0c486ef349a1e527001efbcee2ed2b836f56e83
Bug: skia:13011
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/514577
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
I added a comment and didn't rebuild; this shifted line numbers around,
which is reflected in the debug trace opcodes.
Change-Id: I1b8e00ff65557a03483e8d7ff0c4dbec9852866f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/514777
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
The `break_loop` test causes LLVM to get confused and crash when
compiled on some GPUs. The crash goes away if we pass a literal 5
instead of a 5 that is computed at runtime. This also results in a
simpler test for SkVM, for better or worse, but we still have
coverage for dynamic loop exits in other tests.
LLVM crash: https://paste.googleplex.com/4718583155261440
Dangerous shader: https://paste.googleplex.com/4776089520963584
Change-Id: Ic6cbd55a36d2de58e5dd3459d4dfd74acdbc9f91
Bug: skia:13005
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/514538
Reviewed-by: Arman Uguray <armansito@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
MSL does not support the unary "-" operator on matrix types. Similarly
the SPIR-V OpFNegate/OpSNegate operations only work on scalar and vector
type.
* An expression such as "-<mat>" is now transformed to "-1.0 * <mat>" when
generating MSL.
* The same expression now generates a component-wise negation in SPIR-V,
matching what glslang outputs for GLSL.
* A unary "+" is now treated as NOP for MSL, matching the SPIR-V backend.
An expression such as "+<expr>" is now evaluated as "<expr>".
* The shared/Negation.sksl has been moved to folding/ as much of its
contents exercise constant-folding of comparison expressions.
* The shared/UnaryPositiveNegative.sksl test has been extended to
exercise scalar and matrix types.
NOTE: The SPIR-V backend changes have caused a minor re-ordering of SSA
IDs generated when writing out a prefix-expression. The affected gold
files have been updated.
Bug: skia:12627, skia:12992
Change-Id: Iec5cdafc591aed7e49b3b52bda42a02661380bab
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/513976
Auto-Submit: Arman Uguray <armansito@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Arman Uguray <armansito@google.com>
We previously had no way to signal a parse error from arraySize,
resulting in a cascade of additional errors downstream. This tightens
up the behavior and allows us to fail more gracefully.
Bug: skia:12416
Change-Id: I83d3d5bc1dc63395edb325297375a6eb52415817
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/512952
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
On modern hardware, this will give the correct result for `NaN != x`
(true).
Change-Id: I9683f74756da5da5f34ccacec02c1f2449791f26
Bug: skia:12977
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/513317
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Arman Uguray <armansito@google.com>
Commit-Queue: Arman Uguray <armansito@google.com>
I wasn't able to find any other test which exercised child color-filters
or child blenders. (SampleWithExplicitCoord evaluates from a shader.)
Change-Id: I58ecee3beca2d3dc11ded5de0eea031e1d7c3e1e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/507922
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Arman Uguray <armansito@google.com>
Commit-Queue: Arman Uguray <armansito@google.com>
These all stemmed from the same root cause, but are interesting and
distinct enough to include in our error tests.
Bug: oss-fuzz:44555, oss-fuzz:44557, oss-fuzz:44559, oss-fuzz:44561, oss-fuzz:44565
Change-Id: I22c1798809754b4b38c77ffbe369a97c64a2f60e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/507636
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
The fuzzer constructs a long, valid nonsense expression
(x+x+x-x+x-x, etc.) which exceeds parse depth. At that point, the token
stream points to a `+` token. The parser attempts to consume a new
statement but stops in `unaryExpression`; this fails again, due to the
max parse-depth, but doesn't consume a token. The parser continues
trying to parse the statement, but stopping in `unaryExpression`, making
no forward progress in an infinite loop.
I've made a couple of changes as a result.
- Exceeding the max parse depth now sets `fEncounteredFatalError`.
- Encountering a fatal error causes block() to immediately halt. This
actually undoes a few of the arbitrary changes from
http://review.skia.org/506463 but not in a bad way.
- `unaryExpression()` now consumes a token before checking parse-depth.
- `structDeclaration()` had a similar issue where it could potentially
fail without consuming any tokens; this is fixed as well.
- Some unnecessarily-nested logic in ternaryExpression() was flattened
while I tried to ensure that it always consumes a token.
Change-Id: I52c2161965ffbcef1185761ca6897ec1cba5df89
Bug: oss-fuzz:44551
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/507436
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
This enables the SkSL error testing logic for runtime effects. The core
logic is identical, only the ProgramKind differs.
(Error creation scripts: http://go/paste/6413797460803584 with some
light post-processing)
Change-Id: I877205b3cc1014b50ccccf6037a2f4034c07543e
Bug: skia:12665
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/506538
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Previously, when the parser found a bad statement inside a Block, it
would stop processing that Block entirely. This caused our brace
matching to fall out of balance. block() would normally only return once
the Block's closing brace was consumed, but in this case, the closing
brace would still be in the parse stream awaiting consumption even
though block() had returned.
Now, when a bad statement is found inside a Block, we just ignore it and
continue processing. (I tried injecting a poisoned statement as well,
to see if it would affect the test results, but they were identical.)
This seems to generate somewhat better errors.
Change-Id: I8dc781d5602bf99d7610f8280cde8b7c1925cb65
Bug: skia:12868
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/506463
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
std::stringstream has a subtle bug in OS X 10.12. Reading in a too-large
floating point value returns INFINITY but does not set failbit. This
caused SkSL to report a different error message than expected
("floating point value is infinite" instead of "floating-point value
is too large: NNNNN"). We now guard against this case in SkSL::stod by
adding an explicit `isfinite` check.
Bug: skia:12928
Change-Id: I9996e64b69512ea5710e6fc3ff00ad1ad83c247b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/505939
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This breaks on OS X 10.12: http://screen/7A9bumDr8Z4ihcy
Debugging is difficult via a trybot. This CL can be reverted once the
root cause is discovered and fixed.
Change-Id: Ibbfadc9fbe39eb8d1755e6f382b806d1d648a6fe
Bug: skia:12928
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/505803
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
We no longer enforce a particular string form of 3.41e+38.
Change-Id: I33b8a30aa3c7ab54de0c7f4a02181b60cd8f71a3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/505799
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This was (crudely) automated with shell scripts:
http://go/paste/5484300603490304
Change-Id: Ic9e1c93112772d303d1158eb26d995f27b439eba
Bug: skia:12665
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/505637
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This reverts commit 43539c22a2.
Reason for revert: UB fixed at http://review.skia.org/505678
Original change's description:
> Revert "Verify that tests in errors/ actually generate the expected errors."
>
> This reverts commit 8d646c127a.
>
> Reason for revert: triggering UBSAN
> http://screen/887FeQtZWs2A6oo
>
> Original change's description:
> > Verify that tests in errors/ actually generate the expected errors.
> >
> > Error expectations are embedded in the source with a special *%%*
> > marker, like this:
> >
> > /*%%*
> > expected 'foo', but found 'bar'
> > 'baz' is not a valid identifier
> > *%%*/
> >
> > This unit test compiles every effect in errors/ and verifies that it
> > makes an error. It also verifies that the errors returned include the
> > expectations from the *%%* marker section, in the listed order, if any
> > expectations have been listed. (Error expectations are not meant to be
> > exhaustive; additional errors are allowed.)
> >
> > In this CL, I've manually attached error expectations to the first few
> > error tests. A followup CL will (mechanically) add expectations to every
> > error test, based on their current error reports.
> >
> > Change-Id: I4add30fef6419c4d3f8d2a221c5aeb53eee35ae7
> > Bug: skia:12665
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/505399
> > Auto-Submit: John Stiles <johnstiles@google.com>
> > Reviewed-by: Brian Osman <brianosman@google.com>
> > Commit-Queue: Brian Osman <brianosman@google.com>
>
> Bug: skia:12665
> Change-Id: I3bcdbe9fc1abab13656d6462b73f6439967fd96f
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/505642
> Auto-Submit: John Stiles <johnstiles@google.com>
> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bug: skia:12665
Change-Id: I49e23869f4ef383a0b076006e319e0a6d7191cad
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/505643
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
It's undefined behavior to cast a double to an int64 if the double is
out of range. Our SkSL error tests managed to trigger UBSAN on the tree,
pinpointing the issue (which we had already written up a bug for).
Change-Id: Ia06896732223ff310f2c175efcbeb96ba5786fa8
Bug: skia:12863
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/505678
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This reverts commit 8d646c127a.
Reason for revert: triggering UBSAN
http://screen/887FeQtZWs2A6oo
Original change's description:
> Verify that tests in errors/ actually generate the expected errors.
>
> Error expectations are embedded in the source with a special *%%*
> marker, like this:
>
> /*%%*
> expected 'foo', but found 'bar'
> 'baz' is not a valid identifier
> *%%*/
>
> This unit test compiles every effect in errors/ and verifies that it
> makes an error. It also verifies that the errors returned include the
> expectations from the *%%* marker section, in the listed order, if any
> expectations have been listed. (Error expectations are not meant to be
> exhaustive; additional errors are allowed.)
>
> In this CL, I've manually attached error expectations to the first few
> error tests. A followup CL will (mechanically) add expectations to every
> error test, based on their current error reports.
>
> Change-Id: I4add30fef6419c4d3f8d2a221c5aeb53eee35ae7
> Bug: skia:12665
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/505399
> Auto-Submit: John Stiles <johnstiles@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
Bug: skia:12665
Change-Id: I3bcdbe9fc1abab13656d6462b73f6439967fd96f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/505642
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Error expectations are embedded in the source with a special *%%*
marker, like this:
/*%%*
expected 'foo', but found 'bar'
'baz' is not a valid identifier
*%%*/
This unit test compiles every effect in errors/ and verifies that it
makes an error. It also verifies that the errors returned include the
expectations from the *%%* marker section, in the listed order, if any
expectations have been listed. (Error expectations are not meant to be
exhaustive; additional errors are allowed.)
In this CL, I've manually attached error expectations to the first few
error tests. A followup CL will (mechanically) add expectations to every
error test, based on their current error reports.
Change-Id: I4add30fef6419c4d3f8d2a221c5aeb53eee35ae7
Bug: skia:12665
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/505399
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This code should be easily adaptable to matrix-times-vector as well;
just treat the vector as a 1-row or 1-column matrix. I haven't gotten
around to writing tests for this, though.
Change-Id: If59ae52cd12952b44d3574d54398b2dc66edbcc8
Bug: skia:12819
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/505221
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
These tests only generate an error in the SPIR-V or GLSL backends. We
will soon enforce that everything in errors/ must actually fail to
compile.
Change-Id: Ic54707eb3bfa19287b4ed52335066fc0fbf19ec1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/505397
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This mirrors a lot of the existing matrix ES2 tests, but using
non-square matrices. This is still important because a lot of subtle
bugs can slip through the cracks when rows == columns.
Change-Id: I626c4c2b176c8280da64513d16f59e76e726cbe7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/505218
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
GPUs that failed continued to fail when I put in error bars like
`distance(a, b) <= 0.001`, so they're just disabled entirely now.
Presumably their results are very busted.
Change-Id: I0f1b80f661563a20630740f8cfb6ef69f2a47934
Bug: skia:11209, skia:12858
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/503817
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Requires tweaking one inliner test to avoid an Intel driver bug (on
ANGLE).
Bug: chromium:709351
Cq-Do-Not-Cancel-Tryjobs: true
Change-Id: I08fac938396d6b90805ba9650c7a520af888bc12
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/503819
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Test "InlinerHonorsGLSLOutParamSemantics" was failing on Wembley devices
and is now disabled on that GPU.
Also, it turns out that the inliner has ignored functions with out
params for a long time now, but our test names haven't been updated to
account for this. So, did some additional cleanup:
- "InlinerHonorsGLSLOutParamSemantics" (the test in question) has been
moved to shared/ and renamed to "OutParamsAreDistinct."
- Removed test "OutParamsNoInline" as it is functionally the same as
"OutParams".
Change-Id: I1431ed197b9216cb482eee4f5e4eb2579a5303f7
Bug: skia:12858
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/502303
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
sk_SecondaryFragColor corresponds to an ES2-only concept
(gl_SecondaryFragColorEXT) and does not have any SPIR-V equivalent.
Two fixes were needed:
- sk_SecondaryFragColor shouldn't be in SPIR-V code at all. Report it as
an error when it appears.
- We don't stop compilation when this error is reported, so we need to
fix up the assertion that the fuzzer initially discovered.
Specifically, the fuzzer found that the `sk_SecondaryFragColor`
variable never got a SPIR-V ID assigned to it in fVariableMap, so the
compiler would assert when assembling an expression containing that
variable. Now, we make sure to populate fVariableMap with an (unused)
ID in `writeGlobalVar` to avoid this crash.
Change-Id: Ib86919dfc9a325b2b82a7f4b2054b747dad7c32f
Bug: oss-fuzz:44096
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/501976
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Removed a special case from `writeFunctionCallArgument` which avoided
using a scratch variable for out params; now we always use the scratch
variable and copy it back to the original variable at the end.
Change-Id: I0e446a3fde6d19554943384210bd911f6f9c8cfa
Bug: skia:11052, skia:11919, skia:12858
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/501836
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Upcoming dehydration / rehydration changes require $intLiteral and
$floatLiteral to be present in the symbol table (as all other private
types are). It turns out that even with them marked private, having
them in the symbol table allows them to be incorrectly accessed without
error due to a code path that fails to check for private types.
This CL takes care of that and ultimately results in better output from
PrivateTypes.
Change-Id: Ic47b77a770834079f28c3195545a7cabca8e6cb3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/501196
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
GLSL ES2 behavior is explicitly undefined if an out-param is never
written to: "If a function does not write to an out parameter, the value
of the actual parameter is undefined when the function returns."
We do see divergence here in practice: SkVM's behavior (the parameter is
left alone) differs from my GPU's behavior (the parameter is zeroed
out).
SkSL will now report an error if an out parameter is never assigned-to.
There is no control flow analysis performed, so we will not report
cases where the out parameter is assigned-to on some paths but not
others. (Technically the return-on-all-paths logic could be adapted
for this, but it would be a fair amount of work.)
Structs are currently exempt from the rule because custom mesh
specifications require an `out` parameter for a Varyings struct, even if
your mesh program doesn't need Varyings.
Bug: skia:12867
Change-Id: Ie828d3ce91c2c67e008ae304fdb163ffa88d744c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/500440
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Previously, when attempting to cast a huge value to an int, SkSL would
report an error, then return the IR for
`ScalarCast(Int, FloatLiteral(huge-value))` . Now, to minimize the blast
radius of the error, we report the error but return `IntLiteral(0)`.
We've already reported an error, so there's no need to preserve the
value, and zero is less likely to produce follow-up errors.
(A similar approach is used here and worked well: https://osscs.corp.google.com/skia/skia/+/main:src/sksl/ir/SkSLConstructorCompoundCast.cpp;l=57-59)
Change-Id: Ie8e8d48380cb963466d1f47d123d64e3301cf87c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/499563
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
The test input was removed at http://review.skia.org/497742.
Change-Id: I7b30f2f70cd0812b900c9c67b70e742b3d96930a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/499574
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
The test has been moved to shared/, since it's a valid test, but it is
no longer related to inlining, as the inliner no longer attempts to
inline functions with inouts at all.
Also, one function here (outParameterIgnore) actually invoked undefined
behavior and has been removed. According to the GLSL ES2 docs: "If a
function does not write to an out parameter, the value of the actual
parameter is undefined when the function returns." SkVM leaves the value
unchanged, so SKSL_TEST_CPU would pass, but a GPU might clear it (and in
fact, my GPU does).
Change-Id: I77c77ed1354bc980344ec5c406992bd62015f5e5
Bug: skia:11919
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/499752
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Now, constant mat+mat, mat-mat, and mat/mat operations can be optimized
away. mat*mat does not operate componentwise and will need to be
handled differently.
Change-Id: Iabac6e58999eac46c256d7dcdb9b95d05de530bc
Bug: skia:12819
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/498716
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
GLSL supports adding, subtracting, multiplying, and dividing matrices
with scalars. This works by splatting the scalar across every matrix
component and then performing the op componentwise. Our constant folder
now knows how to fold out these simplifications.
Change-Id: Idb8751ec16135e1b61da0d58cfd0505ab31ac087
Bug: skia:12819
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/497738
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
In a followup CL, these will be updated to properly fold.
Change-Id: I20d125c0d54cbbcf12f7d096beda1fdf75e51b65
Bug: skia:12819
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/498617
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Previously, matrix-scalar operations did not actually fold, so the tests
didn't live in folding/. In a followup CL, these will fold.
Bug: skia:12819
Change-Id: I6fdacf89088920719e7666d6c9b05ddffaf6cb6d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/497742
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
SkSL is somehow interpreting a large positive value as a negative one.
Change-Id: I299e0bf389a9fcbfe697741bd33a54df07748753
Bug: skia:12863
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/499556
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
