RADV向けRay-Tracing InspectorがMesaにマージ、Linux GPUドライバ最適化の観察手段が増えた

MesaのRadeon VulkanドライバRADVに、レイトレーシングの内部状態を調べる道具が入った。マージリクエスト「tool: Add a tool for inspecting acceleration structures and ray tracing dispatches」は2026年6月21日にmainブランチへマージされ、src/tool/rtinspector 配下にRay-Tracing Inspector（RTI）の実装を追加した。変更は58ファイルに及び、-D tools=rti でビルドできる実行ファイル rti、RADV側の新しいtrace mode、.rti ファイル形式、BVHとレイ履歴を読むビューアをまとめて導入している。

この追加は、ゲームやアプリのユーザーが有効にする描画機能ではない。RADVの開発者がVulkanレイトレーシングの実行結果を、画面に出たフレームだけでなく内部の探索過程から調べられるようにするのが狙いだ。Vulkanのレイトレーシングでは、シーン内の三角形やAABBを高速に探索するためにacceleration structureを使い、vkCmdTraceRaysKHR などのdispatchから多数のレイを走らせる。性能問題が起きたとき、最終的なフレーム時間だけを見ても、どのレイがどのBVHノードを多くたどったのか、どのdispatchが重いのかは分かりにくい。RTIは、その見えなかった部分をRADVの内部データから辿る道具になる。

-D tools=rtiでビルドする開発者向けGUIが加わった

RTIはMesaの既存ツール群に追加された開発者向けGUIである。Mesonの tools オプションには新たに rti が入り、src/tool/rtinspector/meson.build は rti という実行ファイルを定義している。依存関係としてVulkanとSDL3を使い、UIにはImGuiを採用する。Mesa側にはImGuiのSDL3/Vulkanバックエンドも追加され、bin/imgui-update.py にはRTIがImGuiのdockingブランチを必要とすることが書かれている。

ビューア本体は汎用的なファイルビューの枠組みとRADV専用の読み取り処理に分かれている。rti_file_view.h では、acceleration structureの一覧、アドレスから構造体を引くmap、3D viewport、BVHツリー、ノード情報、レンダリングタスクなどを扱う共通部が定義された。RADV用の rti_file_view_radv.cpp とBVH4/BVH8向けの実装は、RADVが使うBVHノードを読み、三角形、AABB、instanceを3D表示へ変換する。

RTIは「ファイルを開いて眺めるだけ」の補助ツールではない。BVHのツリー表示、ノード選択、3D viewport、dispatch一覧、ray history、選択したinvocationの詳細が同じUI内に並ぶ。dispatchごとの画面では幅、高さ、深さを変えて表示でき、z sliceを選び、box、instance、primitiveのiteration countを切り替えられる。選んだpixelに対応するinvocationから、どのtrace rayがどのacceleration structureへ向かったかまで辿れる。

.rtiファイルはBVHとray historyを同じ捕捉に収める

RTIの追加でRADV側にも捕捉経路が入った。radv_instance.c のtrace optionには rti が追加され、radv_instance.h には RADV_TRACE_MODE_RTI が定義された。capture triggerの処理もRRAだけでなくRTIを対象にするよう変わっている。RTIのtrace modeが有効な状態で捕捉が発火すると、RADVは /tmp/<process>_<timestamp>.rti という名前のファイルを作り、radv_rti_dump_trace で内容を書き出す。

この経路は、Mesaが既に持つVulkan traceの考え方に沿っている。Mesaの環境変数ドキュメントでは、MESA_VK_TRACE はオフライン解析用のtrace typeを指定する仕組みで、捕捉ファイルは /tmp に書かれる。捕捉はアプリケーションウィンドウにフォーカスがある状態でF1を押す方法のほか、MESA_VK_TRACE_FRAME や MESA_VK_TRACE_TRIGGER でも発火できる。現在のドキュメント表にはrmv、rgp、rra、ctxrollが並んでいるが、今回のコード変更はそのtrace optionに rti を増やしている。

.rti の中身は新しい src/util/rti_format.h で定義される。ヘッダにはversion、driver、chunk countがあり、driver enumは現段階で rti_driver_radv を持つ。chunk typeにはacceleration structure、RADV trace info、RADV ray historyが用意される。acceleration structureのchunkには、GPU仮想アドレス、割り当てサイズ、compacted size、構造体の種類、geometry type、geometry count、名前の長さ、primitive count、名前、BVHデータが入る。

ray history側は、dispatch countとdispatch infoを持つ。dispatch infoには vkCmdTraceRays、vkCmdTraceRaysIndirect、vkCmdTraceRaysIndirect2 に対応するtypeと、dispatchの幅、高さ、深さが入る。RADVはray history bufferを見て、必要なサイズと実際のbuffer sizeもstderrへ出す。RTIはacceleration structureだけ、またはdispatchだけを孤立して扱うのではなく、同じ捕捉内で「どのdispatchのどのinvocationが、どのBVHをどう歩いたか」を結びつけられる。

dispatchの負荷を画像で見て、選んだレイをBVHへ戻せる

RTIのUIでは、dispatch viewとBVH viewが同じ捕捉データから動く。dispatch一覧にはindex、type、width、height、depthが表示される。各dispatchの画面では、invocationごとのiteration countを画像として表示する。iteration countはbox、instance、primitiveに分けて足し合わせられ、最大値に対する明るさとして描画される。負荷の高い場所が画面上の明るいpixelとして見えるため、開発者は問題のあるinvocationを選びやすい。

選択したinvocationでは、trace rayの詳細が表として表示される。RTIはacceleration structureのアドレス、origin、direction、tmin/tmax、SBT offset、SBT stride、miss index、cull mask、ray flagを出す。ray flagにはOpaque、NoOpaque、TerminateOnFirstHit、SkipClosestHitShader、CullBackFacingTriangles、CullFrontFacingTriangles、CullOpaque、CullNoOpaque、SkipTriangles、SkipAABBsなどが含まれる。Vulkanのray tracingでは、hit shaderやmiss shaderの参照位置はshader binding tableの規則に従って決まるため、SBT関連の値がinvocation単位で見えることは、遅いレイや想定外の経路を調べるうえで意味を持つ。

ray historyの画面では、trace rayのあとに続くiteration tokenを読み、ノード種別とoffsetを表示する。そこで選んだ項目はacceleration structureのウィンドウへ戻り、該当するBVHノードを開く。3D viewportでは、対象のacceleration structureをprimitive index、geometry index、instance indexに応じて色分けでき、選択したレイのoriginと線分も描ける。文字の表、dispatch画像、BVHツリー、3D表示が連動するため、開発者は「遅いpixelを選ぶ」「そのレイを見る」「通ったノードを見る」という流れで調べられる。

この流れは、Vulkanレイトレーシングの性質に合っている。レイトレーシングの負荷は、shaderの命令数だけで決まらない。シーンのBVH構造、instanceの配置、ray flag、cull mask、SBTの指定、AABBや三角形への到達数が絡む。RTIは、性能を語るときに必要な材料を、RADVの内部で実際に使われたBVHとdispatch履歴から取り出す。最終的なフレーム時間の数字だけでは、ここまでの切り分けはできない。

RADVの最適化は「速くした結果」より先に「見える範囲」を増やした

今回のRTI追加は、RADVのレイトレーシング性能がすぐ上がったという発表ではない。だが、ドライバ開発では計測できないものを安定して速くするのは難しい。特にray tracingでは、BVHの作り方や探索の順序、instanceの扱い、shader binding tableの参照、ray flagの扱いが性能と正しさの両方に影響する。RTIは、その検証対象を視覚化し、捕捉ファイルとして残し、開発者間で同じ状態を共有できるようにする。

コード上では、既存のRRA/BVH dumpingの資産を使いつつ、RTI用の出力を分けている。radv_bvh_dumping_enabled はRRAまたはRTIのtrace modeでBVH dumpを有効にするよう変更された。radv_rti_dump_trace はdeviceをidleにしてからacceleration structureを集め、アドレス順に並べ、BVHデータとray historyをchunkとして保存する。RRAがRadeon Raytracing Analyzer向けの既存経路であるのに対し、RTIはMesaツリー内に入るRADV向けの専用ビューアとして追加された形だ。

Linux上でVulkanレイトレーシングを改善するうえでも、この位置づけは意味を持つ。性能差が出たとき、アプリケーションが作るacceleration structure、dispatchの形、RADVのBVH処理、GPU上の探索のどこで負荷が増えているのかを分ける必要がある。RTIはエンドユーザー向けの設定ではないが、ドライバ開発者がその分解を進めるための観察手段になる。

まずはRADV専用、公開版へ届く時期と非AMD展開は未確定

RTIには明確な制約がある。マージされた実装はRADVを対象にしており、ファイル形式のdriver enumも現段階では rti_driver_radv だけを持つ。共通のfile view構造は用意されているものの、非AMD Vulkanドライバ用のバックエンドが同じ変更で入ったわけではない。Mesa mainに入った状態であり、どの安定版リリースや各Linuxディストリビューションのパッケージにいつ届くかは、今回の一次情報だけでは確定できない。

もう一つの制約は、RTIが性能改善そのものではなく、性能改善に必要な観察の道具だという点だ。.rti の捕捉を作るにはtrace modeを使う必要があり、captureは開発者や検証担当者の作業になる。レイトレーシング対応ゲームのフレームレートがこのマージで直ちに変わる、という読み方はできない。

今回の追加で、RADVのレイトレーシング開発は調べられる範囲を広げた。Vulkanのray tracingは、最終画像の裏側でBVH、dispatch、SBT、ray flag、node traversalが複雑に絡む。RTIはその関係を、.rti ファイルとGUIで同時に調べられる形にする。次に見るべきなのは、RTIで見つかったボトルネックがRADVのBVH構築、探索、shader lowering、あるいは実際のVulkanレイトレーシング負荷でどのような修正につながるかである。