recipes-ml: add ExecuTorch 1.3.1 (+ torchgen-native)#227
Open
jetm wants to merge 4 commits into
Open
Conversation
Contributor
|
Looking good, can you rebase this please |
ExecuTorch 1.3.1's build-time operator codegen (codegen.gen, gen_oplist) imports torchgen for the ATen schema, and its functions.yaml references overloads such as mean.dtype_out that only exist in torch>=2.12.0a0. The packaged python3-pytorch is 2.4.1, whose schema is too old, and building a 2.12 nightly libtorch natively is disproportionate when the codegen needs only the pure-Python torchgen package. Extract torchgen from the torch 2.12.0 CPU wheel (a zip; downloadfilename makes BitBake unpack it) and install just that package for the build host. No libtorch is built. torchgen's only third-party imports are pyyaml and typing-extensions, supplied as native deps by the consuming recipe. Signed-off-by: Javier Tia <javier@peridio.com>
ExecuTorch has no scarthgap recipe in the layer-index. ENG-1969 requires
it as a dogfood target for the yocto-engineer skill.
The recipe targets the minimal portable C++ runtime: all backends (XNNPACK,
CUDA, Vulkan, QNN, OpenVINO, Ethos-U), Python bindings, tests, and devtools
are disabled. The MODULE extension's preset requires DATA_LOADER, FLAT_TENSOR,
and NAMED_DATA_MAP, so all four are enabled together.
Fetch and source layout:
- gitsm fetches the bundled submodules (flatbuffers, flatcc, gflags,
nlohmann-json, cpuinfo, pthreadpool); git://...;submodules=1 silently
fetches nothing and fails do_configure under FETCHCONTENT_FULLY_DISCONNECTED.
- v1.3.1 is on branch release/1.3, not main, or the fetcher rejects the SRCREV.
- destsuffix names the tree `executorch`; the CMakeLists aborts otherwise
(upstream issue 6475), and it doubles as the PYTHONPATH import root.
Build-time codegen runs on the host, never the target:
- flatbuffers-native supplies flatc; the 0001 patch repoints the imported
flatc target at it, since the bundled flatc cross-builds and cannot run.
- torchgen-native (pinned to torch 2.12.0, the version 1.3.1 requires) plus
pyyaml/typing-extensions native supply codegen.gen and gen_oplist. cmake
resolves their `python3` to the build container's interpreter, so PYTHONPATH
carries both the executorch source tree and the native site-packages.
Packaging: ExecuTorch installs libflatccrt_d.a and libextension_evalue_util.a
to an absolute build path; do_install:append relocates them to ${libdir},
drops the leaked tree, and rewrites the exported cmake targets file (which
recorded the same absolute path in IMPORTED_LOCATION) to be install-prefix
relative - otherwise buildpaths QA warns and find_package(ExecuTorch) breaks.
The bundled cpuinfo drops cmake files in ${datadir} and a header in ${libdir},
routed to -dev. The lib*.a ship in -staticdev, which is what
packagegroup-avocado-extra pulls in for feed validation.
The recipe builds clean: zero errors and no recipe-attributable warnings.
Exercise the executorch recipe through the feed-validation suite from the zeromq feed bringup. ExecuTorch ships only static libs and headers (-staticdev), so the case asserts executorch-staticdev installs into the extension and libexecutorch.a lands in its sysroot (SDK tier). There is no runtime shared object to load on a booted device, so boot is no - the boot tier targets runtime libraries like zeromq's libzmq.so. This depends on the feed-validation infra introduced on the zeromq bringup branch. Signed-off-by: Javier Tia <javier@peridio.com>
executorch is an SDK-driven tool for cross-compiling target executables, so its dev artifacts belong in the SDK rather than every shipped device image. Move executorch-staticdev out of packagegroup-avocado-extra (the runtime image) and into the SDK target sysroot (packagegroup-avocado-sdk-extra SDK_SYSROOT_DEPENDS) so SDK users can link the runtime, and drop the unused static libs from the device image. Add nativesdk variants of executorch and torchgen and pull them into the SDK host tools (SDK_TOOLCHAIN_DEPENDS) so the executorch codegen toolchain is present on the SDK host, per the 6/17 SDK-integration decision. Signed-off-by: Javier Tia <javier@peridio.com>
jetm
force-pushed
the
eng-1969-executorch-recipe
branch
from
38d0ccc to
713b37c
Compare
Contributor
Author
|
Hi Justin, done - rebased onto scarthgap. The feed-validation, zeromq, and qemu guest-agent commits had already merged there, so they dropped out as duplicates; what's left is the four executorch-specific commits (torchgen, the recipe, the SDK-tier feed-validation case, and the SDK staging). Verified locally with an avocado-complete build and the feed-validation E2E, both green (3/3). Ready for another pass. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Depends on #223 (feed-validation infra + qemuarm64 default machine). Draft until #223 lands; I will rebase onto
scarthgapand retarget then.What
Adds a scarthgap recipe for ExecuTorch 1.3.1 (PyTorch's portable inference runtime), building the minimal portable CPU runtime (static libs + headers). Wires
executorch-staticdevintopackagegroup-avocado-extraand adds an SDK-tier feed-validation case.New recipes:
recipes-ml/executorch/executorch_1.3.1.bb- portable C++ runtime; all backends (XNNPACK, CUDA, Vulkan, QNN, OpenVINO, Ethos-U), Python bindings, tests, and devtools off.recipes-devtools/torchgen/torchgen_2.12.0.bb- native-only, pure-Python torchgen for the build-time operator codegen (no libtorch build).Build notes (the non-obvious bits)
branch=release/1.3- the v1.3.1 tag is the tip of the release branch, not main; the bundled submodules need the gitsm fetcher (git://...;submodules=1silently fetches nothing).destsuffix=executorch- upstream CMakeLists aborts unless the source tree is named exactlyexecutorch(issue 6475); destsuffix also serves as the PYTHONPATH import root for codegen.0001-use-native-flatc-for-cross-compilation.patch) - executorch builds flatc and runs it at build time; the patch repoints the importedflatctarget atflatbuffers-nativeso it does not cross-build.torch>=2.12.0a0; the codegen's ATen schema must match (the packaged 2.4.1 lacks ops likemean.dtype_out). Pure-Python torchgen extracted from the CPU wheel - no nightly libtorch build.${libdir}, route cpuinfo's cmake/header to-dev, and rewrite the exported cmake targets to be install-prefix-relative (nobuildpathsQA warning, workingfind_package).Validation
bakar bitbake executorch meta-avocado/kas/machine/qemuarm64.ymlbuilds warning-free. Feed-validation SDK tier passes on qemuarm64:executorch-staticdevinstalls into the app extension andlibexecutorch.alands in the ext sysroot. executorch ships only static libs, so the case is SDK-tier only (boot=no).