Finding a dangling ExternalFunctionReference in the IR should be handled
the same as a FunctionReference; both are equally indicative of a
problem in the user's code.
Change-Id: I5aa9204e692678d7b54d78fc7253d49940dd130a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/442694
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Bug: skia:8451 skia:10827
Change-Id: I5b38a1d72cd4558f8e2a92aaf9b12f05efce0923
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/442683
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
This is a first step towards replacing `finalizeFunction` with a
`FunctionDefinition::Convert` method living outside of the IRGenerator.
Previously this code would assert that we had no early returns from a
vertex-program main() method; this has been turned into an error.
(The original assertion was also tied to fRTFlip, because the *problem*
with early-returns in main is tied to the lack of RTFlip fixups, but
we fundamentally don't allow early returns, so it makes more sense to
just universally disallow it.)
Change-Id: Iba0742f7ef3cbc83995ea130fec1eb1ef2556c44
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/442691
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
SkRectPriv::Subtract had assumed that Sk[I]Rect::Intersects returns
false if either argument is empty. However, when an SkIRect with
overflowing dimensions is intersected with a non-overflowing SkIRect,
then the intersection can be valid and the remainder of the impl's
expectations are violated because dimensions are "negative".
Since these overflowing rects are considered empty anyways, this just
explicitly checks for that.
Bug: chromium:1243206
Change-Id: I8b69731e8d8ae467cf98c906da3aaa657dfe7994
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/442277
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
The fuzzer invented a much more elaborate example, but I was able to
winnow it down to a simple otherwise-normal test case. This also fixes
a latent DSL bug; DSL functions were not updating the list of referenced
intrinsics, so the compiler might emit finished programs that called
built-in functions that didn't exist in the code.
Change-Id: I095bb566b9db9f87cbe9460732c300b7973eb112
Bug: oss-fuzz:37659
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/442325
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Removes --alsologtostderr flag, which was removed along with glog.
Change-Id: I8d2b5ac267feb0f8f88e19d346c7292fc825b1fb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/442316
Reviewed-by: Erik Rose <erikrose@google.com>
Commit-Queue: Eric Boren <borenet@google.com>
The fuzzer managed to trigger an assertion by returning an invalid type
from a void function. We were neglecting to clear out the expression
when reporting it as invalid, leaving it for `checkValid` to find later.
Change-Id: Icc152c867a3316fe994967e192601fb4d10da98f
Bug: oss-fuzz:37704
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/442678
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>
No-op arithmetic simplification will convert expressions like `x += 0`
to `x`. When making this simplification, we will also downgrade the ref-
kind of `x` from "write" to "read" since the new expression is no longer
an assignment.
The fuzzer discovered that the ref-kind downgrade was too aggressive,
and would also traverse into nested subexpressions and downgrade them
as well. That is, for `x[y=z] += 0` would convert both `x` and `y`
into "read" references, which is incorrect; `y` is still being written
to.
The fuzzer managed to turn this mistake into an assertion by leveraging
a separate optimization. It added a leading, side-effect-less comma
expression for us to detect as worthless and eliminate. In doing so, we
clone the expression with the busted ref-kind, triggering an assertion.
Change-Id: I42fc31f6932f679ae875e2b49db2ad2f4e89e2cb
Bug: oss-fuzz:37677
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/442536
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Because a SkVx::Vec<4, uint32_t> was stored in a class, the c++17
compiler used an over-aligned delete. This is not present in the
c++14 library. Just use memcpy instead.
Change-Id: Ia70da7bf7724e441212b0be909f02f3839011f16
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/442278
Auto-Submit: Herb Derby <herb@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Herb Derby <herb@google.com>
Function parameters can't be explicitly declared as statements.
It shouldn't be possible to reach this assertion.
Change-Id: If19395f80112c61e3bd027f0fe3a251393c84767
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/442296
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Change-Id: I4cd34eec09775f39421c6077d3669df99dad57d1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/442321
Reviewed-by: Ravi Mistry <rmistry@google.com>
Commit-Queue: Eric Boren <borenet@google.com>
Several failing Adreno tests pass in Vulkan but fail in GLSL.
(Unfortunately, some tests do fail across the board.) We can increase
our scope of testing by limiting our test disables to only the backends
where failures actually occur.
Change-Id: I9374cb98a7062db58a5470d0ed2bd02105f02f04
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441888
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
We had some error-checking logic in IRGenerator that could trivially
move into VarDeclaration::Convert. It's better to centralize the logic
when we can. (In PS2, I added matching assertion checks to Make.)
Change-Id: If15aeaa501274c4332c9ccec069b7e2ab1137dc9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/442240
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This CL extracts the very fiddly edge case code that should be common
to both blurs. This is a single step in the progression to share
even more code.
Change-Id: I9d22cb8ae44e7ff2cb49196a3c0b464e48c21cdc
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441062
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Herb Derby <herb@google.com>
Mechanical.
Bug: skia:11837
Change-Id: Ic302ee314ad73ce034c8daac38416a8249a125a4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/442276
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Very originally, skif::Mapping::DecomposeCTM() and
SkBaseDevice::setDeviceCoordinateSystem assumed that if the canvas
matrix was invertible, then any scale decomposition would produce a
valid device coordinate system. This proved not to be true and fuzzers
quickly caught it, but I had attempted to address it by forcing
SkCanvas to do extra work so that the above two functions remained
unchanged.
However, it's become apparent that even making the assumption that the
product of two invertible matrices remains invertible does not always
hold true in the wonderful world of floating point math.
Instead, this rewrites DecomposeCTM and setDeviceCoordinateSystem to
return bools, allowing them to fail. This cleans up some of the earlier
checks that SkCanvas makes while computing the skif::Mapping, and it
also ensures that once we fold in the prior device's transform, the
net layer->global transform remains valid. If any of this fails, it
just gets rid of the new device and sets the clip to empty, basically
preventing drawing until the invalid layer has been restored.
Bug: chromium:1239968, chromium:1240685
Change-Id: Ib9ce8f95859e726a9eacf1154f6eef8dd3995500
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/442017
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Before running this script, you'll need someone from infra team to give
your @google.com account access to the Google Cloud fuzzer repo. Once
that's been done, run this Python script and it will automatically
recreate the fuzzer corpus from our SkSL test inputs and upload it to
the cloud.
Change-Id: I804fdf7933a99b92dd1640d9af17530d4db97a4e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/442001
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
The entire ASTNode is probably going away soon, but this is a decent
place to start. Checking the fuzzer logs, we had 0% coverage in here,
which makes sense because it's unreachable by any normal means.
Change-Id: I396464e3e613d46e990b629c4fc991c11f6110fa
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/442000
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>
+small fix for placeholder in getGlyphPositionAtCoordinate
Bug: skia:12322
Change-Id: I8f03c5c808db54fc9742e5817768db4a088bc5b5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/440458
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Julia Lavrova <jlavrova@google.com>
Our current intent is to disable MSAA for all of Intel, but it snuck
through on Intel.
Change-Id: I1fb5c4d88a9650556f3e64f7a3aaaa3907169c76
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/442036
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
This reverts commit 9155b338bb.
Reason for revert: disable test for GLSL + Adreno 6xx
Original change's description:
> Revert "Add ES3 intrinsics isinf/isnan to public SkSL ES3."
>
> This reverts commit e43714f490.
>
> Reason for revert: Several Pixel (Adreno) devices failing the test
>
> Original change's description:
> > Add ES3 intrinsics isinf/isnan to public SkSL ES3.
> >
> > The ES3 spec doesn't mandate that `isnan` actually has to do anything,
> > so the Isnan test is not enabled. (It doesn't work on my personal
> > machine unless I make the NaN detectable at compile-time.)
> >
> > We do not support these functions in constant-expressions, as we
> > currently avoid optimizing anything into a non-finite value; we leave
> > expressions alone if we calculate a NaN/inf result for their value.
> >
> > Change-Id: Ibfdfb47b6e6134165c8780db570de04a916d2bfa
> > Bug: skia:12022
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441581
> > Auto-Submit: John Stiles <johnstiles@google.com>
> > Reviewed-by: Brian Osman <brianosman@google.com>
> > Commit-Queue: John Stiles <johnstiles@google.com>
>
> TBR=brianosman@google.com,ethannicholas@google.com,johnstiles@google.com,skcq-be@skia-corp.google.com.iam.gserviceaccount.com
>
> Change-Id: I89899ed391aa870350d0452bab4a0fb75bd7be38
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: skia:12022
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441716
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
Bug: skia:12022, skia:12377
Change-Id: Ib149dbc1138feb3ee2bf6f7e31e9e8a9414560bc
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441884
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Change-Id: Ia5a11580a793226253e2e294f6c43aa76fa97e8f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441882
Commit-Queue: Brian Salomon <bsalomon@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Auto-Submit: Brian Salomon <bsalomon@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Change-Id: I4a825c0d191f3f24d558c4331e07fe2a55832f76
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441838
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
We'll switch to the correct context when necessary (e.g. before
calls that talk to the GPU). This is achieved by adding in
calls at the JS layer to switch the context before making a call
that is known to talk to the GPU (e.g. draw calls on SkCanvas).
Another implementation that was considered was to add a C++
shim in GrGLInterface that would switch the context before
every call in the GPU - however, that seemed too difficult
and would add extra overhead if a single draw* call talks
to the GPU multiple times.
Bug: skia:12255
Change-Id: I96e4c6b41a5bfcc9913aeaca7ccb125358048ad3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/432136
Reviewed-by: Brian Salomon <bsalomon@google.com>
We're seeing a significant perf hit when running on Mac msaa8, so
disabling for now.
Bug: skia:12376
Change-Id: Ic785e99b2ae42aeb54f8313114d82202b645b273
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441881
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Our SPIR-V code generator did not implement support for negating a uint.
However, this is something that GLSL allows (as does the rest of SkSL).
I checked glslang and it uses OpSNegate here. The SPIR-V docs indicate
that OpSNegate allows any type of integer, and the validator lets it
pass, so we now use OpSNegate here as well.
http://screen/33mkq92uxAT5Xu8http://screen/4YBTh3gCWz8eZx7http://screen/388HtXyytcN5vLZ
Change-Id: I8c142018fd5e162dcd051abe1bc5d69a6e034794
Bug: oss-fuzz:37627
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441880
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Previously, a struct containing a vardecl with multiple declarations
would interpret arrays incorrectly. An array would be applied to ALL
variables in the decl after its initial appearance. That is,
`int w, x[10], y, z;` would be interpreted as
`int w, x[10], y[10], z[10];`.
This is now fixed and our test case runs as expected.
Change-Id: I5b4a617c58cdfb83face651effd42770a1f68638
Bug: oss-fuzz:37622
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441879
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
The fuzzer detected a serious parsing error; a struct containing a
vardecl with multiple declarations would interpret arrays incorrectly.
An array would be applied to ALL variables in the decl after its initial
appearance. That is, `int w, x[10], y, z;` would be interpreted as
`int w, x[10], y[10], z[10];`. The fuzzer caught this by putting two
arrayed variables in a row; the second variable was interpreted as a
nested array, which led to an assertion.
This CL contains a simple hand-written test case demonstrating the bug,
with the fix coming in a followup.
Change-Id: I42d7372ba77fa1528ae24eb8c29a2e5903784139
Bug: oss-fuzz:37622
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441878
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
We weren't coercing the expression because we don't care about its type,
but that allowed intermediate-expressions to pass through without
reporting an error. Now we coerce the expression to its present type,
which will always fail if the type is disallowed and succeed otherwise.
Change-Id: Ic0de0d17f0f5d56360575efe992ce4d74dec2a5a
Bug: oss-fuzz:37620
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441876
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
The BuiltinTypes helper functions were deleted as part of
http://review.skia.org/423585, and the friend class is no longer needed.
Change-Id: I9a1980daa1891fc5c3c12dc35a5a1037e64dea86
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441799
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>
Support is added so we can differentiate between using discardable
msaa for normal msaa draws and using it for DMSAA. Before this
many asserts and checks throughout GrVk* assumed we could only have
discardable msaa if the actual render target was msaa.
After this change the only thing missing to enable DMSAA on Vulkan
is to fix GrProgramInfo to store the actual sample count the program
will use instead of the same count of the GrRenderTarget.
Change-Id: Ifdb9a3beb641f96f6dfebe3241ccc5a2c8770bb3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441517
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
src/gpu/GrBlockAllocator -> src/core/SkBlockAllocator
src/gpu/GrTBlockList -> src/core/SkTBlockList
Tests and references also renamed.
Bug: skia:12330
Change-Id: I5fad05faa3dcecd89a0a478dcf30c090ea7589f5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/441477
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
