test(gpu-vulkan): Vulkan compute (lavapipe software driver) operator carpet

[Lfan-ke]

Overview

apps/starry/gpu-vulkan: a per-binding Vulkan compute carpet on StarryOS. Vulkan runs as a CPU software implementation - Mesa lavapipe (the vulkan-swrast driver) provides a real Vulkan compute queue over llvmpipe's LLVM CPU JIT, so no host GPU is required. The on-target gate builds and runs the native C and C++ carpets on all four arches (x64/aa/la/rv); Rust (ash) and Python (pyvulkan / kompute) cells form the host reference layer.

Cells and assertions

Cell	Binding	Assertions	Gate
vulkan_c	Vulkan C API (vulkan/vulkan.h)	114	on-target (x64/aa/la/rv) + host
vulkan_cpp	Vulkan-Hpp (vulkan/vulkan.hpp)	54	on-target (x64/aa/la/rv) + host
vulkan_rust	ash 0.38	115	host reference
vulkan_py	pyvulkan + numpy	191	host reference
kompute_py	Kompute (kp) + numpy	72	host reference (x64/aa only)

Total: 546 assertions.

Coverage

Each cell covers the Vulkan compute API end to end: instance / physical-device / device / queue / buffer / device-memory (map/flush/invalidate) / shader-module / descriptor-set-layout / pipeline-layout / compute-pipeline / descriptor-pool / command-buffer / fence / semaphore / event / query-pool / push-constant / dispatch / indirect-dispatch / timestamp / transfer commands, plus core-1.1 *2 queries. Operators (vector-add, saxpy, element-multiply, local-memory reduction) are dispatched as real GLSL compute shaders and every output element is compared to the closed-form / numpy reference. Boundary cases and error paths are asserted directly; where lavapipe permits a case the assertion records it as PERMITTED rather than faking a rejection.

Backend and runtime

Provisioned from Alpine edge as musl packages: mesa-vulkan-swrast (lavapipe), vulkan-loader, vulkan-headers and glslang/shaderc (GLSL to SPIR-V), plus the llvm-libs closure lavapipe links against. Alpine edge builds mesa-vulkan-swrast for all four arches, so the C and C++ carpets run on-target on every arch. prebuild.sh cross-compiles them against the provisioned musl headers/libraries under qemu-user, compiles the GLSL shaders to SPIR-V, and stages the binaries plus the mesa closure into the per-arch rootfs.

Gate

programs/run_all.sh runs every native carpet and requires both a clean exit (rc == 0) and the exact final <name> OK <n> marker. A carpet that prints its marker and then aborts in teardown (non-zero exit after the last assertion) fails the gate. TEST PASSED is printed only when all built carpets pass both conditions.

On-target StarryOS (single-core)

aa/rv/la/x64 pass the native C and C++ carpets (228 assertions each). StarryOS runs one vCPU; run_all.sh pins the mesa thread pool with LP_NUM_THREADS=1 and prints the detected CPU count. The carpets assert numerical correctness and API ordering semantics, not throughput. x64 on-target runs via the CI ESP path.

[mai-team-app]

评审总结

本 PR 在 apps/starry/gpu-vulkan/ 下新增了一个 StarryOS Vulkan 计算算子地毯式测试应用，通过 conda-forge 的 Mesa lavapipe（软件 Vulkan 驱动，LLVM 20 llvmpipe CPU JIT）+ kompute Python 绑定在 StarryOS 上运行 33 个真实 GLSL compute shader 算子。整体方向正确，应用放置路径 apps/starry/gpu-vulkan/ 符合项目规范，非 x86_64 架构上的诚实回退逻辑（打印 no-Vulkan 说明后以 TEST PASSED 收场）设计合理。

CI 状态

CI workflow 全部实质性任务被 path filter 跳过（仅 "Detect changed paths" 和 "Cancel stale CI runs" 成功），因为本 PR 只涉及 apps/starry/gpu-vulkan/ 下的非 Rust 代码。这是预期的 CI 行为，不视为 PR 引入的 CI 故障。

重复/重叠分析

• git grep gpu-vulkan 在 dev 分支无任何已有代码，这是全新应用。
• GitHub 搜索 repo:rcore-os/tgoskits type:pr state:open gpu-vulkan 只有本 PR #1575，无重叠或冲突 PR。

本地验证

本 PR 不含 Rust 代码变更，无需 cargo fmt --check / cargo clippy。由于容器环境难以搭建 conda-forge Mesa lavapipe + kompute 完整 Vulkan 计算栈（需要 LLVM 20、mesalib 25.0.5、SPIR-V 编译器等），未能在本环境运行完整的 QEMU 测试。

阻塞问题

以下问题需要修复后重新评审：

1. README aarch64 声明与代码行为矛盾（见行内 comment）：README 声称 cargo xtask starry app qemu -t gpu-vulkan --arch aarch64 # 1/1 (33 operators)，但 prebuild.sh 为非 x86_64 架构默认禁用 conda（PYSCI2_CONDA=0），且 PR 正文明确指出 kompute 无 linux-aarch64 conda 包。实际 run_vk.py 在 aarch64 上将输出 GPU_OK=0/0 而非 33 个算子。aarch64 应与 riscv64/loongarch64 一样标注 NOTE: no Vulkan distribution。

2. prebuild.sh 文件头注释错误（见行内 comment）：文件头（第 2-23 行）描述的是 "py-sci2 carpet (SciPy / SymPy)" 的工作流，提及 scipy、sympy、numba、openblas、libgfortran 等与 Vulkan 计算完全无关的包。实际脚本安装的是 Mesa lavapipe + vulkan-loader + kompute。这是从 py-sci 复制粘贴后未更新的残留，会严重误导维护者。

3. README 中 "py-sci2" 引用不存在：第 27 行提到 "py-sci2 已证 conda-forge glibc 二进制可跑"，但仓库中并无名为 py-sci2 的应用（实际为 py-sci）。

非阻塞建议

• prebuild.sh 中的变量名 PYSCI2_CONDA、PYSCI2_ROOTFS_SIZE、PYSCI2_CONDA_DL 等前缀来自 py-sci，建议改为 GPU_VULKAN_* 或通用名称以提升可维护性。conda 下载缓存目录 ${XDG_CACHE_HOME:-$HOME/.cache}/py-sci2-conda 同理。

结论

请修复上述文档与代码一致性问题后重新请求评审。修复后建议在 x86_64 QEMU 上实际运行一次 cargo xtask starry app qemu -t gpu-vulkan --arch x86_64 确认 TEST PASSED 与 GPU_OK=1/1 输出。

Powered by deepseek-v4-pro

[Lfan-ke]

Closing to re-deliver as a single comprehensive, industrial-grade GPU/compute suite: full API/interface coverage across every backend, plus model-inference correctness (not smoke) and parallel-compute test cases. This operator-level carpet is superseded by that forthcoming work.

[Lfan-ke]

Replaced the initial smoke test with a per-API Vulkan compute carpet across five bindings (C/vulkan.h, C++/vulkan.hpp, Rust/ash, Python/pyvulkan, Kompute). Each cell enumerates the compute-relevant Vulkan API against the real headers - instance/physical-device/device/queue, buffer+memory alloc/map, SPIR-V shader module, descriptor set layout+pool, compute pipeline, command buffer, direct and indirect dispatch, pipeline barriers, fences/semaphores/events, timestamp query, and the 1.1 *2 query variants - and checks each operator (vadd, saxpy incl alpha 0, mul, reduction over 1M-element grids) element-wise against numpy/closed-form, plus boundary and VkResult error paths.

Host: 546 assertions on Mesa lavapipe (LLVM 20). On-target StarryOS single-core: the native C (114) and C++ (54) cells run on x64/aa/la/rv via Alpine mesa-vulkan-swrast (Mesa 26.1.1 + vulkan-loader 1.4.347), 168 assertions per arch, all TEST PASSED (qemu 21-57s per arch). Rust/pyvulkan/Kompute are host-reference; Kompute has upstream binaries for x64/aa only (noted in prebuild).

Addressed the review: the prebuild header comment now describes this app (no unrelated references), the Kompute arch limitation is documented, and the Rust cell is cargo-fmt clean.

[mai-team-app]

评审总结

本 PR 在 apps/starry/gpu-vulkan/ 下新增了 StarryOS Vulkan 计算地毯式测试应用。当前代码版本（commit eddeef04）已从前次评审的 kompute+conda-forge 版本演化为跨五个绑定（C/Vulkan.h, C++/Vulkan-Hpp, Rust/ash, Python/pyvulkan, Kompute）的 Vulkan API 全面覆盖测试，通过 Alpine edge 的 musl 包（mesa-vulkan-swrast + vulkan-loader）为全部四个架构提供 on-target C/C++ 地毯，Rust/Python/Kompute 为 host 参考层。前次评审指出的三个问题（prebuild.sh 文件头残留 py-sci2 内容、README 中 py-sci2 引用不存在、aarch64 声明与代码行为矛盾）已在当前 head 中全部修复。

重复/重叠分析

• 在 dev 分支上 git grep gpu-vulkan 无已有代码，这是全新应用。
• 然而，同一作者创建了 PR #1574（apps/starry/gpu-compute），其 PR 正文明确声明："This supersedes the earlier per-backend carpets (#1575 Vulkan, #1576 wgpu, #1578 WebGPU) by consolidating them into one app." PR #1574 是一个更大的 PR（38,724 行新增，91 个文件），将 Vulkan 与 OpenCL、OpenGL/GLES、wgpu、WebGPU 合并为一个统一的 gpu-compute 应用。

阻塞问题

PR #1574 声明取代本 PR：PR #1574 的正文明确指出它将本 PR (#1575) 作为被取代的早期单后端地毯之一。如果作者确实认为 #1574 是 #1575 的取代品，则本 PR 不应合并；如果作者改变了想法并希望两个 PR 各自独立合并，则需要：

1. 更新 PR #1574 的正文，移除对 #1575 的 "supersedes" 声明。
2. 确认两个应用（gpu-vulkan 和 gpu-compute）在功能上没有冲突，且 gpu-compute 中的 Vulkan 部分与 gpu-vulkan 不会产生重复文件或冲突。

非阻塞建议

• PR 正文过时：PR 正文仍描述最初的 kompute+conda-forge 版本（33 断言、mesalib 25.0.5、run_vk.py 等），而当前代码已是完全不同的 per-binding API 地毯（546 断言、Alpine musl 供应、多绑定覆盖）。建议更新 PR 正文以匹配当前代码。
• x86_64 build config 与其他架构不一致：build-x86_64-unknown-none.toml 缺少 ax-runtime/display、ax-runtime/rtc、ax-driver/serial、starry-kernel/input、starry-kernel/vsock 等 feature，而其他三个架构均有。如果这是因为 x86_64 使用不同的 boot 路径（如 CI ESP path），建议在文件注释中说明。

CI 状态

所有实质性 CI job 被 path filter 跳过（success=2 为 "Detect changed paths" 和 "Cancel stale CI runs"，skipped=5 为 "Check formatting"、"Run sync-lint"、"Run spin-lint"、"Publish base container image"、"Publish axvisor-lvz container image"，in_progress=3 预计也将被跳过）。这是预期行为，因为本 PR 只涉及 apps/starry/gpu-vulkan/ 下的非 Rust 代码。

环境限制

本 PR 的 on-target 验证需要 qemu-user-static + Alpine edge repos + Mesa lavapipe 供应，当前 reviewer 容器环境不支持完整运行。PR 作者声称全部四个架构通过（"all TEST PASSED"），但无法在本地验证。

结论

请先解决与 PR #1574 的关系后再重新请求评审。如果两个 PR 各自独立，请更新 #1574 正文并确认无冲突；如果 #1574 确实取代 #1575，请关闭本 PR。

Powered by deepseek-v4-pro

[ZR233]

上轮文档/Kompute 架构说明已经在当前 head 修正，58 个 current-head CI check 通过；但 on-target runner 仍忽略 C/C++ carpet 的非零退出状态，只凭输出 marker 判定，因此存在确定性的假阳性路径。

[mai-team-app]

评审总结

本 PR 在 apps/starry/gpu-vulkan/ 下新增了 StarryOS Vulkan 计算地毯式测试应用，通过 Alpine edge musl 包（mesa-vulkan-swrast + vulkan-loader）为全部四个架构（x86_64 / aarch64 / riscv64 / loongarch64）提供 on-target 原生 C/C++ 地毯，并以 ash/pyvulkan/kompute 作为 host 参考层。整体代码质量良好：prebuild.sh 的供应逻辑清晰稳健，run_all.sh 的出口状态检查已修复（当前 head 同时要求 rc == 0 与 OK <n> marker），QEMU 配置覆盖四架构，C/C++/Rust/Python 地毯代码覆盖了完整的 Vulkan 计算 API 表面。

三轮历史评审指出的文档一致性问题（prebuild.sh 文件头 py-sci2 残留、README 中 py-sci2 引用、aarch64 声明与代码矛盾）已在当前 head 中全部修复。ZR233 指出的 runner 忽略非零退出状态问题也在当前 head 修复。

CI 状态

所有实质性 CI job 被 path filter 跳过（success=2 为 "Detect changed paths" 和 "Cancel stale CI runs"，其余均为 skipped）。这是预期行为，因为本 PR 只涉及 apps/starry/gpu-vulkan/ 下的非工作区 Rust 代码。

重复/重叠分析

• git grep gpu-vulkan 在 dev 分支无已有代码，这是全新应用。
• PR #1574（apps/starry/gpu-compute）仍处于 open 状态，其 PR 正文明确声明 "This supersedes the earlier per-backend carpets (#1575 Vulkan, #1576 wgpu, #1578 WebGPU) by consolidating them into one app." 同时作者在此 PR 上也曾留言 "Closing to re-deliver as a single comprehensive...suite"。PR #1574 是一个 91 文件 / 38,801 行的大型 PR，已包含本 PR 的 Vulkan C/C++ 覆盖并扩展至 OpenCL/OpenGL/GLES/wgpu/WebGPU。

阻塞问题

PR #1574 声称取代本 PR：PR #1574 的 "supersedes" 声明尚未更新，且作者历史上曾表示要关闭本 PR 以交付统一套件。当前两个 PR 同时 open 且都活跃更新，关系不明确：

• 如果作者现在认为两个 PR 应各自独立合并（gpu-vulkan 为 Vulkan 专用、gpu-compute 为多后端统一），需要：
  1. 更新 PR #1574 的正文，移除对本 PR 的 "supersedes" 声明
  2. 确认两个应用（gpu-vulkan vs gpu-compute）在功能上没有冲突或冗余
• 如果 PR #1574 确实取代本 PR，则本 PR 不应合并，应关闭。

非阻塞建议

• PR 正文过时：PR 正文仍描述最初的 kompute+conda-forge 版本（33 断言、mesalib 25.0.5、run_vk.py 等），而当前代码已是完全不同的 per-binding API 地毯（546 断言、Alpine musl 供应、多绑定覆盖）。建议更新 PR 正文以匹配当前代码。
• x86_64 build config 与其他架构不一致：build-x86_64-unknown-none.toml 缺少 ax-runtime/display、ax-runtime/rtc、ax-driver/serial、starry-kernel/input、starry-kernel/vsock 等 feature，而其他三个架构均有。如果这是因为 x86_64 使用不同的 boot 路径（如 CI ESP path），建议在文件注释中说明。

结论

请先解决与 PR #1574 的关系后再重新请求评审。代码质量和测试覆盖本身没有阻塞问题。

Powered by deepseek-v4-pro

[mai-team-app]

评审结论

本 PR 在 apps/starry/gpu-vulkan/ 新增了基于 Alpine musl Mesa lavapipe 的 StarryOS Vulkan 计算应用：prebuild.sh 通过目标架构的 qemu-user 安装运行库并交叉编译 C/C++ carpet，QEMU 配置在四个架构启动 StarryOS，Rust/Python/Kompute 作为 host reference。改动范围基本隔离在新应用目录内，base 分支没有同名实现。

阻塞问题

1. runner 失败时仍以退出码 0 结束（apps/starry/gpu-vulkan/programs/run_all.sh:48）。虽然当前 QEMU 配置依赖 fail_regex 捕获 TEST FAILED，但脚本本身在任一 carpet 返回非零、输出 marker 缺失或所有 carpet 缺失时只打印失败 marker，随后仍以最后一个 echo 的状态码 0 退出。这违反 README/脚本所声称的“clean exit + marker”门禁，也会使直接运行 /usr/bin/run_all.sh、未来不使用该 regex 的 runner 或上层脚本把失败误判为成功。请在失败分支显式 exit 1（成功分支显式 exit 0），并保留 fail_regex 作为日志层面的补充，而不是唯一失败传播机制。

2. 当前 head 的实际 StarryOS/QEMU 工作流没有可核验的运行证据。本 PR 新增的是 app-facing QEMU 工作流，不能只用 shell 语法、TOML 解析或通用 CI 结果证明可用；应至少运行文档中的 cargo xtask starry app qemu -t gpu-vulkan --arch x86_64（并覆盖一个非 x86_64 架构），确认 guest 中 C/C++ carpet 真正执行、每个 <name> OK <n> 出现、最终 TEST PASSED 且命令失败传播正确。当前 head 的 59 个 check run 为 success=29、skipped=29、cancelled=1，未见该新增 app 的专门执行证据；本地环境也未能完成 Alpine/Mesa/qemu-user 供应链，因此不能把作者在 PR comment 中的历史声明当作当前 head 的验证替代。请补充可复现的当前 head 运行结果，或在 CI 中接入该 app 的实际测试覆盖。

其他检查

• 已阅读 base AGENTS.md、book/guideline/code-quality.md 与完整 review-single-pr 规范；本 PR 不涉及 Starry syscall ABI，因此 starry/syscall.md 不适用。
• prepare-review 已确认 workspace 为 d9f9edb8be1cba3489a9a3b95be289f4bb5619ae，对比基线为 origin/dev；git diff --check、bash -n apps/starry/gpu-vulkan/prebuild.sh apps/starry/gpu-vulkan/programs/run_all.sh、全部 TOML 解析及 Rust carpet cargo fmt --check 均通过。
• 已检查此前评论：文档残留、aarch64 描述和 #1574 supersedes 关系在当前文件/PR 描述中已部分修正；但 runner 的失败退出语义仍需补强。#1574 当前已将 Vulkan 列为独立 per-backend PR，暂按互补而非重复处理，不过合并前请继续保持两边的范围说明一致。
• 本地限制：容器没有完整 StarryOS Alpine edge/Mesa lavapipe 多架构运行环境，故未把语法检查冒充运行验证。

Powered by gpt-5.6-luna

[mai-team-app]

阻塞（失败传播）：这里在打印 TEST FAILED 后仍以退出码 0 结束。任一 carpet 返回非零、marker 缺失或没有构建出 carpet 时，直接运行 /usr/bin/run_all.sh 会被上层当作成功；当前 QEMU 只是额外依赖 fail_regex 捕获日志，不能替代进程退出状态。请在失败分支显式 exit 1，成功时显式 exit 0，使 runner 本身满足文档所说的 clean-exit 门禁。

[ZR233]

本轮复审确认，上次 ZR233 指出的 carpet 退出码捕获问题已经修复：当前 run() 会立即保存 $?，并同时要求 rc == 0 与 OK <n> marker。该应用的实现路径也已清晰：prebuild.sh 为四个目标架构准备 Alpine musl Mesa lavapipe 运行时并构建 C/C++ carpet，四份 QEMU 配置以 TEST PASSED/TEST FAILED 分类 guest 结果，Rust/Python/Kompute 保持 host reference。

当前仍有一个阻塞的失败传播问题：run_all.sh 最后的失败分支只打印 TEST FAILED，随后脚本仍以 echo 的 0 退出码结束。复现实验直接按当前尾部逻辑设置 fail=1, pass=1, total=2，得到 TEST FAILED 和 runner_tail_rc=0。现有 QEMU TOML 的 fail_regex 可以在当前 xtask 路径补充识别日志，但脚本本身仍违反 README 所描述的 clean-exit 门禁，也会让直接调用或未来不带该 regex 的上层误判成功。请在成功/失败分支分别显式 exit 0 / exit 1，并在修复后运行当前 head 的实际 app 路径（至少 x86_64 及一个非 x86_64 架构），确认 C/C++ carpet、最终 marker 和外层退出状态都正确传播。

本地检查：git diff --check origin/dev...HEAD、两份 shell 脚本 bash -n、8 份 TOML 解析、Rust carpet cargo fmt --check 均通过。当前 CI 的格式、clippy、通用 Starry 四架构 QEMU 等相关基础检查通过，但没有执行 cargo xtask starry app qemu -t gpu-vulkan ... 这一新增应用工作流，因此未把通用 CI 当作 app 运行证据。本轮未重复运行完整 app，因为上述确定性 runner 门禁缺陷已使当前 workflow 的退出语义不满足合并要求。

CI 中 Test starry self-hosted board jl-lsgd2k10 / run_host 的失败与本 PR 无关：日志连续约 6 小时仅报告没有可用 JL-LSGD2K10 板卡，尚未进入 PR 应用逻辑，已用 #1666 跟踪该基础设施问题。

重复/重叠方面，origin/dev 没有同名 Vulkan 应用；相关开放 PR #1574 当前已明确限定为 OpenCL，并把 #1575 列为独立 per-backend PR，路径和后端职责互补，不再构成 superseded/duplicate 阻塞。历史文档问题和旧的退出码捕获线程均已在当前代码中失效，可在本轮结束时关闭；当前行上的脚本最终退出状态问题仍需保留。

[ZR233]

【阻塞｜失败传播】这里的失败分支只执行 echo "TEST FAILED"，因此脚本最终仍返回 0；按当前尾部逻辑设置 fail=1 可稳定复现 TEST FAILED 后 runner_tail_rc=0。虽然四份 QEMU 配置目前用 fail_regex 捕获该文本，但 runner 自身仍会让直接调用或未来不带该 regex 的上层把 carpet 失败误判为成功，也不符合 README 的 clean-exit 门禁。请把分支展开，在成功时显式 exit 0、失败时显式 exit 1，保留 fail_regex 作为日志层补充，并用实际 cargo xtask starry app qemu -t gpu-vulkan ... 验证外层能收到非零状态。