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>
We had support for layout(key=identity), which added a bit to the key
depending on whether or not a matrix variable was identity. That feature
was unused - now 'key' is just a flag, rather than a separate enum.
Change-Id: I691a0b3683610f55e5d020b9cd6d9e414690bee6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/374416
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
This was added to Ganesh briefly in 2016 for an experiment, then
reverted, and never used.
Change-Id: I65849aff53acc14f9adc7585398fd09363a4ed65
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/374376
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Cloned from http://review.skia.org/369716
Re-running the experiment now that @switch is supported when
optimizations are disabled.
Change-Id: I428051d9c679a8084589fba428a637f36587be16
Bug: skia:11341
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/374516
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
At IR generation time, this CL limits our optimizations to only
@switch statements. A regular switch statement will only be optimized
during the optimization phase even if the switch-value is a known
compile-time constant. This is done to avoid upsetting our reachability
analysis.
Most of this CL is moving existing logic from SkSLCompiler into
SkSLAnalysis and SkSLSwitchStatement. Although the diffs look large, the
actual changes are very small.
Change-Id: I90920f41bc386dfa7a980ae7510f6681231a5120
Bug: skia:11340, skia:11342, skia:11319
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/372679
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Bug: skia:10837
Change-Id: I33da2eb1e723ed04ab62d65c21e54306dd362bed
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/372677
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Change-Id: I10d561eec456a7917681d7bdf0b1bd2f5ee5ad5f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/374217
Auto-Submit: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Rename factory function from createGLSLInstance() to makeProgramImpl()
Bug: b/180759848
Bug: skia:11358
Change-Id: I095bdf1f26db5a8192fa8ab59000db4a1d561d96
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/373738
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This splits switch() construction into two stages.
- One version of Make takes an array of case-values and case-statement
lists, and is responsible for reporting errors if the case-values are
not unique or are improperly typed. This is what the IR generator or DSL
will start with on its first encounter with the switch statement.
- The other version of Make takes an array of already-processed
SwitchCases and can assume the invariant that they're all correctly-
typed with unique values. This is what we will have when a statement
is inlined or otherwise cloned. (We still assert this invariant, for
correctness' sake, but in release mode we assume it.)
This CL doesn't perform any optimizations at Make time yet; it does work
equivalent to how `switch` works in the IR generator today. It does
improve duplicate case-label checking slightly; duplicate case labels
are now reported, and duplicate `default:` labels are detected.
(Multiple `default` labels won't pass the parser, but they can be
constructed in DSL.)
Change-Id: I537ce2c8236152d58641fb1793619d66a62c01a8
Bug: skia:11342
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/372616
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This will allow us to disable dead-code elimination and run performance
tests.
Change-Id: Ia98aa88e8db511e77ad2fb669af128f4510285ae
Bug: skia:11361
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/374316
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>
These were unused - we always enable the advanced blend equation
extension using "blend_support_all_equations" (if enabling the
extension is required at all).
Change-Id: I95fd6483ec54dfaf983290de95629fe0e86c22e8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/373877
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Chris Dalton <csmartdalton@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>
This allows the optimizer to remove it when the switch value is known,
instead of waiting for the dead-code-elimination pass to find it.
(If we decide to remove the dead-code-elimination pass entirely, this
will generate better code overall.)
Change-Id: I79a40eb3cfbc7e5d2f4879e1f98323248446483b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/373876
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This allows things to align better between the IR and DSL sides
and gives us equivalent error handling on both sides.
Change-Id: I6d5569e29df51a4d1a6cb0ad1e6611d419dfe30c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/373737
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>
Change-Id: I672345116e3b5538c0f7e8c5f2f74aa56bb81e6d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/372676
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: 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>
There are two forms. Swizzle::Make supports components XYZW only;
Swizzle::MakeWith01 also supports the 01 components, and restructures
the zeros and ones into a constructor (as IRGenerator::convertSwizzle
has historically done). This means that once we are past the initial
IR generation stage, and we know that the 01 components have been
eliminated, we can avoid the extra 01-handling logic and just call
Swizzle::Make directly. This isn't a huge deal but it means that call
sites like the inliner can avoid some extra work that will never happen.
Change-Id: I46690c3d6b07feb6327ee72e8f66f15592a35554
Bug: skia:11342
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/371398
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 IRGenerator's `convertConstructor` and `coerce` were tied at the
hip--coercion can create a constructor, and creating a constructor can
cause type-coercion. This CL migrates IRGenerator::coerce to
Type::coerceExpression, and migrates IRGenerator::convertConstructor to
Constructor::Make.
Most constructor creation should go through Constructor::Make instead of
make_unique<Constructor> for best results. There are exceptions to this
rule:
- during the Compiler's `optimize` phase, we hold raw pointers to
unique_ptrs of existing expression trees, and are manually tracking
variable usage counts, so adjusting the IR tree should be done with
extreme care. Continue to use make_unique here to avoid any "surprise
improvements."
- the Rehydrator is attempting to recreate an IR tree exactly as it used
to be and doesn't want additional optimization or fixups
There are still Constructor-related optimizations in simplifyExpression
which are not yet implemented in Constructor::Make. These are migrated
to Constructor::Make at http://review.skia.org/371482
Change-Id: I0f3876f932835fc2e347ae95414bc490085f120c
Bug: skia:11342
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/370876
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This will help us migrate code out of IRGenerator.
Change-Id: Id9c70cc4577ed41b2fc5ad26f752caea13a56083
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/372437
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Change-Id: I218429246da2da3e80fb1823241fdbcf84f0dd30
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/372478
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
The SwizzleComponent enum would be useful outside of the DSL. This CL
creates a SkSL::SwizzleComponent namespace and has the DSL inject that
namespace into SkSL::dsl via using-directive. Future CLs will use values
from this enum within SkSL::Swizzle itself.
Users expect that `using namespace SkSL::dsl;` will allow statements
like `Swizzle(var, X, Y)` to work normally without any extra
qualifications, using-declarations or #includes, so this is a little
more involved than forward-declaring an enum would be normally.
Change-Id: Id4e2f109d01e465c315c6278f3d4b87027988c86
Bug: skia:11342
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/372018
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Change-Id: I4df18946cdb3d9f1f7833461f913f2df94696821
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/372197
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Change-Id: I3cde541ff8eb7239394e825061ed1433806af5c7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/372123
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
This wasn't even referenced by the parser.
Change-Id: Id6246c3909b7f2b499908a742bdd61f4918f023a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/372119
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
These were all unused, and only implemented on one backend.
Change-Id: Ibd2fcef1a971e6c1bd9da0784c5d852a60708484
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/372117
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Change-Id: I885149c73be63c223ac88a697ffe046a7f8384d0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/372116
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Brian Osman <brianosman@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>
Bug: skia:11295
Change-Id: Iec11f3f4d26eb5b1c07707b3cedd09096bad80d0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/371478
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
When coercing a type, we would previously call checkValid() so we could
detect function-references and type-references, so we could get a nicer
error message.
It turns out that we can just do the "is this a type-reference/
function-reference?" check directly inside coerce() and get the same
improved error messages. Since we should be coercing all our values to
the right type, and type/function-references aren't coercible to
anything, this should catch them all. I don't expect any of these
to survive all the way to the end of IR generation.
(In case one of these types does slip through, I've left the error case
in checkValid, but I've also put in an assertion. If the fuzzer can
make that assertion fire, we are probably missing a call to coerce()
somewhere.)
This cleanup is meant to help migrate coerce() out of IRGenerator.
Change-Id: I031809adf439b1766048768b782c57e7f2494006
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/371479
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
These classes now read the program configuration from the Context.
Change-Id: I15c95cacebb9836ee8f2162c4f4b7f99d453639c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/371396
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Adds trivial name mangling to the .stage output, so we can verify that
it's working in all places (declarations, references, etc). Also added
another global variable whose initializer is - in turn - another global.
Bug: skia:11295
Change-Id: Ic220bfae0a6d1eeeba66ade30d3d781af15c5dea
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/371477
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
During IR generation, this information was previously only accessible
from inside the IRGenerator class. Now anyplace with access to the
Context can look up the program settings or kind.
Moving the ProgramKind inside the ProgramSettings struct would be an
interesting future goal, but this ends up causing significant ripple
effects outside of SkSL and may not be worth untangling. Many of our
callers expect to compile a Vertex, Fragment, and/or Geometry shader all
at once with the same Settings but differing ProgramKind, so perhaps
the distinction between Kind and Settings is relevant and worth
keeping as-is.
Change-Id: I8b3a61510911b4ff309549663f81f3b960bdb0da
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/371256
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Change-Id: Idd0d49d3564dc3a24455db3c504ffa124f34dd05
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/371336
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@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>
Previously, a manual codeAppend call was required to add a statement. We
now automatically invoke codeAppend when a statement is destroyed.
Change-Id: I09eaf230b1d58242c3ff6abb85e970ed5ed3bce2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/371141
Auto-Submit: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Bug: b/179848728
Bug: b/146635333
We're seeing some slow shader_compiles on Android, so add some more
tracing to help determine where that time is being spent.
Use ATRACE_ANDROID_FRAMEWORK_ALWAYS instead of ATRACE_ANDROID_FRAMEWORK
for driver_compile_program and driver_link_program so that tracing for
the work done in the GPU driver will be turned on even if the developer
does not manually turn on skia tracing with
adb shell setprop debug.hwui.skia_atrace_enabled true
This matches the "shader_compile" tag added in b/146635333 and allows
non-Skia developers to easily capture traces with more info.
Change-Id: Ic698daad878bc0b946e15ec2f2f2e8cf53f30fbc
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/369483
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
This change will allow these types to be forward-declared; C++ doesn't
allow forward declaration of types declared inside a struct. Moving
these types out of Programs resulted in a large diff.
The Settings::Value helper class has been moved inside of the
IRGenerator. In practice, it was actually just an implementation detail
of how IRGenerator looks up caps-values by name. It seems very unlikely
that this will be necessary elsewhere going forward.
Change-Id: I6119417fae608f1c492a27de746d2b550ef8ca20
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/370836
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 lets us write `op.isAssignment()` instead of
`Operators::IsAssignment(op)`.
Change-Id: If35f2ac500b6ccabc364f9104faaad6e62564667
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/369958
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>
The out-param helpers emitted by the Metal code gen (intended to provide
GLSL out-parameter semantics in Metal) emitted bad code if passed the
same variable for two separate out parameters. It would previously
create two parameters in the helper with the same name. The helper
function now omits the name of the second variable in the parameter list
if it is redundant; we already know the caller is passing the same
variable twice.
Change-Id: Ibdc6c02a9e9e4bdb4f4546a25068f2018aa07b10
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/370258
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This reverts commit 5ad759065d.
Reason for revert: Experiment concluded - got the data we need.
Original change's description:
> Performance experiment: Disable SkSL optimization in nanobench/skpbench
>
> Change-Id: I974571e7e0e9d0170f92b970d425d9ce530e312e
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/369716
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
TBR=bsalomon@google.com,brianosman@google.com,johnstiles@google.com
Change-Id: I68bc07e8a604abb77fe9c1f1dac794ab7b90b9e9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/370156
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@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 know expressions can't contain @if or @switch statements inside of
them, so we can avoid recursing into them and run this check slightly
faster.
Change-Id: I60cd6dd40ddda74f7af259fd13e5ea0779982384
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/370076
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@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>
