Change-Id: I87cc0e6d9dc60a0ceaf32c453d2278091ea3c5e5
Bug: skia:12339
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/465393
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Change-Id: Ic657319cf4f3ba2c3c23e2923cf121138d16dbf2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/457397
Commit-Queue: Joe Gregorio <jcgregorio@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
In Metal on some GPUs, `test_for_preserving_PM_conversions` can fail
when half4s are used for premul conversion.
Change-Id: I95a737a88aa8f5a998e3201516900977d5223666
Bug: skia:12339
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/465798
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Additionally, the default clip state was quick rejecting all the draws.
Bug: skia:12466
Change-Id: I8eaa95418bf24af2a5718c8cf21e97cdd7f80a34
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/465476
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
This is a reland of 75e1f4c028
Original change's description:
> Lift recursive curve culling out of tessellators
>
> We need recursive chopping/culling logic in order to draw
> astronomically large paths. But rather than do that at the same time
> the tessellators chop curves, this CL moves that logic into an
> SkPath -> SkPath transformation that runs ahead of time (and only if
> the path is extremely large to begin with). This will enable us to
> remove recursion from the tessellators and quickly determine ahead of
> time the size of buffers they need.
>
> Bug: skia:12524
> Change-Id: Ib2800fb23054f1548501811203173e58273fbc83
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/463936
> Commit-Queue: Chris Dalton <csmartdalton@google.com>
> Reviewed-by: Greg Daniel <egdaniel@google.com>
Bug: skia:12524
Change-Id: Idf54f0c2bddaaddc9fc17bee99c910f3961682a5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/465361
Reviewed-by: Greg Daniel <egdaniel@google.com>
Auto-Submit: Chris Dalton <csmartdalton@google.com>
Commit-Queue: Chris Dalton <csmartdalton@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>
When the flag is disabled, everything works the same as before and all
uniforms are copied to buffers as 32-bit values. Enabling the flag will
cause shorts and halfs to be written to the uniform buffer as 16-bit
values (converting as needed).
Change-Id: I7e7c191f98b14b55a2587dc1499e8a6ff72f573c
Bug: skia:12339
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/464920
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Bug: skia:12466
Change-Id: Ia0da94fc300ab678712e9bb79a011694fea8595e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/464677
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
The iPhone 6 only has 1GB of RAM. (The iPhone 7 and 8 have 2GB.)
Change-Id: I4efd00f21feb9c7b6e42d99936989573d26acef3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/465390
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Erik Rose <erikrose@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Erik Rose <erikrose@google.com>
This is a reland of c77620c308
Original change's description:
> Move alpha modulation into paint conversion (Step 1)
>
> Skia has a rule that says (roughly), any SkShader is modulated by the
> paint alpha. The CPU backend implements this precisely - the entire
> shader sees the opaque paint color, and the alpha is applied once at
> the root. The GPU backend has previously made each SkShader responsible
> for doing this modulation. That led to two kinds of problems:
>
> 1) Some shaders forgot to do the modulation at all.
> 2) In shader trees, it's possible for the alpha to get applied
> multiple times, or to child effects where it isn't desired.
>
> A consequence of #2 is that the GPU implementation of things like
> blend-shaders have to jump through hoops to invoke their children with
> opaque versions of their input colors.
>
> This CL allows us to remove the explicit alpha modulation from a variety
> of shaders, and should also cleanup of the blend shader logic. However,
> to get the CL past chrome's layout tests, we need to guard the change.
> So this version just makes the major change so paint conversion, in a
> way that will work universally. Once chrome switches to the new method,
> it will be safe to clean up the various shader implementations.
>
> Bug: skia:11942
> Change-Id: I518534becdd5d10cbd78cf3ff7d4a46dd1faabf9
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/464116
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
Cq-Do-Not-Cancel-Tryjobs: true
Bug: skia:11942
Change-Id: I3bf184932adbb425959b02d28af1e6b7f5d127d5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/464928
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Bug: skia:12466
Change-Id: Ib23a501664ebba581376fa0cb1ce5c6537e5d349
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/465136
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
We used to just assert, but it turns out that Android has tests that
explicitly set out-of-range alpha values (and disable our asserts).
Bug: skia:11942
Bug: b/186543004
Change-Id: I167de7aba261ca3df579f9a0bddb0d90605e0094
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/465381
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: 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 reverts commit 65a726bb49.
Reason for revert: You cannot include a src file in an include file. This ends up using c++17 features in our includes. Breaks rolls.
Original change's description:
> Move GR_MAKE_BITFIELD_OPS and GrAlignTo to non-GPU files
>
> These have been renamed SK_MAKE_BITFIELD_OPS and SkAlignTo
> because nothing seemed particularly GPU/Ganesh specific to them.
>
> I moved the latter to SkTypes.h because we have other align
> code there and former to src/SkUtils.h because I didn't know
> where else it should go.
>
> The primary motivation was removing the GrTypesPriv.h
> include from src/core/SkBlockAllocator.h. I had attempted
> some amount of #if SK_SUPPORT_GPU, but that's not as clean
> here because both our CPU and GPU backends use the
> SkBlockAllocator (as far as I could tell).
>
> This also moves sk_memset* from SkUtils.h to SkOpts.h, because
> SkOpts.h requires bringing in RasterPipeline, which seemed
> like overkill.
>
> Change-Id: I5163ef5064ad3840a15b7e873930d60e2620bf9d
> Bug: skia:12584
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/464876
> Reviewed-by: Brian Osman <brianosman@google.com>
Bug: skia:12584
Change-Id: I1b772bbbc6f150d737bb53fa4e5f45d1581929fa
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/465376
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>
This uniform uses a float2 type, not half2. Previously, this was only a
latent problem, since we treated halfs and floats the same when setting
up uniform buffers.
Change-Id: I54f7033561542cf984c08070b2c3eca4173ca69c
Bug: skia:12339
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/465216
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:12466
Change-Id: I12c64396791d8e0b8891b82927b1c8811a6e164f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/464385
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
We need to know a uniform's type to convert it to the uniform-buffer's
expected format when uniforms are set. We have this data in other
arrays, but it's not accessible to the program data manager.
We don't necessarily need to use a bitfield here, if we think there's
ever a possibility of having a uniform buffer > 16MB in size.
Change-Id: I88b3936de5319d65c76891ec0f1d87badc71d2dd
Bug: skia:12339
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/465076
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
The SortKey will only hold the uniqueID of the program and uniform data. When actually executing the draw we will need to reconnect with the actual data.
Bug: skia:12466
Change-Id: Iea7f0a99d471ea7fe2a3864bdd60255b09289088
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/464926
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Change-Id: Ifedf6172c8152b809ef8faeae4dd0e7b87b142ee
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/464927
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Bug: skia:12466
Change-Id: I3c3eda26d0c09a58108a5b7bdd1bca0e63973f17
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/462887
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Bug: skia:12466
Change-Id: If31d25a1f4a4805069f6556c6802f33fa0bdfcc1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/464380
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
These have been renamed SK_MAKE_BITFIELD_OPS and SkAlignTo
because nothing seemed particularly GPU/Ganesh specific to them.
I moved the latter to SkTypes.h because we have other align
code there and former to src/SkUtils.h because I didn't know
where else it should go.
The primary motivation was removing the GrTypesPriv.h
include from src/core/SkBlockAllocator.h. I had attempted
some amount of #if SK_SUPPORT_GPU, but that's not as clean
here because both our CPU and GPU backends use the
SkBlockAllocator (as far as I could tell).
This also moves sk_memset* from SkUtils.h to SkOpts.h, because
SkOpts.h requires bringing in RasterPipeline, which seemed
like overkill.
Change-Id: I5163ef5064ad3840a15b7e873930d60e2620bf9d
Bug: skia:12584
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/464876
Reviewed-by: Brian Osman <brianosman@google.com>
Make sure graphite compiles standalone and not just if ganesh is also
enabled.
Bug: skia:12466
Change-Id: Ic843881a2a88c8d4b62f3a2ea38a10b6a86a12d4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/464817
Reviewed-by: Robert Phillips <robertphillips@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Greg Daniel <egdaniel@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>
On low memory machines a common cause of crashes is when a draw
operation requires a large layer (or many large layers) because an
implementation of SkSurface_Base::onCopyOnWrite does not actually have
the resources available to do the copy when required by a draw. Allow
this method to fail and percolate up the call chain so that the draw
simply does not happen instead of crashing.
It appears some users are creating their own subclasses of
SkSurface_Base for their tests. Add SK_SURFACE_COPY_ON_WRITE_CRASHES to
keep the old crashy behavior until they can be updated.
Bug: chromium:1116362
Revert: 5b19ebe0c5.
Revert-Change-Id: I2873589f996ded9c9fd6d27b19155ca18d5b5326
Revert-Reviewed-on: https://skia-review.googlesource.com/c/skia/+/463956
Change-Id: Id06d1e6d3aacb409a3b00b9a862bd8ddd1aaa22f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/464456
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Ben Wagner <bungeman@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>
SkTypes.h makes sure SK_SUPPORT_GPU is defined.
I was tempted to move these files to include/gpu and
src/gpu, but that might be best handled in a follow-up
CL in case any clients depend on them.
Change-Id: Ia4d6717567fe6b1842bed2c7fc0439e85e1795b2
Bug: skia:12584
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/464638
Reviewed-by: Brian Osman <brianosman@google.com>
