Our SPIR-V code generator did not implement support for negating a uint.
However, this is something that GLSL allows (as does the rest of SkSL).
I checked glslang and it uses OpSNegate here. The SPIR-V docs indicate
that OpSNegate allows any type of integer, and the validator lets it
pass, so we now use OpSNegate here as well.
http://screen/33mkq92uxAT5Xu8http://screen/4YBTh3gCWz8eZx7http://screen/388HtXyytcN5vLZ
Change-Id: I8c142018fd5e162dcd051abe1bc5d69a6e034794
Bug: oss-fuzz:37627
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441880
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Previously, 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];`.
This is now fixed and our test case runs as expected.
Change-Id: I5b4a617c58cdfb83face651effd42770a1f68638
Bug: oss-fuzz:37622
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441879
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 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>
We weren't coercing the expression because we don't care about its type,
but that allowed intermediate-expressions to pass through without
reporting an error. Now we coerce the expression to its present type,
which will always fail if the type is disallowed and succeed otherwise.
Change-Id: Ic0de0d17f0f5d56360575efe992ce4d74dec2a5a
Bug: oss-fuzz:37620
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441876
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This reverts commit e43714f490.
Reason for revert: Several Pixel (Adreno) devices failing the test
Original change's description:
> Add ES3 intrinsics isinf/isnan to public SkSL ES3.
>
> The ES3 spec doesn't mandate that `isnan` actually has to do anything,
> so the Isnan test is not enabled. (It doesn't work on my personal
> machine unless I make the NaN detectable at compile-time.)
>
> We do not support these functions in constant-expressions, as we
> currently avoid optimizing anything into a non-finite value; we leave
> expressions alone if we calculate a NaN/inf result for their value.
>
> Change-Id: Ibfdfb47b6e6134165c8780db570de04a916d2bfa
> Bug: skia:12022
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441581
> Auto-Submit: John Stiles <johnstiles@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,skcq-be@skia-corp.google.com.iam.gserviceaccount.com
Change-Id: I89899ed391aa870350d0452bab4a0fb75bd7be38
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:12022
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441716
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Bug: skia:12302
Change-Id: I8cf958acf9214d0de903a4097647afd74f2a659e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441541
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
The ES3 spec doesn't mandate that `isnan` actually has to do anything,
so the Isnan test is not enabled. (It doesn't work on my personal
machine unless I make the NaN detectable at compile-time.)
We do not support these functions in constant-expressions, as we
currently avoid optimizing anything into a non-finite value; we leave
expressions alone if we calculate a NaN/inf result for their value.
Change-Id: Ibfdfb47b6e6134165c8780db570de04a916d2bfa
Bug: skia:12022
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441581
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
If x is a known compile-time constant value, it can already be optimized
to a final value.
If x is not known, it could be zero, and 0/0 should result in a NaN.
Change-Id: I643a7c6da0a43ec366235c4df39fc78d3b361de7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441580
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>
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>
After further discussion, using intrinsics with signatures similar to
sample keeps us looking like GLSL. However, using "sample" is still
misleading, so this adds explicit "shade", "filter", and "blend"
intrinsics. After migrating clients, the "sample" versions will be
removed.
Bug: skia:12302
Change-Id: Ia03e4b3794fc1fc5ae3c3099a7a350343ec7702e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441457
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
The additional tests from http://review.skia.org/441238 uncovered a gap
in the constant folder's abilities; it was not able to fold away
boolean vector comparisons even when they were constant. These are ES2
constant-expressions, so folding them properly is a requirement.
Change-Id: Ia0b4d5d1215c5fc2b247ac3f0dec4c8747d2153e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441579
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>
Much easier to maintain, especially with an upcoming change to the
sampling syntax.
Change-Id: I378811b7be0afcce5b7e68a942e7b46d96568155
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441518
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>
This fixes an assertion failure uncovered by the fuzzer.
Bug: oss-fuzz:37469
Change-Id: I626c003cfa8a0bc65851899df3a7695dbe29200b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441311
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: John Stiles <johnstiles@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>
Improved tests caught a longstanding bug in the compile-time
optimization logic for round/roundEven. These would *always* round to an
even number even when it didn't make sense to do so. (e.g. 3.1 would
round to 4.)
RoundEven isn't available in lower shader models of Direct3D;
SPIRV-Cross throws if it's unavailable. We may need a caps bit for this.
Change-Id: I3cc50238a2116b8d4e2c4059730d8b5cfb2bb056
Bug: skia:12022, skia:12352
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441078
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
The fuzzer noticed insufficient guards in IndexExpression::Convert when
converting an array size from an IntLiteral to a SKSL_INT. We had code
in IRGenerator which did this properly, so I moved our array-size
conversion logic into SkSLType and had IndexExpression share it.
Also, a variety of tests around similar error conditions were added.
Change-Id: I51529dea25f9029f81ae236511610069d66be29f
Bug: oss-fuzz:37462
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441236
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
We now stop processing a var-declaration if its array-size expression is
invalid. Previously, we'd pass a null array-size expression into
convertVar, which would assert (but would fail cleanly afterwards).
Change-Id: I976f3326e32afbc7045a86d73c0dcb28f418a6f4
Bug: oss-fuzz:37457
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441079
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
These now have proper testing and compile-time optimization support.
Change-Id: I7978161ec126e1c3096b9ca9dfbb2be7d8ea02f5
Bug: skia:12202
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/440859
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 no-op-arithmetic simplifier was written before we allowed casting a
mat2x2 to a float4, and did not expect a matrix inside a vector ctor.
The expression `float4(myMat2) * float4(anything)` would assert when we
tried to determine if `myMat2` was a constant zero or constant one.
The code has been rewritten to use getConstantSubexpression and now
allows matrices inside.
Change-Id: Id625141256bf89d816c57d2d21f16b0ec252c158
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/440858
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
The prototype has been added sksl_public, compile-time optimization is
implemented, and test code has been improved.
Change-Id: I536d6bd7fcae437a03744941b008940bf2a3b1c1
Bug: skia:12202
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/440524
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
When compiling test shaders, we were setting SK_FRAGCOORD_BUILTIN on the
`coords` parameter to main() instead of SK_MAIN_COORDS_BUILTIN. These
two built-ins don't have the same type (float2 vs. float4) and don't
mean quite the same thing.
The SPIR-V code generator saw a variable with the SK_FRAGCOORD_BUILTIN
builtin value and assumed the presence of a global variable named
`sk_FragCoord`, which didn't exist (because it was never referenced in
the code, so it was never cloned in from the sksl_frag module).
This is only a concern when compiling test shaders with skslc; real
shaders don't hit these code paths. The generated code here is still
imperfect; if you look closely, you'll see the GLSL and Metal code is
referencing the `coords` variable but it's never declared anywhere.
Change-Id: I3ad249469927ff35eb1e75d6536f95317502708f
Bug: skia:12340
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/440520
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: I9ddb80b8886827250e243dc9174bb3679e70df9b
Bug: skia:12202
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/440262
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
If the passed-in shader references RTFlip (i.e., sk_FragCoord is used),
the settings must contain RTFlip layout info; otherwise, an error
occurs. Originally, the fuzzer detected this as a problem because the
error was being delivered via SK_ABORT, but it's failing more cleanly
now that Ethan's new error handling code is in place (causing the fuzzer
to report that the bug was "fixed"). With this CL, the oss-fuzz shader
will actually compile successfully in SPIR-V instead of leading to an
error.
Change-Id: I3268e84bd8e01c95a25ed0845a37324e98033c4b
Bug: oss-fuzz:35916
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/439779
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This intrinsic uses non-square matrices, so it will be useful in
confirming that we can use ES3 types in sksl_public intrinsics. Bulking
up this test (which we don't run in SkSLTest today) is a good first
step.
Change-Id: I8178f13d5ca376d7cae3d1a4350b2bc0397efb1f
Bug: skia:12348
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/440256
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Previously, we hid non-ES2 numeric types from Runtime Effect code by
only including them in the private symbol table. Now, they are present
in the root symbol table, but marked with a new flag that identifies
them as disallowed in ES2.
The IR generator now enforces that strict-ES2 code doesn't contain types
that aren't allowed. This has two benefits:
- Intrinsic functions in sksl_public can now reference these types
- Error reporting is nicer
Change-Id: I32375de4efdcb57b74a8a1692fb2ee315a003336
Bug: skia:12348, skia:11115
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/439997
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Surprisingly, we didn't actually have a preexisting test covering this.
Error reporting is lackluster in this CL but will be improved in the
followup.
Change-Id: I0b1cdb5a82f066af6b9d3fd9c39748080c2e18c0
Bug: skia:12348
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/439996
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Right now, Metal forces types to full precision. The matrix helper
functions previously baked in that assumption by hard-coding "floatX".
Now, they honor the component type; if this->typeName() started
returning "half", our helper functions would be named with "halfX". This
would allow half-precision and full-precision helpers to coexist.
Change-Id: I1679e6e76d2cf3c27fd69c42a92fb24bff6b69ec
Bug: skia:12339
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/439396
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This adds sinh, cosh, tanh, asinh, acosh, and atanh. We now also support
compile-time optimization for the arc functions.
Change-Id: I688f579b50403db534622b82926aa20d1f445341
Bug: skia:12202
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/439319
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 can now add functions to sksl_public.sksl with an $es3 prefix. These
will be allowed in a Runtime Effect when strict-ES2 mode is disabled.
Note that the CPU backend still doesn't have support for these calls,
and will fail ungracefully (assertion, nonsense result) if these
intrinsics are used.
The testing here is limited, due to an unrelated bug in SPIR-V
(skia:12340)
Change-Id: I9c911bc2b77f5051e80844607e7fd08ad386ee56
Bug: skia:12202, skia:12340
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/439058
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This modifier is currently allowed on built-in functions only.
The presence of this modifier will be used to indicate intrinsics which
are ES3-specific (and therefore, not allowed in user code under typical
circumstances).
Change-Id: Ice6be8d9d1b2bf0c8f07f2a89f335bb2f90f6681
Bug: skia:12202
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/439057
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
The value of 32 was causing errors when other uniforms were present, as
the SPIR-V code generator would detect overlapping uniform offsets and
fail.
Change-Id: I7bb1cf1244e54c39596c3a39e9f6972c6a47899c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/439059
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@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>
The Metal code generator has historically avoided low-precision types in
the final output in order to dodge a variety of type-coercion issues.
However, the workaround was only coded for half/float. Extended the
workaround to cover int/short and uint/ushort as well.
Change-Id: I16e3a387ba2baef1ef2de7742e1b0d27786fee0e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/437688
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Previously, SPIR-V would generate two separate SpvIds for array types if
they differed in SkSL, even if they matched in SPIR-V. For instance,
`half[10]` and `float[10]` are the same SPIR-V type, so they should
reuse the same SpvId. (The RelaxedPrecision decoration doesn't go on the
type.)
This is important because OpLoad and OpStore require the same SpvId on a
variable; you can't OpLoad from one type SpvId and OpStore to a
different type SpvId, even if the underlying type behind the SpvId is
the same.
(A slightly simpler fix exists at http://review.skia.org/437237, but
this triggered a memory pooling bug that I can't properly debug from
this machine.)
Change-Id: I7669a95a2c946dde1eeff73474a3a0fb9d180512
Bug: skia:12248
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/437683
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: 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>
OSSFuzz discovered a minor variation of oss-fuzz:36770 which tickled a
different bug in SPIR-V RTFlip handling; we did not properly handle the
case where the InterfaceBlock is an array. SPIR-V does not support this
at all, but the IRGenerator allows it, and we don't detect it an an
error until later in the compilation process.
Change-Id: I80bd67a13dad878717dc122462132a2ed675532d
Bug: oss-fuzz:36850
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/437018
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This CL does not update the DSLParser to honor these precision
qualifiers; that will be done in a followup.
Change-Id: Ib629bc99c0e6c7afb550a381d4e3b6ccc26aa64e
Bug: skia:12248
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/436337
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@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>
