DirectX

Shader Model 6.10公開、DX12に行列API

情報の灯台

2026年4月28日

Shader Model 6.10とAgilitySDK 1.720-previewが公開され、DirectX 12にlinalg::Matrix APIが採用された。シェーダースレッドから行列演算を直接駆動でき、ニューラルレンダリングの土台が変わる。

DirectX 12がついに「行列を扱う言語」になった

Microsoftは日本時間4月28日早朝、DirectX開発者向けブログでShader Model 6.10とAgilitySDK 1.720-previewのリリースを発表した。同時に、対応するシェーダーコンパイラDXC 1.10.2605.2 も公開されている。

Shader Model 6.9（2026年2月リリース）に続くアップデートで、今回の目玉は明確だ。HLSL（DirectX用シェーディング言語）にlinalg::Matrix という線形代数APIが正式に組み込まれた。LinAlg（Linear Algebraの略）と呼ばれるこの機能群は、シェーダーから行列演算を直接記述できるようにする。

何が画期的なのか。これまでGPUで行列演算を駆動するには、開発者が手動で複数のシェーダーに分解するか、DirectMLのような別のレイヤーを経由するしかなかった。前者はハードウェアごとに最適化が必要で、後者はリアルタイムグラフィックスパイプラインとの統合が難しかった。LinAlgはそのどちらの経路も置き換える設計になっている。

linalg::Matrixは、Cooperative VectorとしてSM 6.9で先行プレビューされていた設計を発展的に統合したものだ。Cooperative Vectorは「将来の統合設計に置き換えるため非推奨」と明記されており、その「将来の設計」がついに姿を現した格好になる。

3つのスコープで「使い分け」を可能にする設計

linalg::Matrixの中核は、3つのMatrixScope（行列スコープ）という概念だ。それぞれ異なるユースケースを想定している。

Threadスコープ はスレッド単位の小さな行列を扱う。従来のシェーダーをそのまま置き換える形で、たとえばライティング計算をニューラルネットワークの推論で代替できる。

Waveスコープは1つのWave（同時実行されるスレッド群）が協調して扱う中規模行列向け。GPUのSIMT実行モデルを直接活かす設計で、共有メモリと専用ハードウェアを使った高効率な行列積が可能になる。

ThreadGroupスコープ がもっとも野心的だ。Microsoftは公式ブログで、LLMのような大規模ニューラルネットの入力行列や重み行列はWaveスコープでは収まりきらないと説明している。ThreadGroupスコープなら、開発者が手動でタイリング（行列を分割して処理する作業）を書かずに済む。タイリングの最適配分はドライバー側が引き受けるため、開発者は単一実装をデプロイするだけでいい。

これがどれほど開発者の負担を減らすか。Wave単位の行列で大規模ネットワークを動かすには手動タイリングが必須で、しかもクロスハードウェア性能を出すには複数のカーネルを書き分ける必要があった。LinAlgのThreadGroupスコープは、その手動作業を不要にする。「単一実装で最適タイリング」という、長年あきらめられてきた目標に手を伸ばしている。

linalg::Matrix の3つのMatrixScope（行列スコープ）

	Thread	Wave	ThreadGroup
協調単位	1スレッド	1Wave （同時実行のスレッド群）	スレッドグループ全体
扱える行列規模	小	中	大
手動タイリング	不要	必要	不要
代表的な用途	シェーダー単位の軽量推論	高効率な行列積	LLM級の大規模ネット
タイリング配分	—	開発者がカーネル別に最適化	ドライバーが自動配分

※ Microsoft DirectX Developer Blog「D3D12 LinAlg Matrix Preview」（2026年4月27日）に基づく。Threadスコープは旧Cooperative Vectorに相当。

Microsoftはlinalg::Matrixを「シェーダースレッドからニューラルレンダリング技法を効率的に駆動し、同時にMLおよび画像処理のための高帯域な行列MMA演算を活用する、単一統合API」と位置づけている。

Wave構造を直接見える化、共有メモリ上限も撤廃

linalg::Matrix以外にも、Shader Model 6.10には地味だが効く改良が並んでいる。

新組み込み関数 GetGroupWaveIndex() と GetGroupWaveCount() は、スレッドグループ内のWave構造をシェーダーから直接照会できるようにする。これまで開発者は SV_GroupIndex を WaveGetLaneCount() で割るような不確実なテクニックに頼っていた。この回避策は全ハードウェアで正しく動く保証がない。新組み込み関数によって、単一コードパスがあらゆるWaveサイズ で正しく動く環境が初めて整った。

もう一つの目玉がグループ共有メモリの上限撤廃 だ。これまで32KB（メッシュシェーダーは28KB）に固定されていた制限が、ハードウェアの実上限まで開放される。新しいランタイムクエリMaxGroupSharedMemoryPerGroup でハードウェアの実容量を取得し、エントリーポイント属性 [GroupSharedLimit(<bytes>)] で必要量を宣言する。

これがなぜ重要か。大規模タイルカリング、ソフトウェアラスタライザのビン管理、巨大行列ワークロード。いずれも仕様の上限が原因で諦められていた領域だ。ハードウェアは余力を持っていたのに、APIが頭を押さえていた格好になる。その天井がようやく外れる。

レイトレーシング側にも追加がある。TriangleObjectPositions() はAny hitやClosest hitシェーダー、RayQueryから三角形頂点の位置を直接取得できる組み込み関数だ。ClusterID() はクラスタの識別IDを返すが、クラスタ化ジオメトリのDXR対応がまだ揃っていないため、現時点では使い道が限定される。

Microsoftはクラスタ化ジオメトリ機能の本格投入を「2026年秋プレビュー以降」としており、ClusterID() の出番はそこからになる見込みだ。

D3D12にも非同期コマンドリストAPIが追加

D3D12側の刷新も大きい。新たに加わるのが、Batched Asynchronous Command List APIs（非同期コマンドリストAPI）と呼ばれる機能だ。

D3D12のレガシーなCopyBufferRegion、ClearUnorderedAccessViewFloat/Uint、ResolveSubresource などのコマンドは、これまで厳密に直列実行されていた。古いResourceBarrierモデルが「同種の二つの操作のあいだの依存関係」を表現できないからだ。たとえばコピー先からコピー先へのコピーが連続するとき、GPUは毎回ストール（待機）していた。実際には独立したメモリ領域を触っているのに、だ。

新APIは暗黙の直列化契約を取り除く。開発者は本当に同期が必要な箇所、たとえば二つのコピーが同じバッファの重なる領域に書き込むケースだけで拡張バリアを使い、それ以外はすべて並列に走らせる。GPU使用率の底上げ が期待できる。

ほかにも、ClearTextureSubresources はリソースポインタとフォーマットを直接指定して領域をクリアできる。RTV（Render Target View）もUAV（Unordered Access View）もディスクリプタヒープも特殊リソースフラグも要らない。ブロック圧縮対応のクリア命令 がD3D12に初めて入る、地味だが本質的な拡張だ。

ハードウェア対応の現実

ここからが歓声と現実のあいだの温度差だ。Microsoftは各ベンダーの対応状況を一覧で公開している。

linalg::Matrix ：AMDはRadeon RX 9000シリーズ（RDNA 4）のみ対応、NVIDIAは全RTXハードウェアで対応、Intelは「将来リリースで対応予定」と記載している。

Group Wave Index：AMDはRX 7000および9000、IntelはArc B-Series、NVIDIAは「将来リリースで対応予定」。

Variable Group Shared Memory：AMDはRX 7000および9000（ただし当面はデフォルトサイズのみ。上限拡大は今後のドライバー対応）、IntelはArc B-Series、NVIDIAは全RTX対応（ただし値はハードウェアにより異なる）。

レイトレーシング系（TriangleObjectPositions/ClusterID）およびBatched Async Commands：AMDはRX 7000および9000、IntelはArc B-Series、NVIDIAは全RTX対応となる。

Shader Model 6.10／AgilitySDK 1.720 機能別ハードウェア対応状況

	AMD	Intel	NVIDIA
linalg::Matrix	RX 9000のみ	将来予定	全RTX対応
Group Wave Index	RX 7000／9000	Arc B-Series	将来予定
Variable Group Shared Memory	RX 7000／9000 （既定値のみ）	Arc B-Series	全RTX対応
Raytracing Intrinsics （TriangleObjectPositions／ClusterID）	RX 7000／9000	Arc B-Series	全RTX対応
Batched Async Command List APIs	RX 7000／9000	Arc B-Series	全RTX対応

※ Microsoft DirectX Developer Blog「Announcing Shader Model 6.10 Preview and AgilitySDK 720 Preview」（2026年4月27日）の Feature Support 表に基づく。「将来予定」は今後のドライバーリリースで対応予定の意。AMDのVariable Group Shared Memoryは現時点では既定の上限サイズのみ対応で、上限拡大は今後のドライバーで実装予定。

つまり、もっとも目立つlinalg::Matrixの対応状況にも温度差がある。AMDはRDNA 4のみ、Intelは将来予定。NVIDIAはRTX全世代に展開する一方、Group Wave Indexの対応は将来ドライバー待ちと、機能ごとに足並みがバラバラだ。今回はあくまでプレビューであり、開発者向けの実験フェーズでもある。AMD向けの専用ドライバー（AgilitySDK Developer Preview Edition 25.30.41.02）、Intel Arc向けのWindowsドライバー、NVIDIAは「開発者リレーション担当に問い合わせを」という案内で、エンドユーザーが触れるものではない。

Microsoftは次世代レイトレーシング規格「DXR 2.0」のプレビューを2026年晩夏に予定しており、その必須要件にShader Model 6.10が含まれる。今回のリリースは、レイトレーシング次世代の前準備という側面も持つ。

静かな転換点

新しいシェーダーモデルの発表は派手な見出しを取りにくい。グラフィックボードの新製品でも、ベンチマーク数値の更新でもないからだ。けれど、ゲームエンジンや業務用GPUワークロードがどう書かれるかという基盤の部分で、こうした変化はじわじわ効いてくる。

linalg::Matrixが意味するのは、ニューラルレンダリングを「特殊なハードウェアに最適化された別物」ではなく、「DirectX 12の標準的な書き方」として組み込もうという意思表示だ。ニューラルテクスチャ圧縮、ニューラルラディアンスキャッシュ、AI駆動のデノイジングや超解像。いま研究段階で動いている技法群が、来年以降のゲームエンジンに普通に載ってくる地ならしになる。

ただし、対応ハードウェアと実用レベルの安定性が揃うまでには時間がかかる。NVIDIAの将来ドライバー、AMDのRDNA 4以降、IntelのXe2以降。どれも来年以降の話だ。ゲーマーが体感できる変化は、早くて2027年のタイトルからだろう。

技術の地殻変動は、たいてい派手な発表のずっと前から始まっている。今日のリリースノートも、後から振り返ったとき、その始まりの一行に数えられるかもしれない。

参照元