Research window: 2026-10-28 04:30 ~ 2026-10-29 04:30 (Beijing time, past 24 hours), directly contiguous with the previous issue (cutoff at 10-28 04:30).

Sources: Full-repository review of GitHub organizations (RuyiAI-Stack, ruyisdk, openRuyi-Project, buddy-compiler, checking commits, PRs, and Releases within the window repo by repo; upstream forks filtered by keywords such as RISC-V / RVV / XuanTie), openRuyi commit and PR merge statistics, ruyi package manager Releases, RuyiSDK developer community forum, ruyiai-daily daily intelligence archive, three-page snapshot of the official RuyiAI homepage, arXiv search, Google News RSS targeted Chinese and English queries (via proxy).

This Issue’s Index

  • Today’s Focus: K3 decode attention moved onto VIR, performance on par with hand-written RVV kernels (10-28)
  • I. RuyiAI Stack Progress (PyTorch / Triton / TileLang RISC-V adaptation)
    • 1.1 llvm-project: no more rebasing; adds “one-click rebase from author fork” workflow (10-28)
    • 1.2 pytorch: riscv branch silent for a seventh day; twenty commits on main still upstream (10-28 status)
    • 1.3 triton-riscv: anchor raised another notch; three riscv64 CI runs queued with no response (10-28)
    • 1.4 tilelang-riscv: main branch silent for a thirteenth day (10-28 status)
  • II. RuyiSDK Toolchain and Distributions
    • 2.1 openRuyi PR #1350: three commits rebased; GCC build cost quantified at 2.81x (10-28)
    • 2.2 openRuyi: 27 commits, 15 PRs merged; qemu 11.1.2 and libvirt backports landed (10-28)
    • 2.3 Review queue: KDE Frameworks 6.31, cross toolchain, Gradio 6.31 (10-28 status)
    • 2.4 ruyisdk: 0.54.0 still unreleased; package list and support matrix silent; installer UI terminology changed (10-28 status)
  • III. Vector Extensions, Architecture Testing, and Operator Optimization
    • 3.1 Vector repos and three FBGEMM repos silent; cpuinfo stuck at 05-20 (10-28 status)
    • 3.2 Vector width convention: VIR side set to 1024 bits, one LMUL 4 group per head (10-28)
    • 3.3 No new arXiv entries in window; 10-21 long-vector FlashAttention still most relevant to RVV (10-28 status)
  • IV. Buddy Compiler Updates
    • 4.1 K3 decode attention moved onto VIR: bit-exact numerics; measured K3 throughput falls in the same range (10-28)
    • 4.2 buddy-server source reorganization; Whisper example enters x64 CI (10-28)
    • 4.3 Four in review: int64 cast, Whisper preprocessing reuse, new ABI, aligning with llama-server (10-28 status)
    • 4.4 Nightly dev20261028 released, still excludes the day’s three commits (10-28)
  • V. Community, Events, and Official Homepage
    • 5.1 Official homepage unchanged across three pages; two blog posts, twenty-three doc chapters (10-28 status)
    • 5.2 No new forum posts in window; backfilling 10-27 LPi4A UEFI hands-on post (10-27)
    • 5.3 One ruyiai-daily issue; ruyi-imager changes “Manufacturer” to “Vendor” (10-28)
    • 5.4 Zero external news hits; neither openRuyi 2026.10 nor 0.54.0 released (10-28 status)
  • VI. Trend Observations
    • 6.1 From “can express” to “runs just as fast”: VIR’s first performance reconciliation using a real model kernel
    • 6.2 The cost of rebasing shifts from patch drift to governance: workflow takes over rebasing, branches still rely on people
    • 6.3 The distribution-layer debate now has a price: 2.81x build time is more persuasive than “preference”

Today’s Highlight: K3 decode attention moved onto VIR, performance on par with hand-written RVV kernels (10-28)

Date: 2026-10-28　Source: buddy-mlir PR #1014, K3 docs, triton-riscv PR #91, llvm-project rebase workflow

The most substantive step today came at 09:36: buddy-mlir’s #1014 “K3: write the decode attention in the VIR dialect” was merged (4 files, +476/−14), moving the entire decode attention of the K3 w4g32 kernel onto the VIR dialect. This is not another round of dialect capability fill-in, but the first time a real model’s kernel has been used for reconciliation—on one side the previously hand-written RVV vector kernel, on the other a VIR kernel assembled in Python, comparing numerics, instruction counts, and on-board throughput.

The approach breaks down into four layers. The construction layer no longer hand-assembles operators and hand-assembles types (previously operator names and type descriptions had to be written into strings), but instead goes through buddy_mlir.dialects.vir’s SetVLOp, load, shuffle, fma, reduce; one work item is a vir.set_vl region, with length taken as half the head dimension (64 lanes), each head being a scalable vector formed by joining the two RoPE halves, and the region returns that head’s (max, sum). The rotation layer loads, rotates, and scales q within the region, with rotate_half lowered to a single vir.shuffle, and cos/sin stored as two rows of equal-length data, so vir.from_vector is no longer needed. The memory view layer uses memref.expand_shape to split q, the KV cache, the output, and q’s normalization weights into 2×64 along the last dimension. The normalization layer (Qwen3’s q/k norm) gets its own one-dimensional vir.set_vl region, computing the sum of squares over the two halves following the _head_rmsnorm approach.

Pipeline parameters changed accordingly: kernel lowering switched from vector-width=128 to rvv-vlen=1024, use-scalable=false, with vector sizes determined by analysis based on the A100’s registers, because the region contains vir.shuffle, each head is kept as a vector group of 128 f32 (LMUL 4). The author states plainly in the PR: switching to use-scalable=true is the next commit’s job. The old _attn_decode_fn is retained, and the A210 kernel’s decode attention still uses it.

All three results are solid. On numerics, with and without q/k normalization, it is bit-identical to _attn_decode_fn; on machine code, the two parallel bodies each have 178 vector instructions, the key-value loop has the same instructions as the old version, with only two spill-reload positions changed; on-board throughput (K3, buddy-cli greedy decoding, three alternating rounds, 9 pairs of generated text fully identical) all three tiers fall in the same range—after 63 tokens, 28.26~28.49 vs. 28.10~28.58; after 458 tokens, 26.82~27.13 vs. 27.02~27.04; after 900 tokens, 25.37~25.41 vs. 25.29~25.77. The author notes: two builds of the same code can differ by up to 2%, and the ranges overlap.

Two other commits today accompany this main line. First, llvm-project’s riscv branch gained a 244-line automatic rebase workflow (see 1.1), moving the problem of “PRs on the author’s fork falling behind the baseline” from manual work into Actions. Second, triton-riscv’s dependency anchor was raised another notch by renovate to dev20261028 (see 1.3), but this nightly build was produced before this morning’s three merges, so even if this dependency update is merged, downstream still won’t get #1014—using today’s results requires waiting for the next nightly build.

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

1.1 llvm-project: No More Re-basing; Adds “One-Click Rebase of Author Forks” Workflow (10-28)

Date: 2026-10-28　Source: riscv branch commit cf00909d, full workflow text, riscv branch commit list

Unlike the previous issue’s “fifth full-branch replay in five days,” the local patch set on the riscv branch is untouched this period: the branch head advanced one commit from ed439f3e, and compared with the previous head it is 1 ahead, 0 behind, touching only 1 file. The new commit (cf00909d, authored 23:27, committed 23:54) is a pure CI asset—.github/workflows/autorebase.yml, +244/−0.

The workflow’s design intent is stated in its comments: it is installed on the default branch of the author’s source repository, run manually from Actions with a target PR number, uses the source repository’s own GITHUB_TOKEN, and requires no custom secrets or labels. It is triggered via workflow_dispatch with two inputs—the PR number (required) and “dry run only, no push” (enabled by default). It runs on ubuntu-24.04 with a 90-minute timeout; the comments explicitly require that PR code, hooks, builds, or submodules never be executed while holding write permissions, and the git config points hooksPath, attributesFile, and fsmonitor all to /dev/null, with GIT_TERMINAL_PROMPT=0 and GIT_EDITOR=true. Conflict handling has a dedicated function: for cases -Xours cannot handle (including modify/delete conflicts), it walks ls-files --unmerged entry by entry—taking the local version if stage 2 exists, deleting otherwise; during rebase it first checks whether the baseline is already an ancestor, and can recognize “equivalent patches” and discard duplicate old baseline patches.

What this addresses is a concrete cost that has recurred over the past several issues: the branch is fully replayed once a day, so PRs on the author’s fork immediately fall behind, and manual replay is both slow and prone to scrambling the patch set. The boundary needs to be clear—it rebases other people’s PRs; the branch’s own daily full replay still requires maintainer action. It reduces the cost of “following the baseline” from manual judgment to a single scheduled run with a dry run, but it does not automate the trigger condition. Its real value can only be verified when the next external PR is submitted against the new baseline.

1.2 pytorch: riscv Branch Silent for a Seventh Day; Twenty Commits on Main Still Upstream (10-28 status)

Date: 2026-10-28 (status)　Source: pytorch riscv branch, pytorch main branch

The riscv branch head is still “Add riscv64 image locally (#51)” from 10-22 03:00 (Beijing time), marking a seventh consecutive day with zero commits from 10-22 to 10-28. The two mainline proposals for upstreaming RVV capabilities (#46 vector extension support for ATen, #48 RISC-V Vector CPU capability) still have no updates this period.

The main branch saw 20 commits over the same period, all upstream syncs, none involving RISC-V: a CUDA-side fix for 64-bit indexing within max_pool3d slices, online softmax merge switched to exact exponentials, a rollback of symbolic shapes deprecated API cleanup, inductor-benchmarks images pinned to pytest 9.1.1, batch application of c10::irange to ATen native operators, and ROCm’s rocSOLVER batched syevd workspace switched to allocation from the caching allocator. This branch’s cadence matches the previous issue’s conclusion: upstream tracking is updated daily, RISC-V replays are scheduled manually.

Worth reading alongside is the distribution side: openRuyi’s #1352 is still packaging this branch’s artifacts as python-torch-ruyiai (not updated this period, stuck at 10-27). The branch is idle while the package waits—this is the most important mismatch to watch on the pytorch front right now: whether the branch will have fallen behind the upstream baseline by the time the package merges currently has no answer.

1.3 triton-riscv: Anchor Bumped Again; Three riscv64 CI Jobs Queued Without Response (10-28)

Date: 2026-10-28　Source: triton-riscv PR #91, PR #90, buddy-mlir nightly list

At 18:51, the renovate bot opened #91, bumping the upstream buddy-mlir nightly from nightly/v0.1.3.dev20261027 to nightly/v0.1.3.dev20261028, still a two-line change (+2/−2). The difference from the previous one is that it was not auto-merged: by the end of the window this PR was still open, with mergeable status unstable.

Six of eight checks have returned: all three x64 tiers (3.12, 3.13, 3.14) succeeded, as did pre-commit and clang-format; riscv64 3.12 has been running since 18:54, while 3.13 and 3.14 have been queued since the PR was opened. The previous one in the same repo (#90) was auto-merged within minutes of opening; this period’s difference comes down to the execution queue on the riscv64 side—this is infrastructure cadence, not a problem with the dependency itself.

There is also a timing detail to clarify: the build bucket for the dev20261028 nightly predates the three merges that morning (#1010 08:54, #1014 09:36, #1012 09:55), so this version does not carry the K3 decode attention work. For downstream to get #1014’s results, it must wait for the next nightly build plus another dependency update—at minimum one build cycle.

1.4 tilelang-riscv: Main Branch Silent for a Thirteenth Day (10-28 status)

Date: 2026-10-28 (status)　Source: tilelang-riscv commit list, open PR list, openRuyi PR #1350

The last commit on the main branch is still 10-16 10:52, marking a thirteenth consecutive day without commits; open PR #4 has been stalled since 09-28. The repo-side silence contrasts with triton-riscv: the latter is at least following dependencies, while the former has not even made dependency updates.

The only progress remains on the distribution side. The python-tilelang-ruyiai spec in #1350 was rebased along with the entire PR this period (see 2.1 for details), still with 4 patches: relax Apache TVM FFI 0.1.10, switch to system build dependencies, discover the buddy-mlir toolchain, and skip the z3 soname rewrite. The repo is stalled while the package advances—this state of “substituting distribution artifacts for repo iteration” has persisted for nearly two weeks.

II. RuyiSDK Toolchain and Distributions

2.1 openRuyi PR #1350: Three commits rebased, GCC build cost quantified at 2.81x (10-28)

Date: 2026-10-28　Source: openRuyi PR #1350, review comments, PR commit list

At 16:22, all three commits in the RuyiAI trio packaging PR (buddy-mlir, python-triton-ruyiai, python-tilelang-ruyiai) were rewritten within the same minute, clearly a rebase onto the latest main branch; the current scope is 9 files, +680/−0, 14 lines more than recorded in the previous issue. The PR was refreshed again at 18:15 due to review comments, now totaling 13 comments, and remains unmerged.

The most informative item this issue comes from the author’s reply at 10:41. The previous issue’s framing was “GCC can be substituted, but build time is at least 1.5x”; this issue provides measured data: on a riscv64 machine, switching buddy-mlir’s build from LLVM to GCC changed the time from 8814 seconds to 24798 seconds (about 2 hours 27 minutes versus 6 hours 53 minutes), 2.81x, and that GCC build failed at the link stage and did not complete.

This turns the debate from a matter of position into a matter of cost. “Whether to externalize the LLVM bundled with buddy-mlir” was originally a dispute between two technical approaches; it now has a number that a distribution build farm can understand: 2.81x means scheduling, machine occupancy, and timeout policies all need to be recalculated. The author’s other rationale also holds up better as a result—the LLVM used by buddy-mlir is only used within its own packages, and those packages pin specific LLVM commits, so keeping it in-package is what makes it reproducible. He also notes that triton upstream’s setup.py has a mandatory check for whether git is executable, so either a git build dependency must be added or setup.py must be patched (the latter will break as triton is upgraded).

2.2 openRuyi: 27 commits, 15 PRs merged, qemu 11.1.2 and libvirt backports land (10-28)

Date: 2026-10-28　Source: openRuyi commit list, PR #1520 qemu, PR #1519 libvirt, PR #1521 python packages, PR #1522 toolchain macro

The main repo saw 27 commits and 15 merged PRs this issue, with 9 contributors: misaka00251 with eight, Ruoqing He with four, Sun Yuechi with four, Jingiw with three, Zheng Junjie with three, Kimmy with two, and cl2t, Julian Zhu, and YunQiang Su with one each. All commits are concentrated between 11:20 and 20:49, with no new commits thereafter through the end of the window. The volume has clearly contracted versus the previous issue (45 commits), and the nature has shifted from “pre-release cleanup” to routine follow-up.

Virtualization is the most complete group this issue. qemu was upgraded from 11.1.x to 11.1.2 (#1520, merged 13:28), having been in the “under review queue” in the previous issue and landing within a day. Two libvirt commits were merged (#1519, 09:47): one ships /var/lib/libvirt/secrets with the package so that the directory virt-secret-init-encryption needs exists and virtsecretd can start; the other backports the fix for rbd pools breaking after Ceph 21 removed auth_supported. Both are patches for “installs but won’t run” class issues, which are hard indicators of distribution quality.

The packaging infrastructure side also has content. The %toolchain_major_version macro was merged (#1522, 12:36), allowing specification of toolchain major versions such as gcc-15, gcc-16, or clang-22, clang-23—which gives the cross-toolchain PR under review a place to land. A batch of python package build failures was merged (#1521, 14:02): scikit-build-core upgraded to 1.1.1, cmake gains Python distribution package metadata, ml-dtypes upgraded to 0.6.0, charset-normalizer upgraded to 3.5.2, and httptools relaxes its hard version pin on setuptools. The scikit-build-core and cmake metadata items are directly relevant to the RuyiAI stack—wheel builds for CMake extensions like triton and tilelang go through exactly this path.

Other merges: attr upgraded to 2.6.0, go backports an index optimization, python-backports-zstd removed, go-family packages follow the gcfg v2 rename to fix dependencies, python-graphql-core downgraded to 3.2.13, procps fixes the rpm name and restores uptime, a set of krb5 build options and systemd services, ceph follows the upstream snapshot, sql-migrate added, four rustvmm crate dependencies (linux-loader 0.14, vm-memory 0.18, kvm-ioctls 0.25, acpi-tables 0.2.1), and .gitignore added at the root.

2.3 Review queue: KDE Frameworks 6.31, cross toolchain, Gradio 6.31 (10-28 status)

Date: 2026-10-28 (status)　Source: PR #1513 KDE, PR #1490 cross toolchain, PR #1516 qemu-rustsbi, PR #1532 Gradio

There are 9 open PRs updated within the window. The WIP update for KDE Frameworks 6.31.0 was refreshed at 00:04 (#1513) and is still marked WIP. The cross riscv64 toolchain (#1490, Z572) was refreshed at 14:18 and is still WIP—forming a pair with the toolchain major-version macro merged this issue: the macro provides the switching entry point, the PR provides the concrete toolchain, and cross-compilation only becomes usable once both are in place. Gradio 6.31.0 and its dependency alignment (#1532), python-pyvex upgraded to 10.0.5 (#1533), and the manual provides epoch version fix for graphql-core (#1531) were all refreshed in a burst between 20:03 and 21:27. qemu-rustsbi (#1516) has two discussion threads and is preparatory work for bringing a Rust-written SBI into the virtualization stack. The rest are vkpeak (#1349) and the Prometheus v3.13 module (#1441).

2.4 ruyisdk: 0.54.0 still unreleased, package index and support matrix quiet, installer changes UI terminology (10-28 status)

Date: 2026-10-28 (status)　Source: ruyi Releases, packages-index, support-matrix, ruyi-imager commit a87b8dd9

The ruyi package manager’s main branch has had no commits since 09-25, the latest Release is still 0.53.0 from 09-24, and 0.54.0 has only the 09-18 alpha tag. The biweekly progress issue 079 stated that “0.54.0 was moved to end of October due to a release cycle adjustment”; with only two days left in the month, there is still no beta or release candidate this issue, and the delivery window is already very narrow.

packages-index had no commits within the window (the latest is the 10-26 revyos Milk-V Meles image bump), corroborating the ISCAS software source data sync issue mentioned in issue 079—built packages have not been refreshed to the public mirror, so naturally there are no batch updates on the index side. support-matrix likewise had no commits within the window; the two boards from the previous issue (SpaceMiT K3 Pico-ITX with Bianbu 4.0.8 rated good, VisionFive 2 Lite with Ubuntu 24.04.5 rated basic) remain the most recent batch.

ruyi-imager has one commit: “Rename manufacturer labels to supplier in the GUI” at 15:46, uniformly changing “manufacturer” to “supplier” in the UI. This is pre-release wording standardization, in the same category as the previous issue’s “selection dialog no longer pre-selects”—both are usability polish for the installer.

III. Vector Extensions, Architecture Testing, and Operator Optimization

3.1 Vector repos and the three FBGEMM repos go silent; cpuinfo stuck at 05-20 (10-28 status)

Date: 2026-10-28 (status)　Source: VecIntrinBench, IntrinTrans, FBGEMM, cpuinfo

All four repos relevant to this topic had zero commits during the window, and the silence has lasted a while: VecIntrinBench stuck at 02-13, cpuinfo at 05-20, IntrinTrans at 06-25, FBGEMM at 07-13. torq-tile is stuck at 04-09, dsh-osc at 09-15, and pytorch-ci has no commit records.

This means all vector-side progress this period happened elsewhere—the expression layer in buddy-mlir’s VIR, and the toolchain layer in the llvm riscv branch—rather than in the dedicated vector intrinsic testing and operator optimization repos. For a stack targeting “rising vector capability,” a long-dormant benchmark side is a latent risk: VIR can now express scalable vectors, but without a continuously scored vector intrinsic benchmark, it is hard to tell whether later optimizations are real gains or noise (issue #1014 already shows “the same code differing by 2% between two builds,” which is exactly the case that needs a stable benchmark to judge).

3.2 Vector width convention: VIR side set to 1024 bits, one LMUL 4 group per head (10-28)

Date: 2026-10-28　Source: buddy-mlir PR #1014, llvm riscv branch commit 1811501f, commit ed439f3e

#1014 sets the target vector length for kernel lowering at 1024 bits and requires that scalable vectors not be used, so each head (128 f32) occupies exactly one LMUL 4 vector group, and the vir.shuffle in that region also completes within the group—size, grouping, and instruction are all constrained by the same set of parameters. This is a technical convention worth recording this period.

This convention is one end of the same thing as the upstream backend. In the previous window, the llvm riscv branch merged #30, which lowers IME intrinsics to SpacemiT A100 dot-product instructions, and #31, which added HP/SP and pack/unpack lowering paths for A100 plus scheduling calibration. One is the backend doing instruction selection and scheduling by register; the other is the kernel expression layer sizing vectors by register. No document states whether the parameters in the two places constrain each other, and no cross-validation has been done on K3—whether this convention loosens when the switch to scalable vectors happens in the next stage (the author has said this is the next change) is the point most worth watching.

3.3 No new arXiv entries in the window; the 10-21 long-vector FlashAttention remains the closest fit to RVV (10-28 status)

Date: 2026-10-28 (status)　Source: arXiv search

A search filtered on RISC-V plus compiler, vector, and MLIR returned no new papers in the window; the latest are still the 10-23 comparison of open-ISA supercomputer architectures and the 10-22 multi-agent framework for binary lifting to canonical compiler IR. The closest fit to this period’s main thread is still the 10-21 “Reorienting the Vector Axis: Restructuring FlashAttention for Long-Vector Processors”—a FlashAttention restructuring for long-vector processors, the same class of problem as #1014’s approach of segmenting decoding attention into 64 lanes with one LMUL 4 group per head. Unfortunately, there was no follow-up in the window.

IV. Buddy Compiler Updates

4.1 K3 decode attention moved onto VIR: bit-exact numerics, K3 measured throughput in the same range (10-28)

Date: 2026-10-28　Source: buddy-mlir PR #1014, K3 documentation changes, test file

Last issue recorded the Python bindings from #1009 as “going from a buddy-opt-only feature to a programmable dialect”; this issue delivers the first real thing written with those bindings: #1014 merged (09:36), 4 files, +476/−14, of which 264 lines are new kernel implementation, 152 lines of tests, 10 lines of lowering pipeline, and 50 lines of K3 documentation.

The technical points are covered in “Today’s Highlights”; here we add only three verifiable details. First, the PR explicitly states this is a redo of the closed #998, and the redo rests on the four subsequent commits: activity-based sizing (#1000), rows (#1005), vir.shuffle (#1006), and Python bindings (#1009)—in other words, this is not an independent optimization but a one-shot stress test of the foundation laid by those four. Second, the validation is fairly rigorous: the tests do bit-level comparison of _attn_decode_fn, covering with and without threads, start offsets 0/15/16/37/70, and 0/37 when q/k normalization is enabled; the qk_norm path in test_k3_w4_moe.py also runs the VIR kernel; check-buddy 239 + 401 all pass. Third, at the machine-code level the two parallel bodies each have 178 vector instructions, the key-value loop is identical to the old version, only two spill-reload positions changed, and the q rotation went from an operation on two LMUL 2 half-groups to vfneg plus one register move.

One point to keep in check: this “performance parity” was obtained on a single K3 board, with greedy decoding, over three sequence lengths, and the author notes that two builds of the same code can differ by 2%. What it proves is that VIR no longer introduces a performance penalty—not that VIR is already better than hand-written kernels.

4.2 buddy-server source reorganization, Whisper example added to x64 CI (10-28)

Date: 2026-10-28　Source: PR #1010, PR #1012

#1010 merged at 08:54, 47 files, +349/−292—the largest change this issue. It reorganizes buddy-server by responsibility: production sources grouped into HTTP, protocol, and plugin; tests split into unit, integration, packaging, and fixtures directories; a buddy-server-core library introduced to avoid recompiling production sources for tests; and service lifecycle and route registration extracted into BuddyServerApp, leaving only argument parsing and startup in the executable entry point. This kind of refactor doesn’t affect functionality but frees up room for later interface changes.

#1012 merged at 09:55, 4 files, +92/−3, adding output validation to the Whisper example and wiring it into x64 CI. The PR notes it addresses only the Whisper and x64 part of issue #757, with the remaining examples left in that issue; it also notes that local validation depended on the build fix in #1011 (forcing the scalable VIR fragment count to int64), which itself has not yet merged—in other words, this CI green light was obtained on top of a build fix that has not yet entered the main branch.

4.3 Four under review: int64 cast, Whisper preprocessing reuse, new ABI, aligning with llama-server (10-28 status)

Date: 2026-10-28 (status)　Source: PR #1011, PR #1013, PR #1015, PR #994

Four open PRs saw updates within the window. #1011 is a build fix: under the Clang/LLVM version pinned by the repo, divideCeil returns an unsigned value, and aggregate initialization narrowing it into an int64 field raises an error; the fix casts explicitly, leaving division, vector width, masks, and layout untouched (+4/−4, one file)—small, but the prerequisite for #1012 to run. #1013 refreshed at 16:01, reusing Whisper’s preprocessing results to reduce redundant computation. #1015 refreshed at 22:53, switching buddy-server to a new ABI. #994 refreshed at 15:35, aligning buddy-server’s interface with llama-server—the earliest PR to propose this alignment direction, still unmerged.

4.4 Nightly dev20261028 released, still excludes the day’s three merges (10-28)

Date: 2026-10-28　Source: nightly dev20261028, Releases list

The nightly was published at 07:56 (v0.1.3.dev20261028). The release time precedes the morning’s three merges (#1010 08:54, #1014 09:36, #1012 09:55), so this build contains neither the K3 decode attention nor the buddy-server reorganization or Whisper CI. The 0.1.3 line has now gone four consecutive nightlies without a formal release (the most recent formal release is 0.1.2 on 10-25); the next nightly build is where #1014 first reaches downstream.

V. Community, Events, and Official Homepage

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

Date: 2026-10-28 (status)　Source: RuyiAI official homepage, Blog, Documentation

The sha256 of the homepage, blog, and documentation pages match the previous issue: 3 homepage index entries, 2 blog posts (Triton’s RISC-V port, PyTorch RISC-V CI practices), and 23 documentation chapters. No new blog posts or chapters have been added for several consecutive windows.

The gap between this side and the engineering side is even more pronounced this issue: on the same day there was VIR carrying real model kernels, an llvm branch adding the rebase workflow, and 15 merges into the distribution, yet the official content pages remain stuck at the two September articles. The K3 measured data in #1014 (on-board throughput, instruction counts, bit-level consistency) is itself ready-made material for a technical blog post, but currently exists only in the PR description and repository docs.

5.2 No new forum posts in the window; backfilling the 10-27 LPi4A UEFI hands-on post (10-27)

Date: 2026-10-27　Source: lpi4a UEFI #2896, RuyiSDK Developer Community

No new posts in the forum window; the latest post is still #2896 from 10-27. One correction here: the previous issue described the forum status as “the latest two posts stopped at the 10-22 summit recap and course lecture notes,” omitting the 10-26 biweekly progress #2895 (which was already covered in the 10-27 issue) and the 10-27 #2896, the latter of which was skipped between the two windows and is backfilled in this issue.

#2896 is titled “lpi4a UEFI,” posted by lzzhzh at 10:45 on 10-27, with six screenshots and photos: three 1366×768 system screenshots and three 1920×1440 photos. The body says an update was spotted on September 26, and the author held off for a month before flashing the LPi4A; although there is not yet a RevyOS matching the UEFI available, “at least there’s hope.” Yuxi replied “nice, nice.” The value of this post lies in documenting a real blocker in the LPi4A firmware ecosystem: the UEFI firmware can already be flashed, but the matching distribution image has not caught up—exactly the kind of status the support matrix should record but for which there were no submissions in this window.

5.3 One issue of ruyiai-daily; ruyi-imager changes “manufacturer” to “vendor” (10-28)

Date: 2026-10-28　Source: ruyiai-daily, ruyi-imager commit a87b8dd9

ruyiai-daily committed the “daily-news: 2026-10-28” issue at 06:22, continuing its daily-archived intelligence updates.

ruyi-imager committed a change at 15:46 that uniformly renames the “manufacturer” label in the UI to “vendor.” The change is small but the direction is clear: the installer targets board suppliers rather than chip manufacturers, so the wording is tightened to match the actual semantics. No other commits in the remaining repositories during the window—harness stopped at 10-27, ruyisdk-website at 10-23, wechat-articles at 10-26, and both docs and attached-matrix-extension saw no activity.

5.4 Zero external news hits; neither openRuyi 2026.10 nor 0.54.0 released (10-28 status)

Date: 2026-10-28 (status)　Source: Google News RSS, openRuyi distribution news page, openRuyi tags

Targeted Google News queries in Chinese and English for RuyiSDK, RuyiAI, openRuyi, and Ruyi RISC-V returned zero hits in the window; the latest result for “Ruyi RISC-V” was a 10-25 summit exhibition report (Yixing Intelligence), which falls outside the window and is unrelated to the Ruyi community, so it is not included in this issue.

On the distribution side, both versions remain outside the window. The latest entry on the openRuyi news page is still the 2026.09 release announcement (9-30), the repository tags stop at 2026.09-experimental, and 2026.10 has not been released. ruyi’s 0.54.0 only has the 09-18 alpha tag; per the issue 079 wording, the official release is expected at the end of October. Following the pace of previous months (6-30, 7-23, 8-27, 9-30), the October release will most likely land at the end of this month; with two days left until month-end, the next issue is the last chance to verify this.

VI. Trend Watch

6.1 From “can express” to “runs just as fast”: VIR performs its first performance reconciliation against a real model kernel

Over the past three issues, this thread has been filling in expressiveness: on 10-26, seven commits in one night added scalable vectors; on 10-27, Python bindings were added; on 10-28, the entire K3 decode attention was ported over, with on-board throughput reconciled. The significance lies in the combination of three numbers—bit-level numerical consistency, identical instruction counts (178 each), and overlapping throughput ranges. Homegrown dialects most easily get stuck at “runs but slow,” and #1014 at least proves this hurdle has been cleared for now.

But two things are still missing to judge whether this stack can truly replace hand-written kernels. First, coverage: only decode attention was ported this time; the A210 kernel still uses the old function, and the MoE, quantization, and prefill paths remain untouched. Second, scalable vectors: this issue explicitly disables use-scalable; once enabled in the next commit, vector size will no longer be determined at compile time, the LMUL 4 grouping assumption will loosen, and whether numerical values and instruction counts can hold will need to be reconciled again. Until then, treating “VIR has caught up with hand-written kernels” as a conclusion is premature; the accurate statement is “caught up in the K3 decode attention segment, at a fixed vector length.”

6.2 The cost of rebasing shifts from patch drift to governance: the workflow takes over rebasing, but the branch itself still relies on people

On the same day, the llvm riscv branch stopped full-branch replay and switched to a 244-line automated rebase workflow. This shift deserves a separate note: the pace over the past five days was “one full-branch replay per day, rewriting twenty commits each time,” with author dates unchanged, committer dates unified, and no new functionality in the patch set itself. This approach keeps up with upstream, but the cost is that external contributors’ PRs are always one step behind—anyone who wants to submit must replay it themselves.

The new workflow turns this into a dispatch of “fill in the PR number, dry-run by default, one-click push,” always taking the riscv side on conflicts, automatically discarding duplicate patches, and never executing PR code or builds. It does not solve the branch’s daily following, but it separates part of “the cost of following the baseline” from the maintainer’s manual judgment. What to watch next is whether external PRs actually increase as a result—if no external PR is submitted against the new baseline within two weeks of the workflow going live, that would indicate the bottleneck is not the rebase tool but something else.

6.3 The distribution-layer debate now has a price: a 2.81× build-time ratio is more persuasive than “preference”

#1350 has been debated for nearly a month, with the core disagreement being whether buddy-mlir’s bundled LLVM should be externalized. The previous issue’s framing was still “GCC can be used, but at least 1.5× the time”; this issue the author provides measurements: on riscv64, 8814 seconds becomes 24798 seconds, 2.81×, and the GCC run failed to link and did not complete. The nature of the debate has thus changed—from technical preference to build-farm scheduling arithmetic.

The lesson for the RuyiAI stack is not in the conclusion but in the method: many disagreements in RISC-V distribution packaging (whether to vendor, whether to externalize the toolchain, whether to ship IR with the package) ultimately come down to three measurable numbers—build time, image size, and reproducibility. Last issue, openRuyi withdrew the “ship LLVM IR with the package” route; this issue, #1350 uses 2.81× to defend “keep LLVM in the package.” The two judgments point in opposite directions, but rest on the same kind of cost accounting. The next thing to watch is whether this PR can be merged with this number attached—if not, it would indicate the distribution’s tolerance for build duration is lower than the author expects, and that is what truly needs adjusting.

Source Verification Table

Source Verification Result
RuyiAI-Stack organization (all repos) llvm-project: riscv branch has 1 new commit (cf00909d, rebase workflow +244/−0), local patch set unchanged; pytorch: riscv branch has zero commits for the seventh consecutive day, main branch’s 20 commits are all upstream; triton-riscv: 1 dependency update PR #91 (not merged); tilelang-riscv silent for the thirteenth day; ruyiai-daily one issue; harness, FBGEMM, cpuinfo, VecIntrinBench, IntrinTrans, torq-tile, pytorch-ci, dsh-osc, skills, SyncBots-DeepAgents, caffe, mxnet have no commits in the window
ruyisdk organization (all repos) ruyi-imager 1 commit (UI terminology unification); packages-index, support-matrix, docs, ruyisdk-website, wechat-articles, attached-matrix-extension, ruyici, AME-operator have no commits in the window; ruyi main repo has had no commits and no new Release since 09-25 (0.53.0 maintained)
openRuyi-Project organization openRuyi main repo 27 commits (misaka00251 8, Ruoqing He 4, Sun Yuechi 4, Jingiw 3, Zheng Junjie 3, Kimmy 2, remaining 3 people 1 each) + 15 PRs merged; includes qemu 11.1.2, two libvirt commits, toolchain major-version macros, python packaging batch; 9 open PRs updated (including two RuyiAI ones, of which #1350 has three commits rebased); no new tags (2026.09-experimental is the latest)
buddy-compiler organization buddy-mlir 3 merged (#1014 K3 decode attention, #1010 buddy-server reorganization, #1012 Whisper x64 CI) + nightly v0.1.3.dev20261028; 4 open PRs updated (#1011, #1013, #1015, #994); buddy-benchmark, buddy-examples, compiler-eval, FeGen, gemmini, firesim have no commits in the window
RuyiSDK developer community forum No new posts in the window; latest #2896 “lpi4a UEFI” (10-27 10:45) was missed in the previous issue and is backfilled here; biweekly progress issue 079 (10-26) is the most recent formal report, issue 080 expected in early November
openRuyi distribution news page No new articles; the 2026.09 release announcement (9-30) remains the latest; repo tags stop at 2026.09-experimental, 2026.10 not released
ruyi package manager / Releases 0.53.0 maintained, no new alpha or beta (0.54.0-alpha.20260918 remains the most recent); main branch has had no commits since 09-25
Official homepage (ruyiai.org) Three pages unchanged: homepage index 3 items, blog 2 posts, docs 23 chapters, sha256 identical to the previous issue
arXiv (RISC-V) No new entries in the window; latest are the 10-23 open ISA supercomputing comparison and the 10-22 binary lifting to compiler IR framework; the 10-21 long-vector FlashAttention remains the most relevant to RVV
Google News RSS (multiple Chinese and English queries) Zero hits for RuyiSDK, RuyiAI, openRuyi, and Ruyi RISC-V targeted queries; the latest “Ruyi RISC-V” item is a 10-25 summit exhibition report, which falls outside the window and is unrelated to the Ruyi community, so it is not included

Complete Source List