RuyiAI Weekly Report (2026-10-19 ~ 2026-10-23)

Reporting period: Monday, October 19, 2026 through Friday, October 23, 2026 — 5 working days.

Sources: 5 issues of this publication’s daily RuyiAI update reports (2026-10-19 to 2026-10-23; each issue covers the window from 04:30 the previous day to 04:30 the current day, with Monday covering the past 3 days including the weekend); plus a 168-hour repository audit of three organizations — RuyiAI-Stack, ruyisdk, and buddy-compiler — a supplementary audit of key repositories in openRuyi-Project, dual-source verification against the RuyiSDK developer community and the openRuyi distribution news page, and three-page snapshots of the official RuyiAI homepage (audit coverage extends to the morning of 10-24).

Editorial note: Three main threads ran in parallel this week. First, the main openRuyi repository completed an overall pivot to “packaging by dependency” across 637 commits, progressing from filling in the Rust crate closure, to adding Python cloud storage backends, to removing vendoring from Go, and on to completing source checksums and %autochangelog specification compliance. Second, whole-branch replays of the two riscv branches — PyTorch and LLVM — converged from “scheduled as needed” to “daily”; the set of patch titles is unchanged, while commit hashes expire daily. Third, the compiler, simulator, and operator layers of the RISC-V matrix extensions (AME and Ztt) all landed this week simultaneously, forming a minimal closed loop that “compiles, executes, and produces correct results.” Beyond the daily-report material, the weekly report adds seven newly discovered audit findings, all falling on the daytime of 10-23 (after the daily-report window) or at period boundaries, listed in the appendix.

I. Weekly Highlights

openRuyi lands 637 commits in five days, packaging strategy shifts wholesale to “package by dependency”: By calendar day, 10-19 through 10-23 saw 221, 137, 51, 109, and 119 commits respectively, dominated by Leetfs (333) and Jingwiw (152). The progression is clearly traceable—10-19 alone had 211 Rust-related commits (roughly 200 new packages) and advanced the network storage stack (dpdk 26.07, spdk 26.09, liburing 2.15, btrfs-progs 7.1, nvme-cli 3.1); 10-20 filled out the full fsspec cloud storage backend family with a symmetric structure of 42 commits each for Rust/Go/Python; 10-21 through 10-22 landed the de-vendoring rework of minio (merged 10-20), sonobuoy, and umoci (merged 10-21) on main, and added the import paths required after vendor removal, while a similar proposal for picoclaw is still queued; from 10-22 the work shifted to spec completion, with Jingwiw sweeping 54 packages in one pass to add source checksums and switch to %autochangelog. Sources: openRuyi commit list, PR #1459 minio de-vendor, PR #1466 umoci
Whole-branch replays of two riscv branches settle into daily operations: PyTorch replays five mornings running, LLVM breaks eight days of silence with three consecutive rebases: The PyTorch riscv branch was rewritten five days straight from 10-18 to 10-22, with heads at 8b254cfd, 44826095, 7f49d33f, 3c1ea315, and 29259d90, each time uniformly rewriting committer timestamps across the branch; the LLVM riscv branch, silent for eight days since 10-13, rebased three times in a row on 10-21, 10-22, and 10-23, with heads at dd05e5b5, 58d62a47, and 7c77126b. Both lines share the same trait: the set of patch titles is unchanged commit by commit and no local work is lost, at the cost of invalidating any downstream reference by commit hash every day. In the same period PyTorch saw its first PR merge in nearly five weeks (#51 riscv64 local image, merged 10-17), while seven open PRs only refreshed timestamps all week with no new review comments. Sources: PyTorch riscv branch, LLVM riscv branch, PR #51
Ztt matrix extension lands for the first time on the AME branch of ruyisdk/llvm-project (10-23 17:15), completing the matrix extension chain together with the AME trio: On the last workday of the week, the AME branch landed “[RISCV] Add initial Ztt matrix extension support based on spec v0.6”, its second commit after the AME CI workflow merged on 10-19. Together with the AME patch series on the RuyiAI-side LLVM branch (extension and backend path design #16, #24, #27; instruction updates #29; IME builtin lowering and A100 HP/SP scheduling #30, #31, #32), QEMU’s ame-0.6 branch, and the AME-operator operator library, the matrix extension is now complete across all three layers: compilation, simulation, and operators. The common gap across all three is real-world measurement: the compiler-side performance model is calibrated to A100 instructions, QEMU only guarantees semantic correctness, and the operator library is validated on simulation or existing hardware—no layer provides real-silicon throughput data. Sources: Ztt v0.6 commit 29fefa0f, AME CI PR #170, qemu ame-0.6, AME-operator
QEMU completes full instruction simulation for P extension v0.6, with GCC and LLVM aligned in step: The p-dev branch of ruyisdk/qemu (based on upstream v11.1.0) landed a 12-commit wrap-up batch at 10-21 16:35, all focused on packed SIMD—Q-format multiply and multiply-add, pure multiply, multiply-accumulate, two-way and four-way multiply-add/subtract, horizontal reduction, load-copy, pack/merge/leading count, RV32-only instructions—plus removal of P’s dependency on Zbkb to align with the new spec and additions to tests/tcg/riscv. The toolchain side aligned in the same period: GCC updated P extension support to version 0.6, and LLVM merged intrinsics in batches including mulq, multiply high accumulate, sati/usati, Packed Pair, and packed multiply. The P extension has thus reached the second half of “full simulator coverage, generatable by both compilers,” with the gap on the application-side benchmark. Sources: qemu p-dev, Biweekly Report No. 079
Biweekly Report No. 079 finalized, six sections completed: Between 10-22 09:26 and 14:20, ruyisdk/wechat-articles landed ten patches in a row (mainly #383 through #391), writing up all sections on GCC, LLVM, V8, OpenJDK, Go, QEMU, plus the package manager and IDE. The technical content centers on four areas: LLVM lists twelve patches, nine merged, including RVA23.1 and RVB23.1 profile ratification, GlobalISel handling f16 truncation with Zfhmin, and LLT reloads for unaligned scalar memory access; V8 merged four, covering riscv64 binary-search sign extension and Liftoff constant tracking; Go proposed six mainline CLs, with two riscv64 sha256/sha512 hardware acceleration (zvknha/zvknhb) CLs merged; OpenJDK merged twelve and completed a preliminary RISC-V port of JEP 544 (AOT static compilation). Three sections remain blank: the opening remarks, version testing and open issues, and the website and documentation. Source: Issue 079 file
IREE clears the first precision tier of RVV matrix multiply-add in two days: v3.13.0, released 10-19, brought the RISC-V V f32 vfmacc.vf inner_tiled MMA into the official release (PR #24933); on 10-21 main landed the f16 version (PR #25000, 946 lines changed, over 800 lines of tests), selecting encodings in three tiers by extension availability—vfmacc.vf with +zvfh, widened vfwmacc.vf for f16×f16→f32, and degrading to widening to f32 and truncating back with only +zvfhmin. The performance direction reported: on X60 (VLEN=256) single-threaded inner_tiled is already faster than the mmt4d ukernel, while large shapes at 4 and 8 threads remain slower, with the remaining gap in tiling and threading (tracking issue #24932). Sources: IREE v3.13.0, PR #25000
Kernel and firmware lines stir back to life at week’s end (10-23): linux-xuantie-kernel landed “riscv: Migrate T-Head extensions to the vendor extension framework” at 10-23 11:23, migrating the previously renamed XUANTIE vendor extension keys wholesale into the kernel’s vendor extension framework and ending seven consecutive days of silence since 10-16; the same day ruyi-imager added “Add SpacemiT K3 UFS and UEFI provisioning support” at 10:30, and support-matrix added three RT-Thread basic test reports for the RDC2022-D1s at 10:47. All three lines had been idle all week, with effort going entirely into openRuyi’s userspace packages; this weekend batch pulls focus back to the platform and board side. Sources: kernel commit 92c3f534, ruyi-imager commit 732a9214, support-matrix

Summit concludes, community output released in force: retrospective post gives seven live demos and a set of reproducible acceleration figures: The 6th RISC-V China Summit was held in Shenzhen from 10-18 to 10-20, and the forum published a retrospective post at 10-22 11:31 with scale figures—over 3,600 on-site professional attendees, 10 team members present, two technical talks, six technical posters, and an independent D15 booth. Hard numbers from the posters include a package manager metadata index of 328+ packages and 265+ system images covering 41 development boards, published to PyPI and integrated into the RevyOS and Bianbu repositories; the course rebuild totals 821 videos and 1.441 million views. The most convincing of the seven demos is the OpenCV RVV acceleration comparison: on the same hardware platform, the ruyi-installed version achieves 3–8× speedup over the distribution’s bundled OpenCV on operators such as image filtering and feature extraction. The next day the forum also added the lecture notes for “RISC-V Linux Practice Course 02

Just Enough C Fundamentals”. Sources: Summit retrospective #2893, Practice Course 02 #2894

II. RuyiAI Stack Progress (PyTorch / Triton / TileLang RISC-V Adaptation)

Window Overview: Activity in the RuyiAI-Stack organization (18 repos) this week centered on pytorch (a full branch rewrite each of five mornings), llvm-project (three consecutive rebases after eight days of silence), triton-riscv (nightly builds resumed for one cycle, then stalled), ruyiai-daily (seven consecutive issues), and the site repo (routine daily refresh of contributor data); tilelang-riscv, harness, FBGEMM, IntrinTrans, VecIntrinBench, cpuinfo, torq-tile, caffe, mxnet, and dsh-osc had no commits during the window.

PyTorch fork: five consecutive morning branch replays, first pause on 10-23

The riscv branch’s operational cadence is now fixed: a full branch rewrite around 03:00 daily, with heads in sequence 8b254cfd (10-18), 44826095 (10-19), 7f49d33f (10-20), 3c1ea315 (10-21), 29259d90 (10-22). Each rewrite is characterized by uniformly rewritten committer timestamps and unchanged local patch titles line by line; only the sync range of the upstream baseline changes. The 10-21 rewrite versus the prior head showed 67 ahead, 24 behind, and 208 file differences; the 10-22 rewrite showed 60 ahead, 24 behind, and 106 file differences. All differences fell in upstream (MPS operators, Metal kernels, CI workflows, and pr_review scripts); no local patch files appeared in the diff lists.

The local patch series is stable at four groups: riscv64 local image (#51), bytes_to_scalar floating-point fix (#44), inductor opinfo blocklist (#50), and ULP tolerance scoping for linear cross entropy (#42), plus the CI series (#20 core/full split, #21 CI workflow fix, #40 continue parsing after Jenkins failure, #41 verdict bypass). No new merges this week: the first merge in nearly five weeks was PR #51 “Add riscv64 image locally,” landed via squash at 00:04 on 10-17, adding .ci/docker/build-riscv64-local.sh and adjusting build and image scripts, which appeared in the Monday daily’s three-day window.

Worth noting separately is the break in cadence: no new rewrite appeared on the morning of 10-23, and as of the 10-24 morning check the head remained at 10-22’s 29259d90. This is the first gap since the current “daily baseline” cadence began; whether it signals a shift from daily to as-needed requires confirmation next cycle. Seven open PRs (#23 Enable XNNPACK, #35 for testing, #36 timeout relaxation, #38 temporary DataLoader disable, #43 patch slimming, #46 ATen RVV support, #48 RVV CPU capability) remained open all week, with timestamps refreshed in the same batch on each replay and no new review comments; #46 and #48 remain the two main proposals for advancing RVV capability. Sources: riscv branch, PR #51, PR #46, PR #48

Compiler fork (llvm-project): eight days of silence end, then three rebases in a row

The riscv branch had no pushes for eight consecutive days from 10-13 to 10-20, with the head at 0fb2da86 (#31 A100 HP/SP and pack/unpack lowering plus scheduling calibration). At 23:00 on 10-21 the first full branch rewrite in eight days appeared, with the head becoming dd05e5b5 as SyncBots advanced the upstream integration to LLVM b3b5e33; versus the old head this was 1769 ahead, 26 behind, and 300 file differences—a concentrated digestion of eight days of upstream backlog. Two more rewrites followed on consecutive days: 58d62a47 at 23:00 on 10-22 (275 ahead, 26 behind, still 300 files), then 7c77126b at 23:00 on 10-23.

The difference in span across the three rebases illustrates the mechanism: the first day digested the backlog, the latter two were routine catch-up on single-day increments. The branch has entered a state of “advancing the baseline a small step each day,” converging on the same operational pattern as PyTorch. The patch series is fully preserved and unchanged in order, from the BOSC AME extension (#16) to A100 HP/SP and pack/unpack scheduling (#31, #32), including the Buckyball vendor extension (#20), alignment with the Pebble core ISA (#23), the xtame design update (#27), and IME builtin lowering (#30). The two FPGA backend PRs (#25 BOSCAME FPGA, #28 xboscame FPGA) had their timestamps refreshed in the same batch after each rebase and remained open all week with no review progress. Sources: riscv branch, PR #25, PR #28

triton-riscv: nightly builds stall after one resumed cycle; PR #85 remains the only active proposal

PR #87 “Support LLVM 24 and pin Buddy MLIR v0.1.0” was merged at 22:41 on 10-17, and the next day at 08:57 the automated version-tracking PR #88 bumped it to the buddy-mlir nightly v0.1.1.dev20261017; at 10:01 on 10-19 the nightly build nightly/20261018-a305fb6 was produced—the first new build in seven trading days since 10-12’s 20261011-fe554ff—providing six wheels across CPython 3.12/3.13/3.14 and both x86_64 and riscv64 architectures.

Thereafter there were no commits and no new releases all week. The cause is upstream supply: buddy-mlir has had no new nightly since 10-17, leaving triton-riscv with no new upstream to track, and the two sides are waiting on each other. Open PR #85 “softmax and matmul optimization” was last updated at 07:55 on 10-19 and remains the only currently active operator optimization proposal; the other open PRs (#83, #82, #58, #56, #55, #54) last saw activity in mid-to-late September. Sources: Nightly 2026-10-18-a305fb6, PR #85, PR #87

tilelang-riscv: silent all week after five commits on 10-16

This repo landed five commits in a burst between 15:56 and 18:52 on 10-16 (codegen format specification, support for upstream operator runtime semantics, TileOps runtime adaptation upgrade, new Buddy MLIR release CI, and building the Python extension in that CI), after which there were no new commits for seven consecutive days from 10-17 to 10-23. Open PR #4 “Add RVV vector mask and max reduction lowering” has been stalled since 09-28, and PR #2 since 06-16. The repo remains in a lull where “CI and runtime scaffolding are in place, operator coverage still to be filled,” and this week brought no new evidence to change that assessment. Among the five commits, “support for upstream operator runtime semantics” is worth tracking: it fills in lane-local state across serialization stages, safe ragged copy, dynamic control flow, and FP8/FP4 conversion fixes—prerequisites for operator coverage rather than the operators themselves. Sources: tilelang-riscv commit list, PR #4

Technical intelligence and site: ruyiai-daily publishes seven consecutive issues; site sees only routine refreshes

The technical intelligence repo ruyiai-daily published seven consecutive issues this week (10-18 to 10-24, between 06:16 and 07:16 daily), maintaining the five-section structure of PyTorch ecosystem, LLVM-MLIR, Triton and TileLang, RISC-V, and AI industry. RISC-V items covered this week include: the RISC-V multiplication runtime libcall proposal, the Sail RISC-V 0.16 release, the Zvabd encoding update in Unified DB, the linux-riscv execute-only page permission patch, the KVM IMSIC lock design, RoPE emulation for XiangShan AME, two proposals on kernel read-only mapping (PAGE_KERNEL_RO) and syscall return values, the SyterKit C907/E907 boot path update, and review comments on the SpacemiT K3 PCIe patch v7.

Self-test data for triton-riscv under the LLVM 24 plus Buddy MLIR 0.1.0 combination is also recorded by that repo: 618 check-buddy tests passed, 290 triton-shared tests passed, 9 expected failures; of the 3829 items covered locally by FlagGems, 10 native crashes remain, and some examples require a native RVV environment. The original notes that these are all the author’s local results and cannot be used to infer full-model compatibility on the RISC-V side.

The site repo ruyiai-stack.github.io had nine commits this week, eight of which were routine daily refreshes of contributor data (chore: update contributors.json [skip ci]), and the other the 10-17 contributor guide update (PR #80), with no content changes. Sources: ruyiai-daily, site repo PR #80

III. RuyiSDK Toolchain and Distributions (Package Manager, Distributions, Compilers and Kernel)

openRuyi main repo: 637 commits in a single week, shifting from “filling dependency closures” to “specification completion”

Counted by calendar day, the openRuyi main repo had 221, 137, 51, 109, and 119 commits from 10-19 to 10-23, totaling 637 over five days (another 6 commits in the early hours of 10-24 are not counted in this period). By author: Leetfs 333, Jingwiw 152, KimmyXYC 36, cl2t 29, HNO3Miracle 28, misaka00251 21, purofle 19, plus several others with a dozen or so each. All commits carry the SPECS: prefix, i.e. distribution packaging definitions; none involve architecture-specific backports.

The evolution falls into three phases. The first is the 221 commits on 10-19, of which 211 are Rust-related (about 200 new packages), covering cryptography (botan 0.10, twofold, x25519-dalek 2, pkcs1 0.7, secrecy 0.10), serialization (toml 0.6/0.18/0.19, yaml-rust2), compression (brotli 7, alloc-stdlib), regex (regex 1.13.1 plus automata/syntax), and data structures and terminal text processing; the same day advanced the network storage stack — dpdk 26.07 (including backports of RISC-V lpm and fib lookup improvements), spdk 26.09, liburing 2.15, iproute2 7.2.0, btrfs-progs 7.1, nvme-cli 3.1; at 20:49 two crates with direct RISC-V utility were added: rust-riscv-decode 0.2 (instruction decoding) and rust-panic-halt 1 (bare-metal panic halt).

The second phase is the three-language parallel work from 10-20 to 10-22. The 137 commits on 10-20 show a symmetric structure of 42 each for Rust/Go/Python: on the Python side, 28 land on fsspec and various cloud-vendor backends (s3fs, gcsfs, adlfs, ocifs, dropboxdrivefs, smbprotocol, cloudpathlib) and their accompanying auth dependencies (azure-identity, msal, google-cloud-storage, google-auth-oauthlib, proto-plus, crc32c, etc.); on the Go side, mainly wrapping up minio de-vendoring plus Prometheus/Kubernetes components; on the Rust side, concentrated on the windows-0.61 family, the zerocopy/rkyv family, and the cap-std/io-lifetimes family, together with the same day’s python-uv-build, pointing to the dependency closure of the uv build backend. The 51 commits on 10-21 continue this direction: the Go side adds the k8s trio plus import paths for moby-sys and smarty-assertions, turning sonobuoy, umoci, and go-mtree into genuine “build without vendored dependencies”; the Rust side adds 23 rust-uv-* packages and bumps python-uv-build to 0.13.4.

The third phase is the normalization from 10-22 to 10-23. Of the 81 commits, Jingwiw accounts for 54 alone, all of the same kind: “Add source checksums and use %autochangelog”, covering alphabetically by package name the range from luksmeta to xmltoman; such changes add source checksums to specs and switch changelogs to generation via %autochangelog, without changing any package’s version or behavior. The remaining 27 are substantive upgrades, with the security batch the most concentrated: go 1.27.3, php 8.5.12, nss 3.131.1, ca-certificates-mozilla 2.92, rustup 1.29.2, python-pip 26.2.2, nodejs 24.22.1, python 3.14.9, python-pillow 13.0.0, nginx 1.31.8. From 22:47 on 10-23 to 00:54 on 10-24 another batch of Go packages was added (go-gopkg-gorp.v1, go-github-ziutek-mymysql, go-github-denisenkom-go-mssqldb, the go-github-gobuffalo-* series, etc.). Sources: commit list, PR #1361 kubecomps dependencies, PR #1486 python-uv-build

openRuyi PRs: about 37 merged over three days, large CVE PR split and resubmitted

Per the daily records, ten were merged on 10-20, five on 10-21, and 22 on 10-22. The ten on 10-20, in order, were #1128 (Prometheus 3.13 modules), #1342 (CVE Part 1), #1461 (graphql-core 3.3.0), #1355 (first batch of kubecomps Go dependencies), #1462 (buildx), #1344 (fsspec CVE), #1459 (minio de-vendoring), #1372 (moniker), #1463 (dropwatch), #1458 (uwsgi). Among the five on 10-21, #1464 sonobuoy and #1466 umoci are the landing of de-vendoring, plus #1361, #1136, and #1486 python-uv-build 0.13.4 (58 files, +5640/-201).

CVE handling is the item that best illustrates this week’s process change: #1341 “CVE Vulnerability Fixes (Part 0)” was closed with 50 files, +997/-4788 but not merged, and the same day #1468 and #1469 were opened as continuations, indicating the original large PR was split and resubmitted; the #1344 fsspec CVE fix was merged separately. The 22 merges on 10-22 essentially cleared the queue of nineteen security updates under review, with four openjdk versions landing in two batches (first 27.0.1.0.2.1, 25.0.5.8, 21.0.13.9, 17.0.21.9, then 17 and 21 tagged [security-fixes]). As of the morning of 10-23, the open queue still held 77 items.

Worth tracking in the queue is a group of proposals pointing the same way: qemu enabling GUI test features (#1421), adding virglrenderer (#1415), adding fwupd to ovmf (#1436), adding ydotool (#1457), fixing a man page conflict in xorriso (#1489), and a WIP cross riscv64 toolchain (#1490, targeting direct production of a riscv64 toolchain on an x86 host). The five span virtualization, graphics virtualization, firmware updates, input automation, and optical image tooling, together pointing to “running a full desktop on RISC-V with automated validation”. Sources: PR #1341, PR #1415 virglrenderer, PR #1490 cross toolchain

ruyi package manager: 0.53.0 held all week, 0.54.0 slated for end of October

Both GitHub Releases and PyPI remain at 0.53.0 (released 09-24), the main branch’s last commit is stuck at 09-25 (merging #503), and there were no new versions or commits all week; the latest pre-release on GitHub is still 0.54.0-alpha.20260918 from 09-18, with no alpha since for a month.

Issue 079 gave the direct reason for the slowdown: most members of the development and testing teams were in Shenzhen last week attending the RISC-V China Summit. Due to a release-cycle adjustment, 0.54.0 is expected to be officially released at the end of October, and the three in-progress items are unchanged — ABI compatibility detection between packages and the current system, macOS packaging for more officially maintained packages, and toolchain adaptation for SpacemiT K1/K3. The issue also gave a software source maintenance commitment: the content of ruyi update is compatible with the last three official versions. With about a week left in the month, the things to watch are whether an alpha comes out first, and whether the K1/K3 adaptation ships as a toolchain package or as preset configuration. Sources: ruyi Releases, PyPI ruyi, Issue 079 package manager section

packages-index: ISCAS source sync issue, no package updates all week

The repo’s last commit is still 10-13 (adding ubuntu-old-releases mirrors, fixing the ubuntu version for SiFive Unmatched), with zero commits all week. Issue 079 explained the silence: for the past two weeks the ISCAS software source has had data synchronization problems, and packages that had already been built could not be refreshed to the public network, so there are no package updates for now.

This explains the combined phenomenon this week of “no new package manager version, no new packages in the index” — not a development halt, but a blocked release channel. The direct impact on users is that installing packages via ruyi still shows the old set; this is a server-side issue and nothing needs to be checked locally. Sources: packages-index, Issue 079 resource update section

Distributions and images: 2026.09 still latest, ruyi-imager completes four K3 supply-side changes

The openRuyi distribution news page had no new articles all week; the 2026.09 release announcement (09-30) remains the latest, and the 2026.10 page is not yet online. On a monthly cadence, the October version has entered its end-of-month window, while the main repo is still bulk-adding packages; the release timing is the next thing to watch.

ruyi-imager had ten commits this week in three phases: three on 10-21 signed by Glavo, consolidating Gradle dependency versions into a shared version catalog, upgrading dependencies and bundled tools to stable maintained versions, and bumping TOMLJ to 2.2.0 with simplified parsing; three on 10-22 improving interaction (moving activity progress to a fixed status bar and separating update errors, aligning settings controls and condensing update feedback, offering the download action directly at the image selection step, PR #12); four on 10-23 turning to capability and engineering (aligning CLI output with the console charset while keeping JSON as UTF-8, adding UFS and UEFI provisioning support for SpacemiT K3, preserving all image target associations in the directory and GUI, and parsing repository messages only once when loading by directory).

Follow-through on the nightly build channel was also clarified: the package built at 22:15 on 10-19 was not immediately rebuilt after the three pushes on 10-21; it was packaged at 21:31 on 10-21 and only completed at 05:38 on 10-22, a lag of about seven hours, indicating automated builds are still triggering but with delay. Sources: ruyi-imager commit list, nightly build channel, openRuyi news page

Technical items in biweekly issue 079: GCC / LLVM / V8 / Go, four tracks

GCC, three items: rebasing Zvdota/Zvbdota support and fixing issues found during the rebase (patches sent to patchwork), adding Md support for the Ztt extension, and updating P extension support to version 0.6. Of LLVM’s twelve, nine are merged, in four groups: RVA23.1 and RVB23.1 profiles promoted (#234064), GlobalISel handling f16 truncation with Zfhmin plus half-precision legalization (#231370), LLT overloading of unaligned scalar loads/stores letting memcpy expand with wider instructions (#232183), and P extension mulq/multiply-high accumulate/sati·usati/Packed Pair and packed multiply intrinsics (#232316, #232340, #233769, #232202, #232612), plus an RV64 constraint fix for __builtin_riscv_rev16_64; two are still under review, an InstCombine improvement inferring addend ranges from sum ranges (#231357) and generating and selecting vector library calls with TableGen to fix RISC-V SLEEF selection (#231739).

V8 merged four: on riscv64 the binary-search switch input is always sign-extended, Sandbox trusted pointer table entries are tagged, Liftoff tracks f32 and 32-bit f64 constants (porting an upstream commit), and the interpreter entry trampoline gains a maximum parameter count check. Go proposed six mainline CLs; the two for riscv64 sha256 and sha512 zvknha/zvknhb hardware acceleration are merged, and the rest are removing redundant MOVDnop, optimizing bit tests with register shift values, Zfa assembly support, and riscv_hwprobe going through vDSO. On base C libraries, glibc ported sinh, sinhf, sinpi into the existing libmvec framework, and newlib ported acosf, logf, asinf, asinhf, asinpif, atanf into the vector math framework. Sources: Issue 079 file, GCC P 0.6 commit 883d7da2, RVA23.1 PR #234064

Compiler and emulator branches: AME branch lands Ztt v0.6, QEMU branches wrap up

The AME branch of ruyisdk/llvm-project had only two commits this week: at 13:32 on 10-19 it merged PR #170 “Add AME CI”, adding a 45-line .github/workflows/ruyi-riscv.yml that builds LLVM with RISC-V support on the AME branch and runs targeted compiler, codegen, assembly, and semantic tests; at 17:15 on 10-23 (after the daily report window) it landed initial support for the Ztt matrix extension spec v0.6, the AME branch’s first integration of the Ztt instruction family. Previously the branch’s validation relied on manual work; from this week regression testing is in GitHub Actions.

On the QEMU side, two branches wrapped up in parallel: the P extension v0.6 wrap-up batch on p-dev (12 commits, 10-21 16:35) and the DAMO AME v0.6 implementation on ame-0.6 (visible commits up to 10-16, assembled into this issue this week). The official description of ame-0.6 is completion of major feature development and architectural refactoring, supporting 32/64-bit user mode and system mode, covering matrix computation, mixed integer and floating-point operations, data movement and type conversion, and supporting a multi-core shared backend, state migration, and debugging; the commits visible in the branch are the landing of the Ztt instruction family — decodetree decoding, instruction-family helpers, GDB state exposure, experimental CPU configuration exposure, disas support, and four groups of tests for numeric/tensor operations, control and shared backend, memory and debugger integration, and configuration and migration. Both lines are based on the same upstream v11.1.0, with the same goal: turning not-yet-production extensions into a runnable software baseline. Sources: AME CI PR #170, Ztt v0.6 commit 29fefa0f, qemu p-dev, qemu ame-0.6

Kernel and firmware lines: seven days of silence broken by vendor extension framework migration

linux-xuantie-kernel (linux-6.6.36 branch) had no commits in the first four days of this week, its last commit stuck at the 10-16 cpufeature and hwprobe batch — adding Ziccamoa, Ziccif, Ziccrse, Za64rs, and Zicclsm to cpufeature and hwprobe, and carving out an ID range for private extensions in hwcap, aligned with upstream numbering. At 11:23 on 10-23 a commit “riscv: Migrate T-Head extensions to the vendor extension framework” landed, migrating the previously renamed XUANTIE vendor extension keys wholesale into the kernel’s vendor extension framework, following the 10-15 key-name unification and the 10-16 ID alignment, so that the naming, exposure, and registration paths of XuanTie private extensions are unified under upstream rules.

The firmware line remained silent all week: the latest ruyifirmware release is still “Ruyi Firmware 20261015” from 10-15, and edk2-ruyi’s last commit is stuck at the K3 system information page on 10-15; both lines have had no activity for more than seven consecutive days. The openRuyi homepage repo had one content commit at 21:35 on 10-22 (adding an experimental tag to the docs and adjusting the tag description), consistent with the main repo marking some packages as experimental, indicating the distribution is turning “experimental” from an internal convention into a publicly visible classification. Sources: kernel commit 92c3f534, cpufeature commit 8fd30253, ruyifirmware Releases, homepage repo

Support matrix: two reports for Duo S dual-system and RDC2022-D1s

support-matrix had five commits this week: two on 10-16 adding Zephyr and RT-Thread Smart test reports for Milk-V Duo S; three at 10:47 on 10-23 adding RT-Thread basic test reports for RDC2022-D1s (Allwinner D1s), including the initial commit and two rounds of review revisions. The direction of covering low-end RISC-V boards with RT-Thread and Zephyr continues; the RDC2022-D1s RT-Thread Smart 5.0.0 factory firmware report was already assembled into issue 079. Source: support-matrix commit list

IV. Vector Extensions and Operator Optimization (VecIntrinBench / IntrinTrans / FBGEMM)

This stack’s vector repos: silent all week, latest activity stuck between February and July

VecIntrinBench last stopped at 02-13, IntrinTrans at 06-25, the FBGEMM fork at 07-13, cpuinfo at 05-20, torq-tile at 04-09, and harness at 10-10; none of the six repos had a commit all week. The upstream verification line was equally quiet: riscv-arch-test’s latest commit stopped at 09-08 (ACT 4.1 release notes and workflow fixes), and the main XiangShan repo also had no in-window commits within this topic’s scope (its 10-19 to 10-20 CoupledL2 changes are covered in the next item).

All substantive progress on the vector side this week came from outside this stack: the RVV MMA precision step in upstream IREE (next item), three merges in RISC-V architecture tests, and a preprint on restructuring FlashAttention for long vectors. Our assessment of this stack is unchanged—the vector benchmark side has produced no new data for several consecutive months, and operator-side activity is concentrated in the two compiler frontends triton-riscv and tilelang-riscv, neither of which had new commits this week.

IREE: RVV matrix multiply-accumulate climbs one precision step in two days; single-thread already beats the mmt4d ukernel

v3.13.0 was released on 10-19, adding an inner_tiled MMA for RISC-V V f32 vfmacc.vf in the CPU backend (PR #24933), while also changing LLVMCPU scalable vectorization to require --iree-llvmcpu-vscale-range, taking the larger of the two lower bounds when the +zvl*b feature is present. On 10-21 main landed the f16 version (PR #25000): it reuses the same lowerRiscvVFmaccLike and the hoisted accumulator legalization, sets Tile N to vlen/8, and selects the encoding in three tiers by extension availability—f16 times f16 to f16 with +zvfh uses vfmacc.vf; f16 times f16 to f32 uses the widening vfwmacc.vf; with only +zvfhmin, the two paths respectively go “extf accumulator to f32, f32 vfmacc, truncf back” and “extf both panels, then f32 vfmacc”. At VLEN=256 the cost model gives intrinsics_m of 14, 7, and 6 respectively.

The performance conclusion is only directional: on X60 (VLEN=256), single-threaded inner_tiled is already faster than the mmt4d ukernel under both native f16 and vfwmacc encodings, while large shapes at 4 and 8 threads remain slower (tracking item #24932). On the same day, PR #24849 aligned the scalable-vector dispatch tile to base * vscaleMax, a routine legalization on the VLA path—the block size must be divisible by an integer multiple of the hardware’s actual VLEN, otherwise tail-block degradation occurs on narrow-VLEN hardware. Within the 10-22 window IREE had no RISC-V-specific commits, only integrating upstream LLVM to a new baseline and tightening register validation in its own bytecode VM. Sources: IREE v3.13.0, PR #25000, PR #24933, PR #24932, PR #24849

Verification and caches: three merges in riscv-arch-test; XiangShan CoupledL2 splits banks by set index

RISC-V architecture tests merged three changes on 10-19 to 10-20: Sdtrig coverage points for A-extension triggers and icount coverage across Sm/S/U modes; adding S_F/S_V/S_VF to the S suite, covering the privilege levels operating systems actually use; and extending vector instruction coverage to all valid SEWs plus completing SEW=8 vrgatherei16 and fault-only-first LMUL selection. Together the three push the verification surface toward “S mode + all SEWs”, a usable regression baseline for teams running RVV operators on K1/K3.

On the XiangShan side, CoupledL2 splits the directory and data SRAM banks by set index, restricts MCP2 stalls to consecutive accesses within the same bank, and pauses acceptance of new prefetches when RequestBuffer occupies 2 slots (PR #36, merged 10-19; the default bank split value is 2 and can be reverted to 1); the main repo subsequently updated the XSCache pointer to incorporate the change (PR #6738). Cache parallelism and prefetch admission are adjusted together—a verifiable microarchitectural change. Sources: riscv-arch-test PR #2413, PR #2791, PR #2858, XSCache PR #36, XiangShan PR #6738

Paper: restructuring FlashAttention on long-vector processors yields 1.84x to 2.08x measured speedup

arXiv 2610.29489v1, “Reorienting the Vector Axis: Restructuring FlashAttention for Long-Vector Processors” (Emmanuel Irabor, Marc Casas), ports PyTorch’s CPU FlashAttention kernel to a RISC-V CPU with 2KB vector registers, starting with a blunt baseline: only 16.2% of peak floating-point throughput.

The cause analysis is specific: the original kernel advances row by row over query rows, vectorizing the multiply with V along the 64-element head dimension; softmax’s per-row maximum and sum are reductions that “collapse an entire register into a scalar”, and the polynomial coefficients of the software exponential function also compete with tile data for vector registers, causing spills to the stack—the three together keep vector register utilization low. Neither fix changes the algorithm or numerics: first, transpose the score tile together with the running output so queries fall on a linearly contiguous axis, so that the single parameter “how many queries fit in a tile” uniformly determines the vector length of every kernel section, and the two reductions naturally disappear; second, move the polynomial coefficients into scalar registers, eliminating spills and cutting softmax’s vector memory instructions by 78.7%.

Measured: at head dimension 64, the two together bring whole-kernel cycles down to a 1.84x to 2.08x speedup, raising floating-point utilization from 16.2% to 29.7%; an FPGA of the same design ranks the two changes consistently and gains more, reaching 2.71x. The significance for this stack is methodological rather than numerical: vector-length adaptation and register pressure are precisely the structural problems triton-riscv and tilelang-riscv face in RVV lowering, not “whether intrinsics exist”; the paper’s “match queries per tile to the machine” and IREE’s setting Tile N to vlen/8 are the same class of decision and can be compared directly on equal terms. Source: arXiv 2610.29489

Kernel and boot-path intelligence: read-only mapping proposal, C907/E907 boot state, K3 PCIe patch v7

Four items on the technical intelligence side are worth recording this week. First, a PAGE_KERNEL_RO definition proposal on linux-riscv notes that when RISC-V lacks this definition it falls back to writable PAGE_KERNEL, leaving mappings that should be read-only—such as HugeTLB vmemmap—with write permission; the proposal provides a QEMU virt reproduction and a before/after page-table comparison. Second, the syscall restart path needs to check the full return value, fixing a return-value truncation issue. Third, SyterKit sets the mstatus vector state to initial in the C907 image, making the boot state consistent with the RVV code compiled into the image; E907 instead sets up the system mapping before enabling caches. Fourth, SpacemiT’s K3 PCIe patch v7 received new review comments questioning the use of the PHY bulk API to control all PHYs of multiple ports at once, noting that each port has an independent PHY and PERST#, so the resource modeling needs to be re-argued. Sources: ruyiai-daily 10-19 issue, PAGE_KERNEL_RO proposal, K3 PCIe patch v7

V. Buddy Compiler Updates (buddy-mlir Commits and Releases)

0.1.0 to 0.1.1: Two Releases in Two Days, Both Changes Aimed at Deliverability

buddy-mlir released 0.1.0 on 10-16 at 00:53 and 0.1.1 on 10-18 at 06:26, roughly two days apart. 0.1.1 contains only two commits over 0.1.0, touching 24 files with about +896/-54 lines: first, #989 “buddy-server adds RISC-V server cross-compilation,” which adds a riscv64 cross-compilation path for buddy-server, introduces a handle implementation for the runtime dependency manifest (RaxDependenciesHandle, including unit tests and a test plugin), a stub implementation of plugin discovery with transcription tests, a slimmed-down buddy-cli (a net reduction of 40 lines), and updated RVV environment documentation; second, #925 “add publish-models workflow,” which adds a GitHub Actions release pipeline and a Hugging Face model publishing script (about 313 lines), enabling model artifacts to be pushed and released directly from CI. Together, the two commits address both ends: “the server can run on RISC-V machines” and “model artifacts can leave CI.” They also explain why a release was possible just two days later—the main content had already been frozen in 0.1.0.

The timeline only makes sense when viewed as a whole: 0.0.11 was released on 09-26, nearly three weeks before 0.1.0; 0.1.0 to 0.1.1 took only two days. After the major version jump, the project shifted to small, rapid steps, with nightly builds continuing to serve as daily build verification. Sources: BUDDY MLIR 0.1.1, 0.1.0 to 0.1.1 diff, PR #989, PR #925

Release Line Stalls: A Full Week of Zero Commits, Zero Nightly Builds, Downstream Pinned a Week Back

After 10-18, buddy-mlir’s main branch saw no new commits; the last was #925 on 10-16 at 09:35. Within the window there were 0 commits and 0 releases. Nightly builds stopped for two days after nightly/v0.1.1.dev20261017 (07:24) on 10-17, then produced nothing for the entire week (10-19 to 10-23), five trading days in a row—the first long gap since the 0.1.1 release.

The pending PR queue also saw no updates within the window; the latest three all date to 10-17 to 10-18: #994 “align buddy-server interface with llama-server” (10-18 02:41), #993 “add tile.upsample_nearest operator and recognition pattern” (10-17 08:04), and #992 “fix BN channel broadcasting” (10-17 02:04). Separately, #928 “measure PyTorch coverage and validate 106 operators at the CPU tier” has been open since 09-16 and serves as the baseline proposal for operator coverage criteria.

Downstream Pinning: triton-riscv Nightly Builds Locked to 0.1.1.dev20261017

The last commit on triton-riscv’s main branch is PR #88 on 10-18 at 08:57, which pins the downstream dependency to buddy-mlir’s 10-17 nightly nightly/v0.1.1.dev20261017; the nightly/20261018-a305fb6 released on 10-19 was built on this upgrade. Since buddy-mlir has had no new nightly builds since 10-17, triton-riscv’s nightly builds have no new upstream to follow, leaving the two sides waiting on each other—restoring daily output on this chain depends on when buddy-mlir restarts its nightly workflow.

The groundwork from two weeks earlier should also be noted: the batch of RISC-V usability changes from 10-13 to 10-16 (fixing the Makefile’s RISC-V target #986, adding board cross-compilation for buddy-cli #987, simplifying the cross-compilation process #975, adding RISC-V server cross-compilation for buddy-server #989, and installing the riscv64 build of torch via the Ruyi package index in the manylinux riscv64 build while adding libsndfile), as well as the post-0.1.1 phase goal of bringing end-to-end validation such as “running the Qwen3-VL-30B-A3B decoder on K3” into the regular process. This week’s pause looks more like an intermission after a phase wrapped up than a change in direction. Sources: buddy-mlir commit list, Releases, PR #987, PR #986

VI. Community, Events, and Official Website

The 6th RISC-V China Summit: D15 Booth and Seven Live Demos

The summit was held from 10-18 to 10-20 at the Shenzhen Convention & Exhibition Center (Futian), running for three days. RuyiSDK’s presence consisted of two technical talks, six technical posters, and an independent D15 exhibition area, with 10 team members on site and over 3,600 professional attendees.

The two talks were “RISC-V Course Porting Methods and RuyiSDK Ecosystem Development” (Luo Yunxiang) and “Mastering the RISC-V Vector Extension: Go Language RVV Optimization in Practice” (Meng Zhuo, Zhu Junxian). The former proposed three main threads—”open the door, pave the road, teach the people”—with the approach of running simulation visualization on the host or in the cloud while pushing drivers and inference down to the board; the latter focused on the engineering problems of connecting managed language runtimes to RVV, including vector length adaptation, assembly stubs, and inline optimization.

The six posters concentrated their information in numbers: the package manager’s metadata index contains over 328 software packages and over 265 system images, covering 41 development boards, has been published to PyPI, and is integrated into the RevyOS and Bianbu repositories; there were also RuyiTuner (genetic algorithm search for compiler optimization sequences), AI-driven IDE graphical testing, using Sail plus Pydrofoil to connect to XiangShan difftest (about 800 lines of adaptation layer replacing NEMU), the Sail-RISCV-WASM toolchain running in browser WebWorkers, and the RISC-V course restructuring (821 videos, 1.441 million plays, 26,000 followers).

The most convincing of the seven live demos was the OpenCV RVV acceleration comparison: on the same hardware platform, comparing the ruyi-installed version against the distribution’s bundled OpenCV, operators such as image filtering and feature extraction achieved 3 to 8 times speedup. This data point turns “how much benefit the vector library layer can bring” from an estimate into a reproducible on-site measurement—and it is the only performance number with a control group among all this week’s materials. There was also the “CoreMotion Challenge,” using the RuyiSDK IDE combined with CyberCAM and the K230 onboard KPU for gesture recognition interaction, where 4 developers established cooperation communication channels on site. Source: Summit recap post #2893

Biweekly Report and Forum: Issue 079 Finalized, Summit Recap and Practice Course 02 Added

The forum had only two new topics this week, both on 10-22: the summit recap post at 11:31 (#2893) and “RISC-V Linux Practice Course 02

Sufficient C Language Basics [Handout]” at 20:58 (#2894). The latter is a minimal C language subset for embedded scenarios, covering types and variables, control flow, pointers, arrays, structures, storage duration, strings, and bit operations, with a running example of fan control and temperature reading, and points out common pitfalls such as “integer division truncates toward zero” and “use const to make constants’ meaning explicit”; together with the environment and toolchain handout from Episode 01, this course now has two consecutive self-study installments.

Biweekly reports Issue 078 (10-13) and Issue 079 (10-22) form this week’s regular output line. Issue 079’s three empty sections (preface, version testing and outstanding issues, official website and documentation) are consistent with Issue 078, indicating that the finalization of the editorial pipeline is still completed on the last day. During checks from 10-23 to the morning of 10-24, there were no new topics on the forum, with the latest still being the two posts from 10-22. Sources: Latest forum topics, Practice Course 02 #2894, Issue 079 file

Official Website: Three Pages Unchanged All Week (2 Blog Posts, 23 Documentation Chapters)

The three pages of the official website www.ruyiai.org showed no changes across five snapshots throughout the week: index.html at 7246 bytes with 3 index entries; blog.html at 5632 bytes with 2 indexed posts (“Triton’s RISC-V Adaptation” and “PyTorch RISC-V CI Practice”); docs.html at 10843 bytes with 23 indexed chapters; the sha256 checksums of all three pages remained unchanged. There were no new blog posts and no new documentation chapters this week, with both the blog and documentation lines still stalled at previous output.

This is the third consecutive reporting cycle with no official website updates. Compared with Issue 079’s note that “the team attended the summit in Shenzhen last week, slowing this issue’s pace,” the silence on the official website and documentation shares the same cause as the delayed package manager release—manpower concentrated on the conference period and distribution packaging. What to watch: whether slides, demo plans, and documentation chapters are added after the conference. Sources: RuyiAI official website, Blog page, Documentation page

External News and Industry Side: Targeted Queries Return Zero Hits, V100 and E908A Come into View

Google News targeted queries in Chinese and English for RuyiSDK, RuyiAI, and openRuyi continued to return zero hits this week, while the bare query channel worked normally (the same batch of RISC-V queries returned dozens of results each time), indicating that there is genuinely no media coverage on the content side rather than a collection failure. The openRuyi distribution news page had no new articles, with the 2026.09 announcement still the latest. On the arXiv side, one directly relevant preprint was added this week (long-vector FlashAttention restructuring, see Chapter IV).

There were two industry-side items related to platform form. On 10-19, SpacemiT released the server-class RISC-V processor V100 at the summit: a 46-core hybrid architecture (6 XiangShan Kunminghu V2R2 cores accelerating 40 X100 cores), up to 2.4GHz, dual-socket coherent interconnect up to 92 cores, a single chip with 8-channel DDR5-4800 and 52 PCIe 5.0 lanes, paired with three types of complete machines—C2201 compute, G5201 intelligent compute, and S5236 storage; reports say it passed all BRS specification tests and supports direct installation of distributions including openEuler, openRuyi, openKylin, Debian, Ubuntu, Fedora, Red Hat, and Rocky—this is the first time openRuyi has appeared in a vendor’s server platform compatibility list. On 10-19, DAMO XuanTie released the automotive-grade enhanced CPU IP E908A, claiming it is the first RISC-V CPU IP to simultaneously achieve ASIL-B and ASIL-D, with single-point safety metric SPFM exceeding 90% for the first time, and stating that the next-generation C950A targets 5 times the performance of existing automotive-grade products.

Both items are demand signals rather than current tasks: V100 turns UEFI, ACPI, and SMBIOS into hard requirements, which differs from the current path of board images, toolchains, and support matrices targeting K1/K3; E908A’s deployment depends on a combination of functionally safety-certified toolchains and RTOSes, while compiler qualifications, test suites, and documentation systems related to safety certification have not yet appeared in the public roadmap. Sources: Phoronix: SpacemiT V100, LinuxGizmos: 46-core server CPU, IT之家: XuanTie E908A

VII. Trend Watch

Packaging unit shifts from “source tree” to “dependency package”; this week completes the pivot from closing the closure to completing the spec

This week’s 637 commits have a single throughline: changing “vendor with the source” to “package by dependency.” On the Rust side, the crate closure was completed (including the 23 rust-uv-* packages for the uv build backend); on the Python side, all mainstream cloud backends for fsspec were filled in; on the Go side, vendor was removed and the import paths required after the deleted directories were restored one by one. The order itself shows that the completion condition for de-vendoring is not deleting the vendor directory, but ensuring every depended-upon module can be resolved in the distribution under its original import path—without the import-path restoration, deleting vendor would simply cause immediate compile failures.

By 10-22 the focus had shifted from “can it build” to “can it be audited”: 54 commits added source checksums and switched to %autochangelog, covering a range of package names from m to x. Source checksums make build inputs verifiable; %autochangelog makes changelogs generated from commit history rather than hand-written. Once both are in place, CVE fixes propagate along a single unified path. The indirect value to RuyiAI lies in upper-layer usability: PyTorch’s DataLoader, checkpoint, and dataset tooling generally access remote storage via fsspec, so whether the backends are complete directly determines whether training scripts can run on K1/K3—this portion of dependencies that the distribution fills in for the upper layer matters more to “can it be used” than any single operator optimization.

The release channel becomes the new bottleneck: both the package manager and the index go silent, and the cause is not code

Two phenomena coexist this week: the ruyi package manager stays unchanged at 0.53.0 for the entire month, with 0.54.0 slated for late October; packages-index has had zero commits since 10-13. Issue 079’s explanation was an ISCAS software-source data synchronization anomaly, where already-built packages failed to refresh to the public network; combined with the team’s investment in the summit, this creates the contrast of “hundreds of commits per day on the code side, no new packages visible on the user side.”

This suggests that evaluating distribution progress cannot rely on commit counts alone. Filling in packages, checksums, and dependency paths all prepare for final delivery, but if any link is stuck in the release channel, the user’s actual experience is stagnation. The next observation point is whether 0.54.0 ships its alpha on schedule at month’s end, and whether the ISCAS synchronization issue is resolved alongside the 2026.10 release.

Replay moves from “scheduled” to “daily”: the two riscv branches converge on the same operations model, but review remains the real metronome

PyTorch performed a whole-branch rewrite on five consecutive mornings from 10-18 to 10-22, while LLVM, after eight days of silence, rebased three times in a row on 10-21, 10-22, and 10-23. The common features are that committer timestamps are uniformly rewritten, the set of patch titles is unchanged, and commit hashes expire daily; the only difference is span—LLVM led by 1769 commits on the first day (eight days of backlog), then about 275 per day for the next two (routine single-day catch-up).

The engineering significance is decoupling “following upstream” from “maintaining local patches,” at the cost of traceable history: any downstream that references by hash (image builds, CI caches, issue reproduction) breaks that same day or after each rebase, so these two branches should be versioned by the set of patch titles rather than by hash. More noteworthy is that no new patches were added this week—PyTorch’s seven open PRs and LLVM’s two FPGA PRs only refreshed timestamps, with no new review comments and no merges. The replay mechanism is now solid; the real metronome has become the digestion rate of the review queue. PyTorch paused replay for the first time on 10-23; whether this is a pace adjustment needs confirmation in the next cycle.

The extension landing path takes shape: compile, simulate, and operator layers must all be present to count as usable; once complete, the bottleneck shifts to hardware testing

Taking AME as an example, this week shows a complete path from proposal to usability for an extension: first the backend design and instruction-set definitions (LLVM #16, #24, #27, #29), then the lowering and scheduling implementation (#30, #31, #32), alongside the simulator providing executable semantics (QEMU ame-0.6), and finally the operator library providing testable kernels and a verification suite (AME-operator). Ztt also filled in one side this week—the AME branch of ruyisdk/llvm-project landed initial support for spec v0.6, corresponding to the GCC-side Ztt Md support and QEMU’s Ztt instruction-family implementation.

The P extension follows the same path but is already in its latter half: QEMU covers all instructions (a 12-commit finishing batch), GCC is updated to 0.6, and on the LLVM side intrinsics such as mulq, multiply-high accumulate, sati/usati, and Packed Pair are merged upstream in batches. By comparison, the P extension lacks application-side benchmarks, and AME lacks real hardware. This order is worth recording as a method: without a simulator you cannot verify the compiler, and without an operator library you cannot verify the simulator; before all three are present, talking about performance is meaningless, and only after they are complete does the bottleneck shift to hardware and real measurements. This week’s progress is “completeness,” not “faster.”

The RVV backend’s focus shifts from “are the instructions there” to “tiling and threading”

IREE walked the precision ladder from f32 to f16 in two days, reusing the same lowerRiscvVFmaccLike and the same accumulator legalization both times; the order is to first guarantee a correct path (f32), then pick the fastest one according to extension availability (native f16, widened f16, +zvfhmin fallback), with the cost model pricing the three paths separately. Measurements on X60 make the bottleneck location clear: single-threaded inner_tiled is already faster than the mmt4d ukernel, while 4-thread and 8-thread remain slower.

The arXiv paper on long-vector FlashAttention restructuring reaches a conclusion from the same source: by transposing the score tile and the running output so that queries fall on the linear contiguous axis, the two reductions naturally disappear and register spills are eliminated, bringing whole-core cycles down to 1.84–2.08x and raising floating-point utilization from 16.2% to 29.7%. Both are saying the same thing—once single-core instruction selection is in place, what remains is tiling parameters and threading. For tilelang-riscv and triton-riscv, this is a roadmap that can be compared item by item: the choice of Tile N = vlen/8, the way the cost model is tiered, and the binding relationship between queries per tile and vector length are all worth comparing under the same terms in one’s own lowering, rather than only looking at “whether f16 is supported.”

Distributions begin laying out desktop and virtualization validation stacks; platform forms diverge into server and embedded paths

A group of aligned proposals has appeared in openRuyi’s open PR queue: enabling GUI test features in qemu (#1421), adding virglrenderer (#1415), fwupd support in ovmf (#1436), adding ydotool (#1457), and fixing a man-page conflict in xorriso (#1489). The five items span virtualization, graphics virtualization, firmware updates, input automation, and optical image tooling; together they point to “running a full desktop on RISC-V and automating its validation”—the other end of the same requirement as the “AI-driven IDE graphical testing” shown at the summit.

Platform forms are diverging at the same time. At the server level, represented by SpacemiT V100, UEFI, ACPI, and SMBIOS in the spec become hard requirements, and BRS compliance testing and the installation chain are the entry ticket; at the embedded and consumer level, represented by K1/K3, the path is board images, toolchains, and a support matrix. This week ruyi-imager added UFS and UEFI provisioning support for K3, the first concrete action on the tooling side of this divergence; meanwhile the openRuyi main repo had zero server-platform-related commits all week, so whether V100’s compatibility list is delivered depends on the 2026.10 release and subsequent firmware-line actions.

Appendix: Sources and Verification Notes

Source List

2026-10-19 issue: window 10-16 04:30 ~ 10-19 04:30 (past 3 days, covering Saturday and Sunday).
2026-10-20 issue: window 10-19 04:30 ~ 10-20 04:30.
2026-10-21 issue: window 10-20 04:30 ~ 10-21 04:30.
2026-10-22 issue: window 10-21 04:30 ~ 10-22 04:30.
2026-10-23 issue: window 10-22 04:30 ~ 10-23 04:30.
Activity outside the period boundaries (10-23 daytime through 10-24 morning) was verified against organization repositories and added, as described in the next section.

Verification Method and Scope

Organization verification (168-hour window): covers commits, PRs, and releases across three organizations — RuyiAI-Stack, ruyisdk, and buddy-compiler — via both Atom feeds and web pages, without relying on API rate limits; commits from upstream forks (PyTorch riscv, LLVM riscv, LLVM main) are included after filtering by RISC-V, RVV, vector extension, and XuanTie-related keywords.
Supplementary verification of key repositories: openRuyi-Project’s openRuyi (daily commit counts and author distribution, via full paginated API statistics), ruyifirmware, edk2-ruyi, homepage; ruyisdk’s qemu (p-dev, ame-0.6), llvm-project (AME), linux-xuantie-kernel, riscv-gcc (ztt-dev), wechat-articles, ruyi-imager, support-matrix, ruyi, packages-index, AME-operator; buddy-compiler’s buddy-mlir.
Dual community sources: RuyiSDK developer community forum (latest topic list), openRuyi distribution news page.
Official homepage: three-page snapshots of www.ruyiai.org homepage, blog page, and docs page compared by sha256, with blog and docs index entries attached.
Time conventions: repository commits use committer time converted to Beijing time; “daily” descriptions follow consecutive calendar days; the weekly period is the five working days from 2026-10-19 to 2026-10-23. openRuyi’s 637 commits are counted by committer time across the five calendar days 10-19 to 10-23, which differs from the 24-hour window used in each daily report, so the figures do not fully correspond to those in individual daily issues.

Items Added This Week Beyond the Daily Reports

10-23 17:15, ruyisdk/llvm-project’s AME branch landed “[RISCV] Add initial Ztt matrix extension support based on spec v0.6” (commit 29fefa0f), the branch’s first integration of the Ztt instruction family.
10-23 23:00, RuyiAI-Stack/llvm-project’s riscv branch was rebased for the third consecutive time, with the head moving from 58d62a47 to 7c77126b; verification the same day confirmed the PyTorch riscv branch was not replayed again this round, with the head still at 29259d90.
10-23 11:23, ruyisdk/linux-xuantie-kernel landed “riscv: Migrate T-Head extensions to the vendor extension framework” (commit 92c3f534), ending a seven-day silence since 10-16.
10-23 09:56 to 13:31, four commits in ruyisdk/ruyi-imager: CLI output aligned with the console character set while keeping JSON as UTF-8 (#14); added UFS and UEFI provisioning support for SpacemiT K3; preserved all image target associations in the catalog and GUI; repository messages parsed only once when loading by catalog.
10-23 10:47, three commits in ruyisdk/support-matrix: first version of the RT-Thread basic test report for RDC2022-D1s plus two rounds of review revisions.
10-23 22:47 to 10-24 00:54, 13 Go packages added to the openRuyi main repository (go-gopkg-gorp.v1, go-github-ziutek-mymysql, go-github-denisenkom-go-mssqldb, the go-github-gobuffalo-* series, etc.); another 6 commits in the early hours of 10-24 are not counted in this period.
10-24 06:24, ruyiai-daily published the 2026-10-24 issue, bringing the week’s total to seven issues.

Main References

Data sources: daily RuyiAI activity reports (5 issues total, 2026-10-19 to 2026-10-23) and this week’s supplementary verification (organization repositories, dual community sources, official homepage); reporting period is 2026-10-19 to 2026-10-23.