OpenGL docs specifically insist that the sequence (comma) operator
should not be treated as a constant-expression so that attempts to
declare multidimensional arrays with a comma will fail:
http://screen/vJEpAe9yNmbzZTm
(See "12.43 Sequence operator and constant expressions" in the OpenGL
ES3 documentation or read skia:13311 for details.)
In practice, we don't get much benefit from optimizing away unused
comma-expressions; it improves some synthetic tests, but realistically
this will not help Skia in any real-world scenario. The constant folder
no longer attempts this optimization, and comma-expressions are now
rejected in a constant-expression context.
Change-Id: Ic5dea6ff90e36614b548c1ce89a444e81da944ae
Bug: skia:13311
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/539565
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Arman Uguray <armansito@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
We will continue to fold expressions like `10 + 0` or `5 * 1` or
`PI * 1` (assuming PI is a const float) because both sides are known,
but non-constant-expressions like `x + 0` (assuming x is not a constant)
or `foo *= 1` will be left as-is when the optimizer is off.
This improves the accuracy of the Viewer shader tab, because a runtime
effect expression like `color *= scale` will be preserved in the final
output when optimization is off, instead of being replaced with a Nop
when scale equals one.
Change-Id: I218b327cb0cd12654dca446dee8a5baa96f589b8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/539197
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Fixes a minor issue discovered by http://review.skia.org/539198 .
Change-Id: I63f555cc005df33ce50c412796a8c773a501d271
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/539199
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Previously we didn't have any mechanism for disabling the optimizer when
building golden outputs, so every golden output always had optimizations
applied.
Change-Id: I8f370b06daab6cb50bb4339eab0d39578621413b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/539198
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This node was only used to detect recursion while inlining. We no longer
need to do this, because we disallow recursion in all programs.
The removal of one IRNode per inlined function actually allows for
slightly more aggressive inlining, since we restrict inlining based on
IRNode consumption. This allows the "ExponentialGrowth" tests to inline
a bit more deeply than before.
Change-Id: I894dbb1ca3096bb785b67facb01cc9c630f694c4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/534780
Reviewed-by: Arman Uguray <armansito@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
We enforce no-recursion in all programs now, not just Runtime Effects.
Change-Id: I3737329e4526fa1b7fdbb47ccb959f78f507f665
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/535119
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This limits our error reporting to the first 16MB of SkSL code in a
program, and error marks are limited to a run of 255 characters or
less. In practice, these limits do not affect normal code in any way.
This gives us the same tight memory footprint we originally had when
positions were stored as `int32 fLine`.
Change-Id: Idef04344324870a7b92aca154feb5e1a0121d284
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/533699
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
These were not being generated because they were in the "settings" test
group; we have switch-rewrite settings that also need to be tested.
This was a blind spot in our golden output coverage; without these
tests, there is very little switch-statement usage in our corpus.
They are now in the SPIR-V test group as well.
Change-Id: Ic23b726d00c3047f2d19f7f6dc41e58e600e991c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/534141
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Arman Uguray <armansito@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
We now have a new type of ProgramKind, private runtime shaders.
`sksl_rt_effect.sksl` is now only loaded for these kinds of program.
Rather than having a special-case check for sk_FragCoord in
SkRuntimeEffect, the symbol will no longer exist at all unless a private
options flag is set.
Change-Id: I9223baaf59d74c44d64f322cd57fc841625342b7
Bug: skia:12202
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/532784
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Right now nothing prevents it from working. (skslc doesn't use
SkRuntimeEffect::MakeInternal.) This will be fixed in a followup.
Change-Id: Ib8479220e1f194b035516d976a7369d926a07f5d
Bug: skia:12202
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/532783
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This has two benefits:
1) We get detailed error messages with accurate positions
2) We can actually test these in our golden .rts files.
Thanks to #2, add a new unit test file, and adjust some existing files
that were breaking these rules.
Change-Id: I0b65e2f06f79ce8cbea9bad4c3d27062ec9b6e6c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/532769
Reviewed-by: Arman Uguray <armansito@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Bug: skia:13169
Change-Id: Icf0b720d3e3a13d490aba8495cf9db83d1d62318
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/532762
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
This will allow us to reuse this logic in Graphite.
Change-Id: I649dcd3893a1355af457a2583a6db3066fb87c9a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/532758
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>
Bug: skia:13170
Change-Id: I11ef0ea5ac3ae61b24a47805bb3290a37880cfee
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/532536
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Bug: skia:13173
Change-Id: Ifbcce77605dd781563568293fc501dfa31f143da
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528706
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Bug: skia:13171
Change-Id: I6dffb98ac2464f930995cf8ea57e422091d20fd2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/531743
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
(This mirrors an optimization performed in the constant folder.)
Expressions like `OpIEqual %20 %20` or `OpFUnordNotEqual %15 %15` can be
replaced by `true` or `false` on sight. The GLSL spec makes it clear
that checking for NaN is optional:
4.7.1 Range and Precision
"... NaNs are not required to be generated. Support for signaling NaNs
is not required and exceptions are never raised. Operations and built-in
functions that operate on a NaN are not required to return a NaN as the
result."
Change-Id: I2e29b659a73582e9ade0eb61f70f7d362a007c50
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/531550
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, every expression/statement type was responsible for
pruning or clearing the store-cache when branches were involved. This
was difficult to reason about and easy to get wrong, particularly if
the details are not fresh in your mind.
Now, `writeLabel` takes care of the details for you. Pass in the
location of the branch(es) which use the label, and the proper cache
updating behavior will occur automatically.
Some of the label enum types are not strictly necessary and exist for
the benefit of a reader. Specifically:
- `kBranchlessBlock` and `kBranchIsOnPreviousLine` are synonyms
- `kBranchIsBelow` and `kBranchesOnBothSides` are also synonyms
The hope is that extra enum names will be easier for a reader to
follow, versus fewer but very-verbose enum names (like
`kBranchIsBelowOrOnBothSides`).
This change earned some very minor switch-related dividends. Previously,
every label in a switch was treated as a forward-branch, but in fact,
the very first label in a switch is privileged. This is because we are
branching from the previous line, and the store cache is trustworthy in
this case. (Versus "branching from above," where the store cache needs
to be pruned before it can be trusted.)
Change-Id: I38b539069c22be9f0777b632f60f0eab2409d687
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/531540
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
We now have two functions `writeOpLoad` and `writeOpStore` which are
in charge of writing SpvOpLoad and SpvOpStore instructions.
`writeOpStore` also keeps track of pointer stores in a "store cache."
Subsequent loads from that same pointer will be found in the cache and
will return the value stored in that pointer instead.
Such a cache definitely cannot work in the face of control flow, so we
make the following concessions:
- `pruneReachableOps` is now `pruneConditionalOps`. Any pointers that
are altered inside a potentially-unreachable block are cleared from
the cache entirely.
- The entire store cache is cleared at all OpLabels within a loop.
The cache also cannot work in the presence of swizzled stores, so we
make another significant concession:
- The entire store cache is cleared whenever we store into a non-memory
pointer (e.g., assigning into a swizzled LValue, such as `foo.xz`).
Despite these significant limitations, this manages to dramatically
shrink many real-world examples.
Change-Id: I0981a0cf7b45b064e153e9ada271494c8e00cad5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530054
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Previously, we would determine the operandType by calling
`getActualType`. This function converts half-precision types to full-
precision ones, which seems to have been unintentional. Fortunately, the
operand type is not actually emitted into the SPIR-V by most code paths
(most paths use the resultType instead) so it was not a significant
impact in practice. A few matrix-based paths emitted ops using this type
and these paths now emit RelaxedPrecision as expected.
Change-Id: I32f4c0327427476fee6b78953284818b7970b6e8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530543
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Arman Uguray <armansito@google.com>
Previously, we only handled the simple case of extracting from an
OpConstantComposite. Now we also handle the complex case of extracting
from an OpCompositeConstruct, where vectors can be composed of other
vectors.
This is particularly challenging because OpCompositeConstruct can
contain SpvIds from almost any other instruction, so we need to be
able to decode those instructions and figure out their type. For
instance:
%5 = OpFAdd Vec2 %1 %2
%6 = OpFAdd Scalar %3 %4
%7 = OpCompositeConstruct FloatVec3 %5 %6
%8 = OpCompositeExtract %7 2
The %8 (OpCompositeExtract) could be replaced with %6 but we need to
peek at the type in *both* OpFAdd instructions to decode this. It
only works when the affected instructions are in-cache, so many
opportunities are currently not optimized because their code still
uses the original, uncached form of writeInstruction.
Change-Id: I5719ae6284f32e1d6f2c898eca282c22b94fc764
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/529743
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Bug: skia:13219
Change-Id: I57c5c2aa40e6eb85d5e6045d6f3374d0379efd39
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530337
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
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>
