This CL adds the ability to add child combinations to the top-level
combinations added to the builder.
Bug: skia:12701
Change-Id: Ibe182c631bb9811d82e314ba58823b1708058165
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/542299
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
DSLType is now a simple wrapper around SkSL::Type*. Previously, its type
was determined through a combination of a Type* and a TypeConstant enum,
and fSkSLType == nullptr was used as a sentinel to mean "use the type
constant instead", which meant that we couldn't have a null DSLType
as it would fall back to the type-constant.
We can now return `DSLType(nullptr)` to indicate an error case in type
handling code, instead of needing to wrap the DSLType in an optional<>.
Change-Id: Iebaab86162b526a7fcb93d253367a7e4881ef6d0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/545781
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
DSLType stored an `fPosition` which was only used in one place, when
reporting that a function is not allowed to return a particular type.
Those errors now highlight the type and function name together, which is
not really any worse than before. This allows us to shrink DSLType down
to its minimal form, just a pointer to an SkSL::Type and nothing else.
Change-Id: I4b430cb996472da0ae57bc2ab095cd123d2c3f51
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/546097
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This CL removes the TypeConstant member from DSLType. The constructor
which takes a TypeConstant now sets the `fSkSLType` field immediately
instead of saving the value and deferring lookup until `skslType()` is
called.
This caused some ripple-effect issues in type setup code which were
fixable by replacing nullptr with Poison.
Change-Id: I8fa73cdf5f0bcd3de143c9a25ea43392d75c7dec
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/545780
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
In general, SkSurfaceProps is only needed when rendering text. However,
there are several existing APIs that don't allow SkSurfaceProps to be
passed in by the user.
This change adds new SkSurfaceProps parameters to several public-facing
APIs:
1. SkRasterHandleAllocator::MakeCanvas
-- The props are used by the canvas whenever text is rendered.
2. SkImage::MakeFromPicture and SkImageGenerator::MakeFromPicture
-- The props are used to render any text in the SkPicture object.
Change-Id: Ic48e8a30bb12b3170415c644de1a007b5eefb818
Bug: skia:13369
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/545396
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Organization v3.5, if we are keeping track :)
This splits the "srcs" filegroup into "srcs" and "private_hdrs",
and renames "hdrs" to "public_hdrs".
To assist with the split, I created the macro split_srcs_and_hdrs.
Rather than keep two separate lists of header and source files,
I figured it would be easiest, at least for the common case,
to keep one list of files and then have a for loop split them
apart. I've tried to be consistent with having the list
of files be named with a _FILES suffix - maybe we can use this
as a marker to generate .gni files in the future?
Suggested review order:
- //bazel/macros.bzl. Note this needs a corresponding
G3 change (http://cl/452279799) as well. The exports_files_legacy
change is the better approach to something I manually
handled yesterday when fixing the G3 roll.
- //BUILD.bazel to see the new target skia_internal and
the previous skia_core renamed to skia_public.
- //src/core/BUILD.bazel to see a typical usage of
split_srcs_and_hdrs.
- //include/... to see the change to public_hdrs and
private_hdrs
- //src/... to see many more usages of split_srcs_and_hdrs
- //tools/... to see changes to skia_internal where
appropriate.
- Everything else. Note that //modules/... might also need
to be built with skia_internal instead of skia_public,
but we can fix that up later, if necessary.
Change-Id: Ie1cc969455d97b029b2d77faa222c4a9bad70671
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/545716
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
Currently there is no way to specify the data that is bound to them.
That will come in later changes.
Bug: skia:12720
Change-Id: I3301a825486469396a13a4095b66d9e0b81f183b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/543716
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
The cast of newly-allocated memory to T* is the only thing that triggers
a CFI error; we can let CFI instrument the rest of the code normally.
Change-Id: I0e6ab76dbddf031967bee34f5a05986ff58e6714
Bug: skia:13339
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/545676
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This reverts commit ef7c45a0fa.
Reason for revert: avoiding perf regression
Original change's description:
> Revert "Disable Control-Flow Integrity in SkTArray when casting buffer to T*."
>
> This reverts commit 0b1384de5a.
>
> Reason for revert: visible impact on performance: http://screen/4N7DNCQNSgtzzBohttp://go/crb/1330618
>
> Original change's description:
> > Disable Control-Flow Integrity in SkTArray when casting buffer to T*.
> >
> > We disable Control-Flow Integrity sanitization (go/cfi) when updating
> > the item-array buffer. CFI flags this code as dangerous because we are
> > casting `buffer` to a T* while the buffer's contents might still be
> > uninitialized memory. When T has a vtable, this is especially risky
> > because we could hypothetically access a virtual method on fItemArray
> > and jump to an unpredictable location in memory. Of course, SkTArray
> > won't actually use fItemArray in this way, and we don't want to
> > construct a T before the user requests one. There's no real risk here,
> > so disable CFI when doing these casts.
> >
> > Change-Id: I5708053339f4a600b12c841fcd38880f9932f7d6
> > Bug: skia:13339
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/542643
> > Commit-Queue: Ben Wagner <bungeman@google.com>
> > Auto-Submit: John Stiles <johnstiles@google.com>
> > Reviewed-by: Ben Wagner <bungeman@google.com>
>
> Bug: skia:13339
> Change-Id: I9f39100fc4a03359fa7712b0a8d8cbe3bc7de625
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/545365
> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
> Auto-Submit: John Stiles <johnstiles@google.com>
Bug: skia:13339
Change-Id: I7629cb9045e0c7a804785f8c0ad569610e1c67e1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/545366
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Mostly, this adds placeholder BUILD.bazel files corresponding to files
used in public.bzl
The exception is src/ports/BUILD.bazel, which adds an explicit
link command for dl, needed for dlopen etc.
Bug: skia:12541
Change-Id: Id3801a4c718cec37bc2aa3920a8d810f8a80a373
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/545359
Reviewed-by: Ben Wagner <bungeman@google.com>
This reverts commit 0b1384de5a.
Reason for revert: visible impact on performance: http://screen/4N7DNCQNSgtzzBohttp://go/crb/1330618
Original change's description:
> Disable Control-Flow Integrity in SkTArray when casting buffer to T*.
>
> We disable Control-Flow Integrity sanitization (go/cfi) when updating
> the item-array buffer. CFI flags this code as dangerous because we are
> casting `buffer` to a T* while the buffer's contents might still be
> uninitialized memory. When T has a vtable, this is especially risky
> because we could hypothetically access a virtual method on fItemArray
> and jump to an unpredictable location in memory. Of course, SkTArray
> won't actually use fItemArray in this way, and we don't want to
> construct a T before the user requests one. There's no real risk here,
> so disable CFI when doing these casts.
>
> Change-Id: I5708053339f4a600b12c841fcd38880f9932f7d6
> Bug: skia:13339
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/542643
> Commit-Queue: Ben Wagner <bungeman@google.com>
> Auto-Submit: John Stiles <johnstiles@google.com>
> Reviewed-by: Ben Wagner <bungeman@google.com>
Bug: skia:13339
Change-Id: I9f39100fc4a03359fa7712b0a8d8cbe3bc7de625
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/545365
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Bug: skia:12720
Change-Id: I7f74b4f88456bf5ddef1a648d2231d28034ed246
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/544237
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Pending errors were used to associate C++ file and line numbers with
C++ DSL code. (We would detect errors in expressions before they had
been associated with a Position, and needed to defer saving the error
until a valid Position had been found.)
We no longer try to assign a position to C++ DSL code, so pending
errors do not do anything useful.
Change-Id: I272a73f64e63269120a6f76f4a0153c11d98fb47
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/543018
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Unlike DSLPossibleExpression, this was only used in a few rare places,
so it was much easier to remove.
Change-Id: I483dc061691f89d3e808d5bbc23c500bc57b680a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/542662
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This reverts commit 193c16380f.
Reason for revert: fixed google3 warning
Original change's description:
> Revert "Eliminate DSLPossibleExpression."
>
> This reverts commit f2d000328f.
>
> Reason for revert: breaking google3 roll
>
> Original change's description:
> > Eliminate DSLPossibleExpression.
> >
> > The Possible(Expression|Statement) classes were added at
> > http://review.skia.org/375069. These classes were responsible for
> > capturing `__builtin_FILE()` and `__builtin_LINE()` when an
> > expression or statement was added to a hand-authored DSL program. This
> > allowed errors to be reported on the C++ file/line where they were
> > encountered. This was a good feature to have, when the plan was to
> > author the majority of SkSL code via DSL.
> >
> > Later, IRNode positions were converted from an integer line number to
> > SkSL Positions at http://review.skia.org/518137. This gave us range
> > tracking, but at a high memory cost (16 bytes per IRNode, versus four
> > bytes when we tracked line numbers only).
> >
> > Positions were reduced to 8 bytes at http://review.skia.org/521005 by
> > removing the filename, which was only used for hand-authored DSL. (The
> > size was pared all the way back to 4 bytes at
> > http://review.skia.org/533699 by packing the data more efficiently.)
> >
> > __builtin_FILE/LINE capturing was removed entirely at
> > http://review.skia.org/528366; the filename was discarded anyway and
> > the line number didn't have a range and wasn't very meaningful without
> > a filename. Also, it didn't matter very much since we no longer intended
> > to hand-craft our programs in DSL.
> >
> > At this stage, DSLPossibleExpression stopped adding value and simply
> > served to move Expressions around.
> >
> > Change-Id: I29ac33e08dcc1804cc0619c1e8856ba28ebcc51d
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/542145
> > Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
> > Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
> > Auto-Submit: John Stiles <johnstiles@google.com>
>
> Change-Id: I33badbdcce8760200246bf50e4932d42721ea952
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/543078
> Reviewed-by: Tyler Denniston <tdenniston@google.com>
> Owners-Override: Kevin Lubick <kjlubick@google.com>
> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
> Commit-Queue: Tyler Denniston <tdenniston@google.com>
Change-Id: I71f248b2343806f85cad5f0661470c95334bbe22
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/545236
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This adds targets which test our Dawn, GL, and Vulkan backends.
It follows the hierarchical filegroup pattern, as
outlined in https://skia-review.googlesource.com/c/skia/+/543977
Suggested Review order:
- tools/sk_app/BUILD.bazel. For many things in tools, I anticipate
they will depend on //:skia_core and other //tools targets.
sk_app shows this off, as well how to make the target
specific to a given platform and pull in the proper native code.
I'm trying out setting test_only = True, to see if we can
partition Skia's tests and helpers from the actual Skia library.
- other changes to //tools/, especially looking at sk_app's
dependencies.
- //example/BUILD.bazel. This uses the cc_binary_with_flags which
existed previously [1] to make it so people don't have to
specify all the flags for a given binary and can build it as is.
These targets nows how up in //bazel/Makefile
- //include/... and //src/..., where some typos from previous
CLs were fixed and rules expanded.
- Misc changes to .cpp files to remove unnecessary includes
that were assuming the GL backend was being compiled in.
- All other changes
[1] 162dfca340/bazel/cc_binary_with_flags.bzl
Change-Id: Ieacec464d44368cad0da0890c7dc85a6c0b900c9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/544317
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
The primary goal of this organization structure is to keep
our top level BUILD.bazel file short, with as little logic
as feasible. The logic required to control which files to
include, which third_party deps are needed, what system libraries
should be linked again, etc, should be in the BUILD.bazel
file best should be as close to the affected files as feasible.
In essence, we use filegroup() rules to bubble up the files
needed to build Skia (all as one big cc_library call) and
cc_library rules to bubble up the other components needed to build.
For example, //src/ports/SkFontHost_FreeType.cpp needs FreeType,
but only if we are compiling Skia with that type of font
support. With the new organization structure in this CL,
//src/ports/BUILD.bazel should have the logic that determines
if the cpp file should be included in the build of Skia and
if it is, that the Skia build should depend on //third_party:freetype2
Another example is //src/gpu/ganesh/BUILD.bazel, which
chooses which of the dawn, gl, vulkan, etc backend sources,
and the associated dependencies to include in the build.
It does not specify what those are, but delegates to the
BUILD.bazel files in the subdirectories housing the
backend-specific code.
The structure guidelines for BUILD.bazel files are as follows:
- Have a filegroup() called "hdrs" (for public headers) or
"srcs" (for private headers and all .cpp files) that is
visible to the parent directory. This should list the
files from the containing directory to include in the
build.
See //include/core/BUILD.bazel and //src/effects/BUILD.bazel
as examples.
- filegroup() rules can list a child directory's "hdrs"
or "srcs" in their "srcs" attributes, but should not contain
select statements pertaining to child directory files.
See //include/gpu/BUILD.bazel and //src/gpu/ganesh/BUILD.bazel
as examples.
- May have a cc_library() called "deps". This can specify
dependencies, cc_opts, and linkopts, but not srcs or hdrs. [1]
See //src/codec/BUILD.bazel as an example. These should
be visible to the parent directory.
- "hdrs", "srcs", and "deps" for the primary Skia build
(currently called "skia_core") should bubble up through
//include/BUILD.bazel and //src/BUILD.bazel, one directory
at a time.
This CL demonstrates a very basic build of Skia with many features
turned off (CPU only, no fonts, no codecs). Follow-on CLs will
add to these rules as more targets are supported. See bazel/Makefile
for the builds that work with just this CL.
Suggested Review Order:
- //BUILD.bazel to see the very small skia_core rule which
delegates all the logic down stack. Note that it has a
dependency on //bazel:defines_from_flags which will set
all the defines listed there when compiling all the
.cpp and .h files in skia_core *and* anything that depends
on skia_core, but *not* //src:deps.
- //include/BUILD.bazel and other BUILD.bazel files in the
subdirectories of that folder. Note that the filegroups in
//include/private/... are called "srcs" to be similar to
how Bazel wants "private headers" to be in the "srcs" of
cc_library, cc_binary, etc. and only public headers are
to be in "hdrs" [2].
- //src/BUILD.bazel and other BUILD.bazel files in the
subdirectories of that folder. //src/gpu/ganesh/...
will be filled in for dawn, vulkan, and GL in the next CL.
- //PRESUBMIT.py, which adds a check that runs buildifier [3]
on modified BUILD.bazel files to make sure they stay
consistently formatted.
- //bazel/... to see the new option I added to make sksl
opt-in or opt-out, so one could build Skia with sksl,
but not with a gpu backend.
- Misc .h and .cpp files, whose includes were removed if
unnecessary or #ifdef'd out to make the minimal build
work without GPU or SkSL includes.
- //bazel/Makefile to see the builds that work with this CL.
[1] Setting srcs or hdrs is error-prone at best, because those
files will be compiled with a different set of defines than
the rest of skia_core, because they wouldn't depend on
//bazel:defines_from_flags.
[2] https://bazel.build/reference/be/c-cpp#cc_library.hdrs
[3] https://github.com/bazelbuild/buildtools/releases
Change-Id: I5e0e3ae01ad42d672506d5aad1239f2512188191
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/543977
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
gazelle ended up being more liability than asset for our C++ rules.
It required devs to manually run the command frequently (and was
easy to forget until the CQ failed). The fact that we still had to
edit the source files (e.g. the "srcs" cc_libraries) meant that
the mixture between generated and hand-written caused some
tension (see include/third_party/vulkan for a good example).
The combination of gazelle and our IWYU enforcement added several
bits of churn without any real benefit. The generated rules
also didn't help identify cases where we were not keeping tight
boundaries (e.g. non-gpu code and gpu code).
Identifying third_party deps automatically ended up being trickier
than anticipated (see the deleted //third_party/file_map_for_bazel.json)
Using the "maximum set of dependencies" worked ok, but ended up
increasing build time unnecessarily. For example, compiling
CanvasKit for WebGL always needed to compile Dawn because
SkSLCompiler.cpp sometimes needs to include tint/tint.h.
Follow-up CLs will rebuild the BUILD.bazel rules without gazelle.
Note to Reviewers:
- The only file worth manually reviewing here is bazel/Makefile.
Change-Id: I36d6fc3747487fabaf699690780c95f1f6765770
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/543976
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
We disable Control-Flow Integrity sanitization (go/cfi) when updating
the item-array buffer. CFI flags this code as dangerous because we are
casting `buffer` to a T* while the buffer's contents might still be
uninitialized memory. When T has a vtable, this is especially risky
because we could hypothetically access a virtual method on fItemArray
and jump to an unpredictable location in memory. Of course, SkTArray
won't actually use fItemArray in this way, and we don't want to
construct a T before the user requests one. There's no real risk here,
so disable CFI when doing these casts.
Change-Id: I5708053339f4a600b12c841fcd38880f9932f7d6
Bug: skia:13339
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/542643
Commit-Queue: Ben Wagner <bungeman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Change-Id: I7ef9d50eeb49076dbd71fd7070a0f849085c4dc7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/543978
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
In PDF there are two different physical encodings of strings (as a
sequence of bytes). There is the literal string encoding which is
delimited by '(' and ') which stores the bytes as-is except for '(',
')', and the escape character '\' (which can introduce octal encoded
bytes). There is also the hex string encoding delimited by '<' and '>'
and the bytes are encoded in hex pairs (with an implicit '0' at the end
for odd length encodings).
The interpretation of these bytes depends on the logical string type of
the dictionary key. There is a base abstract (well, almost abstract
except for legacy purposes) string type. The subtypes of the string type
are `text string`, `ASCII string`, and `byte string`. The `text string`
is logically further subtyped into `PDFDocEncoded string` and `UTF-16BE
with BOM`. In theory any of these logical string types may have its
encoded bytes written out in either of the two physical string
encodings.
In practice for Skia this means there are two types of string to keep
track of, since `ASCII string` and `byte string` can be treated the
same (in this change they are both treated as `byte string`). If the
type is `text string` then the bytes Skia has are interpreted as UTF-8
and may be converted to `UTF-16BE with BOM` or used directly as
`PDFDocEncoded string` if that is valid. If the type is `byte string`
then the bytes Skia has may not be converted and must be written as-is.
This means that when Skia sets a dictionary key to a string value it
must, at the very least, remember if the key's type was `text string`.
This change replaces all `String` methods with `ByteString` and
`TextString` methods and updates all the callers to the correct one
based on the key being written.
With the string handling corrected, the `/ActualText` string is now
emitted with this new common code as well for better output and to
reduce code duplication. A few no longer used public APIs involving
these strings are removed. The documentation for the URI annotation is
updated to reflect reality.
This change outputs `UTF-16BE with BOM` with the hex string encoding
only and does not attempt to fix the literal string encoding which
always escapes bytes > 0x7F. These changes may be attempted in a
separate change.
Bug: chromium:1323159
Change-Id: I00bdd5c90ad1ff2edfb74a9de41424c4eeac5ccb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/543084
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Also cleans up the scattered references remaining in the code base
(including in files I thought I got already...).
Change-Id: I7004354b1e9cea9f9d9f45b791d8ab9ce557ba01
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/542647
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Also makes SDFMaskFilter available.
Bug: skia:13118
Change-Id: I27ca3ed85a057267387841be5dad10d8e6c7f7bf
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/543079
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Remove the need for the Slug/Blob at SubRun creation. This needed
to combine the SkGlyphRunPainterInterface for Slug and Blob.
Change-Id: I8ba1db4590a5db26d1542d025e5414a2625ad88f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/543082
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Herb Derby <herb@google.com>
SK_SUPPORT_GPU needed to be set to 1, and SK_GRAPHITE_ENABLED should
be checked to see if it's defined, not its value.
Change-Id: Ib762c590ceaa570ec98a76558657bbcee672c254
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/543080
Reviewed-by: Greg Daniel <egdaniel@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
This is cleanup left over from a prior CL's review. We will want to
use the combination builder outside of graphite.
This CL is mainly just moving stuff around except for the addition
of the SkCombinationBuilder.buildCombinations method and CreateKey
more accessible outside of Graphite.
Bug: skia:12701
Change-Id: If2cae6fcff5670e488bc14473b7b1d2f9b1fecd7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/543196
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This also adds support for making a Resources unbudgeted state when it
is pulled out of the cache to be used for an SkImage or Surface. It
then puts the resources back as budgeted when returned to the cache.
Bug: skia:12754
Change-Id: I469ace602aa6f5f708b82655e94557ff8ad45a72
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/538046
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Adds a saturated_add function that was on SkNx and used in
SkXfermode_opts, but hadn't been ported to skvx yet.
Removes the Sk4px_opts variants and simplifies some of its functions;
many were already defined skvx.
The largest change is that Sk4px does not extend skvx::byte16, since it
used to extend Sk16b. Now it just has a vector as a data type. This
was necessary so that we could define operators that were typed for
Sk4px and Wide w/o conflicting with the free operators that were
defined for the base skvx types.
Change-Id: I8c667ba86f662ccf07ad85aa32e78abfc0a8c7ae
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/542645
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
This reverts commit f2d000328f.
Reason for revert: breaking google3 roll
Original change's description:
> Eliminate DSLPossibleExpression.
>
> The Possible(Expression|Statement) classes were added at
> http://review.skia.org/375069. These classes were responsible for
> capturing `__builtin_FILE()` and `__builtin_LINE()` when an
> expression or statement was added to a hand-authored DSL program. This
> allowed errors to be reported on the C++ file/line where they were
> encountered. This was a good feature to have, when the plan was to
> author the majority of SkSL code via DSL.
>
> Later, IRNode positions were converted from an integer line number to
> SkSL Positions at http://review.skia.org/518137. This gave us range
> tracking, but at a high memory cost (16 bytes per IRNode, versus four
> bytes when we tracked line numbers only).
>
> Positions were reduced to 8 bytes at http://review.skia.org/521005 by
> removing the filename, which was only used for hand-authored DSL. (The
> size was pared all the way back to 4 bytes at
> http://review.skia.org/533699 by packing the data more efficiently.)
>
> __builtin_FILE/LINE capturing was removed entirely at
> http://review.skia.org/528366; the filename was discarded anyway and
> the line number didn't have a range and wasn't very meaningful without
> a filename. Also, it didn't matter very much since we no longer intended
> to hand-craft our programs in DSL.
>
> At this stage, DSLPossibleExpression stopped adding value and simply
> served to move Expressions around.
>
> Change-Id: I29ac33e08dcc1804cc0619c1e8856ba28ebcc51d
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/542145
> Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
> Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
> Auto-Submit: John Stiles <johnstiles@google.com>
Change-Id: I33badbdcce8760200246bf50e4932d42721ea952
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/543078
Reviewed-by: Tyler Denniston <tdenniston@google.com>
Owners-Override: Kevin Lubick <kjlubick@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Tyler Denniston <tdenniston@google.com>
Change-Id: I1a5490f546a3cb046c64b114a30be991d2d9f2cc
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/541064
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
The Possible(Expression|Statement) classes were added at
http://review.skia.org/375069. These classes were responsible for
capturing `__builtin_FILE()` and `__builtin_LINE()` when an
expression or statement was added to a hand-authored DSL program. This
allowed errors to be reported on the C++ file/line where they were
encountered. This was a good feature to have, when the plan was to
author the majority of SkSL code via DSL.
Later, IRNode positions were converted from an integer line number to
SkSL Positions at http://review.skia.org/518137. This gave us range
tracking, but at a high memory cost (16 bytes per IRNode, versus four
bytes when we tracked line numbers only).
Positions were reduced to 8 bytes at http://review.skia.org/521005 by
removing the filename, which was only used for hand-authored DSL. (The
size was pared all the way back to 4 bytes at
http://review.skia.org/533699 by packing the data more efficiently.)
__builtin_FILE/LINE capturing was removed entirely at
http://review.skia.org/528366; the filename was discarded anyway and
the line number didn't have a range and wasn't very meaningful without
a filename. Also, it didn't matter very much since we no longer intended
to hand-craft our programs in DSL.
At this stage, DSLPossibleExpression stopped adding value and simply
served to move Expressions around.
Change-Id: I29ac33e08dcc1804cc0619c1e8856ba28ebcc51d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/542145
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Bug: skia:13118
Change-Id: Id4afcfeeb9a5b44a0e2cb24b70c76a81ec5daaea
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/542300
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
The ShaderType enum seems like it will persist while the ShaderCombo will not.
Bug: skia:12701
Change-Id: Idf9ed89a50bac46b93a81da3e814207c83b3a1ea
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/541723
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Removes specializations for all() on AVX2 and SSE 4.1, which give the
wrong results if the ints didn't have all bits set (inconsistent with
other platforms and non-SIMD). Added a unit test that checks this case.
The mirror specializations for any() on AVX2 and SSE 4.1 are actually
valid, so added those, and added a 2 instruction specialization for
SSE for any() and all(). This is what clang-trunk produces on -O3, but
ToT clang struggles to vectorize it.
Also adds specializations for NEON for any() and all(), since even
clang-trunk was struggling to vectorize it automatically. In
particular, this will help skgpu::graphite::Rect's implementations of
intersect and contains, which use any/all to get a final boolean value.
In the Instruments app, I had see Rect's intersection as a hotspot
on the Mac M1, and this vectorization helps a bit.
Also takes the opportunity to remove fake C++14 constexpr for a
real constexpr.
Change-Id: Ib142e305ae5615056a777424e379b6da82d44f0c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/542296
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Bug: skia:13329
Change-Id: I9992cd5149e50f9a998af712984a82e5d952d58b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/541936
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
The only usage of `virtual` was the `storage()` method. This value is
now stored in a member variable. It is packed next to a bool so it
should be ~zero extra space, versus 8 bytes for a vtable pointer. We
also save cost of a virtual dtor call every time a DSLVar goes away.
Because VariableStorage is not a public type, this required shuffling
some constructors around to live in the cpp instead of the header.
Change-Id: I9fdefc3696d123848fb567029c051b478349cec7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/542139
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Change-Id: I511f6105537b24953de1533ad7b73d1186afd4fc
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/541060
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Also fix various compile issues if you try to compile w/o SkSL.
Change-Id: I9a5a176254184a04f4c8af93a8dca958c8c69fee
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/542142
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
It can live in the base class instead of having matching implementations
in each subclass. Also, there didn't seem to be a reason to have a
templated and non-templated version which did the same thing.
Change-Id: I312af9e71561d847580430000fbfae6fa99fe837
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/542140
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
The DSLVar class hierarchy had many constructor variations to support
the idea of creating DSL variables without explicitly assigning a name
to them. Instead, name-mangling would automatically assign them a name
like `_123_var`. This was designed to make it easlier to write a
complete shader in DSL.
We no longer have DSL name-mangling, or intend to create complete
programs in pure DSL. In the absence of name-mangling, these
constructors aren't useful (every variable would be named `var`).
They have been removed.
Change-Id: If533e479cc04c5a6ced9a7e880dcc56063f29374
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/542138
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
I believe this was only needed during the sprint, before we had
RenderSteps.
Bug: skia:12701
Change-Id: I4945fc69f9c1cd419b8c3143b6638e4769761ff9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/541976
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
This also makes the PaintCombinations object opaque to the user.
The eventual goal is to have all the bits of the combination allocated
in the builder's arena.
Bug: skia:12701
Change-Id: I9de8ab1fb6a340cee84c2bd437ddd9b0aa3ed6ea
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/541222
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This was only used by DSL fragment processors and is unreferenced.
This removal causes the uniform-handle value in DSLVarBase to become
unreferenced as well.
Change-Id: Ifc89a3dda93f08c40341f654981bbb6593d4fb9f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/541745
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This reverts commit 4b354dfb5b.
Reason for revert: not responsible for chromium:1326848
Original change's description:
> Revert "Remove operator= from DSL expression types."
>
> This reverts commit b143520625.
>
> Reason for revert: might have caused chromium:1326848
>
> Original change's description:
> > Remove operator= from DSL expression types.
> >
> > This means that in raw DSL code, `foo = bar` will need to be written as
> > `foo.assign(bar)`. This is admittedly slightly less convenient. However,
> > in practice, raw DSL code is very rare, and in fact we only had one
> > use-case for operator= across all of our code. This change will allow us
> > to simplify the DSL parser by eliminating the `DSLWrapper` helper class,
> > which was only needed because we overloaded `operator=`.
> >
> > Change-Id: I4fbc39b2c1443fc26a761d424c52e3b9b59169eb
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/541062
> > Commit-Queue: John Stiles <johnstiles@google.com>
> > Auto-Submit: John Stiles <johnstiles@google.com>
> > Reviewed-by: Brian Osman <brianosman@google.com>
>
> Change-Id: I7c7e032c465aba004ba78fd69650c8037e019861
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/541737
> Auto-Submit: John Stiles <johnstiles@google.com>
> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Change-Id: I0814f87e360b5574d4a06764bbfa747c49820774
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/542136
Commit-Queue: John Stiles <johnstiles@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Move allocation of Caps::fShaderCaps to the base class,
and add a finishInitialization method, like GrCaps.
Change-Id: I5353a03afea29390be3cce1fb371374532f5af3c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/541073
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
The DSLVarBase `fDeclared` field was used to track whether a variable
was created with `Var`, but never declared with a matching `Declare`, in
a hand-authored DSL program. This was expected to be a common source of
slip-ups in hand-authored DSL, so we tracked it and printed a handy
error message if `Declare` was ever missing. However, this complicated
testing, because in tiny test snippets we _do_ want the ability to
create variables without necessarily declaring them. So, we had a
separate program setting to disable enforcement for test code.
For programs created in DSLParser, tracking this state is unnecessary;
the parser won't ever forget to declare variables.
Since hand-authored DSL programs are no longer expected to be
commonplace, we can remove the state tracking and the associated
ProgramSettings field entirely.
Change-Id: I32b28f8a2ca6591d3da80cd974fff8101f5a4be8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/541638
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
