Tracking and line spacing computations require knowledge of cumulative
values for the whole line => we need two passes:
1) compute cumulative values
2) compute per-fragment position adjustments
Currently, #1 is implemented in the main onSync() loop (as we iterate
to compute fragment props) and #2 is post-applied via adjustLineProps(),
after the main loop.
The problem is adjustLineProps() is executed after positioning glyphs on
path, and tracking is not taken into account for path positioning
(instead it moves glyphs horizontally, unrelated to the path).
To fix this, we need tracking adjustments to be applied before
positioning on path (which is performed in fragmentMatrix()).
- move the cumulative tracking computation to a dedicate lambda
(compute_linewide_props)
- move the fragment position adjustments to the main onSync() loop
(that way they participate in path positioning)
- to avoid executing the first pass unnecessarily, add flags to detect
the presence of tracking and line spacing animators.
Change-Id: Ieef2afb53ffe14177eba0ef41dc5c71149cab070
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/518696
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
Commit-Queue: Florin Malita <fmalita@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>
This relands commit 4d6d9e3f89.
Original change's description:
> [skottie] Max lines text auto-sizing constraint
>
> Introduce a new text property ("xl"), to limit the number of lines when
> auto-sizing.
>
> This is a Skottie extension, pending UI/controls in Bodymovin.
>
> Change-Id: Id0f1e633e1b324a97b227d6b187cd540990796a7
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/518498
> Reviewed-by: Ben Wagner <bungeman@google.com>
> Reviewed-by: Jorge Betancourt <jmbetancourt@google.com>
> Commit-Queue: Florin Malita <fmalita@google.com>
Change-Id: Ib9d28366332866d8b787f89fa1dc13132c02b435
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/518699
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Florin Malita <fmalita@google.com>
Introduce a new text property ("xl"), to limit the number of lines when
auto-sizing.
This is a Skottie extension, pending UI/controls in Bodymovin.
Change-Id: Id0f1e633e1b324a97b227d6b187cd540990796a7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/518498
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Jorge Betancourt <jmbetancourt@google.com>
Commit-Queue: Florin Malita <fmalita@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>
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>
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>
Co-authored with Ben Wagner, bungeman@google.com.
Similar to how we allow configuration of variable font configurations,
provide additional SkFontArguments to select a base palette and a set
of potentially sparse color overrides.
This is required for implementing CSS font-palette.
Modify the more_samples-glyf_colr_1.ttf to have two additional palettes,
and two additional test glyphs, one that draws with COLRv0 logic, one
that draws with COLRv1 logic and has a foreground palette index dot
in the middle. See [1] & [2] for the additions to the test font.
Add a GM which tests this on the SkFontMgr_custom using makeClone() and
makeFromStreamArgs(). The test displays the two glyphs in default
palette on the left, then with palette overrides (as in the title of the
test) on the right. The first row uses a typeface created with
makeFromStreamArgs(), the second uses one created with makeClone().
[1] https://github.com/googlefonts/color-fonts/pull/91
[2] https://github.com/googlefonts/color-fonts/pull/92
Bug: skia:12730, chromium:1170794
Cq-Include-Trybots: luci.skia.skia.primary:Test-Android-Clang-GalaxyS20-GPU-MaliG77-arm64-Release-All-Android_NativeFonts,Test-Debian10-Clang-GCE-CPU-AVX2-x86_64-Debug-All-NativeFonts
Change-Id: Ia1334f069240edc78fd4791969914e8a6f4fbaf9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/479616
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
The SkRuntimeEffect fuzzer no longer uses the final 256 bytes of each
shader as uniform data, making this corpus obsolete.
(Fuzzer corpus change: https://github.com/google/oss-fuzz/pull/7266 )
Change-Id: I3df9213520390249f401c83c13f0bca5c7f0dde4
Bug: skia:12781
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/508036
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>
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>
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>
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>
Let variable axes override existing or determine style information
with priority over FreeType face flags or information
from the OS/2 table.
Add test case for matching a variable fonts through SkFontMgr_FCI to
ensure the weight determination from variable axes is exercise.
The test does not exercise width or slant.
Add a small (~8.5k) subsetted Noto Sans CJK collection as a test font
(made using [1]), and ensure that matching, reported font style and axis
configuration are correct after matching.
[1] https://github.com/drott/noto-cjk/blob/subsetVFttv/subsetvf.py
Bug: skia:12864, skia:12881
Change-Id: I1fb05d88f68eda308b8864d32d98400c68e46834
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/500516
Commit-Queue: Dominik Röttsches <drott@chromium.org>
Reviewed-by: Ben Wagner <bungeman@google.com>
Auto-Submit: Dominik Röttsches <drott@chromium.org>
Commit-Queue: Dominik Röttsches <drott@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>
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>
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>
The current implementation uses multiplicative composition for opacity
animators (modulate_opacity always scales the new opacity by the old
value). That means that if one animator drops opacity all the way to
zero, there is no way for subsequent animators to increase opacity.
Instead, AE seems to use the same interpolation as for colors
(prev value/animator value, based on modulation param).
Update to use similar interpolation for opacity properties, and also
to only apply when opacity props are actually specified for a given
animator.
Change-Id: I5a96f9e3722399c8ec661a7843c86dfa60eac5ca
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/499376
Reviewed-by: Jorge Betancourt <jmbetancourt@google.com>
Commit-Queue: Florin Malita <fmalita@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>
Some paths through swizzle optimization would replace a swizzles with a
constructor--e.g. `float3(1, 2, 3).y` would be replaced with `float(2)`.
(Constructor::Convert was responsible for replacing this trivial
constructor with the literal `2.0`.)
The optimization code asserted that this replacement would succeed, but
the fuzzer managed to construct a counterexample where the constructor
rejected the value. Specifically, by nesting casts between int3 and
float3, it found a case where Constructor::Convert returned null because
the literal value was out of range for `int` types.
This assertion didn't really add value so removing it was harmless.
Constructor::Convert already reports an error when it fails, and null
returns are handled properly throughout.
Change-Id: I575d441ed90d6b696f6399941c3f6d84698794bc
Bug: oss-fuzz:44045
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/499382
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
These identifiers are reserved for SkSL internal use (and can't be
exposed to GLSL or Metal anyway).
Change-Id: Id554cbf21ed2fb66785e77700ff79424ecdf66db
Bug: skia:12854
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/498036
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
The change in [1] is likely responsible for a regression in which we're
not taking into account P2 for gradient skewing anymore.
Fix that, and add a test case to the gradient set of test cases.
Source for test glyph, see here:
https://github.com/googlefonts/color-fonts/pull/90/files
[1] 2da029b28f
Cq-Include-Trybots: luci.skia.skia.primary:Test-Android-Clang-GalaxyS20-GPU-MaliG77-arm64-Release-All-Android_NativeFonts,Test-Debian10-Clang-GCE-CPU-AVX2-x86_64-Debug-All-NativeFonts
Bug: skia:12822, chromium:1287162
Change-Id: I8b790e2a5c6c04487118306b4b38b1d77349431d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/494676
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Dominik Röttsches <drott@google.com>
Adding tests for matrix math and comparison
bug: skia:12681
Change-Id: Ia1537ee2e411383749456fd6ff938b7c9a2e1061
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/493416
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Julia Lavrova <jlavrova@google.com>
This looks like the GLSL driver in iOS generates wrong results when
returning a value from inside a switch.
Change-Id: I478a045c64c3dae9824f86f52e0c7f8f9685c9af
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/494476
Reviewed-by: Joe Gregorio <jcgregorio@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Change-Id: I3dabd77890a73ea054bb57d466a6ed8273eae3e8
Bug: skia:12811
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/494196
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Change-Id: Iecf1313af5f2938cb899f2a3e750ffc04554bae0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/493977
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>
