ROCm の構造と寄与の層
ROCm Structure and Contribution Layers
`gfx900` 個別事例を越えて、ROCm 一般の設計思想・support の分離・repo 統合・AMD / community の寄与構造を、GitHub 一次資料から読み解くページです。
A public page that steps beyond the `gfx900` case and reads ROCm's general design model, support splitting, repository consolidation, and AMD/community contribution structure from GitHub-side primary evidence.
GitHub-side evidence
ROCm-wide structure
Updated: 2026-03-15
要点: ROCm は GitHub 上で単一 monolith ではなく、release manifest、super-project、super-repo、component repo、retired repo が重なる layered stack として見える。support 問題や contribution も一枚岩ではなく、build・component・driver/user space・source-build 補修・repo 再編の層ごとに役割が分かれている。
Key point: On GitHub, ROCm looks less like a single monolith and more like a layered stack of release manifests, super-projects, super-repos, component repositories, and retired repositories. Support and contribution also split by layer: build, component policy, driver/user space, source-build repair, and repository reorganization.
このページは内部 investigation note rocm-common-investigate_github.md を public 向けに圧縮したものです。private issue や社内意思決定は推定せず、公開一次資料と local clone から確認できる範囲に限って述べています。
This page is a public condensation of the internal investigation note rocm-common-investigate_github.md. It does not reconstruct private issues or internal decisions, and stays within what can be confirmed from public sources and local clones.
このページの立場
How to read this page
`rocm-history` との違い
Different from `rocm-history`
年表中心ではなく、履歴から見える構造軸を整理します。時間順の出来事より、「support がなぜ層ごとに分かれて見えるか」に重点があります。
This page is not primarily chronological. It extracts the structural axes visible in the history, especially why support appears split across layers.
`reveal-hypothesis` との違い
Different from `reveal-hypothesis`
`gfx900` を入口にした仮説検証そのものではなく、ROCm 一般の設計モデルと寄与構造を public evidence から読む補助ページです。
This is not the hypothesis-testing page built around `gfx900` itself. It is a companion page for reading ROCm's wider design model and contribution structure from public evidence.
言い切らない範囲
What stays unresolved
GitHub 上の visible surface だけを扱うため、private planning や internal review を再構成するものではありません。
Because it uses only GitHub-visible evidence, it does not reconstruct private planning or internal review.
結論サマリ
Summary conclusions
- ROCm は GitHub 上で layered / multi-repo stack として自己定義されている。
- ROCm presents itself on GitHub as a layered, multi-repo stack.
- `support` は build、component、package、driver / user space で分離して見える。
- “Support” appears split across build, component policy, package contents, and driver/user-space compatibility.
- official 側では build entry point と repo topology の統合が進んでいる。
- The official side is moving toward more consolidated build entry points and repository topology.
- AMD と community の寄与は単一の ownership story ではなく、整理・統合、issue 可視化、fallback 補修など層ごとに違って現れる。
- AMD/community contribution does not reduce to one ownership story; it appears by layer through consolidation, issue surfacing, fallback repair, and related work.
観測された構造
Observed structure
flowchart TD
ROOT["ROCm\n(release manifest / default.xml)"]
ROOT --> TR["TheRock\nCMake super-project\nsource builds"]
ROOT --> RS["rocm-systems\nsystems monorepo\nROCR-Runtime migrated here"]
ROOT --> RL["rocm-libraries\nlibraries umbrella\nTensile migrated here"]
ROOT --> COMP["compiler / portability\nllvm-project / HIP"]
RL --> M["MIOpen\n(solver registry)"]
RL --> T["Tensile / rocBLAS\n(GEMM / linear algebra)"]
RL --> H["hipBLASLt / CK\n(optimized paths)"]
COMP --> R["rocMLIR\n(MLIR backend)"]
style ROOT fill:#e8f4f8,stroke:#0B3C5D
style TR fill:#e8f8ee,stroke:#1B7A3D
style RS fill:#e8f8ee,stroke:#1B7A3D
style RL fill:#e8f8ee,stroke:#1B7A3D
style COMP fill:#f0f0ff,stroke:#5B4B8A
Fact
Interpretation
Open Question
1. ROCm は layered / multi-repo stack として自己定義されている
1. ROCm defines itself as a layered / multi-repo stack
- Fact: `ROCm/README.md` は ROCm を drivers / development tools / APIs の collection と記述し、`default.xml` と `repo` tool を source management の前提としている。
- Fact: `ROCm/README.md` describes ROCm as a collection of drivers, development tools, and APIs, and treats `default.xml` plus the `repo` tool as the baseline for source management.
- Fact: `TheRock/README.md` は `A CMake super-project for HIP and ROCm source builds` を掲げ、contributors / researchers / advanced users を対象にしている。
- Fact: `TheRock/README.md` explicitly presents itself as `A CMake super-project for HIP and ROCm source builds`, aimed at contributors, researchers, and advanced users.
- Fact: `rocm-systems/README.md` は system projects の migration status と source-of-truth table を公開している。
- Fact: `rocm-systems/README.md` publishes migration-status and source-of-truth tables for systems projects.
- Interpretation: ROCm の public GitHub surface は、release manifest、super-project、super-repo、component repo が重なる layered topology として読むのが自然である。
- Interpretation: ROCm's public GitHub surface is naturally read as a layered topology of release manifests, super-projects, super-repos, and component repositories.
- Open Question: `rocm-libraries` 側の umbrella 化は、今回の local snapshot だけでは均一に追えていない。
- Open Question: The umbrella direction on the `rocm-libraries` side is not yet evenly traceable from the current local snapshot alone.
Fact
Interpretation
Open Question
2. `support` は build / component / driver-user space で分離して見える
2. “Support” appears split across build / component / driver-user space
- Fact: `TheRock#1414` は unsupported target でも hipBLASLt が default arch で build される振る舞いを問題化している。
- Fact: `TheRock#1414` raises the problem that hipBLASLt still gets built for a default architecture even when the requested target is unsupported.
- Fact: `TheRock#1975` は、super-project 側で target が空でも component default に fall back して incompatible package ができる問題を整理している。
- Fact: `TheRock#1975` explains how a super-project can still produce incompatible packages when empty target sets fall back to component defaults.
- Fact: `rocm-install-on-linux#648` は driver version と user-space / ROCm version の split を明示すべきだと指摘している。
- Fact: `rocm-install-on-linux#648` argues that the split between driver version and user-space / ROCm version needs clearer annotation.
- Interpretation: GitHub issue の表面からだけでも、ROCm における `support` は一枚岩ではなく、build matrix、component policy、package contents、driver-user space compatibility に分かれている。
- Interpretation: Even from GitHub issues alone, ROCm “support” does not behave like one single notion; it separates into build matrix policy, component policy, package contents, and driver/user-space compatibility.
- Open Question: これが recurring pattern なのか、個別に露出した論点なのかは、さらに issue を広く見る必要がある。
- Open Question: More issues would be needed to determine whether this is a broad recurring pattern or a smaller set of exposed edge cases.
Fact
Interpretation
Open Question
3. official 側では build entry point と repo topology の統合が進んでいる
3. The official side is consolidating build entry points and repository topology
- Fact: `ROCm/RELEASE.md` には `HIPCC Perl scripts deprecation` が upcoming change として明記されている。
- Fact: `ROCm/RELEASE.md` explicitly lists `HIPCC Perl scripts deprecation` as an upcoming change.
- Fact: `ROCm/tools/autotag/templates/highlights/6.0.0.md` では `GPU_TARGETS` が `AMDGPU_TARGETS` より preferred とされる。
- Fact: `ROCm/tools/autotag/templates/highlights/6.0.0.md` treats `GPU_TARGETS` as the preferred knob over `AMDGPU_TARGETS`.
- Fact: retired repo README は `ROCR-Runtime -> rocm-systems`、`Tensile -> rocm-libraries`、`ROCm/vllm -> upstream` を明示している。
- Fact: Retired repo READMEs explicitly redirect `ROCR-Runtime -> rocm-systems`, `Tensile -> rocm-libraries`, and `ROCm/vllm -> upstream`.
- Interpretation: public record からは、build knob と repository ownership の両方で統合圧力が進んでいるように見える。
- Interpretation: The public record suggests simultaneous consolidation pressure in both build knobs and repository ownership.
- Open Question: この統合が全 component に同じ速度で進むかは、現時点では repo ごとの差が大きい。
- Open Question: It remains unclear whether this consolidation will proceed at the same speed across all components.
寄与の層分解
Contribution layers
ここでの焦点は「誰が全部を支えているか」を決めることではなく、GitHub 上で観測できる寄与がどの層に現れているかを分けて読むことです。
The point here is not to declare who owns everything, but to separate the layers where contribution is actually visible on GitHub.
| 層 |
Layer |
主な根拠 |
Main evidence |
見えている寄与 |
Visible contribution |
| 自己定義 / release / build platform |
Self-definition / release / build platform |
ROCm/README.md, TheRock/README.md, rocm-systems/README.md, RELEASE.md |
official repo 側の stack 定義、release guidance、super-project / super-repo 整理 |
Official stack definition, release guidance, and super-project / super-repo organization |
| support 境界の可視化 |
Support-boundary surfacing |
TheRock#1414, TheRock#1975, rocm-install-on-linux#648 |
user-originated issue による build/support ambiguity の整理 |
User-originated issues surfacing build/support ambiguity |
| source-build / fallback 補修 |
Source-build / fallback repair |
Tensile#1595, Tensile#1862 / #1879(revert) |
contributor patch と maintainer review による portability / fallback 改善。PR #1862 の fallback 拡張は一度 merge されたが PR #1879 で AMD 関連 contributor により revert されており、外部補修が常に公式パスに乗るわけではない例として注目される |
Contributor patches plus maintainer review improving portability and fallback. PR #1862 (fallback library extension) was merged then reverted in PR #1879 by an AMD-affiliated contributor, illustrating that external fixes do not always land in the official path |
| repo topology 再編 |
Repository-topology reorganization |
retired README, rocm-systems/README.md |
official 側の責務再配置と source-of-truth の移動 |
Official reassignment of responsibilities and source-of-truth migration |
見えている協働パターン
Visible collaboration pattern
- Issue 層: user / contributor が support ambiguity や package mismatch を public issue として露出させる。
- Issue layer: users and contributors surface support ambiguity and package mismatches through public issues.
- PR 層: contributor が fallback / source-build 改善 patch を出し、official maintainer / collaborator が review・merge する。
- PR layer: contributors submit fallback or source-build fixes, while official maintainers/collaborators review and merge them.
- Repo 整理層: official 側が README、release、migration table を通じて入口と責務の再配置を公開する。
- Repository-organization layer: the official side publishes entry-point and responsibility shifts through READMEs, releases, and migration tables.
注意: GitHub の `authorAssociation` や current commit author だけから、雇用関係や全体 ownership を断定することはできません。このページが示すのは、観測可能な寄与の層です。
Caution: GitHub `authorAssociation` values and current commit authors are not enough to infer employment status or total ownership. This page is about observable contribution layers only.
このページから今言えること
What this page currently supports
強く言えること
Supported strongly
- ROCm は GitHub 上で layered / multi-repo stack として自己定義されている。
- ROCm presents itself on GitHub as a layered, multi-repo stack.
- support は build / component / package / driver-user space で分離して見える。
- Support appears split across build, component, package, and driver/user-space layers.
- 寄与は user issue、contributor PR、official repo 整理で層ごとに見え方が違う。
- Contribution looks different by layer across user issues, contributor PRs, and official repo organization.
まだ慎重であるべきこと
Still unresolved
- ROCm 全体の contribution ratio を定量化したわけではない。
- This does not quantify contribution ratios across all of ROCm.
- private planning / internal review は public record からは見えない。
- Private planning and internal review are not visible from the public record.
- `rocm-libraries` umbrella 側の全体像は、今回の local snapshot だけでは十分に固定できていない。
- The full `rocm-libraries` umbrella picture is not yet firmly fixed from the current local snapshot alone.
暫定結論: ROCm の GitHub 上の姿は、単一主体の物語としてではなく、official 側の定義・統合・repo 再編と、public user / contributor 側の issue 可視化・source-build / fallback 補修が層ごとに重なっている構造として読むのが自然である。
Provisional conclusion: ROCm's GitHub presence is more naturally read not as a single-actor story, but as a layered structure where official definition/consolidation/repo reorganization overlaps with user issue surfacing and contributor source-build / fallback repair.