PS 1 is re-generating existing BUILD.bazel files
PS 2 is generating BUILD.bazel files for tests/gms
PS 3+ makes modifications to build all of the gms and tests.
It is recommended to view this CL with just a diff between
PS 2 and the end, due to the large amount of generated changes
in PS 1 and 2.
We make a filegroup for the gms and tests because they need
to be compiled as one large blob in order for the registries
to work. Maybe in the future we will break these up, but at least
for WASM/JS, the overhead of starting a browser for each new
test would likely grind things to a halt, so we just group them
all together for now. It's also the most similar to what we
currently do.
In gm/BUILD.bazel and tests/BUILD.bazel, we add a cc_library
that encapsulates all of the deps of the tests, so we can
easily include that the build. These were discovered via
trial and error, not anything automatic or systematic.
The is_skia_dev_build config_setting is very similar to the
GN equivalent from which it was based.
The list of gms and tests to skip (e.g. which are incompatible
with WASM) was determined by building the wasm bundle:
modules/canvaskit$ make bazel_gms_release
tools/run-wasm-gm-tests$ make run_local_debug
# Don't forget to click the button on the screen after the
# browser loads
This way of invoking the tests will be replace soon with
`bazel test <something>`. As such, I didn't bother fully
documenting the current way.
Suggested review order:
- modules/canvaskit/BUILD.bazel taking note that we always
use profiling-funcs to make the stacktraces human readable.
- gm/BUILD.bazel and tests/BUILD.bazel to see the lists of
gms/tests. Notice the tests are roughly partitioned because
we don't support things like vulkan/PDF in the wasm build
and we will want a way to not build certain tests for
certain configurations
- tools/* noting some of the cc_libraries added to make
dependencies easier to add when needed.
- All other files.
Change-Id: I43059cd93c28af1c4c12b93d6ebd9c46a12d381f
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/506256
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
This will hopefully let us pre-package certain binaries (e.g. DM,
fuzz) with more sensible defaults and not make the developer
type out all the settings.
For CanvasKit, which specifies its own build flags, I think I'll
need to make another transition setup, which would go in something
like modules/canvaskit/ck_binary_with_flags.bzl or something.
Some sausage-case-names were converted to snake_case_names as per
go/build-style#target-naming
The example this is based off is worth a look through before
diving into this:
https://github.com/bazelbuild/examples/tree/main/rules/starlark_configurations/cc_binary_selectable_copts
Change-Id: Ia919d47f4d1aa25cf294af7918e36d38838c179e
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/472688
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
These rules can be used to build our GMs on WASM+WebGL and
libskia.a with just the CPU backend (and most other features
turned off).
This can be done with the following commands:
- bazel build //modules/canvaskit:gm-bindings-wasm --gpu_backend=gl_backend --with_gl_standard=webgl_standard
- bazel build :skia-core --config clang
This pivots slightly from http://review.skia.org/463517
by using config_settings [1] instead of platforms for
the optional features that we control. This pivot was
suggested in [2]
We have BUILD.bazel files in many of the subdirectories
that specify filegroups for the appropriate files. In
an effort to make //BUILD.bazel more readable, it is
the responsibility of these subfolders to deal with
conditionally including certain .h or .cpp files.
This is done using select statements and config_settings
or platform constraints as necessary.
For example, src/gpu/BUILD.bazel will different private
filegroups for each of the supported gpu backends [3]
and a more-visible filegroup called "srcs" that has
the right selection of the private files to be used
for compilation.
An effort has been made to avoid using glob() in our
BUILD.bazel files. These file lists were made by using
`ls -1` and some regex to add in quotes. We might want
to make a helper script to assist with that, if necessary.
To specify which options we have, the settings in
//bazel/common_config_settings/BUILD.bazel have been
redesigned. They make use of a macro `string_flag_with_values`
that removes the boilerplate. Patchset 36 shows what the
file looks like w/o the macro.
The top level BUILD.bazel file will still need to use
some logic to handle defines, because local_defines is
a list of strings, not a list of labels [4].
Suggested Review Order:
- WORKSPACE.bazel to see the new dependencies on the
emsdk toolchain and bazel_skylib
- bazel/common_config_settings/* to see the few settings
defined (we have more to define, see BUILD.gn and
//gn/skia.gni for ideas)
- BUILD.bazel to see the "skia-core" cc_library rule.
See also "gms" and "tests"
- modules/canvaskit/BUILD.bazel to see the use of
the emscripten "wasm_cc_binary" rule, which depends
on the "skia-core", "gms", and "tests" rule. Note that
it only builds some of the gms as a proof of concept.
- The other BUILD.bazel files. Some of these are not
platform or feature dependent (e.g. pathops). Others
are (e.g. gpu).
- All other files.
[1] https://docs.bazel.build/versions/4.2.1/skylark/config.html#user-defined-build-settings
[2] https://github.com/emscripten-core/emsdk/pull/920
[3] In this CL, that's just the webgl one.
[4] https://docs.bazel.build/versions/main/be/c-cpp.html#cc_library.local_defines
Change-Id: Ieecf9c106d5e3a6ae97d13d66be06b4b3c207089
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/458637
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
Owners-Override: Kevin Lubick <kjlubick@google.com>
These scripts are useful when testing WebAssembly locally
because the mimetype impacts how the binaries are loaded.
The porting was achieved by doing the following:
python -m lib2to3 -w -n serve.py
Change-Id: I09673fa881339a9b157c5fc993e190766efcd85e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/443884
Reviewed-by: Erik Rose <erikrose@google.com>
There are currently many tests skipped, but many more pass.
This changes the built binary to have a lot of debugging logic
in it so we should be able to get backtraces on those crashes
more easily when debugging.
gmtests.html was removed as it was superceded by run-wasm-gm-tests
and make run_local.
Bug: skia:10812, skia:10869
Change-Id: I72ab34d3db83a654dc8829831b3ecb795fe23d43
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/329170
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Nathaniel Nifong <nifong@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
In this CL, I forked compile.sh and created a new gm_bindings.cpp.
I also moved viewer.html into wasm_tools and created a gmtests.html
for testing out the bindings locally.
Right now there is only one gm file compiled in. I plan in a followup
CL to have some way to generate the list of cpp files that need to
be compiled in from gms.gni. I was unable to get it to work with
simply linking the lib_gm.gni, probably due to the same issue with
Registry that csmartdalton@ ran into when adding viewer.html
and the associated bindings.
Suggested reviewing order:
- gmtests.html to get a sense of how the test flow works.
- gm_bindings.cpp to make sure I setup the contexts/GMs correctly.
- compile_gm.sh to see how the gms are compiled in.
- The remaining files in any order.
When I tested this locally, the bleed_downscale digest was
exactly the same (pixel for pixel, byte for byte) as a known
digest in Gold, so I'm fairly confident in how things work.
Change-Id: I2babef848ca60f7db74e4adf27b8952a66bdeee1
Bug: skia:10812
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/322956
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Adds the command:
make skps_release_and_SIMD
for perfing builds against a set of SKPs in ~/skps for release and
simd builds of CanvasKit. Also outputs a summary of the perf results
in a table format.
See the document "SIMD CanvasKit Build Performance Testing"
for more details:
https://docs.google.com/document/d/114kdSGPMnOSQCZ7pFgd3MGMn5mIW562RMoXVmD13e0M/edit#
Bug: skia:10453
Change-Id: I311629a1420301dda41f7ec57ce1403b05fd949b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/301982
Reviewed-by: Elliot Evans <elliotevans@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
The `experimental_simd` build target builds
CanvasKit using the Emscripten `-msimd128` flag, to build CanvasKit
with SIMD instructions in the compiled WASM. This build of
CanvasKit works in Chrome Canary 86.0.4186.0
with chrome://flags#enable-webassembly-simd enabled.
Also add WebAssembly-specific intrinsics to SkVx.h to enable
support for almost all native SIMD operations in CanvasKit WebAssmebly.
Also add a Skia/modules/canvaskit/wasm_tools/SIMD folder which contains
build_simd_test.sh for testing whether WASM SIMD intrinsics operations
are actually being used by skvx, and for testing correctness of
WASM SIMD operations. Also contains simd_float_test.cpp and
simd_int_test.cpp which serve as documentation for which operations are
correctly turned into WASM SIMD operations by emscripten.
Bug: skia:10453
Change-Id: Icd312b4d189e8d8667d3ffe12a72bfa6febaab2f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/299705
Reviewed-by: Mike Klein <mtklein@google.com>
