These changes are necessary to use the toolchain on both the
M1 Mac and Intel Macs.
This adds a way to detect the host platform and choose different
compile options in the toolchain.
We cannot statically link in libc++.a from the clang zip because
it appears to be x64 only.
Finally, this fixes copts not being passed to objective c libraries.
Known issue:
- Intel Mac building has an error about the default CC toolchain.
Change-Id: Ie8e5e83dc41513563ac684e70a8a6947b36df445
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/552472
Reviewed-by: Jorge Betancourt <jmbetancourt@google.com>
unordered_map is much slower than SkTHashMap in practice, and it is
pretty straightforward in this case to replace.
Change-Id: I6d6bea6fa8c5c1ae6d23dfde05552db651975173
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/553016
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
The particles version is used only when we want to demo brand-new
APIs. These demos should be using stuff that has baked in
for a while.
No-Try: true
Change-Id: I3a6cb9d4f384fe43c4acaae32416820f47adb440
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/553018
Auto-Submit: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Chris Mumford <cmumford@google.com>
Commit-Queue: Chris Mumford <cmumford@google.com>
Pointer data is obliterated when we assemble draw passes, so this
feature didn't work for its intended purpose.
Change-Id: I85331aa7b6212c55fe16081937465c2f38e5a103
Bug: skia:13428
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/552718
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This reverts commit fc51827b56.
Reason for revert: Appears to have broken Mac (https://logs.chromium.org/logs/skia/5baefe22efa21e11/+/steps/dm/0/stdout)
Original change's description:
> Add removeUserDefinedSnippet method to ShaderCodeDictionary.
>
> We need to purge out user snippets when they are no longer needed, to
> avoid unbounded memory usage.
>
> Change-Id: Ib33909ec8c94cd6272f1a28e52a7ab92b27dfb0d
> Bug: skia:13405
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/552577
> Reviewed-by: Michael Ludwig <michaelludwig@google.com>
> Auto-Submit: John Stiles <johnstiles@google.com>
> Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Bug: skia:13405
Change-Id: I914eca4f017697fc4c82316b805ebaaa8c72e162
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/552679
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>
Many of these happen to include private headers.
Change-Id: If416de1f30639d797406727dd18f350a85c744bb
Bug: skia:12541, b/237076898
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/552937
Reviewed-by: Joe Gregorio <jcgregorio@google.com>
The default canvas size was so tall that the instructions to
drag an image on the canvas were easily missed because they
are likely scrolled off the bottom of the page. This change
does the following:
1. Reduce canvas size to minimum for the hard-coded image
renderings.
2. Add a dashed gray border so that the user can more easily
identify where to drag the image. If not dragged to the
canvas then a new tab is opened (we don't want this).
3. Tweaked image drag instructions to reference "rectangle"
(the canvas) instead of the page.
Bug: skia:13456
Change-Id: I4f5aeb2653702e1daa80fe30f6c037b98eb585e2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/551766
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Chris Mumford <cmumford@google.com>
Bump CanvasKit version to latest (0.34.1) to fix incompatibilities with
current version of these demos.
The first code incompatibility with the previous CanvasKit (0.25.0)
was introduced in Change-Id I8cf958acf9214d0de903a4097647afd74f2a659e.
Bug: skia:13456
Change-Id: Idc8c9935698743b4478ff61b8c10d8385093527c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/551762
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Chris Mumford <cmumford@google.com>
The demo pages are deployed to https://demos.skia.org/demo (singular),
but locally live in a "demos" directory. The absolute path to the
test image worked, when run locally, but not when deployed.
Switching to a relative path fixes this.
Bug: skia:13456
Change-Id: Ia6b6d0bedacaade4ba6b96f702179910825e871e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/551765
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Chris Mumford <cmumford@google.com>
This is needed so that runtime effects can control the uniforms,
callback function, etc.
Change-Id: I6f0876246d3eabf64b39422db07ca3df9bcd32bc
Bug: skia:13443
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/551764
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
If we are going to create a new snippet ID every time a runtime effect
is created, we will need the code-snippet ID to support values larger
than a byte.
Change-Id: I49304a0bdaaba51fcf997968fb9c2840c5fb68ef
Bug: skia:13405
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/551761
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Change-Id: I69c7ac2e600e3eaa05d5077720cefcaa5d434307
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/551842
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Julia Lavrova <jlavrova@google.com>
We need to purge out user snippets when they are no longer needed, to
avoid unbounded memory usage.
Change-Id: Ib33909ec8c94cd6272f1a28e52a7ab92b27dfb0d
Bug: skia:13405
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/552577
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
6d3c637052..9197635269
2022-06-24 eddiehatfield@google.com Use C++17 attributes instead of custom macros
2022-06-23 cclao@google.com Vulkan: Destroy DescriptorSet cache when it becomes invalid
2022-06-23 b.schade@samsung.com Fix validation checks in glCompressedTexSubImage3D
2022-06-23 kbr@chromium.org Set pixel unpack state in GL backend's CompressedTexImage3D.
2022-06-23 fwang@igalia.com Fix compilation errors with deprecated sprintf function
2022-06-23 lehoangquyen@chromium.org Metal: Fix invalid iosurface texture after base/max lvl changed
2022-06-23 angle-autoroll@skia-public.iam.gserviceaccount.com Roll SwiftShader from 5cb6a639d494 to ec31f547750c (3 revisions)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/angle-skia-autoroll
Please CC ethannicholas@google.com on the revert to ensure that a human
is aware of the problem.
To file a bug in ANGLE: https://bugs.chromium.org/p/angleproject/issues/entry
To file a bug in Skia: https://bugs.chromium.org/p/skia/issues/entry
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md
Cq-Include-Trybots: skia/skia.primary:Build-Debian10-Clang-x86_64-Release-ANGLE;skia/skia.primary:Test-Win10-Clang-AlphaR2-GPU-RadeonR9M470X-x86_64-Debug-All-ANGLE;skia/skia.primary:Test-Win10-Clang-Golo-GPU-QuadroP400-x86_64-Debug-All-ANGLE;skia/skia.primary:Test-Win10-Clang-NUC5i7RYH-GPU-IntelIris6100-x86_64-Debug-All-ANGLE;skia/skia.primary:Test-Win10-Clang-NUC6i5SYK-GPU-IntelIris540-x86_64-Debug-All-ANGLE;skia/skia.primary:Test-Win10-Clang-NUC8i5BEK-GPU-IntelIris655-x86_64-Debug-All-ANGLE;skia/skia.primary:Test-Win10-Clang-NUCD34010WYKH-GPU-IntelHD4400-x86_64-Debug-All-ANGLE
Tbr: ethannicholas@google.com
Test: Test: *CompressedTexture*Test*
Test: Test: *ETC2RGB8_CubeMapValidation*
Test: Test: KHR-GLES32.core.compressed_format.api.invalid_format_array
Test: Test: KHR-GLES32.core.compressed_format.api.invalid_offset_or_size
Change-Id: Ia4e016bceccbcaa2aa9921f53ff3f8d1260db03d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/552797
Bot-Commit: skia-autoroll <skia-autoroll@skia-public.iam.gserviceaccount.com>
Commit-Queue: skia-autoroll <skia-autoroll@skia-public.iam.gserviceaccount.com>
Currently fMSAAResolvesAutomatically would be enabled when the
system supports 'GL_EXT_multisampled_render_to_texture'. While
for d3d11 backend, this path with automatically resolving still
has some bugs[1] need to be fixed. We could make this path fall
back to the default path before that still uses two different
fbos. By doing this, we could guarantee this dmsaa path is usable
for d3d11 backend in the functionality. Besides, some graphics
workloads could be benefited by the dmsaa fast path.
[1] https://bugs.chromium.org/p/angleproject/issues/detail?id=6030
Change-Id: I949024e7c3546f05af4eea45ef7959e9f1078b52
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/545616
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Reviewed-by: Ravi Mistry <rmistry@google.com>
Our implementation currently requires GrGLCaps::fTransferBufferType to
be set to something other than kNone for this to work. We haven't
enabled transfer surface/buffer transfers yet and so are not
setting this value. To do so we'd have to more thoroughly understand
the additional buffer restrictions in WebGL compared to GLES and it
isn't currently a priority.
Bug: skia:13461
Change-Id: I033b9d2c7a3116bdc95bcdbae1e4ac86c9f1b2c8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/551894
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Auto-Submit: Brian Salomon <bsalomon@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
* Changed one static_assert to SkASSERT in RangeSelector.cpp:42
Change-Id: I12815a8817816261bb30f5412432109ed46826fd
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/551892
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Currently, the SkRemoteGlyphCache can't convert an SkTextBlob
to a Slug because it holds minimal glyph information.
For GlyphVector the remote cache has enough information to
serialize the GlyphVector, but not enough to draw it. In this
first step allow GlyphVector to work with either an SkStrike or
a RemoteStrike.
Change-Id: I8c261d84b40a6a69ac0077aaaeed9d318ae72c23
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/551890
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Herb Derby <herb@google.com>
Label temprory offscreen textures for draws. In this CL, we will
label texture for gradient from GrGradientShader which will help
labeling parts of SkImages too.
Bug: chromium:1164111
Change-Id: Iea49598f7632bb2edfaef21a0956771af5833cc1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/550736
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
The big change here is having the C++ toolchain use
Bazel platforms instead of the C++ specific flags/setup.
In Bazel, platforms are a general purpose way to define
things like os, cpu architecture, etc. We were not using
platforms previously, because the best documentation at
the time focused on the old ways.
However, the old ways were clumsy/difficult when trying
to manage cross-compilation, specifically when trying
to have a Mac host trigger a build on our Linux RBE
system targeting a Linux x64 system. Thus, rather than
keep investing in the legacy system, this CL migrates
us to using platforms where possible.
Suggested background reading to better understand this CL:
- https://bazel.build/concepts/platforms-intro
- https://bazel.build/docs/platforms
- https://bazel.build/docs/toolchains#registering-building-toolchains
The hermetic toolchain itself is not changing in this CL
(and likely does not need to), only how we tell Bazel
about it (i.e. registering it) and how Bazel decides
to use it (i.e. resolving toolchains).
Here is my understanding of how platforms and toolchains
interact (supported by some evidence from [1][2])
- Bazel needs to resolve platforms for the Host, Execution,
and Target.
- If not specified via flags, these are the machine from
which Bazel is invoked, aka "@local_config_platform//:host".
- With this CL, the Host could be a Mac laptop, the Execution
platform is our Linux RBE pool, and the Target is "a Linux
system with a x64 CPU"
- To specify the Host, that is, describe to Bazel the
capabilities of the system it is running on, one can
set --host_platform [3] with a label pointing to a platform()
containing the appropriate settings. Tip: have this
platform inherit from @local_config_platform//:host
so it can add to any of the constraint_settings and
constraint_values that Bazel deduces automatically.
- To specify the Target platform(s), that is, the system
on which a final output resides and can execute, one
can set the --platforms flag with a label referencing
a platform().
- Bazel will then choose an execution platform to fulfill
that request. Bazel will look through a list of available
platforms, which can be augmented* with the
--extra_execution_platforms. Platforms specified by this
flag will be considered higher than the default platforms!
- Having selected the appropriate platforms, Bazel now
needs to select a toolchain to actually run the actions
of the appropriate type.
- Bazel looks through the list of available toolchains
and finds one that "matches" the Execution and the Target
platform. This means, the toolchain's exec_compatible_with
is a strict subset of the Execution platform and
the toolchain's target_compatible_with is a strict subset
of the Target platform. To register toolchains* (i.e. add
them to the resolution list), we use --extra_toolchains.
Once Bazel finds a match, it stops looking.
Using --toolchain_resolution_debug=".*" makes Bazel log
how it is resolving these toolchains and what execution
platform it picked.
* We can also register execution platforms and toolchains in
WORKSPACE.bazel [4], but the flags come with higher priority
and that made resolution a bit tricky. Also, when we want
to conditionally add them (e.g. --config=linux_rbe), we
cannot remove them conditionally in the WORKSPACE.bazel file.
The above resolution flow directly necessitated the changes
in this CL.
Example usage of the new configs and platforms:
# Can be run on a x64 Linux host and uses the hermetic toolchain.
bazel build //:skia_public
# Can be run on Mac or Linux and uses the Linux RBE system along
# with the hermetic toolchain to compile a binary for Linux x64.
bazel build //:skia_public --config=linux_rbe --config=for_linux_x64
# Shorthand for above
bazel build //:skia_public --config=for_linux_x64_with_rbe
Notice we don't have to type out --config=clang_linux anymore!
That was due to me reading the Bazel docs more carefully and
realizing we can set options for *all* Bazel build commands.
Current Limitations:
- Targets which require a py_binary (e.g. Dawn's genrules)
will not work on RBE when cross compiling because the
python runtime we download is for the host machine, not
the executor. This means //example:hello_world_dawn does
not work on Mac when cross-compiling via linux_rbe.
- Mac M1 linking not quite working with SkOpts settings.
Probably need to set -target [5]
Suggested Review order:
- toolchain/BUILD.bazel Notice how we do away with
cc_toolchain_suite for toolchain. These have the same
role: giving Bazel the information about where a toolchain
can run. The platforms one is more expressive (IMO), allowing
us to say both where to run the toolchain and what it can
make. In order to more easily force the use of our hermetic
toolchain, but also allow the hermetic toolchain to be used
on RBE, we specify "use_hermetic_toolchain" only on the target,
because the RBE image does not have the hermetic toolchain
on it by default (but can certainly run it).
- bazel/platform/BUILD.bazel to see the custom constraint_setting
and corresponding constraint_value. The names for both of these
are completely arbitrary - they do not need to have any deeper
meaning or relation to any file or Docker image or system or
any other constraints. Think of the constraint_setting as
an Enum and the constraint_value being the one and only member.
We need to pass around a constant value, not a type, so we
need to provide the constraint_value (e.g. in toolchain/BUILD.bazel)
but not a constraint_setting. However we need a
constraint_setting declared so we can make a constraint_value
of that "type".
Notice the platform declared here - it allows us to force
Bazel to use the hermetic toolchain because of the extra
constraint_value.
- .bazelrc I set a few flags that will be on for all
bazel build commands. Importantly, this causes the C++
build logic to use platforms and not the old, bespoke way.
I also found a way to avoid using the local toolchain on
the host, which will hopefully lead to clearer errors
if platforms are mis-specified instead of odd compile
errors because the host toolchain is too old or something.
There are also a few RBE settings tweaked to be a bit
more modern, as well the new shorthands for specifying
target platforms (e.g. for_linux_x64).
- bazel/buildrc where we have to turn off the platforms
logic for emscripten https://github.com/emscripten-core/emsdk/issues/984
- bazel/rbe/BUILD.bazel for a fix in the platform description
that makes it work on Mac.
- Notice that _m1 has been removed from the mac-related toolchain
files because the same toolchain should work on both
architectures.
- All other changes in any order.
[1] https://bazel.build/docs/toolchains#debugging-toolchains
[2] https://bazel.build/docs/toolchains#toolchain-resolution
[3] https://bazel.build/reference/command-line-reference
[4] https://bazel.build/docs/toolchains#registering-building-toolchains
[5] 17dc3f16fc/gn/skia/BUILD.gn (L258-L271)
Change-Id: I515c114099d659639a808f74e47d489a68b7af62
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/549737
Reviewed-by: Erik Rose <erikrose@google.com>
Reviewed-by: Jorge Betancourt <jmbetancourt@google.com>
The anisomips GM appears to snap an image from a surface and samples it.
Because we haven't implemented that yet, validation of that texture
fails, which in turns means we don't insert a Recording into the
Context, and hence that Context has no CommandBuffer.
Added a message when we fail to validate TextureInfo, and pushed the
CommandBuffer submit in GraphiteMetalWindowContext inside the block
that checks to see if we have a Recording.
Change-Id: I74d8886a56ff703f7550bde321a4c3efbac66f30
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/550708
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Refactor the implementation to decouple frame generators
(FrameGenerator: cpu, gpu, picture) from frame consumers (FrameSink:
png, skp, mp4, null).
Add a GPU frame generator using async readbacks. Unlike other
generators, which execute on a thread pool, selecting the GPU generator
forces single-thread execution.
Also add a couple of backend-specific build targets (skottie_tool_cpu,
skottie_tool_gpu) to facilitate binary size experiments.
Change-Id: Id59e230b3861afe5bf9b7ecfc710d672f38eeaaf
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/551237
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Florin Malita <fmalita@google.com>
