gfx900 は、ROCm そのものについて何を明かしたか
What Did gfx900 Reveal About ROCm Itself?
Vega/gfx900 は単なる旧 GPU の延命事例ではなく、ROCm が layered support・capability-based selection・staged deprecation で動いていることを可視化しやすい観測点だった。
Vega/gfx900 is not just a legacy-GPU survival story. It is a useful observation point that exposes ROCm's layered support model, capability-based selection, and staged deprecation behavior.
GitHub-side verification
ROCm-wide reading
Updated: 2026-03-15
要点: gfx900 の出来事だけから一般論を言うのではなく、README・release block・TheRock issue・Tensile docs・rocBLAS runtime fallback・retired/deprecated repo の痕跡を合わせて読むと、ROCm は「単一の support policy」でなく「層ごと・component ごと・repo topology ごとにズレを持つ stack」として理解するのが自然になる。
Key point: Rather than generalizing from a single legacy GPU event, reading the README, release blocks, TheRock issues, Tensile docs, rocBLAS fallback logic, and traces left in retired/deprecated repos together suggests that ROCm is best understood as a stack with layer-specific, component-specific, and repository-topology-specific behavior, not a single binary policy.
Note / 注記
This document organizes observations from publicly available sources and local repository clones only.
It does not assert the contents of private issues or internal decision-making processes.
本文書は、公開一次資料およびローカル clone から観測可能な設計傾向・保守構造を整理することを目的とする。AMD の意思決定を評価・批判するものではなく、非公開 issue や社内意思決定の内容を断定するものでもない。
検証した仮説
Verified hypotheses
以下は、内部ノートの仮説を GitHub 側の一次資料でどこまで支持できるかを整理した公開版要約です。
This page is a public-facing summary of how far the notebook's broader hypotheses can be supported using GitHub-side primary materials.
仮説1: ROCm は layered / modular stack として自己定義している supported（公開一次資料の範囲で）
Hypothesis 1: ROCm defines itself as a layered / modular stack supported (within the scope of public sources)
ROCm/README.md は、drivers・development tools・APIs を含む open-source stack と明記している。ROCm/README.md explicitly describes ROCm as an open-source stack including drivers, development tools, and APIs.- 同 README は HIP を portability substrate として置き、さらに
TheRock を unified CMake build platform として案内している。
- The same README presents HIP as the portability substrate and points to
TheRock as a unified CMake build platform.
仮説2: support は binary ではなく、層ごと・component ごとに分離している strongly supported（公開一次資料の範囲で）
Hypothesis 2: support is not binary; it is split by layer and component strongly supported (within the scope of public sources)
hipCUB 4.0.0 では gfx803/gfx900 が default build から外れる。hipCUB 4.0.0 removes gfx803/gfx900 from default build targets.TheRock #1414 / #1975 では、super-project 側と各 component 側で supported targets がずれること自体が issue 化されている。TheRock #1414 / #1975 expose a real mismatch between super-project target selection and component-level supportability.rocm-install-on-linux #648 は user space (ROCm) と driver version を分けて説明すべきだと指摘している。rocm-install-on-linux #648 argues that ROCm user space and driver version should be documented separately.
含意: 「非対応」という語は build / runtime / driver / user space / component support を混ぜやすい。公開説明ではどの層の話かを毎回分けたほうがよい。
Implication: The word "unsupported" easily mixes build, runtime, driver, user space, and component support. Public explanations should name the layer explicitly.
新発見: gfx900 はプリコンパイル済み成果物付きで出荷されている shipped_artifact_verified
New finding: gfx900 ships with pre-compiled artifacts and tuning data shipped_artifact_verified
ROCm 7.2 パッケージ（/opt/rocm）に含まれる gfx900 向け成果物を定量確認した（2026-03-15）。
Quantitative verification of gfx900-targeted artifacts in the ROCm 7.2 package (/opt/rocm) was performed (2026-03-15).
| 指標Metric |
gfx900 |
gfx1100 (RDNA3) |
gfx1030 (RDNA2) |
gfx942 (MI300X) |
| MIOpen Perf DB |
169,182 lines |
none |
111,296 lines |
470,080 lines |
| rocBLAS files |
128 |
96 |
88 |
242 |
Fact: gfx900 の MIOpen Perf DB 行数は gfx1030 を上回り、gfx1100/gfx1200 には Perf DB 自体が存在しない。rocBLAS プリコンパイル済みカーネル数は gfx1100・gfx1030 双方を上回る。
Interpretation: これは「コードが残っている」レベルではなく、AMD のビルド・チューニング・パッケージングパイプラインに gfx900 が組み込まれていることを示す。ただし、これが意図的なサポート維持なのかビルドターゲットリストの慣性なのかは外部からは断定できない。
Open Question: gfx1100/1200 に Perf DB がない理由（別のチューニング方式か、MIOpen ターゲット外か）は未確認。gfx803（Fiji）にも Perf DB が存在する。
Fact: gfx900 MIOpen Perf DB line count exceeds gfx1030, and gfx1100/gfx1200 ship no Perf DB at all. rocBLAS pre-compiled kernel count exceeds both gfx1100 and gfx1030.
Interpretation: This goes beyond "code still in tree" — it shows gfx900 is integrated into AMD's build-tune-package pipeline. Whether this reflects intentional support or target-list inertia cannot be determined from outside.
Open Question: Why gfx1100/1200 lack Perf DB (different tuning mechanism? not a MIOpen target?) is not yet confirmed. gfx803 (Fiji) also has Perf DB.
rocBLAS Pre-compiled Files by Architecture (ROCm 7.2)
rocBLAS プリコンパイル済みファイル数（ROCm 7.2）
Blue marks the gfx900 row, slate marks comparison architectures, and striped rows indicate zero shipped data.
青は gfx900 行、スレートは比較対象、ストライプは出荷データ 0 を示す。
gfx900 focusgfx900 注目行
comparison arch比較対象
zero shipped data出荷データ 0
Scale: 0–260 files. Values are the shipped rocblas/library pre-compiled file counts observed in the ROCm 7.2 package.
スケール: 0–260 ファイル。値は ROCm 7.2 パッケージ中の rocblas/library に観測されたプリコンパイル済みファイル数。
MIOpen Perf DB Lines by Architecture (ROCm 7.2)
MIOpen Perf DB 行数（ROCm 7.2）
Same color convention: blue = gfx900 focus, stripe = zero shipped data.
同じ配色: 青 = gfx900 注目行、ストライプ = 出荷データ 0。
gfx900 focusgfx900 注目行
comparison arch比較対象
zero shipped data出荷データ 0
Scale: 0–500 thousand lines. Values are the top observed shipped Perf DB line counts per architecture in ROCm 7.2.
スケール: 0–500 千行。値は ROCm 7.2 で観測したアーキテクチャごとの出荷 Perf DB 行数。
仮説3: capability-based selection と fallback は ROCm の中心設計である strongly supported（公開一次資料の範囲で）
Hypothesis 3: capability-based selection and fallback are central ROCm design patterns strongly supported (within the scope of public sources)
Tensile/Component.py は individual architecture IDs より capability ベースで component を選ぶと明記している。Tensile/Component.py explicitly says kernel components are specified by capability rather than individual architecture IDs.solution-selection-catalogs.rst は fallback catalog と architecture-specific fallback kernels を正式文書化している。solution-selection-catalogs.rst formally documents fallback catalogs and architecture-specific fallback kernels.rocBLAS は hipBLASLt -> Tensile、XF32 -> FP32 の runtime fallback を警告つきで明示実装している。rocBLAS explicitly implements runtime fallback with warnings for hipBLASLt -> Tensile and XF32 -> FP32.
仮説4: ROCm は入口や build knob を統合する方向へ進んでいる supported（公開一次資料の範囲で）
Hypothesis 4: ROCm is moving toward unified front doors and build knobs supported (within the scope of public sources)
HIPCC は deprecated とされ、今後 AMD Clang の symbolic link になると予告されている。HIPCC is deprecated and scheduled to collapse into AMD Clang.AMDGPU_TARGETS は deprecated で、GPU_TARGETS へ寄せている。AMDGPU_TARGETS is deprecated in favor of GPU_TARGETS.TheRock は unified CMake build with bundled dependencies を掲げている。TheRock advertises a unified CMake build with bundled dependencies.- retired repo notice では、個別 repo の責務が
rocm-libraries、rocm-systems、upstream project へ寄せ直されている。
- Retired-repo notices show standalone repositories being regrouped toward
rocm-libraries, rocm-systems, and selected upstream projects.
仮説5: legacy support は staged retreat で進む supported（公開一次資料の範囲で）
Hypothesis 5: legacy support retreats in stages rather than vanishing at once supported (within the scope of public sources)
- 新しい arch は default targets に追加される一方、旧 arch は default build から後退し、さらに一部 component で selective exclusion が起きる。
- New architectures are added to default targets, while older ones retreat from default build and may then be selectively excluded in individual components.
gfx900 はこの staged retreat を可視化しやすい例であり、即時削除ではなく段階的 legacy 化として理解できる。gfx900 is a clear example of this staged retreat, where legacy status emerges gradually rather than through immediate removal.- deprecated MIOpen branch の late change が主に layout / docs 再編だったことは、repo status の変化と arch-specific 痕跡の消滅が同期しないことを示す。
- The fact that late changes on the deprecated MIOpen branch are mostly layout/docs reorganization shows that repo status changes and the disappearance of arch-specific traces do not happen in lockstep.
仮説6: public product layer が private backend constraint を吸収することがある partially supported（事例1件のみ確認）
Hypothesis 6: the public product layer may absorb private backend constraints partially supported (one case confirmed)
MIOpen の gfx900 MLIR disable は public code 側の gating だが、根拠コメントは llvm-project-private#389 を参照している。- The
MIOpen gfx900 MLIR disable is a public gating change whose comment points to llvm-project-private#389.
- ただし今のところ、これを ROCm 全体の一般法則と断言するほど事例は集まっていない。
- At the moment, there are not yet enough examples to declare this a general ROCm-wide rule.
- 2026-03-15 追補: 公開
ROCm/rocMLIR の rocmlir-lib.cpp から Miir C API 実装全体を追跡できることを確認。gating メカニズム自体は public だが、gating の根拠（#389）は private のままである。
- 2026-03-15 addendum: The full Miir C API implementation was confirmed to be traceable through public
ROCm/rocMLIR (rocmlir-lib.cpp). The gating mechanism itself is public, but the root cause (#389) remains private.
（この issue は非公開であり、本文は外部から確認できない。公開側から確認できるのは参照関係と gating の痕跡のみ。）
(This issue is not publicly accessible; its content cannot be verified from outside. What can be observed from the public side is limited to the reference relationship and gating traces in the codebase.)
仮説7: 「AMD 維持かコミュニティ維持か」の二択は粗すぎる framing supported
Hypothesis 7: “AMD-maintained or community-maintained” is too crude a binary framing supported
少なくとも次は分けて考える必要がある。
At minimum, the following should be separated.
| 主体 | 問い |
|---|
| 投入主体 | その分岐やコードを最初に入れたのは誰か |
| 維持主体 | その後も壊れないように残し続けているのは誰か |
| 運用主体 | 見つけて、動かして、回避策を共有しているのは誰か |
| 修正可能主体 | その層の問題を現実に直せるのは誰か |
| Role | Question |
|---|
| Insertion owner | Who introduced the branch or code? |
| Maintenance owner | Who keeps it from breaking over time? |
| Operational owner | Who discovers, runs, and shares workarounds? |
| Repair-capable owner | Who can realistically fix the issue at that layer? |
重要: gfx900 の主要分岐の一部が AMD 社員コミットだったことは、投入主体の証拠である。そこからそのまま ROCm 全体の維持主体まで一般化するのは早い。
Important: The fact that some key gfx900 branches were introduced by AMD employees is evidence about insertion ownership, not automatically about long-term maintenance ownership across ROCm.
2026-03-15 追記 — Provenance Map 完成: 7つの gfx900 生存経路について git blame ベースで 4主体（投入・維持・運用・修正可能）を整理した。主な知見:
- 新経路（MLIR 除外, rocMLIR gating）→ AMD(M) が投入
- 旧経路（Winograd, ASM v4r1）→
@gmail.com 等の外部ドメイン contributor が目立つ（ただし AMD との関係を排除できない）
- 維持: Winograd / MP_bidir は AMD 社員が 2021-2025 に補修。v4r1 / WORKAROUND_1204 は削除コスト由来残存と読める
- 運用: Community（エンドユーザ）が
-S solver 強制選択や HSA_OVERRIDE_GFX_VERSION 等の回避策を共有
- Tensile fallback: 外部 contributor の補修が merge 後に revert されるケースも観測
2026-03-15 addendum — Provenance Map completed: For 7 gfx900 survival paths, git-blame-based mapping of 4 roles (insertion, maintenance, operation, repair-capability) was compiled. Key findings:
- New paths (MLIR disable, rocMLIR gating) → inserted by AMD members
- Legacy paths (Winograd, ASM v4r1) →
@gmail.com / non-AMD-domain contributors stand out (though AMD affiliation cannot be ruled out)
- Maintenance: Winograd / MP_bidir actively patched by AMD(M) staff through 2021-2025. v4r1 / WORKAROUND_1204 persist due to deletion cost
- Operation: Community (end users) share workarounds such as
-S solver forcing and HSA_OVERRIDE_GFX_VERSION
- Tensile fallback: external contributor patches were merged then reverted in at least one case
flowchart LR
A["投入主体
Insertion"]
B["維持主体
Maintenance"]
C["運用主体
Operation"]
D["修正可能主体
Repair-capable"]
A --> E["AMD(M): MLIR disable\nrocMLIR gating"]
A --> F["ExtC/AMD(C):\nWinograd · ASM v4r1"]
A --> F2["AMD(M) pipeline:\nShipped artifacts P8"]
B --> G["AMD patches\nWinograd 2021–25"]
B --> H["deletion-cost residual\nno active maintainer"]
B --> G2["pipeline regenerated\nPerf DB · rocBLAS · FW"]
C --> I["Community\n-S forcing · env vars"]
D --> J["AMD(M) only\ncompiler / backend"]
D --> K["ExtC: Python-level\nTensile logic"]
style E fill:#ddeeff,stroke:#3366aa
style F fill:#eeffee,stroke:#44aa44
style F2 fill:#e8f5e9,stroke:#1b5e20
style G fill:#ddeeff,stroke:#3366aa
style H fill:#f5f5f5,stroke:#999
style G2 fill:#e8f5e9,stroke:#1b5e20
style I fill:#fff8dd,stroke:#aaaa44
style J fill:#ffeedd,stroke:#cc6600
style K fill:#eeffee,stroke:#44aa44
P1–P8 経路別主体一覧（git blame ベース、2026-03-15）
| # | 経路 | 投入主体 | 維持状況 | 修正可能主体 |
| P1 | MLIR iGEMM 除外 |
AMD(M) — Zhuoran Yin
2407d2f, 2021-12-22 |
disable 済み（維持不要） |
AMD(M)（llvm-project-private#389 解消が前提） |
| P2 | ASM v4r1 dynamic (gfx900/gfx906 専用) |
AMD(C) — carlushuang, PR #166, 2020-06 |
削除コスト由来残存。近年の積極補修は少ない |
AMD(M) |
| P3 | Winograd (FP32) |
ExtC — Artem Tamazov
artem.tamazov@gmail.com, 2017-11〜 |
AMD 社員が 2021–2025 に補修継続
（Larochkin 2021-09, Averin 2025-03-11） |
AMD(M) |
| P4 | WORKAROUND_ISSUE_1204 (sramecc 誤報) |
ExtC — Artem Tamazov, PR #1231, 2021-10-21 |
削除コスト由来残存 |
AMD(M)（ROCm runtime 修正が根本対応） |
| P5 | MP_bidir Winograd workspace 制限 |
ExtC — Kamil Nasyrov, PR #358, 2020-08-21 |
Averin が 2025-03-11 に gfx9 命令制限注記を追加 |
AMD(M) |
| P6 | Tensile fallback / arch parsing |
AMD(C) — Cory Bloor, PR #1595, 2022-09-17 |
外部補修 PR #1862 が merge 後に AMD 関連 contributor により PR #1879 で revert |
AMD(M) + ExtC（Python レベル） |
| P7 | rocMLIR gating (Miir C API) |
AMD(M) |
AMD(M) 積極維持 |
AMD(M) |
| P8 | Shipped artifacts（ROCm 7.2 パッケージ） |
AMD(M) build pipeline |
Perf DB 169K行 + rocBLAS 128ファイル + firmware 16 blob。RDNA3/2 を上回る |
AMD(M) |
ラベル: AMD(M) = org member / @amd.com メール, AMD(C) = @amd.com だが contributor ラベルまたは後に AMD メールで活動, ExtC = 非 AMD ドメイン。雇用関係を断定するものではない。
P1–P8 per-path ownership table (git-blame basis, 2026-03-15)
| # | Path | Insertion owner | Maintenance status | Repair-capable |
| P1 | MLIR iGEMM disable |
AMD(M) — Zhuoran Yin
2407d2f, 2021-12-22 |
Already disabled (no active maintenance needed) |
AMD(M) (requires resolving llvm-project-private#389) |
| P2 | ASM v4r1 dynamic (gfx900/gfx906 only) |
AMD(C) — carlushuang, PR #166, 2020-06 |
Survives via deletion cost; few recent AMD patches |
AMD(M) |
| P3 | Winograd (FP32) |
ExtC — Artem Tamazov
artem.tamazov@gmail.com, from 2017-11 |
AMD staff patches through 2021–2025
(Larochkin 2021-09, Averin 2025-03-11) |
AMD(M) |
| P4 | WORKAROUND_ISSUE_1204 (sramecc false-report) |
ExtC — Artem Tamazov, PR #1231, 2021-10-21 |
Survives via deletion cost |
AMD(M) (ROCm runtime fix is the root fix) |
| P5 | MP_bidir Winograd workspace limit |
ExtC — Kamil Nasyrov, PR #358, 2020-08-21 |
Averin added gfx9 instruction-limit comment 2025-03-11 |
AMD(M) |
| P6 | Tensile fallback / arch parsing |
AMD(C) — Cory Bloor, PR #1595, 2022-09-17 |
External fix PR #1862 merged then reverted (PR #1879) by AMD-affiliated contributor |
AMD(M) + ExtC (Python-level) |
| P7 | rocMLIR gating (Miir C API) |
AMD(M) |
Actively maintained by AMD(M) |
AMD(M) |
| P8 | Shipped artifacts (ROCm 7.2 package) |
AMD(M) build pipeline |
Perf DB 169K lines + rocBLAS 128 files + firmware 16 blobs. Exceeds RDNA 3/2 |
AMD(M) |
Labels: AMD(M) = org member / @amd.com email; AMD(C) = @amd.com but contributor label, or later active with AMD email; ExtC = non-AMD domain. Employment relationships are not asserted.
reveal された設計モデル
The revealed design model
2026-03-15 の補足: public PR / issue 文脈まで含めると、#1231 は community user が踏んだ実害を userspace workaround で吸収した例、#1328 は private root cause を抱えたまま ROCm 5.1 の MLIR release/tuning surface から gfx900 を外した例として読める。
2026-03-15 addendum: Once the public PR/issue context is added back in, #1231 reads as a userspace workaround for a failure hit by community users, while #1328 reads as a ROCm 5.1 MLIR release/tuning-surface removal that still rests on a private root cause.
mindmap
root((ROCm Design Model
revealed by gfx900))
Stack Structure
Layered open stack
Build ≠ runtime ≠ support matrix ≠ driver
Targets drift per component
Selection & Fallback
Capability-based selection
Multi-stage runtime fallback
Build knobs unifying
Legacy Lifecycle
Staged retreat, not instant death
Deprecated repos keep legacy knowledge
Public workaround + private gating coexist
Ownership Layers
Insertion ≠ maintenance ≠ operation ≠ repair
::icon(fa fa-users)
Shipped Artifacts **NEW**
Unsupported arch ships more artifacts
Build pipeline includes gfx900
::icon(fa fa-box)
- ROCm は layered open stack として自己定義されている。
- ROCm defines itself as a layered open stack.
- build / runtime / support matrix / driver / user space は同じ意味ではない。
- Build, runtime, support matrix, driver, and user space are not the same support notion.
- component ごとに supported targets と exclusion policy はずれる。
- Supported targets and exclusion policy drift by component.
- execution path は capability-based selection と fallback で広く支えられる。
- Execution paths are broadly supported through capability-based selection and fallback.
- 表の入口や build knob は徐々に統合される。
- Public-facing entry points and build knobs are gradually unified.
- standalone repo 群も、より大きい umbrella repo や upstream へ再配置されつつある。
- Standalone repositories are also being re-homed into larger umbrella repos or back to upstream.
- repo が deprecated になっても、legacy knowledge や arch-specific workaround はしばらく tree に残りうる。
- Even after a repo becomes deprecated, legacy knowledge and arch-specific workarounds may remain in-tree for some time.
- legacy は source から即死するのでなく、段階的に retreat する。
- Legacy support retreats in stages rather than dying at once in source.
- 同一 component の内部でも、public issue-driven workaround と private-rooted release gating が別の層として共存しうる。
- Even within a single component, public issue-driven workarounds and private-rooted release gating can coexist as different layers.
- 保守主体は単一ではなく、投入・維持・運用・修正可能性に分解して考える必要がある。
- Maintenance ownership is not singular; it should be split into insertion, maintenance, operation, and repair-capability roles.
- 「非サポート」とされるアーキテクチャが、プリコンパイル済みカーネルやチューニング済み Perf DB を公式パッケージに含む形で出荷されうる。gfx900 のこれらの指標は gfx1100（RDNA3）や gfx1030（RDNA2）を上回る。
- An architecture labeled "unsupported" can nevertheless ship with pre-compiled kernels and tuned Perf DB in the official package. For gfx900 these metrics exceed gfx1100 (RDNA 3) and gfx1030 (RDNA 2).
まだ言い切れないこと
What is still unresolved
- maintainer 自身がこの思想を明示的に宣言した一次資料はまだ不足している。
- Primary materials where maintainers explicitly state this design philosophy are still limited.
- community がどこまで実質的に支えているかは、provenance map により運用主体レベルでは整理された（2026-03-15）。ただし GitHub 外のフォーラム・ブログ等での知見共有は調査範囲外。
- How far the community materially sustains the stack has been mapped at the operational-owner level via the provenance map (2026-03-15). However, knowledge sharing on forums and blogs outside GitHub remains outside the scope of this investigation.
- private backend issue が public gating に現れる例が一般的かどうかは未確定。ただし gating メカニズムの実装は public rocMLIR で追跡可能であることが 2026-03-15 に確認された。
- It remains unclear whether private-backend-to-public-gating behavior is common or just a few notable cases. However, the gating mechanism implementation was confirmed traceable in public rocMLIR as of 2026-03-15.
#1231 と #1328 の public 文脈は回収できたが、後者の private root cause 自体はなお非公開のままである。- The public context for
#1231 and #1328 is now recovered, but the private root cause behind the latter remains inaccessible.
- gfx1100（RDNA3）および gfx1200（RDNA4）に MIOpen Perf DB が存在しない理由は未確定である。MIOpen が異なるチューニング方式を採用している可能性、あるいは Perf DB 統合が未完了の可能性がある。
- Why gfx1100 (RDNA 3) and gfx1200 (RDNA 4) have no MIOpen Perf DB remains undetermined. MIOpen may use a different tuning approach for those architectures, or integration may be incomplete.
暫定結論: gfx900 は特殊な例外というより、ROCm が本来持つ layered support / fallback / staged deprecation / 配布パイプラインの構造を観測しやすい地点だった、と読むのが最も自然である。出荷成果物の調査は、「コードが残存している」だけでなく「ビルド・チューニング・パッケージングのパイプラインに gfx900 が含まれている」ことを示す。
Provisional conclusion: gfx900 is best understood not as a weird exception, but as a convenient observation point for ROCm's underlying layered-support, fallback, staged-deprecation, and distribution-pipeline structure. The shipped-artifacts investigation shows not just that code remains, but that gfx900 is included in AMD's build, tuning, and packaging pipeline.