This reverts commit f33cf451a2.
Reason for revert: breaking the android roller
Original change's description:
> Update VMA to latest version.
>
> This is needed so that we can use non skia supplied vk_mem_alloc.h on
> clients that have already updated to newest version. As we transition
> to Bazel builds this helps to make it so we can set the rules for
> specific clients around VMA without things breaking
>
> Bug: skia:13211
> Change-Id: I5d38a3a91a44f6b3fdf75894a3248ee3991dd5d9
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/531157
> Reviewed-by: Kevin Lubick <kjlubick@google.com>
Bug: skia:13211
Change-Id: Ibd621aa2f07359f9b72e1a35df0f50ca3c063e86
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/531543
Auto-Submit: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Now that we can call into Skia utils directly, we can use the
preexisting code from SkOSPath instead.
Change-Id: I67e3099e97ec0e93acc08c7f2142a01a2af48f15
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/531416
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
FreeType introduced FT_LOAD_COLOR in 2.5 so an application could
indicate that it could handle the new color format. If this glyph load
flag was not set then the colors would be desaturated into the old gray
format so that something would be drawn while applications were updated.
The only source of color glyphs was bitmaps, but Skia always set the
flag on both scalable and non-scalable (bitmap and outline) fonts.
In FreeType 2.10 the meaning of this flag was expanded to mean that
using FreeType to render a glyph with an associated COLR entry would
attempt to draw using the color layers instead of the base glyph. This
did not affect Skia since Skia handles the color layers itself.
In FreeType 2.12 the meaning of this flag was updated again to mean that
if using FreeType to load a glyph with an associated SVG entry would
prefer loading the glyph with a new FT_GLYPH_FORMAT_SVG. This means any
users loading a glyph with FT_LOAD_COLOR on a scalable font (like Skia
has been) will get this new format and not the base outlines.
In order to work properly with this setup, Skia must ensure the
FT_LOAD_COLOR is only set on scalable (outline) fonts when Skia supports
SVG glyphs. For now this means setting FT_LOAD_COLOR on bitmap fonts
only with a comment where it should be set when SVG is supported.
Change-Id: Iaf8991b73d353ab7bda836ff4c290d75ab519d78
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/531323
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
This is needed so that we can use non skia supplied vk_mem_alloc.h on
clients that have already updated to newest version. As we transition
to Bazel builds this helps to make it so we can set the rules for
specific clients around VMA without things breaking
Bug: skia:13211
Change-Id: I5d38a3a91a44f6b3fdf75894a3248ee3991dd5d9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/531157
Reviewed-by: Kevin Lubick <kjlubick@google.com>
This is a reland of commit ca0c82a968
Original change's description:
> Eval args of trace macros in debug builds
>
> Change-Id: I9ae48cfa23948fbdcdf6e8997365f5a8c2b3be8b
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530677
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Brian Salomon <bsalomon@google.com>
Change-Id: I8eb6c5fb129e907577c504776c3bab37c6a94fec
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/531236
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Have the GrAtlasManger handle the logic of the
fSupportBilerpFromGlyphAtlas flag directly. This dramatically
reduces the complex plumbing the current code uses.
This is part of a larger CL that has a crash on MSVC-Direct3d-Release
bot, but not the debug bot. I'm breaking the CL into very small
pieces to find the problem.
Change-Id: Idbad1614b511041893c00c291c9db1cf61ab5532
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530737
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Herb Derby <herb@google.com>
Change-Id: I28ef42ff417faf98eb1f124d4a1987b6cc4a609f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530456
Auto-Submit: Eric Boren <borenet@google.com>
Reviewed-by: Ravi Mistry <rmistry@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
These were from a previous attempt.
Change-Id: Ia057e5e23d2ba97e33f1bb7fafc785a3ee92d66e
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/531096
Auto-Submit: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
We now have two functions `writeOpLoad` and `writeOpStore` which are
in charge of writing SpvOpLoad and SpvOpStore instructions.
`writeOpStore` also keeps track of pointer stores in a "store cache."
Subsequent loads from that same pointer will be found in the cache and
will return the value stored in that pointer instead.
Such a cache definitely cannot work in the face of control flow, so we
make the following concessions:
- `pruneReachableOps` is now `pruneConditionalOps`. Any pointers that
are altered inside a potentially-unreachable block are cleared from
the cache entirely.
- The entire store cache is cleared at all OpLabels within a loop.
The cache also cannot work in the presence of swizzled stores, so we
make another significant concession:
- The entire store cache is cleared whenever we store into a non-memory
pointer (e.g., assigning into a swizzled LValue, such as `foo.xz`).
Despite these significant limitations, this manages to dramatically
shrink many real-world examples.
Change-Id: I0981a0cf7b45b064e153e9ada271494c8e00cad5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530054
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Graphite won't draw non-Graphite-backed images so we need to update our
tools to meet that requirement.
Bug: skia:12701
Change-Id: I66dc371b2e11e327e1d371115fb62c85863308e8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530542
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This just adds texture coordinate normalization and kClamp and kRepeat
support.
Bug: skia:12701
Change-Id: I17ed0ccfd95d7081a77cb23428a14f6fef0a118b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530538
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Change-Id: I9ae48cfa23948fbdcdf6e8997365f5a8c2b3be8b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530677
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Some of our oss-fuzz tests contain garbage data which isn't in any
encoding. This throws an error unless the files are opened in binary
mode.
Change-Id: I5caf307f3c79fba5b177496fd8ced8381205b97e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530679
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
It is possible for a single glyph to have multiple representations. In a
COLRv0 or COLRv1 font the outlines of the sub glyphs must be used as
layers or clips. Ensure that bitmaps and SVG representations are
explicitly excluded when loading glyphs with the express purpose of
retrieving any available outline.
Note that this does not touch the flags used in generatePath because in
that case a path should only be loaded if the glyph representation for
rendering is actually outline based.
Change-Id: I499e23aa20dacead81c7f76980039f139fa8edce
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530676
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Now that getType no longer needs it, this was only used to see if two
types matched (modulo precision).
Change-Id: Icdf507573f03a8caf2b202465a83e50359eb6446
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530570
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Arman Uguray <armansito@google.com>
Commit-Queue: Arman Uguray <armansito@google.com>
Previously, we would determine the operandType by calling
`getActualType`. This function converts half-precision types to full-
precision ones, which seems to have been unintentional. Fortunately, the
operand type is not actually emitted into the SPIR-V by most code paths
(most paths use the resultType instead) so it was not a significant
impact in practice. A few matrix-based paths emitted ops using this type
and these paths now emit RelaxedPrecision as expected.
Change-Id: I32f4c0327427476fee6b78953284818b7970b6e8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530543
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Arman Uguray <armansito@google.com>
This now uses existing logic from `nextId` rather than reinventing the
wheel.
Change-Id: I2879fa42e8df6d70936ce7e322d48e4990d79319
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530540
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Arman Uguray <armansito@google.com>
Commit-Queue: Arman Uguray <armansito@google.com>
The COLRv1 bounding box is currently computed without the subpixel
offset. This can lead to cropping of a row or column at the edge of the
rendering. Apply the subpixel offset to the base bounding boxes.
This is simplified by always converting the FT_BBox to an SkRect as
early as is convenient and unifying the COLRv1, COLRv0, outline, and
bitmap application of subpixel positioning and conversion of bounds to
glyph bounds.
This also fixes a long standing issue where it is possible for subpixel
positioned empty (space) glyphs to have non-zero bounds since rounding
out a non-integer aligned empty SkRect to an SkIRect will produce a unit
SkIRect.
Change-Id: I634783250942d0cd45cf28e81d5fd695982547cf
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530523
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
SkFindQuadMaxCurvature returns either a value in [0, 1) or NaN.
split_conic uses this to determine where to chop a conic, but doesn't
check for NaN, and passing NaN to conic.chopAt() will assert. Inverting
the if statement and checking to see if t is in (0,1) rather than that
t == 0 || t == 1 will cover the NaN case, since NaN comparisons are
always false.
Bug: skia:1310167
Change-Id: I401f586d9b4cb9f05332027627f9fac9dc7dee15
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530519
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
We will need this in a followup, because we can apply optimizations to
function-class LValues that wouldn't make sense for other classes.
Change-Id: I99855961cfb8c5bfac0068e33e20e2e687f5aefe
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530537
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Bug: skia:13212
Change-Id: I8fc8bcd01181fcfb9955119984afa4bfbb1f73e5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/529756
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Previously, we only handled the simple case of extracting from an
OpConstantComposite. Now we also handle the complex case of extracting
from an OpCompositeConstruct, where vectors can be composed of other
vectors.
This is particularly challenging because OpCompositeConstruct can
contain SpvIds from almost any other instruction, so we need to be
able to decode those instructions and figure out their type. For
instance:
%5 = OpFAdd Vec2 %1 %2
%6 = OpFAdd Scalar %3 %4
%7 = OpCompositeConstruct FloatVec3 %5 %6
%8 = OpCompositeExtract %7 2
The %8 (OpCompositeExtract) could be replaced with %6 but we need to
peek at the type in *both* OpFAdd instructions to decode this. It
only works when the affected instructions are in-cache, so many
opportunities are currently not optimized because their code still
uses the original, uncached form of writeInstruction.
Change-Id: I5719ae6284f32e1d6f2c898eca282c22b94fc764
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/529743
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Change-Id: I3a9e9e90b0ac1b1099830eaca06506bcce794144
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530055
Commit-Queue: Brian Salomon <bsalomon@google.com>
Auto-Submit: Brian Salomon <bsalomon@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Previously just the base level was uploaded and the level contents
were generated on the GPU.
showmiplevels_explicit now works on GPU.
Bug: skia:11983
Change-Id: I96ed8a7ad90a8252f55a736cb6146eec9b2a3ad1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/521356
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
We don't need deduplication on struct types, but we do want the ability
to look up a SpvId and determine that it is a struct type. (An oversight
from quickly assembling the reland at http://review.skia.org/529748)
Change-Id: Iffd42e4f37c0a585beb6ba0a37d69a92a1759ca6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/529752
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Bug: skia:13219
Change-Id: I57c5c2aa40e6eb85d5e6045d6f3374d0379efd39
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/530337
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
