ROCm GitHub 履歴タイムライン
ROCm GitHub History Timeline
ここでは、すでに内部ノートで確認済みの commit・release block・issue trail・現行コードの痕跡だけを使って、ROCm の変遷を public 向けの年表として並べ直しています。
This page turns already-confirmed commits, release blocks, issue trails, and current-code traces into a public-facing chronology of ROCm's evolution.
GitHub archaeology
Working chronology
Updated: 2026-03-19
要点: いま見えている範囲だけでも、ROCm の歴史は「対応 / 非対応」の単純な二値ではなく、component ごとの追加・後退・統合・fallback、さらに retired/deprecated repo の再編と legacy knowledge の残存がずれながら積み重なる履歴として読むほうが自然です。
Key point: Even with the limited evidence already fixed in the notebook, ROCm history reads less like a simple supported/unsupported binary and more like a layered record of component-specific expansion, retreat, consolidation, fallback, repository reorganization, and lingering legacy knowledge in retired/deprecated trees.
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 から観測可能な範囲を整理したものであり、非公開 issue や社内意思決定の内容を断定するものではない。
読み方: この年表は、正確な日付の commit と ROCm release block 単位でしか固定できていない出来事 と issue trail や retired notice から読める継続的議論 を混ぜています。まだ公式通史ではなく、公開用の working draft です。
How to read this: This timeline mixes exactly dated commits, events only anchored to ROCm release blocks, and ongoing issue trails or retired-repo notices. It is a public working draft, not yet a complete official history.
主要な時間軸
Primary timeline
中心に置いたのは、GitHub 側の履歴から「大きな出来事」として読み取りやすいものです。gfx900 は入り口ですが、年表の主題は ROCm 一般の振る舞いです。
The focus is on events that stand out in GitHub-side history as meaningful turning points. gfx900 is the entry point, but the larger subject is ROCm behavior in general.
timeline
title Key events in gfx900 / ROCm history
section 2021
2021-10 : MIOpen sramecc workaround added (WORKAROUND_1204, commit 8498875ae)
2021-12 : MIOpen MLIR iGEMM gfx900 disabled (commit 2407d2f, PR 1328)
section ROCm 5.5 — 2022
2022-09 : Tensile gfx900 xnack- added (external contributor PR 1595)
2022-10 : MIOpen DB docs gfx900 entries remain
section 2023
2023-12 : Private issue URL updated only (commit b0f912e)
section ROCm 6.2 — 2024
ROCm 6.2 : rocSOLVER adds gfx900 to default build targets
section ROCm 7.0 — 2025
ROCm 7.0 : hipCUB removes gfx900 from default build targets
section Present — 2026
2026 : Runtime and fallback paths still present
2026 : gfx900 Perf DB 169K lines shipped in ROCm 7.2
2021-10-21
exact commit
exact commit
MIOpen は先に gfx900 向け runtime workaround を強めていた
MIOpen first strengthened a runtime workaround for gfx900
- commit
8498875ae（Artem Tamazov）が WORKAROUND_ISSUE_1204 を導入し、gfx900 の sramecc- 誤報を吸収する。
- Commit
8498875ae (Artem Tamazov) introduces WORKAROUND_ISSUE_1204 to absorb incorrect sramecc- reporting on gfx900.
- public PR
#1231 は issue #1204 を明示参照しており、COMGR が gfx900:sramecc-:xnack- を reject する user-visible failure を受けた defensive workaround だったことが公開側からも読める。
- Public PR
#1231 explicitly references issue #1204, making it visible from the public side that this was a defensive workaround for a user-facing failure where COMGR rejects gfx900:sramecc-:xnack-.
- PR comment では legacy ASIC を使う community user への影響が言及され、複数 release branch への cherry-pick も志向されていた。
- The PR comments explicitly mention impact on community users with legacy ASICs, and the fix was pushed toward cherry-picks across multiple release branches.
- 意味: 同じ MIOpen の中でも、ある層では互換性 workaround を加えつつ、別の層では後に solver disable が起きる。後退は単線ではない。
- Meaning: Even inside MIOpen, one layer can add compatibility workarounds while another later disables a solver path. Retreat is not a single straight line.
2021-12-22
exact commit
exact commit
MIOpen が MLIR iGEMM の gfx900 を明示 disable
MIOpen explicitly disables gfx900 for MLIR iGEMM
- commit
2407d2f（Zhuoran Yin, AMD）が、forward / backward / wrw の MLIR solver から gfx900 を除外。
- Commit
2407d2f (Zhuoran Yin, AMD) excludes gfx900 from forward, backward, and wrw MLIR solvers.
- 根拠コメントは
llvm-project-private#389 を参照しており、公開側からは理由の核心が読めない。（この issue は非公開であり、本文は外部から確認できない。公開側から確認できるのは参照関係と gating の痕跡のみ。）
- The explanatory comment points to
llvm-project-private#389, so the core rationale is not visible from the public side. (This issue is not publicly accessible; its content cannot be verified from outside. What can be stated is limited to the observable reference relationship and gating pattern in the public codebase.)
- ただし public PR
#1328 本文とコメントからは、gfx900 を solver だけでなく ctest と tuning surface からも切り離し、ROCm 5.1 向け MLIR solver tuning の前提整理として入れられたことまでは確認できる。
- But the public body and comments of PR
#1328 still show that gfx900 was removed not only from the solver path but also from ctest and the tuning surface, as preparatory cleanup before ROCm 5.1 MLIR solver tuning.
- つまり公開側だけでも、これは単なる局所ガードではなく、release-engineering 上の計画的な切り離しだったことが見える。
- So even from the public side alone, this reads less like a local guard and more like a planned release-engineering separation.
- PR
#1328 のレビューログには 2件の APPROVED（review thread のコメントは 0件）と、release timing 調整の issue comment 2件が残るのみであり、技術的議論は公開側には観測されない。
- The PR
#1328 review log shows 2 APPROVEDs (with 0 review-thread comments) and 2 issue comments about release timing. No technical discussion is visible on the public side.
- 意味: public product code が private backend constraint を吸収している可能性を示す強い観測点。
- Meaning: A strong observation point suggesting that public product code may absorb private backend constraints.
ROCm 5.5.0 block
release-note anchor
release-note anchor
Tensile 側では gfx900:xnack- の追加記録が残る
Tensile still records an addition for gfx900:xnack-
Tensile 4.36.0 の release block には gfx900:xnack- を他の arch と並べて追加した記録がある。- The
Tensile 4.36.0 release block records gfx900:xnack- being added alongside other architectures.
- 意味: 同じ ecosystem の中で、ある component では除外が進み、別 component ではまだ追加系の動きがある。
- Meaning: Within the same ecosystem, one component may be retreating while another still shows expansion-style target work.
2022-10-05
exact commit
exact commit
MIOpen の別層では gfx900 向け workaround と DB docs が残る
Other MIOpen layers still carry gfx900 workarounds and DB docs
- commit
e5c6ce1 由来の current tree には、gfx900 用 sramecc- misreport workaround が残っている。
- The current tree still carries a
gfx900-specific sramecc- misreport workaround from commit e5c6ce1.
embed.md と find_and_immediate.md には gfx900_56 / gfx900_64 の Find-db / immediate-mode 例が残っている。embed.md and find_and_immediate.md still document gfx900_56 / gfx900_64 Find-db and immediate-mode examples.- 意味: MLIR solver は止まっていても、runtime metadata や tuning database の層では
gfx900 がまだ明示的に扱われていた。
- Meaning: Even with MLIR solver support blocked, runtime metadata and tuning-database layers were still explicitly handling
gfx900.
2023-12-13
exact commit
exact commit
private issue 参照は残したまま URL だけ更新される
The private-issue reference survives, with only the URL updated
- commit
b0f912e は ROCmSoftwarePlatform から ROCm への URL 更新を行う。
- Commit
b0f912e updates the URL from ROCmSoftwarePlatform to ROCm.
- ただし、参照先が private issue であること自体は変わらない。
- But the referenced issue remains private.
- 意味: 理由へのポインタは残るが、その理由は公開されないという非対称性が継続した。
- Meaning: The pointer to the reason remains, while the reason itself stays non-public.
ROCm 6.2.0 block
release-note anchor
release-note anchor
rocSOLVER では gfx900 を default build target に追加
rocSOLVER adds gfx900 to default build targets
rocSOLVER 3.26.0 の release block に Added gfx900 to default build targets. が残る。- The
rocSOLVER 3.26.0 release block contains Added gfx900 to default build targets.
- 意味: MIOpen 側で特定 solver が止まっていても、別 component では default target 拡張が続いていた。
- Meaning: Even while a specific MIOpen solver path was blocked, another component was still broadening default target coverage.
ROCm 7.0.0 block
release-note anchor
release-note anchor
hipCUB が gfx803 / gfx900 を default build から外す
hipCUB removes gfx803 / gfx900 from default build
hipCUB 4.0.0 では、これらの target は default では build されず、明示 opt-in が必要と書かれる。- In
hipCUB 4.0.0, those targets are no longer built by default and require explicit opt-in.
- 意味: 完全削除ではなく、運用上の visibility と regression detection を弱める形で legacy 化が進む。
- Meaning: This is not total deletion, but a form of legacy-ization that weakens operational visibility and regression detection.
current tree snapshot
current tree snapshot
それでも runtime/fallback 側には旧経路が残り続ける
Even so, legacy runtime and fallback paths still remain
- 現行 tree には MIOpen の ASM implicit GEMM 許可、rocBLAS/Tensile の lazy loading、dot4 非対応時の fallback が残っている。
- The current tree still contains MIOpen ASM implicit GEMM allowances, rocBLAS/Tensile lazy loading, and fallback paths for missing dot4 capability.
- また、MLIR iGEMM の gating メカニズム実装が公開
ROCm/rocMLIR リポジトリ（rocmlir-lib.cpp）で追跡可能であることが確認された。miirCreateHandle → RockEnabled（layout/dtype 制約）→ miirLowerTuningParams（applicability pipeline）の全チェーンを読める。
- Additionally, the Miir gating mechanism implementation was confirmed to be traceable in the public
ROCm/rocMLIR repository (rocmlir-lib.cpp). The full chain from miirCreateHandle → RockEnabled (layout/dtype constraints) → miirLowerTuningParams (applicability pipeline) is publicly readable.
- 意味: `default build` 後退と `runtime path` 残存は同時に起こりうる。ここが today の mixed-support state を作っている。
- Meaning: Default-build retreat and runtime-path survival can happen simultaneously. That is what produces today's mixed-support state.
2026-03-15
public synthesis
public synthesis
年表として読むと、ROCm の変遷は「層状の後退と統合」に見える
Read as a timeline, ROCm looks like a history of layered retreat and consolidation
- 追加、選択的 disable、default build からの後退、fallback 残存、front door 統合が、完全には同期せず進んでいる。
- Expansion, selective disable, retreat from default build, fallback survival, and front-door consolidation all proceed without perfect synchronization.
- 意味: ROCm の歴史は単純な support matrix の増減ではなく、component autonomy と stack-wide 整理圧力のせめぎ合いとして読むほうが強い。
- Meaning: ROCm history is better read not as a simple support-matrix delta, but as an interaction between component autonomy and stack-wide pressure to reorganize.
retired repo notices
retired repo notices
retired repo の案内先そのものが、ROCm の再編方向を露出している
Retired-repo notices themselves expose ROCm's reorganization path
ROCR-Runtime は retired とされ、移行先として rocm-systems を案内している。ROCR-Runtime is marked retired and points to rocm-systems as the new home.Tensile は retired とされ、移行先として rocm-libraries を案内している。Tensile is marked retired and points to rocm-libraries.ROCm/vllm は retired とされ、移行先として upstream vllm-project/vllm を案内している。ROCm/vllm is marked retired and points back to upstream vllm-project/vllm.- 意味: support policy だけでなく、repo topology 自体も
rocm-libraries / rocm-systems / upstream へ再編されている。
- Meaning: Not only support policy but repository topology itself is being consolidated toward
rocm-libraries, rocm-systems, and upstream projects.
deprecated branch activity
deprecated branch activity
deprecated MIOpen branch の late change は主に layout / docs 再編として現れる
Late changes on the deprecated MIOpen branch appear mostly as layout / docs reorganization
992a835c2 は docs cleanup で find_and_immediate / embed 文書を新配置へ移す。992a835c2 performs doc cleanup and relocates the find_and_immediate / embed material into new sections.7b36cef67 は MLIR solver 群を含む convolution solver を src/solver/conv/ へ R100 rename する。7b36cef67 renames convolution solvers, including the MLIR group, into src/solver/conv/ with R100 moves.5e791ce2c は install docs を再整形するが、gfx900_56 例は残る。5e791ce2c reformats install docs, but the gfx900_56 examples remain.- 意味: deprecated 化の後半で目立つのは、policy の再判断よりも file layout と doc surface の整理である。
- Meaning: In the late deprecated phase, the visible changes are more about file layout and doc-surface cleanup than fresh policy changes for
gfx900.
並行して進んでいる別の流れ
Other currents running in parallel
flowchart LR
B_add["Build: rocSOLVER\ngfx900 ADDED ROCm 6.2"]
B_rm["Build: hipCUB\ngfx900 REMOVED ROCm 7.0"]
B_keep["Build: rocBLAS/Tensile\ncontinues as target"]
S_dis["Selection: MLIR iGEMM\nDISABLED 2021-12"]
S_keep["Selection: Winograd/ASM\nstill passing"]
R1["Repo: ROCR-Runtime\n→ rocm-systems"]
R2["Repo: Tensile\n→ rocm-libraries"]
KEY{{"同一スタック内で\n追加・除外・統合が\n並行して進む"}}
B_add & B_rm & B_keep & S_dis & S_keep & R1 & R2 --> KEY
style B_add fill:#ddffdd,stroke:#44aa44,color:#040
style B_rm fill:#ffdddd,stroke:#cc4444,color:#600
style B_keep fill:#ddeeff,stroke:#4466aa
style S_dis fill:#ffdddd,stroke:#cc4444,color:#600
style S_keep fill:#ddffdd,stroke:#44aa44,color:#040
style KEY fill:#fff8cc,stroke:#aaaa44,color:#440
support の層分解
Support splitting by layer
TheRock #1414 / #1975 や rocm-install-on-linux #648 では、super-project、component、driver、user space を同じ “support” として扱えないことが露わになっている。
TheRock #1414 / #1975 and rocm-install-on-linux #648 expose that super-project, component, driver, and user-space support cannot be treated as one single notion.
front door の統合
Front-door consolidation
HIPCC -> AMD Clang、AMDGPU_TARGETS -> GPU_TARGETS、TheRock の unified CMake は、入口や build knob を減らして stack をまとめようとする流れを示す。
HIPCC -> AMD Clang, AMDGPU_TARGETS -> GPU_TARGETS, and TheRock's unified CMake point toward a more consolidated front door and build surface.
capability-based fallback の持続
Persistent capability-based fallback
Tensile docs と rocBLAS 実装は、individual arch ID より capability と fallback catalog を重視する設計が長く続いていることを示す。
Tensile docs and rocBLAS runtime code show a durable design preference for capability-based selection and fallback catalogs over strict per-arch branching.
repo topology の再編
Repository-topology consolidation
retired notice は、単に古い repo を閉じるだけでなく、rocm-libraries、rocm-systems、upstream project へ責務を寄せ直す再編が進んでいることを示す。
Retired notices show more than closure: responsibilities are being regrouped toward rocm-libraries, rocm-systems, and selected upstream projects.
deprecated branch に残る legacy knowledge
Legacy knowledge preserved in deprecated branches
repo が deprecated になっても、arch-specific workaround、legacy docs、private issue 参照がすぐ消えるとは限らない。MIOpen はその具体例になっている。
A deprecated repo does not automatically lose its arch-specific workarounds, legacy docs, or private-issue references. MIOpen currently serves as a concrete example.
この年表から今言えること
What this timeline currently supports
| 読み筋 |
Reading |
現時点の強さ |
Current strength |
| ROCm は component ごとに異なる速度で変化する |
ROCm changes at different speeds by component |
強い |
Strong |
| legacy support は一括削除より staged retreat に近い |
Legacy support behaves more like staged retreat than instant deletion |
強い |
Strong |
| public code が private backend constraint を吸収する例がある |
Public code sometimes absorbs private backend constraints |
部分的 |
Partial |
| AMD / community の役割は単一主体では説明しきれない |
AMD/community roles are too layered for a single-owner story |
枠組みとして有効 |
Useful as framing |
| repo の統廃合そのものが ROCm の設計整理を反映している |
Repository consolidation itself reflects ROCm's design reorganization |
中程度 |
Moderate |
| deprecated branch の late activity は再編中心で、policy 変更とは限らない |
Late activity on deprecated branches is often reorganization rather than fresh policy change |
中程度 |
Moderate |
| 同一 component 内でも public issue-driven workaround と private-rooted release gating が併存しうる |
Even within one component, public issue-driven workarounds and private-rooted release gating can coexist |
強い |
Strong |
| 「非サポート」のアーキテクチャが、サポート対象（RDNA3/RDNA2）よりも多いプリコンパイル済みカーネルや Perf DB を公式パッケージに同梱して出荷されうる |
An "unsupported" architecture can ship with more pre-compiled kernels and Perf DB than officially supported targets (RDNA 3/2) in the official package |
強い（shipped_artifact_verified） |
Strong (shipped_artifact_verified) |
まだ不足しているもの: private repository 側の事情、maintainer 自身の明示的な設計宣言、そして特に llvm-project-private#389 が何を問題視していたかの一次資料。（この issue は非公開であり、本文は外部から確認できない。公開側から確認できるのは参照関係と gating の痕跡のみ。）なお、Miir 側の gating メカニズム実装は public rocMLIR で完全追跡済み（2026-03-15）、PR #1328 の review ログも取得済みである。今の年表は、すでに確定した断片を public 向けに編み直したものです。
What is still missing: private-repository context, explicit maintainer statements of design intent, and especially primary evidence for what llvm-project-private#389 actually identified as the problem. (This issue is not publicly accessible; its content cannot be verified from outside. What can be stated is limited to the observable reference relationship and gating pattern in the public codebase.) Note: the Miir-side gating mechanism implementation has been fully traced through public rocMLIR (2026-03-15), and the PR #1328 review log has also been retrieved. This page re-assembles already-confirmed fragments for public use.
2026-03-15 追記 — Provenance Map: 7つの gfx900 生存経路について、git blame ベースで投入・維持・運用・修正可能の4主体を整理した。新経路（MLIR, rocMLIR）は AMD(M) が投入し、旧経路（Winograd, ASM v4r1）は外部ドメイン contributor が投入。維持面では Winograd / MP_bidir は AMD 社員が 2021-2025 に補修しており、「放置されている」とは言い切れない。運用面では Community が回避策共有を担っている。
2026-03-15 addendum — Provenance Map: For 7 gfx900 survival paths, four ownership roles (insertion, maintenance, operation, repair-capability) were mapped using git blame. New paths (MLIR, rocMLIR) were inserted by AMD members, while legacy paths (Winograd, ASM v4r1) trace to external-domain contributors. On maintenance, Winograd / MP_bidir have been actively patched by AMD staff through 2021-2025, so "left abandoned" is not a precise characterization. On operation, the community drives workaround sharing.
2026-03-15 追記 — Shipped Artifacts: ROCm 7.2 パッケージの調査で、gfx900 向けの出荷成果物が RDNA 世代を上回る複数の指標で確認された。MIOpen Perf DB: gfx900 合計 169,182 行（gfx1030: 111,296 / gfx1100: なし）。rocBLAS プリコンパイル済みファイル: gfx900 = 128（gfx1100 = 96, gfx1030 = 88）。amdgpu firmware: vega10 ×16 blob。これらは「コードが残っている」レベルではなく、AMD のビルド・チューニング・パッケージングのパイプラインに gfx900 が含まれていることを示唆する。これにより、従来の「維持 / 管理 / 補充」の3層モデルは「配布（shipped artifacts）」を加えた4層モデルに拡張された。
2026-03-15 addendum — Shipped Artifacts: Investigation of the ROCm 7.2 package found that gfx900 shipped artifacts exceed RDNA generations on multiple metrics. MIOpen Perf DB: gfx900 total 169,182 lines (gfx1030: 111,296 / gfx1100: none). rocBLAS pre-compiled files: gfx900 = 128 (gfx1100 = 96, gfx1030 = 88). amdgpu firmware: 16× vega10 blobs. This goes beyond "code remaining in tree" and suggests that gfx900 is included in AMD's build, tuning, and packaging pipeline. This finding extended the previous three-layer model (build / selection / fallback) to a four-layer model adding "distribute (shipped artifacts)."
2026-03-19 注記 — local Debug driver provenance: 後続の INT8 調査では、cross-check に使っていた local Debug MIOpenDriver が current public clone ではなく別 checkout miopen-src@f842c61d からビルドされていたことが確認された。これは investigation artifact の読みを狭める重要な補足だが、新しい public chronology anchor を 1 件追加したわけではない。したがってこのページでは、主要年表そのものは据え置き、年表の読み方に関する注記としてのみ反映する。
2026-03-19 note — local Debug driver provenance: A later INT8 follow-up confirmed that the local Debug MIOpenDriver used for cross-checking had been built not from the current public clone but from a separate checkout, miopen-src@f842c61d. This is an important narrowing of how investigation artifacts should be read, but it does not add a new public chronology anchor of its own. For that reason, this page keeps the main timeline unchanged and records the point only as a note on how the timeline should be interpreted.
出荷成果物のアーキテクチャ間比較
Shipped Artifacts — Cross-Architecture Comparison
%%{init: { 'theme': 'base', 'themeVariables': { 'xyChart': { 'plotColorPalette': '#78909C,#78909C,#1565C0,#78909C,#78909C', 'backgroundColor': '#ffffff' } } } }%%
xychart-beta horizontal
title "rocBLAS Pre-compiled Files (ROCm 7.2)"
x-axis ["gfx942(MI300)", "gfx906(MI50/60)", "gfx900(Vega)", "gfx1100(RX7900)", "gfx1030(RX6800)"]
y-axis "File count" 0 --> 260
bar [242, 156, 128, 96, 88]
%%{init: { 'theme': 'base', 'themeVariables': { 'xyChart': { 'plotColorPalette': '#78909C,#78909C,#78909C,#78909C,#1565C0,#78909C,#1565C0,#B71C1C,#B71C1C', 'backgroundColor': '#ffffff' } } } }%%
xychart-beta horizontal
title "MIOpen Perf DB Lines (top variant, ROCm 7.2)"
x-axis ["gfx942", "gfx908", "gfx90a", "gfx906", "gfx900_56", "gfx1030", "gfx900_64", "gfx1100", "gfx1200"]
y-axis "Lines (x1000)" 0 --> 500
bar [470, 372, 328, 235, 108, 111, 61, 0, 0]
4層観察モデル — gfx900 から読みとれる構造
Four-Layer Observation Model — Structure Revealed by gfx900
flowchart LR
L1["Layer 1\nBuild / Maintain\nLLVM · MIOpen solvers\nTensile files"]
L2["Layer 2\nSelection / Manage\nhipcc targets · CMake\nIsApplicable()"]
L3["Layer 3\nFallback / Supplement\nCK ref · HIP fallback\nNaive solver"]
L4["Layer 4\nDistribute / Ship\n128 rocBLAS files\n169K Perf DB · firmware"]
L1 --> L2 --> L3 --> L4
style L1 fill:#e3f2fd,stroke:#1565c0
style L2 fill:#fff3e0,stroke:#e65100
style L3 fill:#fce4ec,stroke:#b71c1c
style L4 fill:#e8f5e9,stroke:#2e7d32
暫定結論: ROCm の歴史は、単に「古いものを切って新しいものに置き換える」直線ではなく、追加・統合・選択的無効化・fallback 残存・repo 再編・deprecated branch 上での legacy knowledge 温存が層ごとにずれながら進む履歴として読める。
Provisional conclusion: ROCm history is better read not as a straight line of replacing the old with the new, but as a layered record in which expansion, consolidation, selective disable, fallback survival, repository reorganization, and legacy-knowledge preservation on deprecated branches proceed at different speeds.