sk_app has existing support for Dawn on top of Vulkan, and
this adds support to build //example:hello_world_dawn and
get this to run on Linux.
Dawn depends on Tint and abseil-cpp. Tint further depends on
spirv_tools and spirv_headers (for writing to the SPIR-V format).
Dawn and Tint only have GN and CMake support, so we need to make
our Bazel rules for them (see //third_party/BUILD.bazel).
abseil-cpp and the SPIR-V libraries have Bazel support, so we
can just include them (see //WORKSPACE.bazel). It is important
that @spirv_headers be called that exactly because @spirv_tools
depends on it by that name.
The hand-crafted cc_library rules for Dawn and Tint were produced
by reading the appropriate GN files and using the parts necessary
for a supporting Vulkan+Linux. If we use Dawn for other backends
(e.g. WebGPU), we will need to expand the Bazel rules. One day,
we might contribute the Bazel rules to Dawn and Tint so they
can support them and avoid breaking us if new files are added.
Suggested Review Order
- bazel/common_config_settings/BUILD.bazel to see introduction
of new select-able option "has_gpu_backend" which cleans up
some of our code that is enabled for any GPU backend.
- src/*/BUILD.bazel to see has_gpu_backend rolled out.
- WORKSPACE.bazel to see DEPS declared there (using the files
in third_party/externals, which are brought in via
tools/git-sync-deps).
- third_party/BUILD.bazel which adds Dawn and Tint rules.
It may be helpful to look in third_party/externals for
the Dawn [1] and Tint [2] GN files. Especially interesting
are the Python scripts [3] Dawn uses to generate some
header and source files.
- All other files.
[1] https://dawn.googlesource.com/dawn/+/d9f22ce0346b222759d5510be3d1cd93caa5ab86/src/dawn/native/BUILD.gn#183
[2] https://dawn.googlesource.com/tint/+/453d5ae84ec30ab51ac592c13d472412ae8b5fc9/src/tint/BUILD.gn#174
[3] https://dawn.googlesource.com/dawn/+/d9f22ce0346b222759d5510be3d1cd93caa5ab86/generator/dawn_json_generator.py#774
Change-Id: Ied5b162045d8e841b9666457f0158457e2b078d4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/516996
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
PS1 regenerates BUILD.bazel files
I suggest reviewing the deltas between PS1 and the latest
PS to focus on the interesting bits.
The changes here allow for a Vulkan-only build of HelloWorld
based on sk_app. The toughest change was properly fetching
the VisualID after removing the gl calls that used to
fill that in.
There are a few changes that fix resolution of Dawn
header files, but those won't actually be built until
a follow-on CL.
Change-Id: I54fb58b5dd7ecd4313562aed401759b3eaed53c0
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/516999
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
This documents the various factory settings (I kept getting
confused as to what each was doing).
Additionally, this makes setting the factory flag bring in
the dependent code as well (like our current GN rules do).
Change-Id: I93437651b078baac04433c14c573a95982b7bc15
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/493396
Reviewed-by: Ben Wagner <bungeman@google.com>
bazel run //example:hello_world --config=clang
causes a window to open and draws a circle and a square.
Text to follow in a future CL.
To make this work, I had to get rid of musl and use glibc.
All the shared libraries (.so files) that were pre-built
and available for download (e.g. from https://packages.debian.org/bullseye/amd64/libgl1/download)
were compiled against glibc. When I tried to run a
program statically linked with musl and dynamically linked
against things using glibc, I got a segmentation fault
on things like calloc().
Initial attempts to use glibc had failed because it was thought
that the libc.so.6 file could only be referred to by absolute
path (and thus Bazel would not be happy about it). As it turns out,
that was simply a misconfiguration of the builtin_sysroot
parameter to cc_common.create_cc_toolchain_config_info
(see //toolchain/clang_toolchain_config.bzl). By setting that
to `external/clang_linux_amd64` and not
`external/clang_linux_amd64/usr`, the libc binary which had
been extracted to `external/clang_linux_amd64/lib/x86_64-linux-gnu`
was perfectly reachable from
`external/clang_linux_amd64/usr/usr/lib/x86_64-linux-gnu/libc.so`
To bring in the shared libraries to link against (e.g. X11, GL)
I made build_toolchain.bzl easier to modify in that we simply need
to add a debian download url and sha256 hash to a list (rather than
having to plumb this through via arguments).
Recommended Review Order:
- example/BUILD.bazel (not sure if we always want to set bare
link arguments like that or if we want to use "features" to
pass those along to the toolchain).
- tools/sk_app/BUILD.bazel to see initial cc_library for
wrapping sk_app code.
- toolchain/build_toolchain.bzl to see removal of musl and
new list of debs.
- toolchain/clang_toolchain_config.bzl (where use of the
no-canonical-prefixes was key to compilation success).
Notice also that we statically linked libc++ (I did not
have any shared libraries for it locally, so I guessed
a typical developer might not either).
- Rest of toolchain/ for trivial renames.
- bazel/Makefile to see extra docs on those targets and
a new target that compiles all the exes so far for a
quick way to test the build.
- third_party/BUILD.bazel and src/gpu/BUILD.bazel which have
non-generated changes. (all other BUILD.bazel files do).
- go.mod, which needed to update the infra repo version in
order to pick up http://review.skia.org/491736).
Change-Id: I8687bd227353040eca2dffa9465798d8bd395027
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/492117
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
