Support ESP32 S3 and P4

[navado]

ESP32 is versatile platform with advanced networking and camera support. Popular in hobby and industrial projects.

ESP32 S3 and P4 chips support 128 bit SIMD instructions and seemingly could run facex with good performance.

[bauratynov]

Thanks! ESP32-P4 with PIE SIMD is a great fit. We have four model sizes from 200KB (fits SRAM, 97% LFW) to 1.8MB (99.7% LFW) — same engine, just swap the weights file. The Nano model should run well on P4. Training our own weights this week. If you have a board and want to experiment — PRs welcome!

[bauratynov]

Hey @navado — agreed, ESP32 S3/P4 with the new PIE 128-bit SIMD is a natural target for this stack. The whole surveillance pipeline (decoder + YOLO + FaceX) fits in <2 MB and has no FFmpeg/libav dependency, so flashing to an MCU is the obvious next step.

Current AVX-512 paths are gated behind runtime CPU detection and there's an existing NEON header for ARM, so adding a PIE 128 backend is mostly:

• A new SIMD kernel header (gemm_pie.h, dwconv_pie.h) — same shape as gemm_neon.h
• Tweaking the runtime dispatch to pick it on Xtensa
• Quantizing the recognition models to INT8 (we already have nn2 INT8 paths)

I want to do this on real hardware (not just QEMU). If you have an S3-DevKitC or P4 module on hand and want to co-test, I'm in. Otherwise it's on the roadmap and I'll grab a board this month.

Closing question for you: which inference target matters more for your use case — face recognition only (FaceX nano, ~200K params), or full detect+recognize (YOLOv8n + FaceX)? The first fits very comfortably; the second needs more aggressive INT8 quantization.

[navado]

Unfortunately I don't have real ESP32P4 board here, playing around with hypothetical+agentic approach and focusing on I.MX.. I think I need to close the PR and then to split it to several: M2 is working, then I. MX 95 (debugging) and then the rest when I can test.

[bauratynov]

Sounds good. M2 path is the easiest to land first — you have the hardware, it's already 51/51 passing, and Apple Silicon is a market in itself.

One thought on the split: rather than closing PR #3 and reopening fresh ones, consider keeping it as the umbrella and pushing stack PRs off the same commits — git checkout 7afb4f7 -- <files> into a new branch per target. That way:

• The existing review history on Multi-target ports + unified bench infrastructure #3 stays referenced (your CSV bench schema, the AArch64 NEON foundation, etc. came up there).
• Each new PR has a single landing target and a single rebase surface.
• iMX 95 and ESP32-P4 can sit in draft state with [blocked: hardware] labels until you (or someone) tests on real silicon.

Concrete order I'd suggest:

1. #3a — AArch64 NEON foundation + bench tool (7afb4f7). Unblocks every other ARM target. Mergeable on M2 alone.
2. #3b — Apple Silicon perf paths (f75fd64). Real numbers, opt-in via make ACCELERATE=1. Mergeable.
3. #3c — i.MX NPU lib (6bc5f99). Keep draft until i.MX 95 board is in hand.
4. #3d — ESP32-P4 component (83aeee7). Same — draft until real chip.

If you don't want to babysit four PRs at once, I'm fine just merging #3a + #3b now and revisiting the embedded ones later — your call.

On my side this week:

• Pushed a 100% client-side WebAssembly demo (full pipeline incl. our own face detector trained on WIDER FACE): https://facex-engine.github.io/facex/demo/
• Added 4 trained recognition variants (nano → xs, 200 K to 2 M params) under Apache 2.0
• Ported MiniFASNet anti-spoof into our nn2 engine — 2× faster than ONNX RT

Nano (200 K params, 95.6 % LFW) is the obvious target for ESP32-P4 SRAM. xs (2 M, 99.07 %) fits on i.MX 95 NPU with INT8.

Thanks for pushing this forward.

[navado]

I don't mind merging 3a and 3b

I got ahold of I.MX95 and I.MX8M, but the CPU and GPU part there is nothing special, and bringing NPU part is not that straight forward, going slowly