Research window: 2026-10-30 04:30 ~ 2026-11-02 04:30 (Beijing time, past 3 days, covering Saturday and Sunday; directly contiguous with the previous issue’s 10-30 04:30 cutoff).

Sources: Full-repository audit of GitHub organizations (RuyiAI-Stack, ruyisdk, openRuyi-Project, buddy-compiler, with commits, PRs, and Releases within the window checked repo by repo; upstream forks filtered by keywords such as RISC-V / RVV / XuanTie, with the commit comparison API used to distinguish replays from new additions), openRuyi commit and PR merge statistics, Releases and tags of the ruyi package manager and ruyi-imager, the RuyiSDK developer community forum, the ruyiai-daily daily intelligence archive, snapshots of three pages of the official RuyiAI homepage, the openRuyi distribution news page, and targeted Chinese and English queries via Google News RSS (through a proxy).

This Issue’s Index

  • Today’s Focus: Buddy Compiler 0.1.3 goes official; ten of sixteen commits are RVV scalable vectorization, while the release notes only mention the server-side ABI (10-31)
  • I. RuyiAI Stack Progress (PyTorch / Triton / TileLang RISC-V adaptation)
    • 1.1 pytorch: second full-branch replay on the riscv branch in the early hours of 11-01, baseline still at 3afdbd3 (11-01)
    • 1.2 llvm-project: riscv branch replayed late on 11-01, including the A100 IME/AME downgrade (11-01)
    • 1.3 triton-riscv: two merges, five new opens, plus one rebase onto official Triton v3.8.0 (10-30 to 11-01)
    • 1.4 tilelang-riscv: main branch silent for a seventeenth day, only one open PR remains (11-01 status)
  • II. RuyiSDK Toolchain and Distributions
    • 2.1 openRuyi: all six commits landed on 10-30, LLVM 23 and ollama security updates merged (10-30)
    • 2.2 openRuyi under review: thirteen-commit Prometheus dependency batch, box64 and firecracker added to the queue (10-30 to 11-01)
    • 2.3 Ruyiai trio #1350: still stuck on spec compliance in week two, one refresh on 10-30 (10-30 status)
    • 2.4 ruyi 0.54.0: end-of-October target missed, only one documentation commit merged to main (10-30)
    • 2.5 openRuyi 2026.10 unreleased, a gap appears in the monthly release cadence (11-02 status)
  • III. Vector Extensions and Operator Optimization (VecIntrinBench / IntrinTrans / FBGEMM)
    • 3.1 All three vector repos silent this issue, latest commits stalled at 02-13, 06-25, and 07-13 respectively
    • 3.2 Operator work has shifted wholesale to the triton-riscv lowering path (10-31 to 11-01)
    • 3.3 Performance mainline #85 stalled at 10-18, a cadence contrast with the five commits on the lowering path
  • IV. Buddy Compiler Updates
    • 4.1 BUDDY MLIR 0.1.3: sixteen commits, one hundred thirty-six files, notes mention only the ABI item (10-31)
    • 4.2 Nightly builds and downstream anchors: three-hop delay closed within two days, anchor still on the nightly (10-31)
    • 4.3 Three under review did not make 0.1.3, Whisper and interface alignment still pending (10-31 status)
  • V. Community, Events, and Official Homepage
    • 5.1 Official homepage unchanged across three pages, two blog posts, twenty-three documentation chapters (11-02 status)
    • 5.2 No new forum posts in the window, biweekly progress issue 080 not yet out (11-02 status)
    • 5.3 Two issues of ruyiai-daily, intelligence coverage spans PyTorch, Triton, and KV cache (10-31, 11-01)
    • 5.4 Zero external news hits, two monthly distribution-side commitments both come due (11-02 status)
  • VI. Trend Observations
    • 6.1 Release notes for the official version are disconnected from the code diff; RISC-V progress is buried in commit history
    • 6.2 triton-riscv shifts from “fix one, merge one” to “batch submission,” with acceptance still absent
    • 6.3 Monthly distribution-side commitments missed repeatedly, stack-level packaging still reworking at the spec layer

Today’s Focus: Buddy Compiler 0.1.3 Goes Stable — Ten of Sixteen Commits Are RVV Scalable Vectorization, Release Notes Mention Only the Server ABI (10-31)

Date: 2026-10-31　Sources: BUDDY MLIR 0.1.3, commit diff between v0.1.2 and v0.1.3, PR #999 rvv-vlen, PR #1003 scalable vector width selection

At 07:01 on 11-01 (Beijing time), buddy-mlir shipped stable release 0.1.3. The previous stable release was 0.1.2 on 10-25, with five nightlies in between. The release notes expand on exactly one item: the new buddy-server ABI (#1015), which consolidates the per-modality model plugin handles into a unified interface, plus unified paths for loading, status queries, invocation, streaming, and cancellation.

But pulling the commit diff between v0.1.2 and v0.1.3 shows this release actually packs sixteen commits across 136 files, ten of which are a single block of RISC-V vectorization work under [midend][VIR]:

  • #999 introduces (rvv-vlen), making scalable vector length a vectorization target attribute;
  • #1000 counts live vectors in nested loops as input to vector width selection;
  • #1002 makes scalable strip-mining loops step by vscale;
  • #1003 selects scalable vector widths for RVV;
  • #1004 lowers set_vl with results into scalable vectors;
  • #1005 handles multi-dimensional dynamic vector bands with results in set_vl;
  • #1006 adds dynamic vector row-level vir.shuffle;
  • #1007 unifies the index conventions of vir.load / vir.store;
  • #1008 automatically infers the width of index vectors;
  • #996 adds vir.from_vector and reduces reassociation.

Two more commits belong to the VIR line but not under the [midend] prefix: the VIR dialect implementation of decode attention ([frontend][tools]) and Python bindings for VIR (#1009). In other words, twelve of the sixteen commits touch the vector dialect layer, yet the release notes say not a word about RISC-V or RVV.

This gap is worth noting because it changes the answer to the question “where is the RISC-V progress in this stack?” The prior assessment in earlier issues was: buddy-mlir’s RISC-V work mainly flows through nightlies, stable releases are occupied by general work like ABI refactoring, and downstream can only anchor to nightly tags to get RVV changes. 0.1.3 proves that assessment only half right — the stable release did absorb the RVV block, but the release notes were not updated to match, so anyone reading the release page would think 0.1.3 is just a server-side refactor, when in fact it is a release with significantly advanced scalable vectorization capability.

The direct implication for downstream: triton-riscv raised its dependency anchor to the dev20261030 nightly at 13:15 on 10-31 (PR #91). That nightly predates the 0.1.3 stable build, but the two share the same content (0.1.3 was cut from the main branch head on 10-29), so those ten RVV commits are already live downstream; what hasn’t caught up is the fact that “the anchor still says nightly tag” — under the current renovate cadence, switching to release/v0.1.3 will take another round.

A caveat on scope: these ten commits focus on scalable vectorization of the VIR dialect, i.e., the lowering path from set_vl to scalable vectors — not end-to-end model performance data; the release notes provide no benchmarks either. The advance in vectorization capability is verifiable; how fast it runs has no answer this issue.

I. RuyiAI Stack Progress (PyTorch / Triton / TileLang RISC-V Porting)

1.1 pytorch: Second full-branch replay on the riscv branch in the early hours of 11-01; baseline still at 3afdbd3 (11-01)

Date: 2026-11-01　Sources: pytorch riscv branch, PR #51 riscv64 local image, PR #44 bytes_to_scalar fix, open PR list

At 03:00 on 11-01, the riscv branch underwent a full-branch replay: the commit timestamps of the twenty commits on the branch were uniformly rewritten into the two-second window from 03:00:26 to 03:00:27, while all author dates were left unchanged. The head commit is 1867c9b8, with the message still [SyncBots] Integrate PyTorch at 3afdbd3, and the author date of that sync commit itself is 10-29 12:48—meaning this replay did not change the baseline; the branch remains at upstream 3afdbd3, the same landing point as the 10-29 replay.

Compared with the 10-29 replay, the difference is only formal: the previous issue was “replay after seven days of silence + a sync-bot commit adding a dependency cache fix,” while this issue is “another replay three days later, with no content change.” The patch set on the branch is also unchanged, still consisting of Add riscv64 image locally (#51), Fix bytes_to_scalar for float/complex on RISC-V (#44), Scope linear cross entropy ULP tolerance to RISC-V (#42), inductor opinfo blocklist (#50), and the earlier CI and test-tolerance changes.

This kind of replay—”baseline unchanged, only commit timestamps modified”—usually has two causes: first, replaying a different patch order onto the same baseline to eliminate conflict markers or clean up history; second, an automated job unconditionally replaying on a schedule. Either way, the content increment for this issue is zero, and the only thing worth noting is the cadence—two full-branch replays within two weeks, neither accompanied by a new upstream sync.

What still warrants attention is the same misalignment: the distribution-side python-torch-ruyiai (openRuyi #1352) is built from branch artifacts, and every replay changes the branch head SHA, so the source landing point pinned in the package must be realigned; no alignment action was observed this issue.

1.2 llvm-project: riscv branch replayed late at night on 11-01, including the A100 IME/AME lowering (11-01)

Date: 2026-11-01　Sources: llvm-project riscv branch, RISCV_CONTRIBUTING.md, rebase workflow

At 23:00 on 11-01, the riscv branch likewise underwent a full-branch replay, with the commit timestamps of the twenty-six branch-owned commits uniformly rewritten to between 23:00:22 and 23:00:26. The head commit is afdd0982, whose content is [workflows] Push rebased PRs directly and document contribution options (author date 10-29 01:59)—that is, the change noted in the previous issue, “cancel the dry run, add a contribution guide”—and it remains the branch head, with nothing newer stacked on top this issue.

The most relevant items on the branch for this stack are still the two A100 commits: [RISCV] Lower IME intrinsics to SpacemiT A100 dot instructions (#30) and [RISCV] Add A100 HP/SP and pack/unpack lowering with calibrated scheduling (#31). The former lowers IME intrinsics to A100 dot-product instructions; the latter adds pack/unpack lowering for the two precision forms HP/SP along with a calibrated scheduling model. One layer below are [AME] Update BOSC AME instructions (#29) and [RISCV] Update xtame design (#27), forming a complete chain of “AME design doc → instruction definitions → intrinsics → lowering and scheduling.” This chain serves the matrix extension and is where RuyiAI’s “from RVV to Matrix” narrative lands on the compiler side.

One inconsistency to re-check next issue: the author date of the most recent [SyncBots] Integrate LLVM at b3b5e33 on the branch is stuck at 09-29, but comparing the current head commit with the previous issue’s head commit returns a diff that includes upstream commits from 10-30 (such as [clang][AST] Don't give NestedNameSpecifier pointer identity in DynTypedNode (#233153) and [libc] Add truncation casts to avoid warnings in file_test.cpp (#237262)). There is only one explanation for the two together: this replay advanced the upstream baseline while rewriting history, but the sync bot did not add a corresponding record. A sync record disconnected from the actual baseline means judgments like “which upstream this branch is based on” can only be inferred via the compare API; we suggest adding an explicit baseline note on the branch going forward.

1.3 triton-riscv: two merged, five newly opened, plus one rebased onto official Triton v3.8.0 (10-30 to 11-01)

Date: 2026-10-30 to 2026-11-01　Sources: PR #55 asin frontend patch, PR #91 dependency update, PR #92 rebase onto Triton v3.8.0, commit list

The main branch merged two PRs during the window, both over the weekend. At 20:14 on 10-30, [patches] Support asin op via frontend patch (#55) was merged—this brings in the asin operator via a frontend patch, bypassing the backend’s lack of support for inverse trigonometric functions, a typical “trade a frontend rewrite for operator availability” approach. At 13:15 on 10-31, renovate’s #91 bumped the buddy-mlir dependency from nightly/v0.1.3.dev20261029 to dev20261030. Since then the main branch has had no new code commits.

The real change is in the PR queue. Between 15:20 on 10-31 and 17:36 on 11-01, maochuanjun opened five PRs in a row, all in the lowering and analysis layers:

  • #93 [Conversion] Preserve scalar load/store masks (10-31 15:20), preserving masks on scalar memory accesses;
  • #94 [Analysis] Preserve lane offsets in mixed pointers (10-31 21:57), preserving lane offsets in mixed pointers;
  • #95 [Conversion] Lower tensor gathers (10-31 23:41), lowering tensor gathers;
  • #96 [Analysis] Preserve incomplete tensor masks (11-01 17:29), preserving incomplete tensor masks;
  • #97 [Conversion] Handle stacked zero strides (11-01 17:36), handling stacked zero strides.

The titles form a tidy pattern: three Conversion and two Analysis, all phrased as “preserve some kind of information without loss.” This continues the same problem family as the three fixes on 10-29 (tensor padding, loop-carried offsets, scatter tests)—the lowering path repeatedly drops boundary information such as masks, offsets, and strides when translating Triton IR into structured/unstructured forms, and each loss requires another PR.

There is one PR in a different direction: #92 [triton] Rebase integration onto the official Triton v3.8.0 release (jason-hue, updated 10-31 12:57). This is not a defect fix but a move of the entire RISC-V integration onto official Triton 3.8.0. The repo’s integration baseline had previously been stuck at [triton] Update integration for latest upstream (#76) (09-02), with two months of patches but no rebase; once #92 merges, the landing points of the subsequent five PRs will all have to shift. This also explains why #92 and #93–#97 sit in the queue at the same time without being merged into a chain—the rebase is a prerequisite action and is being held for now.

1.4 tilelang-riscv: seventeenth consecutive day of silence on main; only one open PR left (11-01 status)

Date: 2026-11-01 (status)　Sources: tilelang-riscv commit list, open PR #4

The last commit on the main branch is still “Build Python extension in Buddy CI” at 10:52 on 10-16, marking the seventeenth consecutive day without a commit. Open PRs have dropped from two to one, leaving only #4 “RVV vector mask and max reduction lowering” (stalled since 09-28); the earlier #2 “Add Codex-compatible RISC-V operator workflow” is no longer in the open list.

In the same organization and the same window, triton-riscv merged two PRs and opened five in three days, while tilelang-riscv had none. This divergence has lasted three weeks and can no longer be explained by “nobody works on weekends.” The only alternative path visible from the outside is the python-tilelang-ruyiai spec in openRuyi (part of the #1350 trio), i.e., substituting distribution artifacts for repository iteration—and #1350 itself is still stuck in review. With both paths stalled, this component has no forward direction at all this issue.

II. RuyiSDK Toolchain and Distributions

2.1 openRuyi: All Six Commits Land on 10-30, LLVM 23 and ollama Security Update Merged (10-30)

Date: 2026-10-30　Source: PR #1424 LLVM 23, PR #1514 ollama security update, PR #1545 clang-wrap, main repo commit list

All six commits in the window fall on a single day, 10-30, followed by zero commits over the entire weekend. Three PRs merged:

At 11:20, #1424 merged, adding the llvm23 package at version 23.1.4. This introduces LLVM 23 as a co-installable package rather than bumping the default toolchain wholesale—a low-risk approach for a distribution: projects needing the new version depend on llvm23 explicitly, everything else stays on the existing default, and a major-version jump doesn’t drag the entire build surface down with it. For the RISC-V side, the significance is toolchain version optionality—previously, testing a new LLVM backend meant building it yourself.

At 12:39, #1514 merged, bumping ollama to 0.40.7 and tagging it security-fixes. This one was still in the review queue last issue (at time of writing +259/−3371, with the deletions being the vendor directory); its merge this issue means that batch of security fixes has entered the mainline. Three Go ecosystem packages landed in the same minute: go-github-tree-sitter-cpp, go-github-tree-sitter-go-tree-sitter, and go-github-mattn-go-pointer, all filling in dependency closures for existing packages.

At 17:39, #1545 merged, tracking clang-wrap to 20261030. This package has kept same-day cadence with upstream for several issues running—one of the few specs in the distribution where something happens every day.

None of the six commits directly touches the RuyiAI trio, meaning what the distribution side did this issue was “move the foundation forward,” not “install the stack.”

2.2 openRuyi Under Review: Thirteen-PR Prometheus Dependency Batch, box64 and firecracker Added to Queue (10-30 to 11-01)

Date: 2026-10-30 to 2026-11-01　Source: PR #1561 box64, PR #1559 firecracker, PR #1516 qemu-rustsbi, PR #1562 binutils RISC-V test tracking, PR #1547 to #1557 Prometheus batch

The open queue saw twenty-four updates in the window, larger than last issue and with clear structural features:

The largest cluster is the Prometheus v3.13 module dependency batch, thirteen PRs in total (#1540, #1441, #1547 to #1557), all submitted by the same author in DAG order in batches, with titles uniformly reading “Add Prometheus v3.13 modules - DAG dependency batch NN.” This “slice one dependency graph into a dozen-plus layered submissions” approach is usually unavoidable in a distribution—a single submission would draw reviewer demands to split it, while layering ensures each PR can be independently built and verified. The cost is a stretched merge window: if any layer stalls, everything behind it is blocked.

The second cluster is virtualization and binary translation: #1561 adds box64 (a dynamic recompiler for running x86-64 programs on RISC-V), #1559 adds firecracker (a lightweight microVM), and #1516 adds qemu-rustsbi (submitted by luojia65, author of RustSBI, with five comments already). Taken together, the three point to the same class of need—running non-native software and isolated workloads on the RISC-V desktop.

The third category is maintenance items directly related to RISC-V: #1562 binutils: Track RISC-V pr19719 test failures registers a known RISC-V-related test failure in binutils as a tracking item rather than fixing it outright. In a distribution, this means “builds pass, tests aren’t all green”—useful information for downstream users linking with binutils.

The rest are three routine version follows: #1563 bumps Node.js to 26.13.0 and switches to system libraries, #1544 bumps firefox to 159, and #1421 enables a batch of GUI-test features for qemu.

2.3 Ruyiai Trio #1350: Still Stuck on Spec Conventions in Week Two, One Refresh on 10-30 (10-30 Status)

Date: 2026-10-30 (status)　Source: PR #1350 Add Ruyiai packages, PR #1352 python-torch-ruyiai

#1350 (the buddy-mlir, python-triton-ruyiai, python-tilelang-ruyiai trio) had a refresh at 16:16 on 10-30 and remains unmerged, adding one more 10-30 entry to the timeline. All eighteen review comments recorded last issue pointed at spec conventions—no blank lines needed between BuildOption entries, missing BuildRequires: python3dist(wheel), Provides needing to align with actual package names, patches needing to be generated with git format-patch, empty %check needing a comment—and no new directional disputes have surfaced this issue.

Open since 09-21, this PR has now crossed its sixth week. Last issue attributed this to “writing specs from scratch, where every non-standard point needs explaining”; this issue there’s another layer: within the trio, buddy-mlir bundles LLVM, triton depends on the git executable, and tilelang needs to discover the buddy-mlir toolchain—three non-standard points raised separately in review, with no unified packaging-convention document collecting them. The result is that every review round re-explains the same batch of issues, and the rework cost lands on the back-and-forth rather than the writing.

#1352 (python-torch-ruyiai) in the same batch saw no activity this issue, still parked at 10-27. It shares the same unresolved question as the pytorch branch replay in 1.1: the branch changes SHA on every replay, and whether the source landing point in the package should follow suit has no conclusion from anyone.

2.4 ruyi 0.54.0: End-of-October Target Missed, Main Branch Merges Only One Documentation Commit (10-30)

Date: 2026-10-30　Source: PR #508 vendor naming list, ruyi tags, ruyi Releases

At 09:54 on 10-30, the ruyi main branch merged #508 “docs: update vendor naming list,” adding four identifiers—BananaPi, OrangePi, XiangShan, ZhiheComputing—to the vendor naming documentation. This documentation-side alignment and ruyi-imager’s change of the UI label from “manufacturer” to “vendor” are two ends of the same effort, avoiding inconsistent naming between the two places.

Beyond that, 0.54.0’s status is unchanged: the tag list still shows no new tag after 0.54.0-alpha.20260918, the latest stable release remains 0.53.0 from 09-24, and the main branch has had no commits since 09-25 apart from this documentation commit. Biweekly progress issue 079 stated the target was “moved to end of October due to release cycle adjustments”; today is 11-02, October has passed, and that target has now been missed, with no new target put forward in its place.

Worth noting is how it was missed: not a failed release, not a release-candidate rollback, but near-total absence of code activity in the second half of October. #508 is a documentation change, meaning that during that late-October stretch the main branch saw very little even in the way of “release preparation.” This differs from the cadence before 0.53.0—then alpha, beta, and stable came as three consecutive hops; now not even the first hop has happened.

2.5 openRuyi 2026.10 Not Released, Monthly Release Cadence Shows a Gap (11-02 Status)

Date: 2026-11-02 (status)　Source: openRuyi news page, openRuyi main repo

The latest entry on the openRuyi distribution’s news page is still “openRuyi 2026.09 released” (09-30), and the October 2026 release announcement page returns 404. The previous four months’ release dates were 6-30, 7-23, 8-27, and 9-30—not strictly the same day, but with no precedent of a whole month missing; the October release has still not appeared as of 11-02.

Read alongside 2.4, this forms the most noteworthy set of facts this issue: two pipelines belonging to the same “RuyiSDK ecosystem distribution”—the package manager ruyi and the distribution openRuyi—each missed a public monthly commitment at the same end of October, while neither line’s code side is stagnant (the openRuyi main repo still had six commits on 10-30, and ruyi had a documentation merge). This indicates the bottleneck isn’t development but release itself: version freeze, announcement writing, image building, and the publishing process—this stretch hasn’t run on schedule for nearly two months.

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

3.1 All three vector repos silent this period; latest commits stalled at 02-13, 06-25, and 07-13 respectively

Date: 2026-11-01 (status)　Source: VecIntrinBench, IntrinTrans, FBGEMM

None of the organization’s three vector-themed repositories received any in-window commits this period, and their latest commit times fall in three different quarters: VecIntrinBench stalled at 02-13, IntrinTrans at 06-25, and FBGEMM at 07-13. The three respectively cover vector intrinsic benchmarks, intrinsic translation, and quantized operator backends, and originally formed a triangle of “what to measure, how to translate, how to implement operators.”

That triangle is now stalled as a whole, and the stall points differ, indicating this is not a single unified project termination but rather each cooling down naturally. VecIntrinBench having been idle for nearly nine months is the most notable case—if a vector intrinsic benchmark library goes without updates for a long time, the coverage it measures drifts further and further from the set the compiler actually supports.

3.2 Operator work has shifted entirely to the triton-riscv lowering path (10-31 to 11-01)

Date: 2026-10-31 to 2026-11-01　Source: PR #93, PR #94, PR #95, PR #96, PR #97

Since all three dedicated repos have stalled, the actual operator-layer work front can only be read from the triton-riscv PR queue. The five newly opened PRs this period all revolve around “information preservation,” broken down as follows:

#93 handles masks on scalar load/store—the scalar memory access path is the most prone to dropping masks as constant-true during lowering; once dropped, conditional scalar reads and writes become unconditional in the structured IR, and out-of-bounds accesses won’t error but instead read dirty data. #94 handles lane offsets in mixed pointers, i.e., when a pointer expression has both a base address and per-lane offsets, the analysis phase keeps only the base address and treats offsets as constants; #96 handles incomplete tensor masks, i.e., broadcast semantics when the mask shape is smaller than the tensor shape; #97 handles stacked zero strides, i.e., when multiple dimensions all have zero stride, they may be collapsed into one dimension after lowering.

#95 is the only one that adds capability rather than preserving information: lowering tensor gather. Previously gather could only go through the unstructured path, with no corresponding implementation on the structured path; #95 fills that gap.

The common backdrop for all five is the same thing: correctness at this layer is exposed by “bringing real operators up and running them,” not by regression tests. The eight PRs accumulated over three weeks (three on 10-29 plus five this period) all fall into this category. The mechanism works but is costly—each batch of operators brought up requires fixing a string of edge cases, and the verification strength of the fixes varies (of the three on 10-29, one ran the full lit suite of 291 items, one ran only targeted regressions, and one ran only a single file).

3.3 Performance mainline #85 stalled at 10-18, in stark contrast to the five lowering-path PRs

Date: 2026-10-18 (status)　Source: PR #85 softmax and matmul optimization

#85 “softmax and matmul optimization” has not been updated since 10-18 23:55 and remains in place this period. It is the repo’s only open PR explicitly targeting performance, and it forms a clear contrast with the five lowering-path PRs: five PRs a week on the correctness side, no movement on the performance side for half a month.

For a stack meant to “run real models,” this contrast has concrete consequences: correctness fixes like masks, offsets, and strides determine “whether it computes correctly,” while softmax and matmul optimization determine “whether it computes fast enough.” The former is advancing rapidly while the latter sits idle, meaning that even if all 604 operators are brought up, end-to-end performance remains at the level of three weeks ago.

IV. Buddy Compiler Updates

4.1 BUDDY MLIR 0.1.3: Sixteen Commits, One Hundred and Thirty-Six Files, Release Notes Cover Only the ABI (10-31)

Date: 2026-10-31　Source: BUDDY MLIR 0.1.3, commit diff v0.1.2…v0.1.3, PR #1015 buddy-server new ABI, PR #1009 VIR Python bindings

The commit diff for 0.1.3 corroborates what was already covered in “Today’s Highlights”; here we add three observations not in that section.

First, this release’s file footprint is larger than its commit count suggests: sixteen commits touched 136 files, a substantial share of them from the interface refactor in #1015 (four new runtime headers added, four sets of per-modality plugin handles and their corresponding unit tests removed). In other words, 0.1.3 packs two things at once—ten consecutive advances in the vector dialect, and a plugin-system consolidation spanning more than seventy files—overlapping in time (the ten VIR commits from 10-25 to 10-27, #1015 on 10-29) but reviewed separately.

Second, the commit [frontend][tools] Implement the decode attention in the VIR dialect is easy to overlook, but it points in a different direction from the earlier VIR lowering: writing decode attention as an implementation in the VIR dialect amounts to building a direct path from dialect to vectorization for the specific workload of “attention decoding.” This is the first commit in VIR’s move from a “general-purpose vector dialect” toward “workload-specific optimization.”

Third, the VIR Python bindings (#1009) mean this dialect can be constructed and inspected from the Python side; the direct benefit downstream is that projects like triton-riscv can generate VIR at the Python layer for unit validation without going through the full compilation chain each time.

4.2 Nightly Builds and Downstream Anchors: Three-Hop Latency Closed Within Two Days, Anchor Still on Nightly (10-31)

Date: 2026-10-31　Source: nightly dev20261030, triton-riscv PR #91, Releases list

A previous issue noted a fixed-latency structure: buddy-mlir merge → next-day nightly build → renovate dependency update → triton-riscv merge, with the three hops typically taking one to two days. This issue the chain ran through end to end, so we can check the actual time spent at each step:

#1015 merged to main on 10-29 at 15:08; the nightly dev20261030 was published on 10-30 at 08:49 (including #1015); renovate’s #91 merged into triton-riscv on 10-31 at 13:15. From merge to downstream pickup, two days and five minutes in total, consistent with the “one to two days” estimate.

But the shape of the anchor hasn’t changed: triton-riscv still depends on the dev20261030 nightly tag, not the official release/v0.1.3 published on 10-31 at 23:01. The two tags share the same source (0.1.3 was cut from the main-branch head on 10-29, and so was dev20261030); the difference is reproducibility—nightly tags get their references overwritten by subsequent builds, official tags do not. For a stack headed into a distribution, anchoring on nightlies long-term means the sources pinned inside the package are not reproducible over the long run—the same class of concern as “patches should be generated with git format-patch” in 2.3.

4.3 Three PRs Under Review Missed 0.1.3, Whisper and Interface Alignment Still Pending (10-31 status)

Date: 2026-10-31 (status)　Source: PR #1011, PR #1013, PR #994, open PR list

The sixteen commits in 0.1.3 do not include #1011, #1013, or #994, meaning they have not yet been taken into an official release. Their nature: #1011 forces the count in scalable VIR slices to int64 (on the same vector-width line as this issue’s ten VIR commits), #1013 lets Whisper reuse preprocessing within a single transcription, and #994 aligns the buddy-server interface with llama-server.

The most awkward of the three is #994: the llama-server interface it wants to align with is exactly the layer that #1015 refactored away. 0.1.3 has already consolidated the per-modality plugin handles into a unified ABI; if #994 merges in its original direction, it amounts to stacking another compatibility layer on top of an interface that was just rewritten. The PR does not discuss this conflict, and this issue we have not seen it closed or redirected—its current state is “neither in the release nor rejected.”

#1011’s situation is similar but the opposite direction: it is the closing item on the vector-width line, while the ten VIR commits from the same period already landed in 0.1.3. A closing item left outside the release means 0.1.3’s scalable vectorization still has no settled answer at the boundary of “slice counts exceeding 32 bits.”

V. Community, Events, and Official Homepage

5.1 Official homepage’s three pages unchanged; two blog posts, twenty-three documentation chapters (11-02 status)

Date: 2026-11-02 (status)　Source: RuyiAI Official Homepage, Blog Index, Documentation Index

All three pages of the official homepage were unchanged during the window, with snapshot hashes matching the previous issue: 3 entries on the homepage index, 2 blog posts on the blog index (“Triton’s RISC-V port” and “PyTorch RISC-V CI in practice”), and 23 documentation chapters. This state has persisted for several consecutive issues, with no new articles or chapters this period.

Compared with 4.1, this silence is somewhat unusual: the ten RVV vectorization efforts in 0.1.3 represent the most systematic progress in nearly three months, yet the blog side has no corresponding explanatory article. Both official blog posts are of the “porting practice” type; what is missing is precisely a stage-level explanation of “how far vectorization capabilities have come.”

5.2 No new forum posts during the window; biweekly progress issue 080 not yet out (11-02 status)

Date: 2026-11-02 (status)　Source: RuyiSDK Developer Community, Post #2899, Biweekly Progress Issue 079 #2895

There were no new posts on the forum during the window; the latest post remains #2899 from 10-29 (RuyiAI appearing at the 6th RISC-V China Summit), which was already covered in the previous issue. The last formal report was issue 079 on 10-26; issue 080, on the biweekly cadence, should be published in early November and had not appeared by this period.

It is worth noting the distribution of forum activity: the three posts on 10-29 (#2897 to #2899) were all summit-related, followed by four days with zero posts. The summit topic had already used up late October’s discussion quota; the next wave will have to wait for issue 080.

5.3 Two issues of ruyiai-daily, with intelligence coverage of PyTorch, Triton, and KV cache (10-31, 11-01)

Date: 2026-10-31, 2026-11-01　Source: ruyiai-daily

The daily intelligence repository had two commits during the window (daily-news: 2026-10-31 and daily-news: 2026-11-01), still on the fixed cadence between 22:20 and 22:40 each day. The 11-02 issue, per its publishing habit, would not appear until that evening and was not in the window.

These two issues are among the cross-check sources for this report: their entries on PyTorch upstream sync and the Triton downgrade path are consistent with the judgments in sections 1.1 and 1.3 of this report, with no conflicts in framing.

5.4 Zero hits in external news; two monthly commitments on the distribution side both come due (11-02 status)

Date: 2026-11-02 (status)　Source: Google News RSS, openRuyi News Page

Targeted queries in Chinese and English for RuyiSDK, RuyiAI, and openRuyi returned zero hits during the window. The only Chinese-language result containing “如意” remains the 10-25 summit exhibition report (ESWIN), which falls outside the window and is unrelated to the Ruyi community; the English query for “openRuyi” returned only one old article from April.

The absence of external coverage does not conflict with the observations in 2.4 and 2.5—both missed monthly commitments are “things that did not happen,” so there would naturally be no news about them. What really tells the story is the internal signal: the package manager and the distribution both missed the October release window, while the code side of both lines is still moving.

VI. Trend Observations

6.1 The official release notes are out of sync with the code diff, and RISC-V progress is buried in the commit history

The methodological significance of 0.1.3 outweighs the release itself: when a project’s “public description” and “what is actually shipped” diverge over time, outsiders can only infer its state by reverse-engineering the commit history. In this cycle, the release notes mention only the server-side ABI refactor, while twelve of the sixteen commits touch the VIR vector layer.

This disconnect carries a compounding cost. For downstream users, deciding “whether to upgrade” requires consulting the release notes, the commit diff, and the dependency anchors simultaneously; for upstream, the work that most deserves visibility does not appear on the pages where it should—the most systematic vectorization progress of the past three months has no corresponding description in the blog, the docs, or the release notes. For a stack whose narrative is “RVV to Matrix,” reducing vectorization progress to ten lines of commit titles is a waste.

The more practical risk lies on the review side: if the release notes cover only part of the changes, reviewers’ attention will concentrate on that part, and the remaining changes will never be revisited once they have “shipped in an official release.”

6.2 triton-riscv shifts from “fix one, merge one” to “batch submission,” but the acceptance side is still missing

The three PRs on 10-29 were “merged back-to-back within 80 minutes”; this cycle’s five PRs were “opened back-to-back within two days, not yet merged.” The former shows that maintainers have a fast track for clear bug fixes; the latter shows that the new batch has not yet reached that stage. The difference between the two tempos is not development intensity but review bandwidth.

These five, plus the three from 10-29, add up to eight similar fixes in three weeks, all pointing to information loss in the fallback path. The number itself is a signal: this path has no systematic equivalence checking, so issues can only be found by hitting them operator by operator and patched one by one. Meanwhile, the single most valuable thing for downstream—turning the export of FlagGems’ 604 operators into a standing nightly regression—still has not been done. Although PR #56 has recovered from its stall since 09-16 (one push at 10-30 20:50, now expanded to 156 new files, with exported entries growing from 468 to 604), it remains open.

As long as acceptance lives in PRs rather than in the pipeline, the question “can this batch of operators run on riscv64?” will keep being deferred.

6.3 The distribution side’s monthly commitments keep slipping, and stack-level packaging is still reworking at the spec layer

In the last three days of October, two lines directly related to “distribution” missed their windows at the same time: ruyi 0.54.0’s “end of October” target slipped, and openRuyi’s 2026.10 release was still unpublished as of 11-02. Neither line has stalled on the code side—openRuyi had six commits on 10-30, and ruyi had one documentation merge—so the bottleneck is the release process itself, not development.

Meanwhile, the three-piece stack-level PR #1350 has passed its sixth week and is still reworking at the spec level. Taken together, these three items point to the same structural problem: in this ecosystem, “building things” and “shipping things” are two separate capabilities. The former advances across multiple repositories simultaneously; the latter has not completed a single on-time release in nearly two months.

For RuyiAI, the most practical short-term recommendation is not to push for releases but to write the three non-standard points from section 2.3 (buddy-mlir bundling its own LLVM, triton depending on git, tilelang requiring toolchain discovery) into a packaging convention, so that reviews of #1350 do not have to re-litigate the same issues every week—only by lowering the round-trip cost can a monthly release cadence become feasible.

Source Verification Table

Source Verification Result
RuyiAI-Stack organization (all repos) pytorch: riscv branch replayed twenty commits in a second full-branch replay at 11-01 03:00, head commit 1867c9b8, baseline still 3afdbd3, no new patches; llvm-project: riscv branch replayed twenty-six commits at 11-01 23:00, including the A100 IME/AME downgrades (#30, #31), and the compare view shows the upstream baseline already contains the 10-30 commits; triton-riscv: two merges (#55, #91), five new PRs (#93 through #97), one rebase (#92), #56 resumed pushing at 10-30 20:50; tilelang-riscv silent for a seventeenth day, with only #4 remaining open; VecIntrinBench, IntrinTrans, FBGEMM, harness, cpuinfo, torq-tile, pytorch-ci, dsh-osc, skills, caffe, mxnet had no commits in the window
ruyisdk organization (all repos) ruyi main repo: 1 commit (#508 vendor naming list), no new Release, 0.54.0 still has only the 09-18 alpha tag, official release remains 0.53.0; packages-index, support-matrix, docs, ruyisdk-website, ruyi-imager, wechat-articles, attached-matrix-extension, ruyici, AME-operator had no commits in the window
openRuyi-Project organization Main repo: 6 commits (all on 10-30) + 3 PR merges (#1424 LLVM 23, #1514 ollama 0.40.7, #1545 clang-wrap 20261030); 24 open PRs had activity in the window (13 in the Prometheus batch, #1561 box64, #1559 firecracker, #1516 qemu-rustsbi, #1562 binutils RISC-V test tracking, #1563 Node.js, #1544 firefox, #1421 qemu GUI, #1350 Ruyiai three-piece set); the 2026.10 release is unpublished, and the release page returns 404
buddy-compiler organization buddy-mlir: official release 0.1.3 published at 10-31 23:01 UTC (16 commits and 136 files from v0.1.2 to v0.1.3, of which 10 are [midend][VIR] RVV vectorization) + nightly dev20261030; no commits on the main branch in the window (latest 10-29 07:08); #1011, #1013, #994 did not make it into 0.1.3
RuyiSDK developer community forum No new posts in the window; the latest is still #2899 from 10-29; biweekly progress issue 079 (10-26) is the most recent formal report, and issue 080 has not appeared
openRuyi distribution news page No new articles; the 2026.09 release announcement (09-30) is still the latest; the release paths for 2026-10 and 2026-11 both return 404
ruyi package manager / Releases 0.53.0 maintained, no new alpha or beta (0.54.0-alpha.20260918 is still the most recent); only one documentation commit on the main branch
Official homepage (ruyiai.org) No changes across the three pages: 3 items in the homepage index, 2 blog posts, 23 documentation chapters; snapshot hashes match the previous issue
ruyiai-daily Two issues in the window (10-31, 11-01), consistent with this report
Google News RSS (multiple Chinese and English queries) Zero hits for targeted queries on RuyiSDK, RuyiAI, openRuyi, and 如意 RISC-V; the latest on the “如意” side is a 10-25 summit exhibition report, which falls outside the window and is unrelated to the Ruyi community, so it was not included

Complete Source List