Repository navigation
Conversation
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/24709
Note: Links to docs will display an error until the docs builds have been completed. ❌ 4 New Failures, 1 Unrelated FailureAs of commit 29ecee2 with merge base 60a8b5f ( NEW FAILURES - The following jobs have failed:
BROKEN TRUNK - The following job failed but were present on the merge base:👉 Rebase onto the `viable/strict` branch to avoid these failures
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
This PR needs a
|
9ca8878 to
1dc802f
Compare
1dc802f to
c9cb5e4
Compare
c9cb5e4 to
bd1e01c
Compare
|
@claude review effort=max |
|
Claude finished @rascani's task in 53m 27s —— View job PR Review: #24709Request Changes: the new Detailed reviewSummaryThis PR packs the generated ESP-IDF component and serves it from a local
It also adds a Cadence-quantized streaming wake word model, checked frame by frame on S3 and C6. Two findings block approval: the workflow Code Quality
Infrastructure
Testing
Backward Compatibility
Specific Comments
RecommendationRequest Changes: fix the |
…lated target A new CI job builds the component the way a project using the published component gets it. It generates and packs the component, adds the archive to a file:// component mirror (.ci/scripts/esp_idf_mirror.py writes the layout the registry serves, and refuses conditional dependencies, which it cannot evaluate the way the registry does), and builds idf_component_consumer, which resolves pytorch/executorch from that mirror at the version just generated and esp-nn from the registry. The builds use a fresh ESP-IDF Python environment that the job checks cannot import executorch, with EXECUTORCH_PYTHON unset, so they take the kernel bundles made beforehand. They build a copy of the project, which keeps the component manager's state out of the source tree, and the source, model, kernel bundle and build paths have a space. On ESP-IDF 6.1 the job builds for ESP32 (run on ESP-IDF's QEMU), ESP32-S3, -C3, -C5, -C6 and -P4 (run on esp-emu); on 6.0.1, a second job, for ESP32-S3 and -C6. It also lints the component's manifest, and checks that the lock file records the mirror's archive. Every build runs the smoke model. The ESP32-S3 and -C6 builds also run the MLPerf Tiny streaming wake word model, quantized with the Cadence quantizer and exported by the new export_wakeword_model.py as a bundled program of 40 consecutive frames, all 40 of which must match the quantized PyTorch model, and the quantized mul on the esp_nn:: op library; the ESP32-S3 build also runs the ESP-NN delegate program, so the delegate and op library are built from the packed archive against the esp-nn the component manager resolves. To run a stateful model, the smoke app now runs all of a bundled program's test cases in order on one loaded method, and split_bundled_program.py can repeat them so single-case models still check a second execute. idf_component_consumer reuses the smoke app's main component, so the two cannot drift apart. setup.sh gains --idf-version and, unless --skip-emulator, installs QEMU when esp32 is a target. The workflow now also runs for changes to what the component vendors (runtime, the portable, quantized and prim op kernels, schema, the buffer data loader and flat_tensor schema, codegen, the Cadence AOT and generic kernels, the flatbuffers submodule and build_variables.bzl) and to version.txt. Authored with Claude Code.
bd1e01c to
29ecee2
Compare
A new CI job builds the component the way a project using the published
component gets it. It generates and packs the component, adds the archive to a
file:// component mirror (.ci/scripts/esp_idf_mirror.py writes the layout the
registry serves, and refuses conditional dependencies, which it cannot
evaluate the way the registry does), and builds idf_component_consumer, which
resolves pytorch/executorch from that mirror at the version just generated and
esp-nn from the registry. The builds use a fresh ESP-IDF Python environment
that the job checks cannot import executorch, with EXECUTORCH_PYTHON unset, so
they take the kernel bundles made beforehand. They build a copy of the project,
which keeps the component manager's state out of the source tree, and the
source, model, kernel bundle and build paths have a space. On ESP-IDF 6.1 the
job builds for ESP32 (run on ESP-IDF's QEMU), ESP32-S3, -C3, -C5, -C6 and -P4
(run on esp-emu); on 6.0.1, a second job, for ESP32-S3 and -C6. It also lints
the component's manifest, and checks that the lock file records the mirror's
archive.
Every build runs the smoke model. The ESP32-S3 and -C6 builds also run the
MLPerf Tiny streaming wake word model, quantized with the Cadence quantizer
and exported by the new export_wakeword_model.py as a bundled program of 40
consecutive frames, all 40 of which must match the quantized PyTorch model,
and the quantized mul on the esp_nn:: op library; the ESP32-S3 build also runs
the ESP-NN delegate program, so the delegate and op library are built from the
packed archive against the esp-nn the component manager resolves. To run a
stateful model, the smoke app now runs all of a bundled program's test cases
in order on one loaded method, and split_bundled_program.py can repeat them so
single-case models still check a second execute. idf_component_consumer reuses
the smoke app's main component, so the two cannot drift apart.
setup.sh gains --idf-version and, unless --skip-emulator, installs QEMU when
esp32 is a target. The workflow now also runs for changes to what the component
vendors (runtime, the portable, quantized and prim op kernels, schema, the
buffer data loader and flat_tensor schema, codegen, the Cadence AOT and generic
kernels, the flatbuffers submodule and build_variables.bzl) and to version.txt.
Authored with Claude Code.