Note that the 2D cross product isn't defined. There are at least two
possible interpretations of what that might mean. This name makes it
clearer that we're asking for the length of the resulting vector, if
we computed the 3D cross product (assuming Z == 0 for both vectors).
It also eliminates name overlap between builtin functions and actual
intrinsics.
Change-Id: I24e8bc0ab2ec91aaace20f0dd3e8565c10bd44a0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/484440
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
The debug-slot code didn't expect to encounter a void type.
Change-Id: Ied452b51e1cf90a0c0bc24770f82e711105b8e82
Bug: skia:12708
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/482461
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Added comments to explain the semantics (both what's expected when you
set the uniform, and what you see in the shader). The old name was
confusing, because it sounded like you got an sRGB color in the shader.
This is terse, but I think it's the cleanest syntax - and for embedding
clients, they can use C++ (etc.) API to require that color uniforms are
assigned from color types.
Bug: skia:10479
Change-Id: If00ea754060494aaa83001a5b357687953de8a5f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/480577
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
switch is no longer an ES3-specific feature.
Change-Id: Ic878a77268e517e17699c2e35a37da6b0a7765dd
Bug: skia:12450
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/452320
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This demonstrates how much additional non-trace code can be generated
when debug traces are turned on. A followup CL adds a setting to disable
`trace_var`, which eliminates a significant percentage of the additional
ops (at the cost of removing valuable debug info).
Change-Id: I238e28e6f6531f1dbccfef8f1dcd24a1e8481669
Bug: skia:12692
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/478416
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Julia Lavrova <jlavrova@google.com>
I should have realized the fuzzer would find this assert when I added
it. Now the front-end rejects these layout qualifiers on both struct
fields and interface block fields. LayoutInInterfaceBlock.sksl is a
reformatted version of the fuzzer input. LayoutInStruct is hand-crafted
to trigger the same failure on a different code path. Both would
previously assert in the SPIRV generator. Now, neither one gets that
far.
Bug: oss-fuzz:41347
Change-Id: Iff69d8f5482da7b772e9331c4fd2d58e89813c46
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/476396
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
These aren't allowed on push constants (it's a validation error now), so
we at least catch it in the SPIRV generator and emit an error. Fixed two
places where we were breaking this rule when automatically adjusting
layouts for interface blocks.
Bug: skia:12670
Change-Id: I08b88f4c2844da77239207817f49510118be4e60
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/474976
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This is a reland of 9372ef0228
Original change's description:
> Restrict where 'binding' and 'set' can appear
>
> In SPIRV, these are an error when applied to struct members. Some of our
> tests were triggering that because we had free-floating uniforms
> decorated this way (and we coalesce those into members of an interface
> block).
>
> Now, we only allow those layout qualifiers on variable types that will
> remain top-level constructs in the back-end.
>
> Bug: skia:12670
> Change-Id: I73e69cecf6237a1c1180ad38d9b5d52ea80316fb
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/474218
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Bug: skia:12670
Change-Id: I01c0323bba7ce0bddea5f9fb907e2b60e6b812d2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/475156
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This reverts commit 9372ef0228.
Reason for revert: Unhappy bots
Original change's description:
> Restrict where 'binding' and 'set' can appear
>
> In SPIRV, these are an error when applied to struct members. Some of our
> tests were triggering that because we had free-floating uniforms
> decorated this way (and we coalesce those into members of an interface
> block).
>
> Now, we only allow those layout qualifiers on variable types that will
> remain top-level constructs in the back-end.
>
> Bug: skia:12670
> Change-Id: I73e69cecf6237a1c1180ad38d9b5d52ea80316fb
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/474218
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Bug: skia:12670
Change-Id: Ie518192d9a52fc896e615ec08ce0674ad683ec61
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/475099
Auto-Submit: Brian Osman <brianosman@google.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
In SPIRV, these are an error when applied to struct members. Some of our
tests were triggering that because we had free-floating uniforms
decorated this way (and we coalesce those into members of an interface
block).
Now, we only allow those layout qualifiers on variable types that will
remain top-level constructs in the back-end.
Bug: skia:12670
Change-Id: I73e69cecf6237a1c1180ad38d9b5d52ea80316fb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/474218
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This adds new validation rules that we were breaking.
Binding and DescriptorSet can't be applied to push constants, nor to
struct members.
Bug: skia:12670
Bug: chromium:1270328
Change-Id: I332f77717b08d9945c8e5b79c5bf649a8f5f2043
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/474056
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This fails exactly as it should, but we had no test for it.
Change-Id: I0aa3307c444f2c9bc3512ff43b784a56a7c09856
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472449
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
The `eval` methods take a shader/blender/colorFilter, and we assumed
when assembling the ChildCall expression that the child expression would
be a VariableReference because opaque objects don't participate in
normal expressions. However, comma-expressions were allowed to contain
opaque types. GLSL doesn't allow opaque types in comma-expressions:
http://screen/8YW59tYDUbBh9eW
Now we disallow them as well.
Change-Id: Iaf88ef7bddb5cc8f1f1e23b515174dfc291e00c7
Bug: oss-fuzz:41072
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472446
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Mysteriously, I had written a test which put arrays of void inside a
struct, but had neglected to include the non-array case. It causes an
okay-not-great error (referring to void as an "opaque type").
Change-Id: Id20a9d3512d29aecea81d46877dce708b7b2f973
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472450
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Change-Id: I209119e6c74ca54dd6021b6dec4775fc7b66adeb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472448
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
We should, of course, detect this and report an error.
Change-Id: I42b3be6e714a1f367d3251842506a384f2afe019
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472447
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Because SkSL is much more permissive than GLSL about literal types, we
don't actually need to treat values any differently when the `u` suffix
is added. That is, `uint x = 4000000000;` already worked fine. When we
encounter the `u`, we just ignore it. This also means that a literal
like `-100u` would be accepted without complaint (although you'd get a
range error if you tried `uint x = -100u;`).
The value-add here is that it removes a speed bump when porting GLSL
code to SkSL. The Filament example shader used the `u` suffix anywhere
that bitwise ops were present; finding and removing all of them was a
chore.
Also of note: the `u` suffix was only added to GLSL in ES3, but we
"support" it everywhere. (We could go out of our way to detect it in
ES2 and flag an error, but that benefits no one.)
Change-Id: I4bf643612c8cf17710e9bad50a0c16f5936bbe88
Bug: skia:12634
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/471756
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This is required by the ES2 standard: http://screen/Qysv4fPW5r5LA9e
This actually already worked fine because `strtoull` natively recognizes
octal values without any work on our part. However, we lacked a test.
Change-Id: I3033de899918abe99c63a9b7b79bd4c3374ee315
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/471716
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
The only type of expressions that getConstantSubexpression could ever
return are Literal and nullptr. getConstantValue now returns an
optional<double>; nullopt indicates a non-constant value in the slot.
This simplifies most use cases, and allows us to get rid of some extra
"zero" and "one" Literal objects in some of our Constructor classes.
This change fixes a recent fuzzer issue. The fuzzer had discovered that
calling `getConstantSubexpression` on a ConstructorCompoundCast that
contained a compile-time-constant value would return literals of the
wrong type (the cast was not applied). By nesting repeated matrix casts,
this type confusion could be turned into an assertion.
Change-Id: Icee69219e6db2822ffdfab4e5ccdaff54584a4b6
Bug: oss-fuzz:41000
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/471376
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This assigns a human-readable name to a debug slot. The slot map is
emitted into skslc output files, and will be used in the future to
display human-readable names in the debugger.
Change-Id: I288358de305239005faa5814bd1d77a38b5e05b0
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/470400
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 3aaed99930.
Reason for revert: removing changes to PrecisionQualifiers
Original change's description:
> Revert "Fix Metal codegen error with structs containing compound types."
>
> This reverts commit 2a6c41571b.
>
> Reason for revert: causing Mali G7x failures on tree
>
> Original change's description:
> > Fix Metal codegen error with structs containing compound types.
> >
> > While working on an unrelated test, I accidentally triggered a bug in
> > Metal code generation. Our struct-equality helper functions did not
> > properly handle vector fields. Wrapping each comparison in `all(...)`
> > fixes the problem. (all() on a scalar is allowed and does nothing.)
> >
> > Our struct comparison tests now include a vector and a matrix.
> >
> > Change-Id: I59061ae9c3c3ab2c2dbdcb5257bc23e2257152af
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/470399
> > 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: Ieb5d5a1839978fb82525863488e9d54fdf44adbd
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/471097
> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
> Reviewed-by: Chris Dalton <csmartdalton@google.com>
> Commit-Queue: John Stiles <johnstiles@google.com>
Change-Id: I8ee90df3de075cf82c0fcf3b4787577b09bb1a70
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/471156
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This reverts commit 2a6c41571b.
Reason for revert: causing Mali G7x failures on tree
Original change's description:
> Fix Metal codegen error with structs containing compound types.
>
> While working on an unrelated test, I accidentally triggered a bug in
> Metal code generation. Our struct-equality helper functions did not
> properly handle vector fields. Wrapping each comparison in `all(...)`
> fixes the problem. (all() on a scalar is allowed and does nothing.)
>
> Our struct comparison tests now include a vector and a matrix.
>
> Change-Id: I59061ae9c3c3ab2c2dbdcb5257bc23e2257152af
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/470399
> 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: Ieb5d5a1839978fb82525863488e9d54fdf44adbd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/471097
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
While working on an unrelated test, I accidentally triggered a bug in
Metal code generation. Our struct-equality helper functions did not
properly handle vector fields. Wrapping each comparison in `all(...)`
fixes the problem. (all() on a scalar is allowed and does nothing.)
Our struct comparison tests now include a vector and a matrix.
Change-Id: I59061ae9c3c3ab2c2dbdcb5257bc23e2257152af
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/470399
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Previously, none of our `runtime` tests relied on the input coordinate
in any way, so all of the logic was hoisted above the main loop in every
test. This CL adds an artificial reliance on the input coordinate so
that we have at least some SkVM tests with real code in the main loop.
This lets us see debug trace instructions interleaved with real code.
The input coordinate is clamped against a known uniform value
(`colorGreen` always contains 0101) so that the final test output
remains consistent in practice.
Additionally, I noticed that this test was only enabled in ES3, but
it doesn't seem to have anything ES3-specific in it, so it's now
enabled across the board.
Change-Id: Ie82f40b1060edb6071e300040ac59fb7d27094b0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/470397
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Our inliner would ignore any functions with `inout` parameters, because
inlining them properly was more complex than just leaving the function
call. However, real-world code can sometimes contain helper functions
that have `inout` params that are never used at all (e.g. an uber-shader
with some features turned off).
We now read the ProgramUsage and check to see whether or not the
`inout`-qualified parameter is actually modified. If it's never changed,
the function now remains a candidate for inlining.
Change-Id: I92e494f94cc070801cb9aa28bd13faa689b806b6
Bug: skia:12636
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/470299
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Yesterday's implementation was close but I realized later that it wasn't
quite ideal.
- Array index-folding was gated on `isCompileTimeConstant`, which is too
strict. The real limitation is `hasSideEffects`. If an array contains
a side-effecting expression, we should leave it alone. Otherwise it
is safe to pluck out an element from the array and toss the rest.
- Matrix index-folding was gated on `getConstantSubexpression` for the
extracted elements, but did not check the other elements at all. This
was too lenient; we now only proceed to the folding step if
`hasSideEffects` returns false.
I added some tests to verify the final behavior and also discovered a
small related issue. Diagonal matrices were not substituting literals
in for constant-values, which inhibited folding as well and would break
constant-expression evaluation. This is now fixed.
Change-Id: Idda32fd8643c1f32ba21475251cd4d4dd7cea94c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/470396
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Functions which don't write to their out params should be safe to
inline, but we currently don't recognize this.
Change-Id: I753e48067c7be4473675ef6c95e61af17dc5ae41
Bug: skia:12636
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/470298
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
We never used it internally, but the shaders used by Filament rely on
it. It doesn't exist in ES2 so this doesn't affect Runtime Effects.
Change-Id: Idb2afb15ff160b950ad02101bf6381a5d5c56468
Bug: skia:12635, skia:11209
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/470156
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Indexing into a constant matrix is a constant expression, so we are
obligated to support it for ES2 compatibility.
Change-Id: Ibe1e5bac39d9a88ce0222997a38e8b6952fdb336
Bug: skia:12472
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/469819
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
We should support constant-expressions involving matrices (GLSL ES2
does, WebGL does). We currently don't. We do properly report out-of-
range indexing, but we don't optimize away valid matrix index
expressions or allow matrices to be indexed in a constant-expression
context.
Change-Id: If58aa4c5f15abef421a412957072f3617b4176df
Bug: skia:12472
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/469818
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
When optimizations are disabled, the compiler flags this function as
exiting without returning a value (since it doesn't convert the ifs from
maybe-taken into definitely-taken).
Change-Id: I226d0f6ba8cc664aecf1c5afaaf03e92038185ba
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/469821
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Previously, SkSL was unable to resolve the constant expression `x[y]`
for a constant-array `x` and a constant-integer-scalar `y`. Now, if `x`
and `y` are known, we can replace `x[y]` with the indexed array element.
Note that we need to be careful here, as it's not a valid optimization
to eliminate array elements that have side effects. We preserve side-
effecting expressions using the comma operator.
Change-Id: I5721337eb42b48c0b05f919c1cadfae19dd3b84f
Bug: skia:12472
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/469839
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Previously, we didn't have tests which leveraged constant-evaluation of
array indexing (because we didn't support it), and our test files
commingled constant-indexing into vectors with constant-indexing into
arrays.
The test files now separate vector- and array-handling into separate
tests, and a ton of new cases have been added to ArrayFolding. The
ArrayFolding tests now require constant-evaluation of array indexing,
so they fail in this CL, but will be fixed in the followup CL.
Change-Id: I3b663e743d97d6db80627bc9b7808f88c99917a7
Bug: skia:12472
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/469528
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Previously, this code assumed that IndexExpression::Convert had done
range checking and that it was safe to access the base expression at
the passed-in index. The inliner violates this assumption, because it
can replace unknowns (where out-of-range access is undefined but non-
fatal) with knowns (where out-of-range access is forbidden).
We now do range-checking inside IndexExpression::Make and report the
error cleanly, instead of asserting inside of Swizzle::Make due to an
invalid component index.
Change-Id: If0f31b1f694bcc2a875d124f70be311d6634c77b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/469535
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Previously, a dangling type or function reference would be eliminated
silently with optimizations on, or would assert when optimizations were
off.
Change-Id: Ib2e273b6f069724e8872c9cb97351b647b875a62
Bug: skia:12472
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/469525
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
The ExpressionStatement currently eliminates dangling references without
reporting them as an error. This happens due to optimization; these
expressions (being meaningless) have no side effects, and so the
optimizer replaces them with Nop. When the optimizer is off, these
programs trigger an assert:
https://osscs.corp.google.com/skia/skia/+/main:src/sksl/SkSLAnalysis.cpp;l=582;drc=e7a953524787e3bd0c437ec52de4e40986689825
A followup CL will fix ExpressionStatements so that they report
incomplete expressions as an error.
Change-Id: Ica49166032e670749fc1b4e7a869fbab03364d4f
Bug: skia:12472
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/469524
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This writes an entry to the trace buffer every time a slot value is
changed.
Change-Id: Iac3912be71ad654f70a7158e306e0643086c6cb0
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/469179
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This will be used to populate a trace buffer for the SkSL debugger.
See http://go/sksl-tracing for details and rationale.
Change-Id: I4c218c65ff01c339cf460e97e41566860a694720
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/468436
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
When this is enabled, the SkVM code generator will emit trace
instructions for debugging purposes. (The trace instructions are a work
in progress, so at present, the flag doesn't do anything meaningful.)
Change-Id: Ia7d66840d915b1a7e531a3069e641c840bb9c0eb
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/467764
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This effect does not yet support pinned edges or taper
also sneak in a filename change (CCToner) to keep all effect names standard
Change-Id: I17f2b5463408556775bc12a972358abd4d8d8690
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/467319
Commit-Queue: Jorge Betancourt <jmbetancourt@google.com>
Reviewed-by: Florin Malita <fmalita@google.com>
Much like http://review.skia.org/467759, this CL defensively guards
against programs which consume more space than is reasonable. Globals
exist outside of functions, so they wouldn't be caught by the stack size
checks.
Change-Id: I035f27d57bc329508820a729a1e367ecaadfe156
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/467760
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Functions that declare variables totaling more than 100,000 slots will
now generate an error.
This is only a partial mitigation to the problem, as a sophisticated
attack could still chain/nest multiple functions together to consume
extremely large amounts of stack. However, this mitigation is still more
sophisticated than our peers; both WebGL and glslang are susceptible to
similar problems, and in the general case (ES3+ with full flow control)
it's intractable.
Change-Id: I153c75267c017a23f59fe9e59f6e391197ee6101
Bug: oss-fuzz:40304, oss-fuzz:40694
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/467759
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
The fuzzer triggered this error in a strange way that involves parsing a
TK_INVALID token. The fuzzer's original input used \xFF bytes in the
shader text to do this. I replaced these with the ` character since it
behaved the same, but allows our test inputs to remain basic ASCII.
The root problem is that `cast_expression`, part of no-op arithmetic
simplification, can now fail because expressions like `int(4000000000)`
no longer get past Constructor::Convert. Previously we had assumed
`cast_expression` could never return null; now we check its result for
null before using it.
Change-Id: I7335395bab0daf1f788b0c7c154904b2372ae13f
Bug: oss-fuzz:40660
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/467316
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>
