This is supported in GLSL ES3. (Strangely, vector operator! isn't.)
Previously, this was flagged as an error: http://review.skia.org/459885
Change-Id: I2c4299159fff58fefe8bd131c8d317cd82974a62
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/459886
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 eb68973c2f.
Reason for revert: ES2 conformance test checks this
Original change's description:
> Disallow matrix ctors which overflow a column.
>
> The GLSL spec allows matrix constructors containing vectors that would
> split between multiple columns of the matrix. However, in practice, this
> does not actually work well on a lot of GPUs!
>
> - "cast not allowed", "internal error":
> Tegra 3
> Quadro P400
> GTX 660
> GTX 960
> - Compiles, but generates wrong result:
> RadeonR9M470X
> RadeonHD7770
>
> Since this isn't a pattern we expect to see in user code, we now report
> it as an error at compile time. mat2(vec4) is treated as an exceptional
> case and still allowed.
>
> Change-Id: Id6925984a2d1ec948aec4defcc790a197a96cf86
> Bug: skia:12443
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/449518
> Commit-Queue: John Stiles <johnstiles@google.com>
> Auto-Submit: John Stiles <johnstiles@google.com>
> Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Bug: skia:12443
Change-Id: I5a32744c88b9b830ad657488824c8c7dd0b0a652
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/458056
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
To my great surprise, a capital X is allowed in hex literals. In fact,
this is allowed in both GLSL and C. The ES2 conformance suite tests
this, so now SkSL supports it as well.
Change-Id: If795c6033b301420669f002530ee1d14fec29f96
Bug: skia:12533
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/458723
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
GLSL treats builtin types and user-defined types differently; `int` and
`float` are keywords and cannot be used to name variables. However, it's
fine for a user type like `struct xyz` to be hidden by a variable
`int xyz` or even `xyz xyz` (i.e., a variable of type `struct xyz` named
`xyz`).
We now honor that distinction and include tests for it. This will fix
several ES2 conformance tests (local_struct_variable_hides_struct_type,
local_int_variable_hides_struct_type, etc.).
Change-Id: I7a45c70707087f9f355ce5b06b032fed16683f3e
Bug: skia:12527
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/458721
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
SkSL treated these two functions as distinct, even though they are not:
void func(in float x);
void func(float x);
The `in` modifier on a function parameter is the default state, making
these two prototypes functionally identical. We now strip off an `in`
modifier on a function definition. This gives us three potential states
for each param: nothing (meaning `in`), `out`, and `inout`.
Change-Id: Id2acb53ecaca98f86a7f6a83e0b9a375f9abe2b8
Bug: skia:12525
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/458257
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 weren't used anywhere in our test suite.
Change-Id: I35e8607ad2dbddf8f403668bd2b2636a8964d304
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/455777
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Previously we did not have a Pipeline callback function for prototyping
a function, so prototypes would be discarded during translation. This
failure mode can be seen in http://review.skia.org/454741, where
FunctionPrototype.sksl is made more complex (thwarting the inliner).
This causes us to emit invalid GLSL, and dm asserts/fails in the SkSL
tests: http://screen/4PkEEWn4m4tF5e7
This CL makes the same changes to FunctionPrototype, but does not crash.
Change-Id: Ia342c7811a454f62f52677440d247e628a1bdc4f
Bug: skia:12488
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/454740
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
It looks like returning from inside a switch on iOS gives wrong results
in GLSL.
Change-Id: I9d6d8971a7a54600268e27443815444fca6f3c61
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/450994
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This fails on several platforms in practice, and is of very limited
real-world utility.
Change-Id: Ib476396fc33cb51af6bbcf7fe822d30703ed995d
Bug: skia:12467
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/450993
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: I17b5e21a28140b8e9313d87af9b1145674214fdb
Bug: skia:12450
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/450989
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Also, removed "switch containing dead code" test. This wasn't testing
anything meaningful. (When we had full CFG analysis, we could have
eliminated some of the assignments inside the switch body, but this is
not something we do anymore.)
Change-Id: Iaeb74ebee41a7f368113ede9a4e30c033b9de8ac
Bug: skia:12450
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/450985
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>
The Mac Radeon GLSL driver crashes when given a switch statement that
only contains a default case and returns a value. Adding a case works
around the crash, and doesn't affect the meaning of the switch.
Change-Id: Iabbd267e0e31e8df7d3b7e747a7204d50931d0be
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/450977
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This is a reland of be056f4f62
The Switch test has been restructured to dodge an iOS bug.
Original change's description:
> Add switch statement support to PipelineStage.
>
> This allows us to write SKSL_TEST_ES3 tests in SkSLTest and have them
> run properly. Previously, such a test would assert inside the pipeline-
> stage generator. In ES2 mode, we will rewrite switches as chained ifs,
> but in ES3 mode we will want to continue emitting them as-is (they will
> be faster than chained ifs on a modern GPU).
>
> `writeSwitchStatement` is adapted from GLSLCodeGenerator.
>
> Change-Id: I532ea5ed49869e7cdffced0cdcd0e353af8d4d79
> Bug: skia:12450
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/450478
> 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>
Bug: skia:12450
Change-Id: I5102081c636ef09cd23f5bc894e6c96e92a4c121
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/450757
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This fixes a driver bug with the Nexus 7 while retaining the meaningful
part of the test.
Change-Id: I98edab32132f0c52a1f69b03efd403fae43c336b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/450482
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This reverts commit be056f4f62.
Reason for revert: apparently switch on iOS GLSL is extremely broken
Original change's description:
> Add switch statement support to PipelineStage.
>
> This allows us to write SKSL_TEST_ES3 tests in SkSLTest and have them
> run properly. Previously, such a test would assert inside the pipeline-
> stage generator. In ES2 mode, we will rewrite switches as chained ifs,
> but in ES3 mode we will want to continue emitting them as-is (they will
> be faster than chained ifs on a modern GPU).
>
> `writeSwitchStatement` is adapted from GLSLCodeGenerator.
>
> Change-Id: I532ea5ed49869e7cdffced0cdcd0e353af8d4d79
> Bug: skia:12450
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/450478
> 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>
Bug: skia:12450
Change-Id: If40c90023a64c608181285f6470b3e75303cc3cc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/450756
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
This allows us to write SKSL_TEST_ES3 tests in SkSLTest and have them
run properly. Previously, such a test would assert inside the pipeline-
stage generator. In ES2 mode, we will rewrite switches as chained ifs,
but in ES3 mode we will want to continue emitting them as-is (they will
be faster than chained ifs on a modern GPU).
`writeSwitchStatement` is adapted from GLSLCodeGenerator.
Change-Id: I532ea5ed49869e7cdffced0cdcd0e353af8d4d79
Bug: skia:12450
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/450478
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 didn't have a test case for this particular construct, but we will
emit special code to handle it when rewriting switch statements.
Change-Id: I7ac632f7bee348194940812c956c8a7df51ffaff
Bug: skia:12450
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/450477
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
`increment` and `float a` could be eliminated, but are not.
This is fixed in a followup CL.
Change-Id: I7a5c3ab7341f40020f84f157b08a7152bc067af0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/450276
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
The GLSL spec allows matrix constructors containing vectors that would
split between multiple columns of the matrix. However, in practice, this
does not actually work well on a lot of GPUs!
- "cast not allowed", "internal error":
Tegra 3
Quadro P400
GTX 660
GTX 960
- Compiles, but generates wrong result:
RadeonR9M470X
RadeonHD7770
Since this isn't a pattern we expect to see in user code, we now report
it as an error at compile time. mat2(vec4) is treated as an exceptional
case and still allowed.
Change-Id: Id6925984a2d1ec948aec4defcc790a197a96cf86
Bug: skia:12443
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/449518
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This exposes a bug in the Metal code generator which will be resolved
in a followup CL.
Change-Id: If073835dbee474ea9a805eb92b42dc1fca2afbd0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/448378
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
The fuzzer discovered that, when we attempt to verify that an array
doesn't contain any literal values that are out-of-range for its base
type, we pay a linear-time cost based on the size of the array. This
happens even when the array value isn't known at compile time; we still
iterate over its slot count and diligently discover that every single
constant-subexpression slot in the expression is "null".
We now have a helper function on Expression,
`allowsConstantSubexpressions`, which only returns true for expression
kinds that can contain constant subexpressions. We use this helper to
skip over this linear-per-subexpression check when the expression
cannot possibly contain a constant subexpression. In particular,
`AnyConstructor::compareConstant` and `Type::checkForOutOfRangeLiteral`
will now early-out for expressions that can't possibly contain a
constant subexpression.
Change-Id: Ia34e422afa67b478a8616acb0a0e9cd211b29698
Bug: oss-fuzz:37900
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/444136
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>
We had a logic bug when attempting to optimize the following code:
const vecN x = vecN(a, b, c);
-x;
The goal was to replace `-x` with `vecN(-a, -b, -c)` but we accidentally
tried to cast the `x` VariableReference to a Constructor. We
unfortunately didn't cover this in any of our test cases, but the fuzzer
managed to synthesize it by mixing and matching elements from its new
corpus.
This affected several different constructor types: splat, diagonal-
matrix, compound and array.
Change-Id: I10dd2460ab26ba3e820b0cff5db091368fb7e648
Bug: oss-fuzz:37764, oss-fuzz:37861
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/443407
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>
Bug: skia:8451 skia:10827
Change-Id: I5b38a1d72cd4558f8e2a92aaf9b12f05efce0923
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/442683
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
This is a first step towards replacing `finalizeFunction` with a
`FunctionDefinition::Convert` method living outside of the IRGenerator.
Previously this code would assert that we had no early returns from a
vertex-program main() method; this has been turned into an error.
(The original assertion was also tied to fRTFlip, because the *problem*
with early-returns in main is tied to the lack of RTFlip fixups, but
we fundamentally don't allow early returns, so it makes more sense to
just universally disallow it.)
Change-Id: Iba0742f7ef3cbc83995ea130fec1eb1ef2556c44
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/442691
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
No-op arithmetic simplification will convert expressions like `x += 0`
to `x`. When making this simplification, we will also downgrade the ref-
kind of `x` from "write" to "read" since the new expression is no longer
an assignment.
The fuzzer discovered that the ref-kind downgrade was too aggressive,
and would also traverse into nested subexpressions and downgrade them
as well. That is, for `x[y=z] += 0` would convert both `x` and `y`
into "read" references, which is incorrect; `y` is still being written
to.
The fuzzer managed to turn this mistake into an assertion by leveraging
a separate optimization. It added a leading, side-effect-less comma
expression for us to detect as worthless and eliminate. In doing so, we
clone the expression with the busted ref-kind, triggering an assertion.
Change-Id: I42fc31f6932f679ae875e2b49db2ad2f4e89e2cb
Bug: oss-fuzz:37677
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/442536
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
The fuzzer detected a serious parsing error; a struct containing a
vardecl with multiple declarations would interpret arrays incorrectly.
An array would be applied to ALL variables in the decl after its initial
appearance. That is, `int w, x[10], y, z;` would be interpreted as
`int w, x[10], y[10], z[10];`. The fuzzer caught this by putting two
arrayed variables in a row; the second variable was interpreted as a
nested array, which led to an assertion.
This CL contains a simple hand-written test case demonstrating the bug,
with the fix coming in a followup.
Change-Id: I42d7372ba77fa1528ae24eb8c29a2e5903784139
Bug: oss-fuzz:37622
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441878
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Change-Id: I26754745aa26313a2f76a86bd41699c7ac5b8a46
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441596
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 inliner contained a type error when attempting to inline a function
that takes an array as input. The scratch copy of the array was created
as `float[123] var;` instead of `float var[123];`. This led to an
assertion in VarDeclaration::Make.
Change-Id: I5128fe71462bb59a015a7b4e59c1a74800828b16
Bug: oss-fuzz:37466
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441576
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>
During constant-folding, we baked in an assertion stating that any
const-typed variable reference ought to have an initial value, because
you can't declare a const variable without assigning a value. However,
function parameters are an exception to this rule! They are variable
references and are allowed to be const, but will not have an initial
value. (In this case, `const` just means you can't alter the value.)
In this case, all we needed to do was remove the assertion; we already
treated this case defensively and with the appropriate care.
Change-Id: I61242c6d08c59886c6992898f195771e6334f2b4
Bug: oss-fuzz:37465
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441239
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 another place where we needed to use
`getConstantSubexpression` to rebuild vectors/matrices; it is a more
robust approach than trying handle each ctor type individually. The
fuzzer found an edge case with double-casting matrices to vectors that
fell through the cracks with the original approach.
In adding additional tests, I also found a case that the constant-folder
seems to ignore, `bool4(x,x,x,x) == bool4(x)`. This does fold for ints
and floats, so this ought to be fixable in a followup, but it's not a
big deal either way; this is very unlikely to occer in real code.
Change-Id: I4d577c87ef7049306685ca95250ecdf93b1dbc06
Bug: oss-fuzz:37464
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441238
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>
An assignment like `mediump int a[2] = myHighpIntArray;` should succeed
now that the previous CLs have landed; originally, this would have
caused a type-mismatch error.
Change-Id: I86ffe6a21d0c7fbe289eef95aebc2605412566aa
Bug: skia:12248
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/437740
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Compiling a program with "allow narrowing conversions" actually fixes up
narrowing casts in the program by inserting casts wherever they would be
needed for type-correctness. For instance, compiling the statement
`half h = myFloat;`
inserts an appropriate narrowing cast:
`half h = half(myFloat);`.
The Pipeline stage code generator relies on this behavior, as when it
re-emits a runtime effect into a complete SkSL program, the narrowing-
conversions flag will no longer be set, but that is okay, because the
emitted code now contains typecasts anywhere they would be necessary.
Logically, this implies that anything which supports narrowing
conversions must be castable between high and low precision. In GLSL and
SPIR-V, such a cast is trivial, because the types are the same and the
precision qualifiers are treated as individual hints on each variable.
In Metal, we dodge the issue by only emitting full-precision types. But
we also need to emit raw SkSL from an SkSL program (that is what the
Pipeline stage generator does).
SkSL already supported every typical cast, but GLSL lacked any syntax
for casting an array to a different type. This meant SkSL had no array
casting syntax as well. SkSL now has array-cast syntax, but it is only
allowed for casting low/high-precision arrays to the same base type.
(You can't cast an int array to float, or a signed array to unsigned.)
Change-Id: Ia20933541c3bd4a946c1ea38209f93008acdb9cb
Bug: skia:12248
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/437687
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This is a reland of 23d8f94535
Original change's description:
> Fix array-of-matrix/struct comparisons in Metal.
>
> Metal needs helper functions in order to compare arrays, structs, and
> matrices. Depending on the input code, it was possible for the
> array-comparison helper to be emitted before a matrix-comparison
> or struct-comparison helper. If this occurred, array comparisons of that
> matrix or struct type would fail, because the operator== for the array's
> inner type was defined after array==, and Metal (like C++) parses
> top-to-bottom and only considers functions declared above the current
> function.
>
> We now emit prototypes for all the array, struct and matrix helper
> function. These prototypes are emitted above any helper functions. This
> ensures visibility no matter how your comparisons are organized.
>
> Change-Id: Ib3d8828c301fd0fa6c209788f9ea60800371edbe
> Bug: skia:12326
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/437739
> Commit-Queue: John Stiles <johnstiles@google.com>
> Auto-Submit: John Stiles <johnstiles@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
Bug: skia:12326
Change-Id: Ife68020f6b01fae973b97f76099c6d5e8215636c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/438296
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This reverts commit ef9a1b66d0.
Reason for revert: not broken after all
Original change's description:
> Revert "Fix array-of-vector comparisons in Metal."
>
> This reverts commit 130338c9e1.
>
> Reason for revert: SkSL_ArrayComparison test causes Adreno 630/640 to crash in Vulkan
>
> Original change's description:
> > Fix array-of-vector comparisons in Metal.
> >
> > Comparing `vec1 == vec2` returns a bvec in Metal, so the result must be
> > wrapped in `all()` in order to boil it down to a single boolean result.
> > Our array-comparison helper function did not do this. Fortunately,
> > `all(scalar)` is a no-op, so we can just wrap the result unilaterally.
> >
> > Change-Id: I4f1f09a6832164ae2e6577d53b317f561332d581
> > Bug: skia:12324
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/437736
> > 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,skcq-be@skia-corp.google.com.iam.gserviceaccount.com
>
> Change-Id: Ic76a5527a8339c8201f52df08d43041d7dcbeb61
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: skia:12324
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/438077
> Reviewed-by: John Stiles <johnstiles@google.com>
> Commit-Queue: John Stiles <johnstiles@google.com>
# Not skipping CQ checks because this is a reland.
Bug: skia:12324
Change-Id: I3da699b8d1113800efb27e162d0c6315f0aeaa49
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/438176
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This reverts commit 130338c9e1.
Reason for revert: SkSL_ArrayComparison test causes Adreno 630/640 to crash in Vulkan
Original change's description:
> Fix array-of-vector comparisons in Metal.
>
> Comparing `vec1 == vec2` returns a bvec in Metal, so the result must be
> wrapped in `all()` in order to boil it down to a single boolean result.
> Our array-comparison helper function did not do this. Fortunately,
> `all(scalar)` is a no-op, so we can just wrap the result unilaterally.
>
> Change-Id: I4f1f09a6832164ae2e6577d53b317f561332d581
> Bug: skia:12324
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/437736
> 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,skcq-be@skia-corp.google.com.iam.gserviceaccount.com
Change-Id: Ic76a5527a8339c8201f52df08d43041d7dcbeb61
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:12324
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/438077
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This reverts commit 23d8f94535.
Reason for revert: SkSL_ArrayComparison test causes Adreno 630/640 to crash in Vulkan
Original change's description:
> Fix array-of-matrix/struct comparisons in Metal.
>
> Metal needs helper functions in order to compare arrays, structs, and
> matrices. Depending on the input code, it was possible for the
> array-comparison helper to be emitted before a matrix-comparison
> or struct-comparison helper. If this occurred, array comparisons of that
> matrix or struct type would fail, because the operator== for the array's
> inner type was defined after array==, and Metal (like C++) parses
> top-to-bottom and only considers functions declared above the current
> function.
>
> We now emit prototypes for all the array, struct and matrix helper
> function. These prototypes are emitted above any helper functions. This
> ensures visibility no matter how your comparisons are organized.
>
> Change-Id: Ib3d8828c301fd0fa6c209788f9ea60800371edbe
> Bug: skia:12326
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/437739
> Commit-Queue: John Stiles <johnstiles@google.com>
> Auto-Submit: John Stiles <johnstiles@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
TBR=brianosman@google.com,ethannicholas@google.com,johnstiles@google.com,skcq-be@skia-corp.google.com.iam.gserviceaccount.com
Change-Id: I9e0fc69c46e1b4f63133e21e130e527ca4f0b31a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:12326
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/438076
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Metal needs helper functions in order to compare arrays, structs, and
matrices. Depending on the input code, it was possible for the
array-comparison helper to be emitted before a matrix-comparison
or struct-comparison helper. If this occurred, array comparisons of that
matrix or struct type would fail, because the operator== for the array's
inner type was defined after array==, and Metal (like C++) parses
top-to-bottom and only considers functions declared above the current
function.
We now emit prototypes for all the array, struct and matrix helper
function. These prototypes are emitted above any helper functions. This
ensures visibility no matter how your comparisons are organized.
Change-Id: Ib3d8828c301fd0fa6c209788f9ea60800371edbe
Bug: skia:12326
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/437739
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Comparing `vec1 == vec2` returns a bvec in Metal, so the result must be
wrapped in `all()` in order to boil it down to a single boolean result.
Our array-comparison helper function did not do this. Fortunately,
`all(scalar)` is a no-op, so we can just wrap the result unilaterally.
Change-Id: I4f1f09a6832164ae2e6577d53b317f561332d581
Bug: skia:12324
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/437736
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Most of the code generated by the fuzzer is nonsense, but there is a
method to its madness. The crash is only triggered under specific
conditions:
- The runtime effect has enough helper functions to mostly fill up the
call graph hash-map. It won't rehash until it gets close to capacity.
- There must be several calls to built-in functions, in order to add
elements to the call graph to force a rehash.
The fuzzer-generated code manages to satisfy both these requirements.
Change-Id: I9a1d7535557fedd4e9bfece3930ac86ede291ffe
Bug: oss-fuzz:36655
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/437118
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
GLSL allows an array of `lowp float` to be compared against `highp
float` seamlessly because the types are considered to be the same. SkSL,
however, treats these as different types, so we need to coerce the types
to allow this comparison to work.
In other words, these comparisons can cause an array to be implicitly
casted. The expression `myHalf2Array == float[2](a, b)` should be
allowed when narrowing conversions are enabled. To allow this to work,
we need a dedicated IR node representing this type coercion.
We now allow implicit coercion of array types when the array's component
types would be implicitly coercible, and have a new IR node representing
that implicit conversion.
This CL fixes array comparisons, but array assignment needs additional
fixes. It currently results in:
"type mismatch: '=' cannot operate on (types)".
Bug: skia:12248
Change-Id: I99062486c081f748f65be4b36a3a52e95b559812
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/436571
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
The optimization logic for swizzling a constructor assumed that every
argument to the constructor was a scalar or vector. When it was written,
this assumption was true. However, we recently added support for casting
mat2x2 to float4 which violates the assumption.
We now check every argument and do not attempt to optimize if a
non-scalar, non-vector arg is found.
Change-Id: Ia2b297bd62dfdf4af56712164fbc80c29c9611eb
Bug: oss-fuzz:36852
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/437017
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
These parse into new modifier bits; the IR generator does not yet
support these bits. That's coming in a followup CL.
Change-Id: I362e9227694f9b862eaad100f6afca45a9b62a01
Bug: skia:12248
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/436336
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
We don't currently support this. There's no explicit syntax to cast an
array's type, but it can be implicitly required in some situations, like
`halfArray == floatArray` (when fAllowNarrowingConversions is on).
Change-Id: I00fe0ddd4f2682b2950e828dd78bb941d5f0430e
Bug: skia:12248
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/436560
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>
SPIR-V code generation synthesizes some extra variables that don't
actually exist in the Program. Checking the ProgramUsage of these
variables would fail; ProgramUsage::get doesn't know about these
variables, so it asserts (and would consider them as dead even if it
didn't assert). We now track our SPIR-V bonus variables in a separate
set, and always report them as live.
Change-Id: If2f681470654025abf7ca4b3ec8126de2eb01297
Bug: oss-fuzz:36770
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/435625
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: I7b53df1eae83a596c4d1f3620e7f9bd146f68af2
Bug: oss-fuzz:36655
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/434465
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
