Change-Id: Ic6a3ce722c607d4d3c47d37e5749a01ae5fb193f
Bug: skia:12050
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/412668
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This was originally designated for 2x2 matrices only, but this was not
right--all matrix comparisons actually need to be rewritten to fully
work around the bug.
Change-Id: I743d16a65bc55e93361a3dd8753653384583f063
Bug: skia:11308
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/411416
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This is allowed by GLSL, so we allow it too.
GLSL ES 1.0, Section 6.1: "The idiom “(void)” as a parameter list is
provided for convenience."
Change-Id: I551c505d3de518a75acd5e306f09f0f0767e43f2
Bug: skia:12025
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/411300
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This will allow us to rewrite `mat == mat` on Adreno 5xx/6xx GPUs when
running in GLSL.
Change-Id: I621e918a545a49b7ecb9c944ae59b1e7a7594bae
Bug: skia:11308
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/410996
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This is a reland of c6260f9742
Problematic DeadReturn.sksl test cases have been moved to DeadReturnES3.
Original change's description:
> Eliminate unreachable code during optimization.
>
> The Adreno 5xx and 6xx previously failed the SkSLStaticSwitchInline
> test; the driver struggled to interpret code with multiple return
> statements in a row. We now detect unreachable statements and eliminate
> them.
>
> Change-Id: I344d632f2488ca65b0635b37bebffe6e4fb607c5
> Bug: skia:12012
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/410256
> Auto-Submit: John Stiles <johnstiles@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
Bug: skia:12012
Change-Id: I748e8761cbc71c811b5ad8fe49186f980261d8b9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/410793
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This reverts commit c6260f9742.
Reason for revert: Nexus 7 is grumpy, fails SkSLDeadReturn_GPU
https://ci.chromium.org/raw/build/logs.chromium.org/skia/539fff50ff093c11/+/annotations
Original change's description:
> Eliminate unreachable code during optimization.
>
> The Adreno 5xx and 6xx previously failed the SkSLStaticSwitchInline
> test; the driver struggled to interpret code with multiple return
> statements in a row. We now detect unreachable statements and eliminate
> them.
>
> Change-Id: I344d632f2488ca65b0635b37bebffe6e4fb607c5
> Bug: skia:12012
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/410256
> Auto-Submit: John Stiles <johnstiles@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
TBR=brianosman@google.com,ethannicholas@google.com,johnstiles@google.com
Change-Id: Ia3db1f1b28417e479e2d71a4a6ed94a007e47cf9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:12012
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/410780
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
The Adreno 5xx and 6xx previously failed the SkSLStaticSwitchInline
test; the driver struggled to interpret code with multiple return
statements in a row. We now detect unreachable statements and eliminate
them.
Change-Id: I344d632f2488ca65b0635b37bebffe6e4fb607c5
Bug: skia:12012
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/410256
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Change-Id: I6019418526def09c6c9f4b22567a2c76542d043c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/409876
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
If we encounter code like `return 1; return 2;` we need to synthesize a
label, even though the second return statement isn't actually reachable.
This is harmless and satisfies the SPIR-V validator.
Ideally we'd eliminate the dead code entirely, but this case is rare and
isn't likely to cause any problems as-is.
Change-Id: I2d6219dff6868011353e19a662301bec44a015d6
Bug: skia:12009
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/409402
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Now that the various Metal and SPIR-V bugs have been shaken out, we can
enable these tests. Knock on wood.
Change-Id: If4b4e302cfdd91464aaf00bc9639989de5e49aac
Bug: skia:11985
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/408640
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This is a clone of the Metal test. (This can be moved into shared/ and
enabled as a real test once the codegen is fixed.)
At present, this test generates broken code; everything is writing an
SpvOpMatrixTimesScalar opcode regardless of the actual operation being
performed.
Change-Id: If06b4196e7d9be36e41c5c60c006b2a713cc25d8
Bug: skia:11985
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/408297
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
The Metal code generator will now detect matrix-op-scalar expressions
and splat the scalar across a matrix. This allows a scalar to be added
to, or subtracted from, a matrix. (It does not fix division because
Metal also does not natively support componentwise division on
matrices.)
Change-Id: I7d5b0c5bd35393475c524e34cad789bf4f72a103
Bug: skia:11125
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/407616
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
A cast like `float(five)` or `int4(colorGreen)` should detect const
variables and replace the expression with its compile-time constant
equivalent value. At present, this replacement is missed, which inhibits
further optimization opportunities on the expression.
(This CL is very similar in spirit to http://review.skia.org/404676)
Change-Id: I04b5c435a30d2afcdbdb3d020adc15e9c651cc31
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/405682
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
All internal usage has migrated to MakeFor..., this removes the old
program kind, and updates some tests.
Bug: skia:11813
Change-Id: I56733b071270e1ae3fab5d851e23acf6c02e3361
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/402536
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
At present, this is a missed optimization opportunity. These will be
optimized in a followup CL.
Change-Id: I8882058900cdc12c8ab0df03e36ebfb9d8022f01
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/402580
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This is completely unused - GrMatrixEffect is the only thing that deals
with matrix transforms on child sampling. Removing this makes everything
simpler to reason about.
Change-Id: I555a3fd937c064f2480b149a6d4d8e36f7ee69bc
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/402176
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
This CL also removes some vestiges of the kSampler type, which hasn't
been used in .fp files for a long time.
Change-Id: Iaca1d0c6e77ad2df2b6c5dacd1c68079d6dd5cf2
Bug: skia:11854
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/398738
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This is a reland of c412688798
This CL lands the code changes but not the dm test, which is causing
link errors. Tests will be relanded as a separate CL, at
http://review.skia.org/400097
Original change's description:
> Reland "Implement statements and expressions in DSL C++ code generator."
>
> This is a reland of 16cbfb41df
>
> Tests now rely on `shaderDerivativeSupport` and `integerSupport` as
> proxies to indicate ES3 support. The SwitchStatement test has been
> adjusted to hopefully confuse fewer compilers.
>
> Original change's description:
> > Implement statements and expressions in DSL C++ code generator.
> >
> > This CL removes the bulk of the existing C++ code generator, especially
> > all the complex format-string assembly code. It has been replaced with
> > actual DSL code generation. Simple IR can now be successfully translated
> > to a working DSL fragment processor.
> >
> > This CL also adds a simple test harness which is patterned after the
> > existing SkSLTest; it renders a pixel, reads it back, and fails the test
> > if the result isn't solid green (RGBA=0101).
> >
> > This CL doesn't implement every feature. Some obvious gaps include:
> > - Sampling from children
> > - Uniforms/inputs of any kind
> > - Function calls of any kind
> >
> > Change-Id: Ib80c23fe1ba4453f7c3cb43b65f93c5ea0deb709
> > Bug: skia:11854
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/396757
> > Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
> > Reviewed-by: Brian Osman <brianosman@google.com>
> > Commit-Queue: John Stiles <johnstiles@google.com>
>
> Bug: skia:11854, skia:11891
> Change-Id: I91363e31f34611d15ae350b52d6fc459feeace9c
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/399076
> Auto-Submit: John Stiles <johnstiles@google.com>
> Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
> Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Bug: skia:11854
Bug: skia:11891
Change-Id: Ib1f08256c84d1da2130e0b61356f72435dc0a5a8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/399740
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This reverts commit c412688798.
Reason for revert: fix Google3 roll and wasm build
Original change's description:
> Reland "Implement statements and expressions in DSL C++ code generator."
>
> This is a reland of 16cbfb41df
>
> Tests now rely on `shaderDerivativeSupport` and `integerSupport` as
> proxies to indicate ES3 support. The SwitchStatement test has been
> adjusted to hopefully confuse fewer compilers.
>
> Original change's description:
> > Implement statements and expressions in DSL C++ code generator.
> >
> > This CL removes the bulk of the existing C++ code generator, especially
> > all the complex format-string assembly code. It has been replaced with
> > actual DSL code generation. Simple IR can now be successfully translated
> > to a working DSL fragment processor.
> >
> > This CL also adds a simple test harness which is patterned after the
> > existing SkSLTest; it renders a pixel, reads it back, and fails the test
> > if the result isn't solid green (RGBA=0101).
> >
> > This CL doesn't implement every feature. Some obvious gaps include:
> > - Sampling from children
> > - Uniforms/inputs of any kind
> > - Function calls of any kind
> >
> > Change-Id: Ib80c23fe1ba4453f7c3cb43b65f93c5ea0deb709
> > Bug: skia:11854
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/396757
> > Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
> > Reviewed-by: Brian Osman <brianosman@google.com>
> > Commit-Queue: John Stiles <johnstiles@google.com>
>
> Bug: skia:11854, skia:11891
> Change-Id: I91363e31f34611d15ae350b52d6fc459feeace9c
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/399076
> Auto-Submit: John Stiles <johnstiles@google.com>
> Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
> Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
TBR=brianosman@google.com,ethannicholas@google.com,johnstiles@google.com
Change-Id: I71a8cf31e8a013b7a2a0d10f0ad3bc3893ea07ea
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:11854
Bug: skia:11891
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/399499
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This is a reland of 16cbfb41df
Tests now rely on `shaderDerivativeSupport` and `integerSupport` as
proxies to indicate ES3 support. The SwitchStatement test has been
adjusted to hopefully confuse fewer compilers.
Original change's description:
> Implement statements and expressions in DSL C++ code generator.
>
> This CL removes the bulk of the existing C++ code generator, especially
> all the complex format-string assembly code. It has been replaced with
> actual DSL code generation. Simple IR can now be successfully translated
> to a working DSL fragment processor.
>
> This CL also adds a simple test harness which is patterned after the
> existing SkSLTest; it renders a pixel, reads it back, and fails the test
> if the result isn't solid green (RGBA=0101).
>
> This CL doesn't implement every feature. Some obvious gaps include:
> - Sampling from children
> - Uniforms/inputs of any kind
> - Function calls of any kind
>
> Change-Id: Ib80c23fe1ba4453f7c3cb43b65f93c5ea0deb709
> Bug: skia:11854
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/396757
> Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: John Stiles <johnstiles@google.com>
Bug: skia:11854, skia:11891
Change-Id: I91363e31f34611d15ae350b52d6fc459feeace9c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/399076
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This reverts commit 16cbfb41df.
Reason for revert: using ES3 features, breaks on ANGLE ES2 bots
Original change's description:
> Implement statements and expressions in DSL C++ code generator.
>
> This CL removes the bulk of the existing C++ code generator, especially
> all the complex format-string assembly code. It has been replaced with
> actual DSL code generation. Simple IR can now be successfully translated
> to a working DSL fragment processor.
>
> This CL also adds a simple test harness which is patterned after the
> existing SkSLTest; it renders a pixel, reads it back, and fails the test
> if the result isn't solid green (RGBA=0101).
>
> This CL doesn't implement every feature. Some obvious gaps include:
> - Sampling from children
> - Uniforms/inputs of any kind
> - Function calls of any kind
>
> Change-Id: Ib80c23fe1ba4453f7c3cb43b65f93c5ea0deb709
> Bug: skia:11854
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/396757
> Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: John Stiles <johnstiles@google.com>
TBR=brianosman@google.com,ethannicholas@google.com,johnstiles@google.com
Change-Id: I4f3e7667bf1e3a5539d0248b6c47d9ae2296aa88
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:11854
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/398739
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This CL removes the bulk of the existing C++ code generator, especially
all the complex format-string assembly code. It has been replaced with
actual DSL code generation. Simple IR can now be successfully translated
to a working DSL fragment processor.
This CL also adds a simple test harness which is patterned after the
existing SkSLTest; it renders a pixel, reads it back, and fails the test
if the result isn't solid green (RGBA=0101).
This CL doesn't implement every feature. Some obvious gaps include:
- Sampling from children
- Uniforms/inputs of any kind
- Function calls of any kind
Change-Id: Ib80c23fe1ba4453f7c3cb43b65f93c5ea0deb709
Bug: skia:11854
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/396757
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Most backends don't like init-stmts with multiple VarDeclarations inside
them, so we no longer emit IR that does this. This lets us avoid doing
backend-level fixups.
Change-Id: Ide839de18953a73e0f9c7a690df59a7bc3523f89
Bug: skia:11860
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/398221
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Unused InterfaceBlocks were not added to the ProgramUsage map. The
ProgramUsageVisitor now makes sure to account for them during its
initial scan.
Change-Id: If3afac8e954c5b685ddc6b63b0f771d8c0b8f207
Bug: oss-fuzz:33405
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/398016
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
These enforce stricter rules about the signature of main, and each one
uses a separate pre-include module. That prevents color filters from
being able to reference sk_FragCoord (or coords passed to main) at all.
It also limits the versions of sample() that are exposed.
In the new world, an effect created for a specific stage of the Skia
pipeline can only be used to create instances of that stage (SkShader or
SkColorFilter). For now, SkRuntimeEffect::Make uses kRuntimeEffect,
which continues to be more lenient and allow creation of either shaders
or color filters from a single effect. After we migrate all clients, we
can deprecate and then delete that mode.
Bug: skia:11813
Change-Id: I0afd79a72beeec84da42c86146e8fcd8d0e4c09f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/395716
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
We lacked test coverage for this case, and this was broken when compound
VarDeclarations were split from one Statement into several.
Change-Id: I561b4d8acc0bfa01161d873a0c022ec58e316903
Bug: skia:11860
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/396817
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This requires the GN processing to be slightly more complex, as GN has
no native support for more than one extension on a file.
Context: https://groups.google.com/a/chromium.org/g/gn-dev/c/RdEpjeYtb-4
Change-Id: I630511fca9eb291f0e414481ef439f18a8e1b72f
Bug: skia:11854
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/396197
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
The long term goal is for the DSLCPPCodeGenerator to replace the
CPPCodeGenerator entirely, but we will need both to coexist while DSL is
still under development.
Currently, the DSLCPPCodeGenerator is cloned from CPPCodeGenerator and
emits almost exactly the same code (it adds a comment at the top to
distinguish its output). Its output will change in followup CLs.
This CL also allows skslc to recognize the `_dsl.cpp` output suffix and
generate code using DSLCPPCodeGenerator instead of CPPCodeGenerator.
This allows test DSL FPs to be created for inspection.
Change-Id: If5136279c307ea53a9df3a292caa18344c1eb259
Bug: skia:11854
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/396096
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Also add unit test of all GLSL type aliases.
Bug: skia:10679
Change-Id: I93e21621c11adfe3f114d0c55fb8043518e62696
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/395718
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
In http://review.skia.org/393397, I replaced a Constructor::Convert call
with a call directly to ConstructorCompoundCast::Make.
This worked fine if the input expression was actually a compound, but
if it was not, the code would assert/crash. The fuzzer detected this
error right away. (Enums are not considered to be a scalar, a vector or
a matrix in SkSL.)
Change-Id: Ie0df4c5771ff4f4d8f5251d4703e9c3516b6baad
Bug: oss-fuzz:33113
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/395720
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Two of the tests are now (correctly) detected as invalid code, but were
previously checked into /shared/ because they compiled when the fuzzer
first reported them (that is, after the crash was fixed). These have
been moved into the /errors/ test folder.
One of the tests was only generating an error because its main function
was named `a` instead of `main`, so I renamed it to `main`.
Change-Id: I1a2346fb16e304b0c66ff377a3f9bf7e7ee89ba9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/394899
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
These builtins have been obsolete for a long time; they were only
implemented on the GLSL backend. These values are provided in
u_skRTHeight and u_skRTWidth instead. (See GrGLSLProgramBuilder's
addRTHeightUniform and addRTWidthUniform.)
Change-Id: I8cceca348cbf9071939618f913693c316d35dbc6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/395001
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
GLSL (post-ES2) allows array comparison: http://screen/8gryPvb9T7gndyb
Unfortunately, because ES2 does not support array comparisons, we can't
add this test to the dm test suite.
Change-Id: I06b71683e49b2631669cff801dc647951a81a299
Bug: skia:11849
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/394162
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Change-Id: Icc710e414388e4026a5e9819a53b8dac8ee0a2d1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/394896
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Also adds tests of non-uniform shader declarations. These are currently
allowed, but will be detected as an error in the next CL.
Bug: skia:11374
Change-Id: I3fee0a0c97ae590f7bc6952cb367f7e94436b891
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/393080
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
The actual fix happened at prior CL http://review.skia.org/392197, which
reworked how vector-cast constructors function.
Change-Id: Ifb71ec913b349e65d38458dc615441e7a73efddc
Bug: oss-fuzz:32851
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/392841
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Allowed today, will soon be an error.
Bug: skia:11813
Change-Id: I5c13de7657fa85f13fa6d80e1d890225d8a3e868
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/392439
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
We don't directly support this today at all. In practice, though, simple
constant arrays are detected as equal in the constant-folding pass
because they hit the `x == x` self-equality check (using
`IsSameExpressionTree`).
This does not work for our inequality tests, though, so those do not
fold.
Change-Id: I6730a9a2d1da9ac613ee58889d651f3ff65b1d2d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/391057
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
As soon as a single VarDeclaration is successfully created, its Variable
is added to the current symbol table. However, if a variable-declaration
line declared several variables in a row, we would stop if ANY of the
declarations contained an error and discard the entire statement, but
would continue processing the rest of the program. This left us in a
position where some Variables existed in the SymbolTable with valid,
reachable names, but their corresponding VarDeclaration statement had
been thrown away as erroneous. Since Variables point back to
VarDeclarations for their initialValues, this gave us a stale pointer.
Any future reference to that variable name which could trigger an
access to its initialValue would read from this dead pointer.
This CL fixes the conversion of VarDeclarations so that we no longer
throw away any VarDeclarations associated with a successfully-parsed
Variable.
Change-Id: If8ec3c160933e48a0e1f36414234b3a849d8978c
Bug: oss-fuzz:32587
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/389636
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
We had constant-folding tests for vector-scalar arithmetic, but didn't
have an equivalent SkSL unit test for vector-scalar arithmetic that
actually needs to be computed at runtime.
This exposes two SPIR-V bugs: one was previously known, but the other
is a new discovery.
Change-Id: I28737128f20b445797c6c29872335d05f94cc95c
Bug: skia:11267, skia:11788
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/388739
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
On ARM GPUs, the Vulkan driver does not honor relaxed precision when
evaluating SpvOpMatrixTimesVector. This leads to reduced performance
(compared to GLSL, where mediump matrices and floats do evaluate all
intermediate values at mediump).
This caps bit will be enabled on ARM GPUs and, in a followup CL, will
be used to toggle a workaround where `m*v` is rewritten as the sum of
(m[0]*v[0] + m[1]*v[1] + ... + m[N]*v[N]).
Change-Id: I310fa73639b6498552c9672e76860f2eded15d0a
Bug: skia:11769
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/388459
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Change-Id: I22837a4921238749664217e595d24d196503534d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/388096
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Removed error tests which no longer test anything:
- UseWithoutInitialize...: we no longer track variable use-before-init.
- InlineDivideByZero: we no longer constant-fold the result of an
inlined function call into its parent statement.
- Unreachable: we no longer report unreachable statements.
And fixed some minor test-case issues:
- StaticSwitchConditionalBreak: we still check this, but the function
was being dead-stripped before this check could run. Renamed to main.
- OssFuzzXxxxx: these cases no longer report errors, but they are still
valuable as regression tests; moved to `shared/`.
Change-Id: Iade3cff821dc998cacfd02f62d3ac4625e48904c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/387820
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This will be implemented in Metal and SPIR-V in followup CLs.
Change-Id: I397b4db40b15dd54cf1d8a17f414c3fe184b48d2
Bug: skia:10851
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/387638
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
It turns out it is not legal to pass the results of OpAccessChain as a
function argument, for... reasons. This CL switches us over to passing
the argument via a temp variable instead.
Bug: skia:11748
Change-Id: Ib5e86c1d000655ebd7bb62ceea6a27b823808645
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/385936
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
This allows us to remove 100 LOC from the inliner and is very unlikely
to affect any existing benchmark. We don't have any evidence to support
the idea that a one-iteration `for` loop with `continue`-based exits
will be any faster than a standard function call on any existing GPU.
Our fragment processors are generally written to avoid early returns,
in large part to avoid hitting this path.
This drastically impacts BlendEnum.sksl (which can no longer flatten out
a switch over every blend function in SkSL) but is otherwise a wash.
See: http://go/optimization-in-sksl-inliner suggestion 4(a)
Change-Id: I1f9c27bcd7a8de46cc4e8d0b9768d75957cf1c50
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/385377
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This reverts commit a04692f69e.
Reason for revert: Angry Vulkan bots.
Original change's description:
> Fixed a number of spots where we should have been using RelaxedPrecision
>
> Our SPIR-V output was missing many RelaxedPrecision decorations, which
> was presumably impacting performance.
>
> Change-Id: Iee32d4a42f37af167fe0e45f3db94c2142129695
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/384178
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
TBR=egdaniel@google.com,brianosman@google.com,ethannicholas@google.com,johnstiles@google.com
Change-Id: If4fe945cb363c9b61b5a4abfde649a437689d2eb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/384217
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Our SPIR-V output was missing many RelaxedPrecision decorations, which
was presumably impacting performance.
Change-Id: Iee32d4a42f37af167fe0e45f3db94c2142129695
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/384178
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
As you might expect, a function tagged with `noinline` will never be
considered as a candidate for inlining.
Change-Id: Ia098f8974e6de251d78bb2a76cd71db8a86bc19c
Bug: skia:11362
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/382337
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Currently, only one of three uses (local variables) does this correctly.
Bug: skia:11716
Change-Id: Iad11e8e5998fcc7caee4d438e0558c5d4e2b1821
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/382277
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This enables the ternary to be optimized away in code like:
const bool SHINY = true;
color = SHINY ? add_shine(x) : x; // to --> `color = add_shine(x);`
Without constant propagation.
Also, I added a unit test for ternary expression simplification; I
wasn't able to find an existing one.
When the optimization flag is disabled, this CL actually removes the
optimization of `true ? x : y` --> `x` entirely; previously, this
substitution would be made regardless of optimization settings.
Change-Id: I93a8b9d4027902d35f8a19cfd6417170b209d056
Bug: skia:11343
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/379297
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This check now runs at function finalization time, before constant
propagation has occurred; this affected the "DeadIfStatement" test.
Our detection isn't smart enough to realize that a loop will run zero
times, so it treats `for` and `while` loops as always running at least
once. This isn't strictly correct, but it actually mirrors how the CFG
implementation works anyway. The only downside is that we would not flag
code like `for (i=0; i<0; ++i) { return x; }` as an error.
Change-Id: I5e43a6ee3a3993045559f0fb0646d36112543a94
Bug: skia:11377
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/379056
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This should be legal, and we support this, but some versions of Android
do not: http://screen/3bkQewHF3xUMn5v There's no point in allowing
these shaders to exist; they can't compile on real-world clients, and
these vardecls are borderline meaningless (as the variables being
declared aren't reachable by any other statements).
Change-Id: Ie1351933c90caee9124eeab8983364ec030b2653
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/379584
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
In http://review.skia.org/375776, an optimization was added to the
Inliner, causing it to skip generation of unnecessary temporary
variables. The fuzzer immediately discovered a flaw in this logic: the
"unnecessary" variable was actually used in the rare case that a
function failed to actually return a value. The inliner didn't detect
this case. Of course, this isn't a valid program either, so now we
report the error and cleanly fail.
Change-Id: I1f201cfd33f45cace3be93765a4e214e43a46e69
Bug: oss-fuzz:31469, oss-fuzz:31525
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/377101
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
For now, just use this to prevent *any* layout qualifiers from appearing
on functions, or their parameters.
Bug: skia:11301
Change-Id: I05d8118c7121048c6ef49695a54e3714a8f8687e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/376796
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
This adds Analysis::IsConstantExpression, to determine if an expression
is a constant-expression. It now expands to cover 'const' local and
global variables, because we also enforce that the initializer on those
variables is - in turn - a constant expression.
This fixes 10837 - previously you could initialize a const variable with
a non-constant expression, and we'd emit GLSL that contained that same
pattern, which would fail to compile at the driver level. That should
not be possible any longer.
Bug: skia:10679
Bug: skia:10837
Change-Id: I517820ef4da57fff45768c0b04c55aebc18d3272
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/375856
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
The expression `~123` was making a PrefixExpression of type $intLiteral.
It should be converted to type `int` when the ~ prefix is applied.
This change also changes the output from oss-fuzz:27614. Both programs
are essentially nonsense expressions with no real behavior, so this is
fine.
Change-Id: I586be149ce95136fabee72fdd3473814d54948cf
Bug: oss-fuzz:31410
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/376620
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Change-Id: Iafeb13812851271a5262730e9c0642d4469c273f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/375020
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Now, even if a qualifier has a default value, we will know that it
appeared in the text. We can use that to check for redundant qualifiers
(as is being done here), and in the IR generator to prevent any use of
certain qualifiers, depending on context. (eg, runtime effects, wrong
shader stage, on a parameter declaration, etc.)
Bug: skia:11301
Change-Id: I2cd6ad35c2b4c4d6f87ade97e80aea84dc16ee4b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/374616
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
The optimizer now properly recognizes all types of exits from a switch
statement. Break, continue and return are all potential exits and need
to be considered when determining the exit path from the switch.
Previously, dead code elimination was hiding the effects of this bug
from us, but it meant that an optimized switch had the potential to
generate lots of worthless IR nodes which then needed to be detected and
eliminated by the CFG. In particular, this affected the enum form of
blend, causing a catastrophic amount of extra work to be done.
Change-Id: If857e38cadfc016884624ea4db25a273ad3dce5b
Bug: skia:11352
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/372958
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
When we detect a static switch, the optimizer finds the matching switch-
case and eliminates all the other switch-cases. It handles case
fall-through by scanning forward and looking for an unconditional break.
However, the inliner has an interesting quirk--it can replace `return`
statements inside of a switch with `continue` statements, since the body
of the inlined function has been wrapped with a for-loop to allow for
early exits. The optimizer does not recognize these continue statements
as exits from the switch (although they certainly qualify), so it
treats continues as fallen-through and keeps emitting switch-cases.
The dead-code elimination pass was actually doing us a favor here and
eliminating the excess code later. A flag was added to disable DCE in
order to reveal the problem in a test.
Change-Id: I8ff19fde5e32d0ab73d7c5411da40cb953a446f5
Bug: skia:11352
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/372956
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Surprisingly, this error is actually caught by our parser, which
interprets the default label in a unique way. From the parser comments:
"Requiring default: to be last (in defiance of C and GLSL) was a
deliberate decision. Other parts of the compiler may rely upon this
assumption."
The comment is true--we don't check for duplicate default switch-case
labels anywhere else in the code, just here in the parser.
We rely on this, so we should have a test for it.
Change-Id: I6df5c565aca4d4b8565b96638dce9504efc39ccc
Bug: skia:11340
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/372617
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Bug: skia:11335
Change-Id: I88c952cbfe2d2c5920e17675da1674928f37b982
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/371480
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Includes variables with and without initializers. Note that both the
.skvm and .stage output is incorrect right now. (No declarations for
global variables in .stage, and the initializer is dropped in .skvm).
Bug: skia:11295
Change-Id: Icb6d797616be6a1bc7cbdc9db4fefa7e30c65656
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/371143
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
None of these are legal in GLSL ES 1.0. Added a new test that previously
compiled without error. Started out with just assignment and equality,
then realized that sequence and ternary should be blocked, too.
Bug: skia:11323
Change-Id: I02691f819565afabeadbb12cab6c07acf40093f7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/370880
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
GLSL ES2 documentation on out parameters: "Evaluation of an out
parameter results in an l-value that is used to copy out a value when
the function returns."
The inliner does not do any alias checking when inlining an `out` param.
That is, passing the same variable to two separate `out` parameters
would not generate two distinct lvalues in the inlined code; it reuses
the same variable for each out-params in the inlined code.
(Amusingly, our CFG can fully optimize away this test code so it just
returns "red".)
Change-Id: Ib781d2cfdac54f01b6abe159af0c84ff24ff6976
Bug: skia:11326
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/370256
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Multi-dimensional arrays aren't legal in GLSL/SkSL, so this should be
caught and flagged as an error. The parser now verifies that a
variable's type isn't an array-type before accepting a `[` token to
open an array on the variable name.
This CL also refactors the IR generator's `convertArraySize` method to
make sure that various checks are made for all callers. Originally this
restructuring was used to verify array multi-dimensionality, but that
didn't detect errors inside struct declarations (which get no error
checking inside the IR generator) so the IR generator updates no longer
need to check the array dimensions.
Bug: skia:11322
Change-Id: Id33f4bdfb544019ddf995a8196c3c09cfe5a4525
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/369916
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>
We now interpret any statement of the form `Type identifier...` as a
var-declaration and report errors as such. Previously, if a var-decl
statement generated an error during parse, we'd report errors as if it
were an expression-statement, which meant that slightly-invalid code
could return out-of-context, misleading errors.
Bug: skia:11287
Change-Id: I2c6cf2984760eb34593c80cb30f8c4e007d42027
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/370036
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Bug: skia:11314
Change-Id: I66476543462ae378a5bfb6cbd902dfa2f5fc45f5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/369917
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Disabled on Adreno 5xx/6xx as the tests do not pass on those GPUs:
http://screen/3Dkgs9syj37cjBV
Change-Id: Ib935d01e8f06dbfe7decd5cc4e52e0688b48be08
Bug: skia:11306, skia:11308
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/368805
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This emits SkSL that is more-or-less what the compiler re-ingests when a
runtime effect is used to create a GrFragmentProcessor.
Change-Id: I0926be44fc4493e722a5edc18198e161e4192cde
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/367883
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Currently, SkSL is able to constant-propagate `x = x + constant` into
`x = constant` when the starting value of x is known. However, it is not
able to do the same optimization for `x += constant`. This test
demonstrates that once += is encountered, we lose track of x's value and
can no longer propagate its value.
(This is equally true of all the op-assignment operators, += -=
*= /= etc.)
Change-Id: I3523e96baf9a73982cf3b09f0d23b95adacf106b
Bug: skia:11192
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/368248
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
SkSL.
It would previously catch 1 / 0, but fail to detect x / 0.
Bug: skia:11051
Change-Id: I3adb5942cce03a7ad40a13a8ca5d5a7f2029d6ad
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/366720
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: Ethan Nicholas <ethannicholas@google.com>
This is enforced by ANGLE in Strict ES2 mode; we need to enforce it as
well.
Change-Id: I6e2f547ad8e0ce817742cf84659764cf6bce38b9
Bug: skia:11270
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/366339
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
We now catch this error at IR generation time; previously we'd send it
to the driver (where it would fail to compile).
Change-Id: I45890214ffa164be1c0f359320f942bc4dc479ca
Bug: skia:11265
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/365697
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This uncovered a bug in Metal code generation of `matX *= matY` which is
now fixed. (It was emitting the helper function more than once.)
Change-Id: I0aeb0efe7ab5fbf5592a8ca6f4f5b50354d3d7f4
Bug: skia:11262
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/365489
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Previously, our only test was invoking `sin(1)` which is a pretty
ineffective test. Now, we test args and return types for all the basic
scalars/vectors/matrices.
Change-Id: I7d335303eef8b9c9c6cfef2265a15bbd9bd73e0c
Bug: skia:11246
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/363943
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
These are basic vector types, required by GLSL ES2, but we could not
create helper functions using them because they were missing from our
GrSLType enum. (This also prevented Runtime Effects from using these
types in helper functions.)
Change-Id: I78c328499e8ed90cb29c641b90ee59460a5a45de
Bug: skia:11246
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/364036
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
These tests have updated to return green on success, or red on failure.
Some tests were modified slightly to conform to ES2 limitations, or
split into separate ES2 and ES3 parts.
Change-Id: Ib47aeca217aef33f3c4b5999d93afed5d42a1e62
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/363876
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
We already had this trick for scalar integers, this extends it to
integer vectors. As with prior work in this area, it would be better to
detect this case and produce an error, but now we at least produce
consistent and well-defined results (rather than undefined signed
integer overflow).
Bug: skia:10932
Bug: oss-fuzz:29494
Change-Id: I45526fe96b6ea42c0e88b9862f6961b316810321
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/363962
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
The test has been split into an ES2 version and ES3 version; the ES2
side omits unsupported integer ops like << >> & | ^ %.
Change-Id: Iba16d469a477809b17a823b1c68ae8937624c68e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/362616
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
SkVMCodeGenerator was lacking support for the comma operator entirely;
this has now been implemented.
Change-Id: I9350f54e6ee52764c620116e6dbfe4ca3e9cd47e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/363096
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This reverts commit 0492a744a5.
Reason for revert: Intel HD6000 + ANGLE DX9 fails the floor() test.
Original change's description:
> Add some SkSL intrinsics to our dm tests.
>
> This CL adds dm coverage for:
> - abs(half)
> - sign(half)
> - floor
> - ceil
>
> And creates test output for abs(int) and sign(int); these aren't covered
> by dm because they don't exist in ES2 and so are unsupported by Runtime
> Effects.
>
> Change-Id: Ia3e660408cef50dec8fa4b6bdc12906e96179f6e
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/360419
> Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
> Commit-Queue: John Stiles <johnstiles@google.com>
> Auto-Submit: John Stiles <johnstiles@google.com>
TBR=brianosman@google.com,ethannicholas@google.com,johnstiles@google.com
Change-Id: I62121efee9315b16e61e7d38659b6f629bdf8bd8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/362056
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This CL adds dm coverage for:
- abs(half)
- sign(half)
- floor
- ceil
And creates test output for abs(int) and sign(int); these aren't covered
by dm because they don't exist in ES2 and so are unsupported by Runtime
Effects.
Change-Id: Ia3e660408cef50dec8fa4b6bdc12906e96179f6e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/360419
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This allows interface blocks in Metal to compile even if
`layout(binding=...)` is not specified. It will also be used in SPIR-V
in the followup CL, when an interface block is automatically synthesized
for top-level uniforms.
This CL also reorganizes the unit tests around uniforms a bit.
Change-Id: Ia898c536b454dda6f51677e232a8f6e6c3606022
Bug: skia:11225
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/360778
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This is a known deficiency of runtime effects, next step is to fix how
they manage function signatures to solve the problem.
Bug: skia:10939
Change-Id: Id934e0acdf774b03bd6edce78d7b2c077bdeae00
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/360603
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Pre-cleanup as I start looking at how structs are parsed and handled in
the IR.
Bug: skia:11228
Change-Id: I6334d1073211cbbdf69ddffa8df420c45fd59fcc
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/361059
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
This creates a helper function, _entrypoint, which invokes main() and
assigns its result into sk_FragColor. We also make sure to prevent
sk_FragColor from being dead-stripped from the code during IR
generation.
At present this is useful for allowing our SkSL test shaders to compile.
Change-Id: I2d7fab0e1959a77778ffdb18ca569e869bcaeece
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/358525
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
In most cases, this works properly and a `;` is emitted, but in one
particular case (int x, y;) we get nothing.
Change-Id: If88d92502f6a533284dd4e0f78daedaf1481ff3d
Bug: skia:11218
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/359558
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
In GLSL and SkSL, control statements don't require explicit braces
around single-statement children. That is, the `match = true` child
statement here doesn't need to be braced.
if (condition) match = true;
Because there are no braces, we never create a Block or a dedicated
SymbolTable here. This is normally not a problem, but the fuzzer
discovered that it can dump things into the symbol table inside a child
statement:
if (condition) int newSymbol;
This becomes problematic because the symbol name now outlives its block.
This means `newSymbol` can be referred to later, which should be illegal
(and can cause the optimizer to blow up since the structure is bogus).
There doesn't seem to be any reason to allow this code to compile; the
user can add an explicit scope here to make it reasonable, and it's
(almost) meaningless to declare a symbol that's instantly going to fall
out of scope. This code is now rejected with an error message.
Change-Id: I44778e5b59652d345b10eecd4c88efbf7d86a5e0
Bug: oss-fuzz:29849
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/358960
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Change-Id: I94094be7163a04bf48e86406230156a5433469b6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/359140
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Change-Id: I924ac75b5f8a397f7af7a06925ef0c9deba5c509
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/359141
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Change-Id: I8309940f8e40d0e84847ae272830896d010c39de
Bug: skia:11219
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/359138
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
The previous change caused varDeclarations() to sometimes return an
expression-statement. This only made sense in the context of being
called from Parser::statement(). Other places which called
varDeclarations() expect vardecls and nothing else.
Change-Id: I562657cadfa20dcd77b527f2dc43dca0c6bf389f
Bug: oss-fuzz:29845
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/358528
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This allows us to write SkSL shaders which are valid both for use as
Runtime Effect, and for compilation with skslc targeting Metal.
Change-Id: I74e125d81865d4092e657a7d9948d2e72054bda5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/357777
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Added asserts that verify we don't try to emit the same struct or array
with two different memory layout rules. Some code paths were failing to
inspect the associated variable, leading to incorrect errors about the
attached offsets of members.
Added a test case that triggered that error, and also triggers the new
asserts.
Then, fixed the underlying cause: writing out the struct definition as a
side effect of accessing a member in getLValue().
Bug: skia:11205
Change-Id: I6e5fb76ea918ec9ff10425f2d519ddbc54404b27
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/357436
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This will allow us to load these inputs for unit testing in `dm`.
Change-Id: Id256ba7c30d3ec94b98048e47af44cf9efe580d5
Bug: skia:11009
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/357282
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
A passing test returns solid green. Failing tests are written to
return solid red, but drawing any other color than green can be
interpreted as a test failure.
Additionally, tests which cannot compile as RuntimeEffects (due to
non-ES2-compatible features) have been split into an ES2-compatible part
and an ES3 part.
Change-Id: I3f53121d9de0ae4c4e7f1de3177d067811980b55
Bug: skia:11009
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/356999
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This reverts commit b7e836cee9.
Change-Id: I3c39a928ba4a9a2863b616f2a500975294b03860
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/355980
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
This reverts commit ebf569004f.
Reason for revert: std::clamp is c++17
Original change's description:
> Support indexing by loop variables in SkVMGenerator
>
> Bug: skia:11096
> Change-Id: I25a91bacf1c3455ac67422fb0e59b9b152c2054a
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/354667
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Mike Klein <mtklein@google.com>
TBR=mtklein@google.com,brianosman@google.com,johnstiles@google.com
Change-Id: I0590cf7fe626fb59be3381b5e8eb66a9a2a9e8cb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:11096
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/356056
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Bug: skia:11096
Change-Id: I25a91bacf1c3455ac67422fb0e59b9b152c2054a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/354667
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
This enforces an even stricter version of the rules from GLSL ES 1.0
Appendix A, Section 5. Essentially, indices (to arrays, vectors,
matrices) must be made of literals, loop indices, and expressions made
of those two.
Bug: skia:10837
Bug: skia:11096
Change-Id: I437a5ed64da58e24d5991ddbde68859f5214e98b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/354665
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
As far as I know, there shouldn't be a way to introduce a struct or enum
other than at global scope; the keywords are not accepted inside a
function body. In fact, I wasn't able to find a way to exercise these
code paths in practice. But we now have concrete assurance that any
possible type can be cloned into a symbol table safely; all Types are
either built-in (available everywhere by design) or are clonable.
Change-Id: I4b006b6cab995b3e598b683736ab9689828629c9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/354664
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
The inliner discovered that when a binary expression is inlined, its
type is not cloned into the destination's SymbolTable. This meant that
when the inlined-from function was later dead-stripped, the type pointer
would become dangling. Did a quick pass over inlineExpression and
inlineStatement and ensured that types are always copied.
Also found that `copy_if_needed` was making a copy of eligible types
each time one was encountered, instead of making one copy and reusing
it. This is fixed as well.
Change-Id: Iee3259ab038dfb04034bf0110af1909ccffec3de
Bug: oss-fuzz:29444
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/354219
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Unsized arrays are now allowed in exactly one place: On the declaration
of an interface block. This satisfies the one existing use-case, which
is the gl_in (sk_in) declaration for geometry shaders. There is no other
useful scenario, and most of our backends don't support them anyway.
Several spots were using less strict checks when attaching sizes to
arrays, allowing for zero or negative-sized arrays, so those are all
fixed now.
The existing tests that initialize arrays are still a problem, because
Metal doesn't support that (neither does GLES2). Also, ArrayConstructors
has gone from generating an error in the Vulkan backend, to invalid
SPIR-V.
Bug: skia:11013
Bug: skia:11127
Change-Id: Ib08dfe9aeec96bf605661665d6f166419d27e8bc
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/353817
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Change-Id: I47d02ca63ce64d9cfb3de0888d84b2b8a822f2b5
Bug: skia:11164
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/353710
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Also renamed Discard to IllegalStatements, and added testing of while
and do loops.
Change-Id: Ibacf69131267a0436808e2e022ad126704af16ef
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/353706
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
The "disallowed" tests are largely allowed in the current code, but all
fail properly in the followup CL.
Change-Id: I8e03570165480b60db9701ac1a782e1124ded56b
Bug: skia:11164
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/353617
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This revealed a gap in our SPIR-V scalar constructor support;
typecasting a number to bool would lead to an ABORT.
Change-Id: Idac6d7ba34adfd214ed3cad8139e22d7170456f0
Bug: skia:11172
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/353628
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Change-Id: I350a6768ac124362b0d3e0f17e7a026265acf804
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/353627
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Bug: skia:11094
Change-Id: I68a08e79d29579901b74daca3c22f5112fbb3c8c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/353356
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
I started unpacking the mechanics of type coercion, and realized that
the second half of the function was looking up the Symbol for a Type
based on its name (Types are already Symbols), converting that Symbol
back into a Type (we started with a Type anyway), wrapping that Type
in a TypeReference, then calling that TypeReference (which always
calls convertConstructor).
This CL cuts out the middle steps and simply calls convertConstructor
directly. A test was added to confirm that an earlier error encountered
on the CQ is no longer occurring.
Change-Id: I76aae455a301afe4e67ef989d9dfe11f47ed36ae
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/353105
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This CL also adds tests for vector*scalar and scalar*vector folding.
We currently do not constant-fold these, but support will be added in a
followup CL.
Change-Id: I68d7374ae15ab2f4d805a095803b645c92fb03d9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/352237
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
The CFG/definition map are no longer valid after replacing an expression
entirely. Swizzle-of-swizzle optimization was another case where the
optimizer would replace an expression wholesale, but failed to set the
needs-rescan flag.
Change-Id: Ida0363d738cd1d3ac2a48c824aa04065a7ca16b7
Bug: oss-fuzz:29085
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/351776
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Change-Id: If6b23d03b02028b51f96e97080cbd7d34cc33b8f
Bug: skia:10931
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/351503
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Change-Id: Ia4a1c38161046b94dc56a1a76704766f1e14aab7
Bug: skia:11131
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/350019
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This actually exposed a latent bug: we don't support bool(1.23) or
bool(1) casts, but these are valid in GLSL:
https://www.khronos.org/opengl/wiki/Data_Type_(GLSL)#Conversion_constructors
"to bool: A value equal to 0 or 0.0 becomes false; anything else is
true."
Change-Id: Ia929a09914ffc96f081d0402d7bb05b5428f8db6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/349977
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Previously, we did very little to distinguish between a built-in
intrinsic and a user-defined function whose name matches an intrinsic.
This could lead to all sorts of surprising outcomes, as our intrinsic-
rewriting code is able to make assumptions that might not hold true for
arbitrary user-defined functions.
Change-Id: I4180e0c5becdeb6a0a162534eaecfc90dda3392c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/349062
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This code was not using typeName() to emit its types, inadvertently
generating Metal code containing the `half` type.
We didn't have any unit tests which synthesized a matrix-construct
helper with half types, so Matrices.sksl was cloned into two separate
test files--MatricesFloat and MatricesHalf. These should be equivalent
except for float vs half types.
Change-Id: I19ecea994b8bc45594bb3f69e596896a3bcefe4d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/348180
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Previously, some types of overflow were detected, but most would assert
or silently generate invalid code. Now, the parser will properly report
an error if it encounters any integer that exceeds UINT_MAX or any float
that exceeds FLT_MAX.
This fixes test OverflowUintLiteral.sksl. Added a test for floats as
well, OverflowFloatLiteral.sksl.
OverflowIntLiteral.sksl does not fail yet, because its values are larger
than INT_MAX, not UINT_MAX. These are legal from the perspective of the
parser. This must be caught later at IR generation time.
Change-Id: Ia5a904d01427cdc9f2ab5f4174154418737835e6
Bug: skia:10932
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/347176
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This fix is overly conservative in some situations (identity conversions
among vectors with the same component type), but fixes errors in two
existing unit test cases.
Bug: skia:11116
Change-Id: If852f8591fb26817528fdc37191c49129e17d6b3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/347053
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This feature had devolved to just an assert, and one that isn't really
necessary - all of Ganesh is built to handle any child processor being
null. The next step is to remove nullable types entirely -- a large
amount of code.
Change-Id: I612a5867f8690400b405aa1f5c929e76cf5918fd
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/347050
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
This CL updates `compareConstant` to fail gracefully instead of
aborting if the passed-in types don't match. This lets us call
`compareConstant` without checking types first.
Change-Id: Id2acdbdf700e64bcb24825cdad2c0e000992e8cb
Bug: oss-fuzz:28904
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/347038
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Opaque types can no longer be copied via assignment or construction, and
various restrictions originally applied to the "fragmentProcessor" type
have been extended to cover opaque types in general.
Change-Id: I55ab7aefd1e6ef277e56a9408b430e1de5ba12ca
Bug: skia:11027
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/346264
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This intrinsic was previously lacking a unit test, and wasn't actually
implemented in Metal or SPIR-V. Fortunately it's trivial to add.
Change-Id: I68bbdc58376b579c7f3f0ae5f49323b389c2b8c4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/346263
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Previously, a return statement inside a scoped Block would always result
in the return expression being assigned to a temporary variable instead
of replacing the function-call-expression directly. This was done
because there might be variables inside the Block; these would have
fallen out of scope when the expression is migrated to the call site,
resulting in an invalid expression.
We aren't actually examining the return expression so we don't know if
it uses variables from an inner scope at all. (Inspecting the return
expression for variable usage is certainly possible! But it's a fair
amount of code and complexity for a small payoff.)
However, we can very easily get most of the benefit here without paying
for the complexity. In this CL we now look for variable declarations
inside of scoped Blocks. If the code doesn't add any vardecls into
scoped Blocks, there's no risk of scope problems, and we don't need to
use a temp-var to store our return expressions. If any vardecls are
added, we go back to using a temp-var as before.
Change-Id: I4c81400dad2f33db06a1c18eb671ba2140232006
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/346499
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Includes a handful of test cases to exercise the system
Change-Id: I98e73a8bca063f475d2ddb51778e395697392ddb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/346637
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
We have a handful of tests that demonstrate this behavior indirectly,
but lacked a focused test.
Change-Id: I895cc4e3bebf30721ed649244e42bf170cc6ec06
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/346497
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
We need to rescan after optimizing away expressions that might exist
in the CFG/definition map, since we are rebuilding them from scratch and
not just stripping off excess parts from them.
Change-Id: I843a2ea3fc38428e7c0bd0e2bf7a7d41101345e3
Bug: oss-fuzz:28794
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/344972
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Because we use `continue` for flow control handling now, we can escape
from the middle of a switch statement. This wasn't possible when we used
`break`.
This unlocks some pretty stellar optimization opportunities if the
switch value can be determined at compile time; see BlendEnum for an
example.
Change-Id: Id29be92c343c10fd604683a80c5d5bd2bd070cb0
Bug: skia:11097
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/345419
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
do-while loops aren't compatible with GLSL ES2. For-loops which run
only one time should work exactly the same for our purposes. We expect
such a loop to be unrolled by every driver, so it shouldn't come at any
performance cost.
Change-Id: Ia8de5fcab8128c34da97eaeaf81f91ad1ac36ce4
Bug: skia:11097
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/345159
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
We are still missing an implementation for Metal and SPIR-V, but at
least it's correct on GLSL now.
Change-Id: I5b365384eaefacb00faf6af7bda9b690cba00de5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/345397
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Change-Id: If29ee048d359d0ccd7b0ab708f54d40746b92386
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/343423
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Bug: skia:11072
Change-Id: Ic24e40bfea5bf1d2d14c0f681632228a5ecc7104
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/342929
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Auto-Submit: Brian Osman <brianosman@google.com>
The existing code didn't work properly with half types since the $mat
type encompassed both halfNxM and floatNxM. This was fixed by splitting
the half types out of $mat into a separate $matH generic.
Unit tests now compile properly for GLSL, but generate errors in SPIR-V
and generate Metal code which attempts to call a non-existent intrinsic.
Change-Id: I2fff10f0dd7f00534bf6b1d5b13354543694194e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/342926
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
floatBitsToUint was missing from our intrinsic list entirely, and
u?intBitsToFloat were misspelled.
These intrinsics aren't implemented in SPIR-V or Metal either, but that
will be handled in followup CLs.
Change-Id: Iaf9b9d5a2e46e25d41eef71903fad8bd1c177d4e
Bug: skia:11071
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/342757
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Change-Id: I887e700a7bf11bf2d5359c9721798f72f00e53f3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/342756
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Change-Id: I674d758c11071582e9fbedcda5596c540bfb5f71
Bug: skia:11054
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/342558
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This does not give us 100% coverage of intrinsics yet, but it is a
pretty good start.
Change-Id: I97d49324db1afd9f2975c2eeafbacdead710d4aa
Bug: skia:11054
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/341977
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
We now insert helper functions which defer the assignment of out-
parameters back into their original variables to the end of the
function call. This allows us to match the semantics listed the GLSL
spec in section 6.1.1:
"All arguments are evaluated at call time, exactly once, in order, from
left to right. [...] Evaluation of an out parameter results in an
l-value that is used to copy out a value when the function returns.
Evaluation of an inout parameter results in both a value and an l-value;
the value is copied to the formal parameter at call time and the lvalue
is used to copy out a value when the function returns."
This technique also allows us to support swizzled out-parameters in
Metal, by reading the swizzle into a temp variable, calling the original
function, and then re-assigning the result back into the original
swizzle expression.
At present, we don't deduplicate these helper functions, so in theory
there could be a fair amount of redundant code generated if a function
with out parameters is called many times in a row. The cost of properly
deduplicating them is probably larger than the benefit in the 99% case.
Change-Id: Iefc922ac9e2b24ef2ff1e9dacb17a735a75ec8ea
Bug: skia:10855, skia:11052
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/341162
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This sort of error would be detected by most backend compilers. This
case was also detected by the bytecode generator. It's easy for us to do
a similar check during SkSL IR generation and report the error sooner.
Also, `convertIndex` had migrated a few hundred lines away from
`convertIndexExpression`, so I moved it back to live next to its parent.
Change-Id: I715d3abf42581782b55ba60df30d0296355667d4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/341377
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
We will need to emit a helper function to work around this case, as
GLSL supports swizzled out params, but Metal does not. In this CL, we
do not yet synthesize the helper function, but we annotate the code with
a comment indicating affected calls. (Of course, this will be replaced
with a helper function in a followup CL)
Even detecting a swizzle is actually an interesting problem, because
index expressions are sometimes actually swizzles, depending on the type
of the base expression. Also, the index or swizzle might be nested in
several other valid assignable expressions.
Change-Id: I8c74f9a7daec08eff1f32387f8b6b96851c1bd6e
Bug: skia:10855
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/341057
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Pointers require decorating the variable with a * to read back the
value, which the code generator did not properly handle. There was a
special case to add the * but it only supported assignment into the
variable, not reading back. References require no special decoration.
This change fixes compile errors in Functions.sksl with the "bar"
function. (This test marks `x` as an inout but never actually mutates
it.) It also allows us to remove a special-case workaround for `frexp`,
an intrinsic function which uses a reference for its out-parameter.
Additionally, this CL adds a non-inlining copy of "OutParams.sksl" to
the Metal test directory, as most of our tests which use out-parameters
end up inlining all the code, which hides these sorts of bugs.
Change-Id: I31c4db04f6b512b4cd4fe65b3347b82bdbf039cd
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/341000
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Previously, we would emit an invalid [[buffer(-1)]] annotation on the
block, causing the Metal compilation to fail.
Change-Id: I68b2439c05db3163686e84c5dcc9a5c43870ff67
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/340761
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
It's not legal to use identifiers like "int" or "sampler" to name your
variables (or enums, or structs, etc.). SkSL will now report this as an
error instead of relying on the driver to catch this.
(Note that in some contexts, it might be legal by the spec to reuse a
name that you introduced yourself, depending on the scope. In practice,
this confuses Apple GLSL, so we shouldn't support it anyway.)
This caught several existing places in our code where we used the name
"sampler." These were never exposed to the driver (they were intrinsics
that we would replace during compilation) so they were harmless before.
Change-Id: Ia6dcfca8c500d02e1eb5f9427bed8727e114dfc2
Bug: skia:11036
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/340758
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
GLSL only allows one-dimensional arrays. This CL lowers SkSL's array
dimensionality limit from eight to one, and fixes all the tests that
this breaks. The rest of the code still technically supports
arbitrarily-deep array dimensionality; there are many opportunities for
code cleanup and simplification in followup CLs.
Change-Id: I0fc31e4626649ec69d40c5f5597b3924de298df0
Bug: skia:11026
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/340339
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This is illegal in older versions of GLSL and in Metal. We now fail at
SkSL compilation time and properly report the error.
Change-Id: I6ddaeabff5386a1ed6ca3eb8703a6035476ec77a
Bug: skia:11021
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/339298
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
The proper approach for creating multi-dimensional array types is
complicated, so I added a function in SymbolTable which does it the
right way (addArrayDimensions). I found all the places in SkSL which
created arrays from base types and size arrays, and refactored them to
call addArrayDimensions instead of doing it manually.
I believe that this approach fixes a bunch of minor issues with multi-
dimensional array types; some are visible in the current codegen output,
and others are latent bugs. e.g. in some instances, a Variable's type()
was silently holding flipped array dimensions, but this never led to
a visible bug because we ended up using the VarDeclaration's baseType()
plus sizes() everywhere that the type was used. (In particular, this
caused debugging headaches in http://review.skia.org/340137 where I'd
use a Variable's type and suddenly its array dimensions would be wrong.)
Change-Id: Idd6a86aa5d1dce8918d02a53bcc2f7d7886e3ac5
Bug: skia:11016, skia:10924
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/339860
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
The Metal return type from main() diverges from the SkSL source, so we
patch it in the Metal code generator. This CL improves the patching
process in multiple ways:
- A `return` statement from a fragment processor main() is rewritten to:
return *_out;
- A `return` statement from a vertex processor main() is rewritten to:
return (_out->sk_Position.y = -_out->sk_Position.y, *_out);
- We avoid emitting a duplicate `return *_out;` statement if we can
determine that main() already ends in a return statement. This is
harmless either way so it doesn't necessarily catch everything. (e.g.
it doesn't detect an if/else which returns at the end of both blocks.)
Also added a unit test which returns from the middle of a vertex shader,
since we didn't test this anywhere and we need to verify that
sk_Position.y will be negated. (This didn't work properly before.)
Change-Id: I14cf18375894fc712fa6c6466df3888ebaeba7c8
Bug: skia:10903
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/339636
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Previously, this would generate invalid code such as `[[user(locn-1)]]`.
We now generate a more-useful error at SkSL compilation time.
Change-Id: Ifbe335ec6d4abcbdfe89b892ba51063c94d22b11
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/339397
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
GLSL only supports arrays of samplers in very limited ways; they aren't
supported at all by SkSL. We now detect arrays of opaque objects and
reject the code.
We have several paths through the IR generator that create and process
array types; the unit test covers global and local variables, and array
on the type versus array on the variable.
Change-Id: I5b45e88e31cf4005723c3bf35561622d65321f7b
Bug: skia:11008
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/339317
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Just filling in a gap in our tests. The output is a little strange as it
exposes a missed opportunity to constant-fold array accesses, but it
seems fine otherwise.
Change-Id: I6df13e0f9a49455015ceb47d7802bb5e1bbdaa1a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/339217
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Constructors such as `float[2](0, 0)` add a type to the symbol table;
this type needs to be copied into the new symbol table if the
constructor is cloned by the inliner.
Change-Id: Ifa8d2dec87103c6223ce493e2201a904c14c2137
Bug: oss-fuzz:28050
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/339168
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
SPIR-V previously didn't know what to think when it encountered a Type
with a typeKind of kEnum, and would abort. These are now treated as
32-bit signed integers.
Metal previously emitted the SkSL enum typename, which is meaningless to
Metal since we do not emit the enum itself anywhere. Metal now emits
"int" for an enum-typed variable.
(GLSL already correctly emits "int" for enum types.)
Change-Id: I05975a2a399f9c4a22c00c90be0dccacd99d793b
Bug: skia:11003
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/338856
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This CL addresses the root cause of the fuzzer issue, by checking for
LayoutIsSupported before getting the MemoryLayout of a type. However,
this array ought to be detected as an error everywhere, as samplers are
opaque types; at present, this code compiles without error in GLSL and
Metal. This is an issue for followup CLs.
GLSL's actual support for arrays of samplers is interesting and probably
too nuanced for us to try to emulate:
https://www.khronos.org/opengl/wiki/Data_Type_(GLSL)#Opaque_arrays
"Under GLSL version 3.30, Sampler arrays (the only opaque type 3.30
provides) can be declared, but they can only be accessed by compile-time
integral Constant Expressions. So you cannot loop over an array of
samplers, no matter what the array initializer, offset and comparison
expressions are.
Under GLSL 4.00 and above, array indices leading to an opaque value can
be accessed by non-compile-time constants, but these index values must
be dynamically uniform. The value of those indices must be the same
value, in the same execution order, regardless of any non-uniform
parameter values, for all shader invocations in the invocation group."
Change-Id: Ib382f5c3b563f996b3c8f1eb6b021b6d31fa9ce7
Bug: oss-fuzz:28107
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/339159
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This test verifies that dead-stripping works on both built-in and user
functions, if their function call is optimized away.
Change-Id: I3125a34640c69de43c383343cd00d97e5a32ac60
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/338836
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Enums are an SkSL-only concept--when we output code, we emit plain
IntLiterals--so the fix is simply to ignore the Enum program element
when we encounter it. This is what GLSLCodeGen does as well.
Also added a unit test to confirm that enums work normally, and that
enums are subject to optimization and static-comparison checks just as
ints would be.
Change-Id: Ic4f8da7a27983add9eb41b936d46f6638d22bd4b
Bug: skia:11003
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/338800
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
There were a surprisingly small number of dedicated SPIR-V tests.
SkSLSPIRVBadOffset was the only test that didn't already exist in the
golden outputs, although it actually contained two tests.
The SPIRVTest.cpp file has been converted to SPIRVTestbed.cpp, which can
be used for local debugging of SPIR-V issues via dm (like GLSLTestbed
and MetalTestbed).
Change-Id: I978d8a7cf5735af7f537113d2b9411ce42cfcf88
Bug: skia:10694
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/338756
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This is very unlikely to occur in real-world code, as it's somewhat
nonsense to use the comma operator in this way. However, it's better to
fail cleanly than to assert.
Change-Id: I76481cd8a993cb1a798ee16956400a512efd4c15
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/337636
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Fix code generation for Metal and Vulkan with geometric
intrinsics that have scalar versions in GLSL/SkSL, but no
native support in MSL/SPIR-V.
Change-Id: Id4538a00172e0d233ad9d5ed8d33db6436b83208
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/338276
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Previously, we assumed that if a vector in `is_constant` was not made of
floats, it must be made of integers. This ignores that boolean vectors
also exist. The original code would abort when `getIVecComponent` was
called on a bool vector.
There is another bug here--arithmetic operators on bool types should be
disallowed entirely. That will be addressed in later CLs.
Change-Id: I78781d839abde9376917fd92f2fe6311a1a58b02
Bug: oss-fuzz:27808
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/338055
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Change-Id: I1be21b428939d17bbf3a9347a64db56c7cd69eb4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/337638
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Previously, the code which calculated Constructor constant values
assumed that a constant-value PrefixExpression would always have an
operand of Constructor. It turns out that another valid case is multiple
PrefixExpressions nested within each other (representing repeated
negation). Updated the code to work regardless of the type of the prefix
operand.
Change-Id: Ic9bf54725ae59330ac817bc4ec7a64def384ab54
Bug: oss-fuzz:27663
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/337177
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
We now have SPIR-V golden outputs for `blend` and `shared` tests.
This exposes a handful of SPIR-V limitations for us to address.
Change-Id: Ie5278889b8a61432403d06231b17765885bee0ac
Bug: skia:10694
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/337182
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
The fix submitted at http://review.skia.org/335868 did not support
casts. The fuzzer discovered this shortcoming right away.
Change-Id: I2f5166528cee41367348564d4e664476fd5704ff
Bug: oss-fuzz:27650
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/336656
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
The fuzzer managed to create a test case which temporarily evaluates to
expression `half2(half(0.2)) + 2` as it is optimized. This requires a
bunch of temporary nonsense math as the IR Generator is attempting to
simplify as it goes; various attempts to remove terms from the fuzzer
test-case would cause it to stop reproducing the error.
Constructor::getVecComponent assumed that any constructor with a single
scalar argument would always implement `getConstantFloat` and
`getConstantInt`; however, constructors themselves did not actually
implement these methods. This meant that nesting a scalar constructor
inside a non-scalar constructor would abort when it tried to deduce the
value inside the inner constructor.
This has been fixed by implementing `getConstantFloat` and
`getConstantInt` for Constructors. These methods will assert if the
constructor has more than one argument or is a non-scalar type. This
should allow any number of nested constructors, e.g.
`half4(half(half(half(1))))` should recursively evaluate properly,
should we somehow generate this as an intermediate expression.
Change-Id: Iaee4284cba03974443cd7b5dccfd7909c1a5f3a6
Bug: oss-fuzz:27614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/335868
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This was slightly complicated by the fact that this syntax indicates an
array with a known size:
float[] x = float[](1, 2, 3, 4);
Of course, the size is 4; it's just never explicitly stated in the
code. (The SkSL parser never actually deduces the size, but it doesn't
apparently have a need to; we don't do much in the way of optimization
for arrays.) However, this prevents us from simply failing whenever we
parse "[]" in non-builtin code; we need to keep scanning and see if the
variable is initialized. We already check this in the
ArrayConstructors.sksl test file.
Change-Id: I5b86958e81bd9bf5edf28a617cecf95c1875583e
Bug: skia:10957
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/335240
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This is a followup to http://review.skia.org/335196. This detects opaque
types (samplers and textures) at parsing or IR generation time and
reports an error regardless of backend. This check occurs before Metal
or SPIR-V would have a chance to detect the error, so it changes their
output to a slightly more focused error message. The Metal/SPIR-V fix in
the prior CL is still a nice broad catch-all for preventing spurious
ABORTs, though.
Change-Id: I4cce92a8767d72b5d3d7277a8afde8ce5ce86db2
Bug: skia:10956
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/335217
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Previously, MemoryLayout would ABORT if it encountered any types that
we can't layout in memory (e.g. opaque types like samplers). Instead of
an abort, this case is now detected cleanly and an error is reported
identifying the offending type.
This should unwedge the fuzzer, which appears to be very
enthusiatically generating interface blocks with nonsense types inside.
(Note that code generators which don't actually try to compute a memory
layout--that is, GLSL--will still accept these types. This should still
be caught and reported as an error, since it's still illegal in GLSL,
but that's for a future CL.)
Change-Id: I88a9649bcd8c75dadc8cca679f3c5e94570742bc
Bug: skia:10956, oss-fuzz:27525
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/335196
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Metal-specific tests are pretty thin on the ground here, and some of
the remaining tests no longer added value as they were already covered
pretty well by existing tests in Shared. The majority of remaining tests
were specific to Metal's lack of flexible matrix casting (and SkSL's
ability to paper over this with helper functions).
Change-Id: I7b3c445268b95320e7f46ec88d793c315d43ee8a
Bug: skia:10694
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/334956
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This prevents OOMing when given a pathological input, but is large
enough that almost all inputs should continue to compile as-is.
Change-Id: If5c46711b886ee08495bfd09af537e9dc7ea5649
Bug: skia:10945, oss-fuzz:27442
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/334838
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
In practice, the inline threshold does a good job of limiting the
blast radius here.
Change-Id: I495184116e733262ea9d84fec30885ea047ca116
Bug: skia:10945
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/334597
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This fixes a fuzzer crash in Metal.
Private types aren't meant to be used directly; we can't generate a
valid MemoryLayout for them. We will now detect them during IR
generation and report an error. (Note that unreferenced structs
currently don't have any IR representation at all, so structs have to be
used somewhere in the code to trigger the error.)
Bug: oss-fuzz:27288
Change-Id: I432f0a69fbb54cd33ff5b90a9f3d4757a9370117
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/334830
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
At present, we do not report any error; the values wrap silently.
Change-Id: I8c435cfdd81f6c2e5fd87e9c39c708138bf4ec82
Bug: skia:10932
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/333676
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This addresses a sanitizer issue discovered in
https://oss-fuzz.com/testcase-detail/4908118777266176 (it has not been
assigned an oss-fuzz bug number yet; coming soon)
This puts an upper bound on struct nesting, again to prevent memory-
layout and other recursive type-handling code from overflowing the
stack. Coincidentally, while researching GLSL behavior around this bug,
I learned that WebGL has a similar limitation but caps nested structs to
4 deep. (I could not find any documented GLSL upper bound.)
Note that both the GLSL and Metal outputs for StructMaxDepth are badly
malformed. (Structs cannot be embedded within another struct in GLSL;
structs SA7 and below are never declared in GLSL; the array list for SA7
is backwards in GLSL; Metal is missing structs SA1 through SA8; Metal
puts the array list on the type instead of the variable name.)
These issues will be addressed in separate CLs.
Change-Id: I0f1059b6faa400cd0647dd7010ec839f73779a36
Bug: skia:10922, skia:10923, skia:10925, skia:10926
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/333316
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This addresses a sanitizer issue discovered in
https://oss-fuzz.com/testcase-detail/4908118777266176 (it has not been
assigned an oss-fuzz bug number yet; coming soon)
We need to set some sort of limit here to avoid stack overflow. Eight
array dimensions seems like more than enough for any sort of code that
we might realistically need, but the limit is definitely flexible if we
wanted to increase it. (The fuzzer needed to generate a several-
hundred-dimensional array before encountering a crash.)
Change-Id: I3630ab40e47cc58a2280ba200b485e1958371fdc
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/333160
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This addresses a sanitizer issue discovered in
https://oss-fuzz.com/testcase-detail/4908118777266176 (it has not been
assigned an oss-fuzz bug number yet; coming soon)
A followup CL will limit array dimensionality to 8. This is an arbitrary
choice which is hopefully larger than any reasonable program will need.
Change-Id: I4cf05f40ec92c1c3444c71c45f759bb30d7da3c9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/333135
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
`in` vars shouldn't support initializer expressions at all. The fuzzer
noticed that dead-stripping interacts poorly with `in` var initializer
expressions, which makes sense because it's an unsupported and untested
path. In a followup CL, lines 1 and 3 will both become errors.
Change-Id: Ibb64ca319a046b040eea976acb6798a1402451de
Bug: oss-fuzz:27300
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/333128
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Change-Id: I19a9564ac4d52b709b8fdd757b99222372c626f4
Bug: oss-fuzz:26942
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/331598
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
- Prototypes for never-declared functions
- Prototype before use
- Prototype after use
- A variety of inputs and outputs on the prototyped functions.
- Calling declared-but-undefined functions
Currently, the prototypes are not actually emitted in the generated GLSL
or Metal output at all. This CL is demonstrates our baseline before
proper prototype support is added.
Change-Id: I6112e0a89ab9bbecefccaca9fba985bb8011fff1
Bug: skia:10872
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/331376
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This improves the test output for Metal. Previously, the Metal output
was just an error message, since 1D textures were unsupported. Now we
have a valid golden output for the 2D case in Metal. (1D is still
unsupported and is likely to remain unsupported; Skia currently has no
use case for 1D textures.)
Change-Id: I91977712030f08e371cc6bfb2afa578940ca00b7
Bug: skia:10797
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/330940
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This error was caused by an unbalanced symbol table push. This could
occur when an interface block encountered an error while parsing its
var-decls.
Change-Id: I910a980ac92fac7c0786c48b8dc3003ee3e75e5b
Bug: oss-fuzz:26700
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/330896
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
(This CL also adds modulo to the IntFolding shared test, since this was
absent from the test. It's implemented and working properly already.)
Change-Id: I24a947ab38754bff2624cd5b58cf7a39553ca888
Bug: skia:10870
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/330596
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
`func1` and `func2` emit bad code, `return %s()`, and because they don't
consume their `%s` format argument. This leaves the format argument list
unbalanced and all future args are wrong.
Another serious problem is that we don't actually know the names of the
functions that they need to call, because we haven't emitted them yet.
`func3` is not emitted at all. Sampling from a fragment processor
apparently fails in this context.
This is a more general case repro for skia:10684--it turns out that
recursion in particular wasn't the issue, but nested function calls just
don't work properly at all in FP files. This wasn't an issue in practice
because we don't have any existing FP files which nest function calls,
and the inliner also tends to aggressively flatten everything out if we
don't explicitly disable it.
Change-Id: Iff029c459c7d90be566f9b4c9be0e3150e459866
Bug: skia:10684
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/329367
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
The generated code does not assign to sk_OutColor correctly; it assigns
into the `factorial` function name instead, which doesn't make sense.
Change-Id: Ibad1d47f2f9c4fbb410b5277cea6e1022daf8b9d
Bug: skia:10684
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/329360
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
In cases where multiple variables were declared on a single line, it is
legal for variable initialization-expressions to reference variables
declared earlier in the var-decl statement. It is NOT legal for the
inliner to move those references up to the previous statement, where the
variable doesn't exist yet.
This is mitigated by disabling the IRGenerator inliner for var-decls
past the first one in a var-decls statement. (The optimizer will still
pass over this code later and is able to inline it correctly, if it is
worth doing.)
Change-Id: I7a0d45eab20e30ed9f6b2f5c1251b6e0d8eeaea3
Bug: oss-fuzz:26167
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/329357
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
These don't compile in GLSL, so they shouldn't compile in SkSL either--
and fortunately, they do not.
(In C++, and consequently in Metal, these expressions are considered
legal by the grammar and do compile, but generate garbage output.)
Change-Id: I6c7bea70b3d91677ccd8fcbad1eba123d655e856
Bug: skia:10694
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/329359
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>
