Upcoming dehydration / rehydration changes require $intLiteral and
$floatLiteral to be present in the symbol table (as all other private
types are). It turns out that even with them marked private, having
them in the symbol table allows them to be incorrectly accessed without
error due to a code path that fails to check for private types.
This CL takes care of that and ultimately results in better output from
PrivateTypes.
Change-Id: Ic47b77a770834079f28c3195545a7cabca8e6cb3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/501196
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
GLSL ES2 behavior is explicitly undefined if an out-param is never
written to: "If a function does not write to an out parameter, the value
of the actual parameter is undefined when the function returns."
We do see divergence here in practice: SkVM's behavior (the parameter is
left alone) differs from my GPU's behavior (the parameter is zeroed
out).
SkSL will now report an error if an out parameter is never assigned-to.
There is no control flow analysis performed, so we will not report
cases where the out parameter is assigned-to on some paths but not
others. (Technically the return-on-all-paths logic could be adapted
for this, but it would be a fair amount of work.)
Structs are currently exempt from the rule because custom mesh
specifications require an `out` parameter for a Varyings struct, even if
your mesh program doesn't need Varyings.
Bug: skia:12867
Change-Id: Ie828d3ce91c2c67e008ae304fdb163ffa88d744c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/500440
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Previously, when attempting to cast a huge value to an int, SkSL would
report an error, then return the IR for
`ScalarCast(Int, FloatLiteral(huge-value))` . Now, to minimize the blast
radius of the error, we report the error but return `IntLiteral(0)`.
We've already reported an error, so there's no need to preserve the
value, and zero is less likely to produce follow-up errors.
(A similar approach is used here and worked well: https://osscs.corp.google.com/skia/skia/+/main:src/sksl/ir/SkSLConstructorCompoundCast.cpp;l=57-59)
Change-Id: Ie8e8d48380cb963466d1f47d123d64e3301cf87c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/499563
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
The test input was removed at http://review.skia.org/497742.
Change-Id: I7b30f2f70cd0812b900c9c67b70e742b3d96930a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/499574
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
The test has been moved to shared/, since it's a valid test, but it is
no longer related to inlining, as the inliner no longer attempts to
inline functions with inouts at all.
Also, one function here (outParameterIgnore) actually invoked undefined
behavior and has been removed. According to the GLSL ES2 docs: "If a
function does not write to an out parameter, the value of the actual
parameter is undefined when the function returns." SkVM leaves the value
unchanged, so SKSL_TEST_CPU would pass, but a GPU might clear it (and in
fact, my GPU does).
Change-Id: I77c77ed1354bc980344ec5c406992bd62015f5e5
Bug: skia:11919
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/499752
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Now, constant mat+mat, mat-mat, and mat/mat operations can be optimized
away. mat*mat does not operate componentwise and will need to be
handled differently.
Change-Id: Iabac6e58999eac46c256d7dcdb9b95d05de530bc
Bug: skia:12819
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/498716
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
GLSL supports adding, subtracting, multiplying, and dividing matrices
with scalars. This works by splatting the scalar across every matrix
component and then performing the op componentwise. Our constant folder
now knows how to fold out these simplifications.
Change-Id: Idb8751ec16135e1b61da0d58cfd0505ab31ac087
Bug: skia:12819
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/497738
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
In a followup CL, these will be updated to properly fold.
Change-Id: I20d125c0d54cbbcf12f7d096beda1fdf75e51b65
Bug: skia:12819
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/498617
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Previously, matrix-scalar operations did not actually fold, so the tests
didn't live in folding/. In a followup CL, these will fold.
Bug: skia:12819
Change-Id: I6fdacf89088920719e7666d6c9b05ddffaf6cb6d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/497742
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
SkSL is somehow interpreting a large positive value as a negative one.
Change-Id: I299e0bf389a9fcbfe697741bd33a54df07748753
Bug: skia:12863
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/499556
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Some paths through swizzle optimization would replace a swizzles with a
constructor--e.g. `float3(1, 2, 3).y` would be replaced with `float(2)`.
(Constructor::Convert was responsible for replacing this trivial
constructor with the literal `2.0`.)
The optimization code asserted that this replacement would succeed, but
the fuzzer managed to construct a counterexample where the constructor
rejected the value. Specifically, by nesting casts between int3 and
float3, it found a case where Constructor::Convert returned null because
the literal value was out of range for `int` types.
This assertion didn't really add value so removing it was harmless.
Constructor::Convert already reports an error when it fails, and null
returns are handled properly throughout.
Change-Id: I575d441ed90d6b696f6399941c3f6d84698794bc
Bug: oss-fuzz:44045
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/499382
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This guards against any potential for conflict with user code.
Change-Id: Iecaf3ead5f8ada50b6dc159a4ad9e7f3e371edc7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/499296
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This reverts commit a97a6769b5.
Reason for revert: breaking bot Housekeeper-PerCommit-CheckGeneratedFiles -- see http://screen/5FN75fF9tvcQFKR
Based on the diff, I think this just needs to be synced up to latest code and a rebuild should fix it.
Original change's description:
> [skslc] Generate .hlsl test output files
>
> - The build now generates HLSL output when `skia_compile_sksl_tests` is
> enabled.
> - The "blend" and "shared" tests have been enabled for HLSL with the
> exception of 6 tests that exercise intrinsic inverse hyperbolic
> functions, which don't have HLSL equivalents.
>
> Bug: skia:12691, skia:12352
> Change-Id: Ia970f878f75ff58e8e3d47249c2dc2f756c165b4
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/482778
> Reviewed-by: John Stiles <johnstiles@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
> Auto-Submit: Arman Uguray <armansito@google.com>
> Commit-Queue: Arman Uguray <armansito@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
Bug: skia:12691, skia:12352
Change-Id: Iaad607d48edd136eee2b60e48c0643b6e90179e9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/499216
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>
- The build now generates HLSL output when `skia_compile_sksl_tests` is
enabled.
- The "blend" and "shared" tests have been enabled for HLSL with the
exception of 6 tests that exercise intrinsic inverse hyperbolic
functions, which don't have HLSL equivalents.
Bug: skia:12691, skia:12352
Change-Id: Ia970f878f75ff58e8e3d47249c2dc2f756c165b4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/482778
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: Arman Uguray <armansito@google.com>
Commit-Queue: Arman Uguray <armansito@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Previously, any code which emitted a binary expression would always emit
a leading and trailing space. This caused comma expressions to look
goofy: `foo() , bar();` instead of `foo(), bar();`.
Operator::operatorName() now returns the operator token with appropriate
whitespace around it, and tightOperatorName() is a new method which
omits the whitespace. Functions which assemble binary expressions
should now concatenate `x + operatorName() + y` instead of hard-coding
`x + " " + operatorName() + " " + y`. Prefix/postfix expressions should
use `tightOperatorName()` because otherwise negation looks bad (` - 123`
instead of `-123`).
Super low priority, but it was easy to fix.
Change-Id: I3c92832207293a310fb1070b3b5e72455757b0ce
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/497776
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
These identifiers are reserved for SkSL internal use (and can't be
exposed to GLSL or Metal anyway).
Change-Id: Id554cbf21ed2fb66785e77700ff79424ecdf66db
Bug: skia:12854
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/498036
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This eliminates a handful of useless statements. They were harmless, but
presumably this saves optimization work for the GLSL compiler.
(Patterned after http://review.skia.org/496377 )
Change-Id: Ibe135750488a9917b982dcac67f22b3765412ee1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/496599
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
These are harmless, but they can cause the Metal compiler to emit a
warning, and these warnings are making some logs messy for Flutter.
Change-Id: I21b7a3c9ae661c55bbbe8bc13d097966180e977d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/496377
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Adding tests for matrix math and comparison
bug: skia:12681
Change-Id: Ia1537ee2e411383749456fd6ff938b7c9a2e1061
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/493416
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Julia Lavrova <jlavrova@google.com>
This looks like the GLSL driver in iOS generates wrong results when
returning a value from inside a switch.
Change-Id: I478a045c64c3dae9824f86f52e0c7f8f9685c9af
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/494476
Reviewed-by: Joe Gregorio <jcgregorio@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Change-Id: I3dabd77890a73ea054bb57d466a6ed8273eae3e8
Bug: skia:12811
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/494196
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Change-Id: Iecf1313af5f2938cb899f2a3e750ffc04554bae0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/493977
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
As @johnstiles suggested I add the test first and the fix after.
bug: skia:12712
Change-Id: I9316cf40f71e756fc1730ee630bc0d0377f200d6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/491936
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Julia Lavrova <jlavrova@google.com>
We used to reject ES3-style array declarations in strict-ES2 mode, so
this test originally expected two errors.
Change-Id: I17f71630076cda4b37b7723225dcff951eba9dcc
Bug: skia:12410
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/491997
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
This reverts commit 6e686b8b8b.
Reason for revert: After internal discussion, we established that nobody was actually sure why this had needed to be an error in the old parser in the first place, so there does not appear to be a reason to carry the behavior forward.
Original change's description:
> Fixed SkSL error reporting on array types
>
> The DSLParser was not reporting errors when the array type appeared
> before the variable name (float[2] x) as opposed to after (float x[2])
> in strict ES2 mode.
>
> Bug: skia:12410
>
> Change-Id: Ia388aa150f65916dc3ccc58f7680dbde0a636c5f
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/491819
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Bug: skia:12410
Change-Id: I355fd1ad89e2e64b0377be7672b7f3f824eebac8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/491996
Auto-Submit: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
The DSLParser was not reporting errors when the array type appeared
before the variable name (float[2] x) as opposed to after (float x[2])
in strict ES2 mode.
Bug: skia:12410
Change-Id: Ia388aa150f65916dc3ccc58f7680dbde0a636c5f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/491819
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Previously, type aliases ('vec2') were just an additional name which
could be used to refer to a type ('float2'). This was simple and worked,
except that error messages would be wrong - any type-related error
message would refer to the type as 'float2' rather than the 'vec2' that
the user actually typed.
This CL adds an AliasType class so that we can track which name was
used to refer to an aliased type and report messages using the correct
type name.
Bug: skia:12737
Change-Id: I40e234239ab47557033e0695e4fbbd5f01da354e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/490256
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Bug: oss-fuzz:43062
Change-Id: I10d8fa40c81c5b1595d30221d89c84f5cc3478fd
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/490857
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Interface blocks now guard against naming their member variables with
built-in type names like "float" or "bool".
Change-Id: Ia767542ace76fb8fbc2d50c81772b7f54b1bf973
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/489616
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Structs already handled this appropriately, but interface blocks did not
guard against naming their member variables built-in type names like
"float" or "bool".
Change-Id: I12ec054b3f158b83e35031449cf2a088ff8d0dc2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/489596
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Anonymous function parameters are now automatically assigned a name,
"_skAnonymousParamN", where N is the parameter index.
Change-Id: I87adcd51ed025c76ae2b333317f21b523a4632b4
Bug: skia:12769
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/489538
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
SkSL will reject ES2-compatible code because function parameters always
require a name in SkSL. (A followup CL relaxes this restriction and
allows anonymous parameters in SkSL.)
Change-Id: Ifdcf0fcbe0f52d16007c018b545631ca4033a8c4
Bug: skia:12769
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/489537
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Structs and interface blocks allow a trailing identifier which is added
to the symbol table. This identifier is now prohibited from
overlapping built-in types.
Change-Id: I33b9d6156a27ce017e6744a05979748c04a04767
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/489516
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Structs and interface blocks allow a trailing identifier which is added
to the symbol table. This identifier should be prohibited from
overlapping built-in types; at present, this is not checked. Add a test
demonstrating the issue.
Change-Id: I99aa915c1715c468cc369c97b7f12e031b86ea4a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/489496
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
These will give the debugger enough information to discard variables as
they fall out of scope.
Change-Id: Ia400e82a3ca9cf0a51a72d819f897d346979226c
Bug: skia:12741
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/484556
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
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>
This reverts commit 85cc1bece7.
Reason for revert: ends up not being useful after all
Original change's description:
> Trace function return values after function-exit.
>
> This will allow function return values to be easily seen when stepping
> "over." This has the unexpected side benefit of generating slightly
> fewer ops when a function has unoptimizable conditional returns.
>
> Change-Id: I48d23de635d3caaddff91aa595593d0371dfcdcb
> Bug: skia:12708
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/481076
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: John Stiles <johnstiles@google.com>
> Auto-Submit: John Stiles <johnstiles@google.com>
Bug: skia:12708
Change-Id: I61ebb175b60d2060f6ad21b170238b37557b80be
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/482458
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@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>
This reverts commit 062652067b.
Reason for revert: design change removes need for this op
Original change's description:
> Add SkVM op `trace_done` to indicate completion of debug tracing.
>
> This op can be used to invoke a callback function and dump the log to
> disk when it is ready. SkRuntimeEffect doesn't have any other viable
> mechanisms for detecting that a paint has completed, AFAIK. We can
> wait for ~SkRTShader to occur, but there's no guarantee that this will
> happen quickly, and the SkPaint with the SkRTShader shader can be reused
> over and over again.
>
> Unlike other trace ops, this only needs a trace mask, not an execution
> mask (we are unconditionally done at the end of main).
>
> Change-Id: I6f7ee41f2005b65940d36dee892279d4f245509f
> Bug: skia:12708
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/479876
> Auto-Submit: John Stiles <johnstiles@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
Bug: skia:12708
Change-Id: Ic4c4f5dd72541195f07ca32035267a20a82536e7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/481577
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@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>
This will allow function return values to be easily seen when stepping
"over." This has the unexpected side benefit of generating slightly
fewer ops when a function has unoptimizable conditional returns.
Change-Id: I48d23de635d3caaddff91aa595593d0371dfcdcb
Bug: skia:12708
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/481076
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This op can be used to invoke a callback function and dump the log to
disk when it is ready. SkRuntimeEffect doesn't have any other viable
mechanisms for detecting that a paint has completed, AFAIK. We can
wait for ~SkRTShader to occur, but there's no guarantee that this will
happen quickly, and the SkPaint with the SkRTShader shader can be reused
over and over again.
Unlike other trace ops, this only needs a trace mask, not an execution
mask (we are unconditionally done at the end of main).
Change-Id: I6f7ee41f2005b65940d36dee892279d4f245509f
Bug: skia:12708
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/479876
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
I ran into a snag while trying to hook up SkRuntimeEffect with debug
tracing. Runtime effects only have access to a skvm::Builder, and are
never exposed to the full skvm::Program. SkVMBlitter is responsible for
assembling the full skvm::Program, but is oblivious to runtime effects
and nested skvm sub-programs. Additionally, multiple runtime effects can
(and often do) coexist within a paint.
This CL changes how debug traces are enabled. skvm::Program no longer
has a `attachDebugTrace` method. Instead, this method lives on the
skvm::Builder. Calling `attachDebugTrace` generates a "trace-hook ID"
(which is actually an index into a vector of TraceHook pointers).
Every trace opcode now includes this trace hook ID. When the Builder
assembles a final Program, it copies the TraceHooks into the Program.
The skvm interpreter uses the trace hook ID on the op to dispatch a
trace command to its associated TraceHook.
From a user perspective, this doesn't change very much, but it does
mean that the SkVM Code Generator now supplies a TraceHook for us
(since it adds trace ops to the Builder and needs to know the proper
trace-hook ID).
Change-Id: I8bd5fea24f477f81470fae8ba41be45f76949407
Bug: skia:12708
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/479597
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Previously, the trace opcodes took a single mask argument, which was
computed as `execution mask & trace mask`. This led to extra bit_ands in
the output, as this value would be need to be recalculated every time
the execution mask changed.
To reduce this cost on program size, the trace ops now take two mask
arguments and require that both must be true. We have four register
slots at our disposal in an Op, which is more than we need, so this
doesn't really cost us anything.
(As an extra minor optimization, if one of the masks is "always-on", we
optimize it away. This avoids burning a register just to hold a ~0
immediate value.)
Change-Id: I9eb71292a1983e71b03c7ac842534beb3d6bbf17
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/478456
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@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>
This shouldn't change code generation when debug traces are disabled.
When they are enabled, we now get trace_var opcodes emitted for every
return statement. Internally, this required a fair amount of refactoring
around how return values are passed around, but it should all be
functionally equivalent.
Change-Id: Ieb9d9c75399109186f905e0499d8fe6e2fc2067c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/477981
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>
SkRuntimeEffect users will be insulated from skvm and the Builder, so
they won't be able to make an skvm::Coord directly. Replace this with
an SkIPoint, and do the conversion inside the SkVM code generator.
This also removes the requirement of assigning a trace coordinate; if
no trace coordinate is set, (0, 0) will be used.
Change-Id: I97be025d0ea146a86655cc3cdb76726f3bbc2324
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/474556
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reusing the same opcode for enter and exit didn't have any real upside,
and forced us to deal with a fake immediate-value.
Change-Id: I35cab4d196f55b6f5e3040074c731b298720d62b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/477157
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@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>
This reverts commit b1f450bb2b.
Reason for revert: Hmm, bot disagrees.
Original change's description:
> Update some skvm test outputs
>
> Not sure how these were wrong in the repo for so long - these all should
> have changed like this when the optimization of commutative operations
> landed: reviews.skia.org/473239
>
> Change-Id: I3035d4f29c208096f83184b4393023666e10ab92
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/476316
> Auto-Submit: Brian Osman <brianosman@google.com>
> Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
> Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Change-Id: I9dc808927c73a979f4cde5c7035b109d8db808f6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/476397
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Not sure how these were wrong in the repo for so long - these all should
have changed like this when the optimization of commutative operations
landed: reviews.skia.org/473239
Change-Id: I3035d4f29c208096f83184b4393023666e10ab92
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/476316
Auto-Submit: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@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 is redundant information now that we have SkVMSlotInfo.
Change-Id: Ia05b1eaa722023e719042c83255708aa9debed61
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473777
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@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>
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
We now canonicalize commutative operations by ordering their value IDs.
The lower-numbered value ID is always placed first into a commutative
instruction. In other words, this instruction:
bit_and result, v7, v5
Would be silently converted to this:
bit_and result, v5, v7
This will allow these two logically-equivalent instructions to be
deduplicated:
bit_and result, v7, v5
bit_and result, v5, v7
Of course, deduplicating these ops can unlock additional free CSE/DCE.
The affected instructions are listed in http://review.skia.org/473238
Change-Id: Ib9beb79d6b72d7903184aaa9a53e8e5a02ae126d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473239
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Herb Derby <herb@google.com>
The SkVMDebugInfo now includes an skvm::Coord that the caller is
responsible for filling in before converting the program. If it is set,
the value indicates the device coordinates that should be traced. If it
is unset, debug traces will not be emitted at all.
Within the SkVMCodeGenerator, we now have a new traceMask() call which
combines the current execution mask with the trace mask. Tracing opcodes
now pass the result of traceMask() instead of mask(). This will limit
trace data to the selected pixel, instead of tracing the entire draw.
Bug: skia:12614
Change-Id: I1f8ce7d18a31aa60a139a4a7335c2a285d6aee60
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472798
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
We no longer indicate functions by their line number, which can be
ambiguous. The debug info now includes a list of function names which we
can refer to by index, and the `trace_call` opcode references functions
by their index in this list.
Change-Id: I4bdf2a6439637a07b116831fd2981f342c19ea4a
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472796
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@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>
This wasn't meaningful, and made some error reporting worse.
Change-Id: I5e72b5aca5d3e159b8439fa9809290d75e44cbe2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472656
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@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>
`void` behaves differently from opaque types in several situations, such
as function return types, and errors involving `void` should not call it
an opaque type. I've fixed all the places where we relied on `isOpaque`
to return catch void types.
Change-Id: I359c00f836be6e56cb0373beff60cf2ff830f77b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472451
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@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>
Previously, we'd report them as an overflowed integer.
Change-Id: Ia3632b4bc880829fb04b08a002d7ce9523567a54
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472056
Commit-Queue: Brian Osman <brianosman@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>
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 enables stepping over function calls automatically.
Change-Id: Ie15ed745377d851cb7752f651b573efa2cc8195f
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/469077
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Previously, the for statement's "increment/test" expressions were
executed without moving the trace-line back up to the for statement.
When stepping through code, we will now explicitly step to the next/test
line on each loop iteration.
Change-Id: I5d9f005a42150670cec77218323cf932ee1cbdb0
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/469180
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@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>
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>
Updated ReturnsValueOnEveryPathES3 to remove overlap with the ES2 tests,
and fixed some broken cases. Disabled the ReturnValueOnEveryPathES3 test
on Intel + Windows because switch statements on Intel + Windows are
pretty broken.
Change-Id: Id93e8af1ef7bf11fd74ef12a464c77d56cc032a0
Bug: skia:11209, skia:12465
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/467078
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
It's possible to write code containing errors that are only apparent
once the inliner runs. For instance, a function which takes a short and
returns its negative it is valid for most inputs, but undefined for
-32768 (because +32768 does not fit in a short). A function which takes
floats and casts them to ints is valid for many inputs, but not valid if
you pass in 5 billion.
This CL restructures our out-of-range integer error detection to report
errors cleanly in these cases instead of asserting. It also refactors
the range checking code to be usable in situations where we don't yet
have a Literal expression.
Change-Id: I98f0be63bf9afbbf1ab90233fa86d380cfae42b4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/466439
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Change-Id: I01d82447658c7acc5fe9eb230eb7020b49fa6c4f
Bug: skia:12498
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/466447
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Change-Id: I7512491f55c10118f0ab058500f6ce9b5b8545cd
Bug: oss-fuzz:40557
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/466296
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This will hopefully improve performance on lower-end GPUs.
Change-Id: I9c2ee6dc31acd08bec0bfb5f59edc3cf90163f9e
Bug: skia:12339
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/465078
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Change-Id: Ic30c48dce0cb0072f07defcdb0b9e60b94f50818
Bug: oss-fuzz:40479
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/465392
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 discovered that SkSL could create an out-of-range int literal
by casting from a floating point literal. We were only doing range
checks when the starting literal was an integer. Since we now assert
when an out-of-range int literal is created (as of
http://review.skia.org/464124), the fuzzer can detect this error.
Change-Id: Ie66f60ddbe7b4fbe5b648c17292c59a4ba079716
Bug: oss-fuzz:40456
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/465385
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 guards against unexpected results when dfdy is used in complex
expressions. In practice, I'm not aware of this causing any trouble.
Change-Id: Ia476e57936969d248273856a94d5c403b47c29b4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/465379
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This guards against unexpected results when dfdy is used in complex
expressions. In practice, I'm not aware of this causing any trouble.
Change-Id: I639bef465d7907049d79681a49f9be67b4c435a6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/465378
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This reverts commit 9fc189f1cb.
Reason for revert: shader compile failure on AndroidOne-GPU-Mali400MP2 devices
Original change's description:
> Wrap 'u_rtFlip.y * dfdy()' in parentheses.
>
> This guards against unexpected results when dfdy is used in complex
> expressions. In practice, I'm not aware of this causing any trouble.
>
> Change-Id: I58d4762871481fdb4c173b570e4d5d6edf657af7
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/465077
> Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
> Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
> Auto-Submit: John Stiles <johnstiles@google.com>
Change-Id: Idfaa9316d657717d5ee7117837c9cc9c3d4ee189
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/465377
Auto-Submit: Greg Daniel <egdaniel@google.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
This guards against unexpected results when dfdy is used in complex
expressions. In practice, I'm not aware of this causing any trouble.
Change-Id: I58d4762871481fdb4c173b570e4d5d6edf657af7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/465077
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
A recent CL (http://review.skia.org/464121) made it an error to coerce a
literal value to a type that cannot hold the value. The fuzzer found a
case where we assumed type-coercion of a literal would always succeed,
and failed to null-check the result. We now null-check the result.
Change-Id: Id97c6016e56c20ef724028f71bbf4688dde3c064
Bug: oss-fuzz:40428
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/464919
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Yesterday's negation-related changes (http://review.skia.org/464123)
exposed a flaw that the fuzzer was able to exploit. We were previously
able to assume that `simplify_negation` would always return a non-null
expression; in some cases, that is no longer true.
Change-Id: Ia585232b0e35fafe0c642384a59ef94ce743ffd5
Bug: oss-fuzz:40427
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/464916
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>
With this change, we no longer have any SkSL tests which are able to
make a Literal integer that overflows its type. Literal::MakeInt now
asserts that its value is within bounds. I look forward to the fuzzer's
inevitable attempts to trigger these assertions.
Change-Id: I7b15e862caaf65984d33f5d72d2c1de816d1d292
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/464124
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This was mistakenly using dFdx in some portions (copy-paste error).
Change-Id: Ifb159b3c44185d9166c10725b24002a28a0895b2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/464381
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, we would create a Literal with the negated value even if it
was outside the type's minimum/maximum values. Error reporting would
happen elsewhere, if at all (e.g. during assignment or coercion).
Change-Id: I020a93daf2b0f5741fb805a58a690489d7578dab
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/464123
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Previously, we would create SkSL literals of ints that didn't fit into
an int. This change causes a few errors to report differently. (In
particular, we no longer create global variables containing values that
wouldn't fit in that variable, so those symbols are invalid later.)
Change-Id: I29d219e853126ea78dd2d2a6d8a69b23ef2b06b8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/464121
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This was causing errors in UBSAN when compiling some of our existing
SkSL tests.
Change-Id: I66f22607094df77d47ff70948a139c77feae8624
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/464118
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
These are not very interesting right now, because the in and out types
boil down to the same thing (int/int, float/float). When half-
precision types are enabled, these helpers will be more useful. They
will return an array which casts each element from int-to-short or
float-to-half (or vice versa).
Change-Id: Ida716ddd27d370ba33fd23f17a1b07fa5a201e40
Bug: skia:12339
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/463337
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
The inverse, outerProduct and matrixCompMult polyfill functions in Metal
were written assuming that all float matrices would use the `float`
type. They now use a template so that `half` matrices will work too.
Change-Id: I7696c8ad1e4aaffbd71c56b9245485e74cd96c5a
Bug: skia:12339
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/463338
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
At this point, it seems like this was a mis-diagnosis of the underlying
issue around dual-source blending (and its interaction with other blend
state).
Change-Id: I11af0c9b70c32e14c353848db3d6adbfe5f08225
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/462176
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
After reporting the error, we convert the reserved word to an identifier
as this led to the best error reporting. (This avoids double error
reporting or strange cascading errors.)
Change-Id: I67209bc342fe794287baeaaaf34fa77afd4ac26b
Bug: skia:12560
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/462096
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Change-Id: I894bfa01e7cf58f140423554d0200b6c66beef35
Bug: oss-fuzz:39998
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/459883
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
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>
At present, we only detect four errors here. We should detect six.
Change-Id: I226854ab930a273695c42cf2f7bdb1d5cd97e50b
Bug: oss-fuzz:39998
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/459882
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>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
See http://review.skia.org/460037 for an example of the existing
behavior. Const variables are constant-expressions and should be allowed
here.
Change-Id: I41383d79668785f270b7825485e9f6fa56c553c1
Bug: skia:12549
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/460036
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>
We now detect attribute, varying, precision and invariant as reserved.
Change-Id: I8c90655a70b1bad31bf6143c3fdcb2ce582320b1
Bug: skia:12484
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/459479
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
`samplerCube` is a type which we don't support at all. It has been added
to the reserved-word list.
`textureCube` was in our list of built-in types, but was not actually
used in any way; it wasn't actually added to the root or private symbol
tables, and was totally unreferenced by the code. It's been deleted.
Change-Id: I4f79ce5d40ac6ebdb2a7067fa60cc79e316b01b6
Bug: skia:12484
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/459123
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@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>
Previously, in public code, private types didn't exist anywhere in the
symbol table chain, and those names were free for the taking. Now, we
register them as invalid types in the public symbol table. This prevents
them from being used as variable names, and gives a more explicit error
if you try to use them as a type.
Change-Id: I9a943bf923639b72cbf36b1acf4b4fbe70982786
Bug: skia:12538
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/459119
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>
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>
This fixes GLSL ES2 conformance test `array`.
Change-Id: I6ebee9253e1e8c394d9ddb6899e3a0940b7a38ef
Bug: skia:12495
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/458718
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@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>
The fuzzer has found that it can get timeouts in SkVM by nesting loops
very very deeply, then at the bottom of the chain, making an inside-out
loop that runs for zero iterations. This has a calculated unrolled-size
of zero, but SkVM would still think hard about unrolling the (ultimately
empty) outer loops.
SkSL now optimizes away unrollable loops that run for zero iteratinons,
as well as empty unrollable loops. This should eliminate the fuzzer's
troublesome construct entirely.
Change-Id: Ic3ef7b7a6a9fc7ee7fb13eb7bd7f34c9bff57448
Bug: oss-fuzz:39661
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/456469
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 fuzzer has been poking various holes in DSL by intentionally
creating illegal types (e.g. private or not ES2-compatible), then
finding ways to use those types, e.g. constructors or swizzles.
Previously we were mitigating those by calling `reportIllegalTypes` at
the locations where the type was used. Now, we detect the illegal type
usage at the source, and return a poison DSLType. This prevents the
illegal type from leaking out at all, and stops the problem at its
source. It also allows us to remove calls to `reportIllegalTypes`
sprinkled through the code, as those are now redundant.
Change-Id: Id50b50f72849111d80f76e4fdc2cb6094d3009bd
Bug: oss-fuzz:39597
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/455999
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@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>
`Type::isPrivate` now works properly even on structs and arrays, so we
don't need two separate methods anymore.
Change-Id: Ic3e16e1315ebb0c8cec575f109af7e472a11ac8c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/455660
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This is a reland of 36f53ec7e1
Original change's description:
> Disallow constructors of ES3 types in ES2 code.
>
> The fuzzer found that we constructed TypeReferences without first
> checking for disallowed tyoes. (In fact, TypeReference creation had no
> error checking at all; it didn't even have Convert/Make functions.)
>
> Added proper Convert/Make to TypeReference, and used those calls to
> report errors or cause assertions if trying to make a TypeReference to a
> type that the program did not support.
>
> (While tracking down this bug, I added strict-ES2 type assertions to our
> constructor IR nodes as well. This helped pinpoint the error and seem
> reasonable to leave in, just in case.)
>
> Change-Id: I896b68ae9d3d9e1f30d7eba9fa594617ab851c74
> Bug: oss-fuzz:39540
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/455498
> 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: oss-fuzz:39540
Change-Id: Id8e323c22b18726214613b6061c08873048b7c69
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/455617
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This turns out to work fine, but we didn't cover it in any test case.
Change-Id: I98c40dc023bc9f0739beeb6e4163cde087a0be99
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/455499
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This reverts commit 36f53ec7e1.
Reason for revert: breaks DS3Types test
Original change's description:
> Disallow constructors of ES3 types in ES2 code.
>
> The fuzzer found that we constructed TypeReferences without first
> checking for disallowed tyoes. (In fact, TypeReference creation had no
> error checking at all; it didn't even have Convert/Make functions.)
>
> Added proper Convert/Make to TypeReference, and used those calls to
> report errors or cause assertions if trying to make a TypeReference to a
> type that the program did not support.
>
> (While tracking down this bug, I added strict-ES2 type assertions to our
> constructor IR nodes as well. This helped pinpoint the error and seem
> reasonable to leave in, just in case.)
>
> Change-Id: I896b68ae9d3d9e1f30d7eba9fa594617ab851c74
> Bug: oss-fuzz:39540
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/455498
> 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: oss-fuzz:39540
Change-Id: I1dc3ccca477fcb9fe3f39cfe8af1fd54dcb18d6b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/455616
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
The fuzzer found that we constructed TypeReferences without first
checking for disallowed tyoes. (In fact, TypeReference creation had no
error checking at all; it didn't even have Convert/Make functions.)
Added proper Convert/Make to TypeReference, and used those calls to
report errors or cause assertions if trying to make a TypeReference to a
type that the program did not support.
(While tracking down this bug, I added strict-ES2 type assertions to our
constructor IR nodes as well. This helped pinpoint the error and seem
reasonable to leave in, just in case.)
Change-Id: I896b68ae9d3d9e1f30d7eba9fa594617ab851c74
Bug: oss-fuzz:39540
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/455498
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>
All of these lines are errors but most of them are currently not
detected by our strict-ES2 checks. This is fixed in a followup CL.
Change-Id: Ifeba9aba3ce3f1bddd1c701dfc4622505e424ea7
Bug: oss-fuzz:39540
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/455497
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: I5a57e2db46734ca08825e6aef7a6363bcaada45a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/453759
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
`optimize_comparison` asserted that its inputs were numbers. However,
it's also valid to compare boolean inputs. Fortunately, other than the
over-zealous assertion, the actual logic worked fine.
Change-Id: I8a9db000274b4993a4c303efa223a1ed72461a87
Bug: oss-fuzz:39513
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/455296
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This should fix a failure in the ES2 conformance suite's "const_in_int".
Change-Id: I8b5487749291ef57712b8fe6c3949dc7c3e76883
Bug: skia:12499
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/455157
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Previously, `Type::applyPrecisionQualifiers` would return a new type
(e.g. `mediump + float` returned `half`) but left the precision
qualifier flags as-is. This was implemented that way because the
modifiers were already baked into a pool, so mutating them was
difficult.
The rewritten DSLParser does not share this limitation--every place
where applyPrecisionQualifiers is used, the Modifiers are easily
mutable. As a result, `applyPrecisionQualifiers` can now clear the
precision-qualifier bits on the Modifier, meaning that `half` and a
`mediump float` will generate the exact same Type/Modifier combination.
This change fixes a bug where precision qualifiers were not allowed on
function parameters. (See `check_parameters` in FunctionDeclaration.cpp
to pinpoint the cause of the error. A less-invasive fix could have just
marked those modifier bits as allowed in `check_parameters`, but this
fix addresses the root of the issue and is honestly how I wanted
`applyPrecisionQualifiers` to work all along.)
Change-Id: I331813efa54138f469a0d5bff2d274cd3ce64b70
Bug: skia:12489
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/455156
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
These files are no longer generated as of http://review.skia.org/452897.
Change-Id: I92730c8734b7b3a4739874b9331cec616ba5c118
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/455161
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 reverts commit 5f15c695f9.
Reason for revert: landed http://ag/15959743 to fix Android roll
Original change's description:
> Revert "Mark GLSL reserved names as reserved in SkSL grammar."
>
> This reverts commit 57f3fc4cde.
>
> Reason for revert: breaking Android roll
>
> Original change's description:
> > Mark GLSL reserved names as reserved in SkSL grammar.
> >
> > We now reject every reserved name in the ES2 docs as an unexpected
> > token, except for the rule that all names beginning with `gl_` are
> > reserved. (Unfortunately, sksl_frag bends the rules by directly
> > declaring a builtin variable named `gl_SecondaryFragColorEXT`.)
> >
> > Change-Id: I5dcb40b754720ca97fe3d80e2f9072beaa39fcdb
> > Bug: skia:11115
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/454737
> > Auto-Submit: John Stiles <johnstiles@google.com>
> > Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
> > Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
>
> Bug: skia:11115
> Change-Id: Ica56f48dc76ef1e52780acaf59b8ad9143637637
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/454860
> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
> Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Bug: skia:11115
Change-Id: I012b8d4e03be7f9c888c26d912552412529b4fb6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/455159
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This reverts commit 57f3fc4cde.
Reason for revert: breaking Android roll
Original change's description:
> Mark GLSL reserved names as reserved in SkSL grammar.
>
> We now reject every reserved name in the ES2 docs as an unexpected
> token, except for the rule that all names beginning with `gl_` are
> reserved. (Unfortunately, sksl_frag bends the rules by directly
> declaring a builtin variable named `gl_SecondaryFragColorEXT`.)
>
> Change-Id: I5dcb40b754720ca97fe3d80e2f9072beaa39fcdb
> Bug: skia:11115
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/454737
> Auto-Submit: John Stiles <johnstiles@google.com>
> Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
> Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Bug: skia:11115
Change-Id: Ica56f48dc76ef1e52780acaf59b8ad9143637637
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/454860
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
In complex programs with multiple functions, the Inliner can cause code
to be reordered in ways that cause a function call to be raised above
its declaration.
The Pipeline stage code generator will now emit a prototype for every
function defined in the program, before emitting any function bodies at
all.
With this change, ES2 conformance test `copy_global_inout_on_call` now
passes.
Change-Id: I85485710a34b778adef3cbc4a7ebe110a21a2a03
Bug: skia:12488
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/454742
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 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>
We now reject every reserved name in the ES2 docs as an unexpected
token, except for the rule that all names beginning with `gl_` are
reserved. (Unfortunately, sksl_frag bends the rules by directly
declaring a builtin variable named `gl_SecondaryFragColorEXT`.)
Change-Id: I5dcb40b754720ca97fe3d80e2f9072beaa39fcdb
Bug: skia:11115
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/454737
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
`input` is a reserved word in GLSL. http://screen/85m4iRwvJRadKbV
Change-Id: Iffc0a47d916a2419a27767902c839e09bfa7fe26
Bug: skia:11115
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/454736
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 reverts commit a909dd6b8d.
Turns out those reportPendingErrors() calls I removed were in fact
necessary, just not on any of the CQ bots.
Change-Id: I8be0898ac0b41dbb703a35f705cac06ca716c0b7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/453077
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
If a VarDeclaration line contained multiple variables, and the first
variable had an illegal initializer-expression, the Declare() would
return a Nop. AddVarDeclaration did not expect to see a Nop and would
assert once we tried to process the second var-declaration. Now, we
allow adding var declarations to a Nop.
Bulked up some tests to cover local and global variables (since those
are parsed in separate functions) and to check both the first
initializer as well as follow-on initializers (since those are parsed in
separate parts of the var-decl handler).
Change-Id: I66341191698175b490a659715cb8edaafe2f75ae
Bug: oss-fuzz:39032
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/452696
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This reverts commit 47f76853c6.
Reason for revert: Test failures
Original change's description:
> Use SkSL "offset" to actually mean "line"
>
> SkSL internally tracks token offsets, but only ever reports errors using
> line numbers. With the introduction of the DSL, which (being embedded in
> C++ source) only has access to line numbers in the first place, tracking
> offsets went from merely providing little benefit to actively making
> life more difficult.
>
> We are changing SkSL's position tracking from handling offsets to
> handling line numbers, but to simplify the review process the change is
> split up into two main steps. The first step (this CL) starts using
> line numbers everywhere, but avoids the thousand-line churn of actually
> renaming "offset", so most "offset" fields, variables, and parameters
> will be briefly misnamed and will actually contain a line number.
>
> The followup CL will complete the process by renaming all of the
> now-misnamed fields, variables, and parameters, but will not make any
> behavioral changes.
>
> Bug: skia:12459
> Change-Id: I30dc87cf4b816c5ddd7b8ae1be32586388962085
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/451419
> Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
> Reviewed-by: John Stiles <johnstiles@google.com>
Bug: skia:12459
Change-Id: I562d9980cd43a2fc5108e562155fe731a1761dca
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/452720
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>
SkSL internally tracks token offsets, but only ever reports errors using
line numbers. With the introduction of the DSL, which (being embedded in
C++ source) only has access to line numbers in the first place, tracking
offsets went from merely providing little benefit to actively making
life more difficult.
We are changing SkSL's position tracking from handling offsets to
handling line numbers, but to simplify the review process the change is
split up into two main steps. The first step (this CL) starts using
line numbers everywhere, but avoids the thousand-line churn of actually
renaming "offset", so most "offset" fields, variables, and parameters
will be briefly misnamed and will actually contain a line number.
The followup CL will complete the process by renaming all of the
now-misnamed fields, variables, and parameters, but will not make any
behavioral changes.
Bug: skia:12459
Change-Id: I30dc87cf4b816c5ddd7b8ae1be32586388962085
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/451419
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
This reverts commit 45e3838006.
Reason for revert: Also need to rewrite them in actual ES2 mode.
Original change's description:
> Rewrite switch statements in GLSL strict-ES2 mode.
>
> Once this lands, switch statements will work everywhere--Metal, SPIR-V,
> GLSL, and SkVM.
>
> Change-Id: I2797d0a872de8be77bb9f7aa6acb93421d571d70
> Bug: skia:12450
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/452356
> Commit-Queue: John Stiles <johnstiles@google.com>
> Auto-Submit: John Stiles <johnstiles@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
Bug: skia:12450
Change-Id: I92656ed40289872405c0873f2c56a52b04e35b1d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/452556
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>
This makes for a slightly more easier-to-read disassembly; register
numbering no longer goes in reverse for vector assignment. Of course, it
makes no difference in the actual execution.
Change-Id: I86c5024bae1f73b1cd98252e4831207e47dc11eb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/452323
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Once this lands, switch statements will work everywhere--Metal, SPIR-V,
GLSL, and SkVM.
Change-Id: I2797d0a872de8be77bb9f7aa6acb93421d571d70
Bug: skia:12450
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/452356
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
SkVM implements switches as a pseudo-loop; breaks are handled with the
condition mask just like a for loop. Fallthrough is handled via a
scratch Value in a temporary slot. `writeStore` neeeded to be refactored
to support writing into slot(s) without an associated Variable.
At IR generation time, SwitchStatements are now emitted without error
even in strict-ES2 mode. The GLSL code generator currently reports these
as an error in strict-ES2 mode, but this will be fixed in a followup
coming shortly (the switch will be rewritten as ifs inside a one-shot
loop, similar to our IR-rewrite strategy).
Change-Id: I5507257246c42a35d2f46b4b9a89492a5ffeff9b
Bug: skia:12450
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/451421
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Prior to this fix, the new test cases would report that the various loop
terms needed to be constant expressions.
Bug: skia:12472
Change-Id: Ic377ed0c4598136ae38fb2b65c93b6d8609d54cb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/452276
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: 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>
While I was in this code, I realized that the setVariable method of
InterfaceBlock was unused and there was therefore no reason to be
storing a pointer instead of a reference.
Bug: oss-fuzz:39000
Change-Id: If7505ba87f4060370cfd32ca2e30c76648965101
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/450446
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: 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>
Missed one more case of Optional<Wrapper<Expression>>. This should be
the last one.
Bug: oss-fuzz:38944
Change-Id: Ic7f790cd99e2a3ee1c3874cc767a4702265d1723
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/450476
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@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>
Unreachable code might contain the only reference to a variable or
function. We can eliminate those variables/functions if we remove the
unreachable code first.
(Are there counterexamples where this order leads to worse results? I
couldn't think of any, and pragmatically it didn't show up in any of
our existing tests.)
Change-Id: Ic9f0222851269e0c37eb9570547307998f882b6c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/450156
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@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>
Missed a case when eliminating optional/wrapper in an earlier CL.
Change-Id: If7f80ea6e2172acadf7b0087fe1a05853ccae445
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/449838
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: John Stiles <johnstiles@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>
Not a big deal necessarily, but considering using this logic in GLSL as
well, and I'm less confident that your average GLSL ES driver will
optimize away the separate array loads.
Change-Id: I6a9f0d18c0fac138f64ad6426670f615e17f3492
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/449099
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 discovered that it could overflow the program-size value.
Rewrote the logic to use SkSafeMath everywhere, and to early-exit as
soon as a statement manages to exceed the program size.
Change-Id: I01511b2201173c95ebc1ac602901410ac9d74d73
Bug: oss-fuzz:38697
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/449098
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Adjusted default caps in skslc to be consistent with runtime behavior,
and added optional settings mode to enable the feature. Tests for both
scenarios. (The error test crashed prior to the fix).
Bug: oss-fuzz:38726
Change-Id: I5270d4837ac982085d7baf5abd4b361f7bfb8562
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/449062
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This is a reland of db38ad7b14
Original change's description:
> Fixed DSL assertion error on source files containing nulls
>
> The assertion was there to make sure we weren't running off the end of
> the source, but naturally fails in the presence of legitimate embedded
> nulls.
>
> Change-Id: I3b80499e9b182c9ea046c479f35d7a965d548401
> Bug: oss-fuzz:38107
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/447182
> Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
> Reviewed-by: John Stiles <johnstiles@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
Bug: oss-fuzz:38107
Change-Id: Idb1a6b7c64d2bb954edadae828d6de808158fd3f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/448660
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Change-Id: Id6e1d1be276af01ce05777682dde8b58d803aedc
Bug: oss-fuzz:37837
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/449097
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
The fuzzer has discovered a bug in our program size-checking logic; for
loops that immediately contain another for loop (with no block) were not
counting the inner loop's iterations. This allowed it to exceed our
maximum program-size threshold (and time out during SkVM compilation).
This test demonstrates the issue. A followup will fix it.
Change-Id: I3b7d4c8a4f0ed04cf0aba3f1a32fdad7d6d784e7
Bug: oss-fuzz:37837
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/449096
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
We already had a test case here, but it wasn't actually in operation.
The test has been split into ES2 (square) and ES3 (non-square) halves,
returns the color like a proper runtime effect, and it's now running in
dm.
Also, Metal doesn't natively support matrixCompMult, so it injects a
helper function; I tweaked the helper so it no longer requires an extra
result variable.
Change-Id: Ie79242768966fcbe879ad73461d17b4fb8e55670
Bug: skia:12202
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/448117
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
