AMD HIPRT 3.2、Medusa APUとCUDA 13に対応

AMDは2026年10月21日、HIP向けレイトレーシングライブラリの1月以来となる更新であるHIPRT 3.2を公開しました。PhoronixがAMDの次期Medusa APUと結び付ける3つの新しいGPUターゲットに加え、CUDA 13への対応を追加しています。また、互換性を壊すリリースでもあります。バージョン3.1向けにビルドしたアプリは、再コンパイルしないと動きません。

このリリースはGitHub上でプレリリースと表示されており、「Latest」バッジは2026年1月5日に出た3.1.0にまだ付いています。

HIPRTとは

AMDのGPUOpenページによると、HIPRTは「HIP向けのレイトレーシングライブラリ」です。HIPはAMDによるGPU向けのC++プログラミングインターフェースで、NvidiaのCUDAに対するAMDの答えです。レイトレーシングは、3Dシーンの中で光線をたどって画像を描画する手法で、時間がかかるのは各光線がどのオブジェクトに当たるかを求める部分です。

それがHIPRTの仕事です。光線と三角形やカスタム形状との交差を判定し、BVH（バウンディングボリューム階層）を構築します。BVHはシーンを囲む入れ子の箱の木構造で、これによりGPUは各光線について大半のオブジェクトを飛ばせます。このライブラリは、レイマスク、保存およびインポートしたBVH、モーションブラーも扱います。

AMDは意図的にこのライブラリを小さく保っているため、HIPアプリは多くの新しいカーネルの種類を覚えなくても導入できます。AMDとNvidiaの両方のGPUで動作します。ハードウェアアクセラレーションによるレイトレーシングには、AMD RDNA 2以降のGPUが必要です。Phoronixによると、「Blenderなどの」クロスプラットフォームのソフトウェアがこれを使っています。

HIPRT 3.2の新機能

GitHubのリリースノートに変更点の全容が載っています。主な追加点は次のとおりです。

変更点	詳細
新しいGPUターゲット	gfx1170、gfx1171、gfx115E。PhoronixはこれらをMedusa APUと特定
CUDA 13	NvidiaのCUDA 13との互換性の改善
SRTフレームのシアー	変換で、拡大縮小・回転・移動だけでなく、オブジェクトを傾けられるように
変換のゲッター	インスタンスのobject-to-worldとworld-to-objectの変換を読み取る、デバイスコード用の新しい関数4つ
同梱コンパイラー	hipRTCとcomgrのDLLが6.4から7.1へ。hipRTC 7.8以降も読み込めるように
SDKの検索	HIPとhipRTCを、HIP_PATHまたはROCM_PATHにあるSDKから優先して読み込む
速度	三角形の法線をトラバーサル後に1回だけデコードし、変換関数をアンロール

gfxの名前は、AMDがGPUの設計に付けている社内コードです。PhoronixはMedusaを、AMDのZen 6世代のクライアント向けCPUとAPUのファミリーと説明しています。APUは、CPUとGPUを組み合わせたチップです。GitHubのノート自体に載っているのはgfxコードだけで、Medusaという名前はありません。

SDKの検索の変更は、Windowsでの問題を修正するものです。グラフィックスドライバーに同梱されたHIPのコピーが、開発者が実際にインストールしたSDKを覆い隠す、つまりそれより優先されることがありました。

備えておくべき互換性を壊す変更

HIPRT 3.2はHIPRT_API_VERSIONを3002に引き上げ、hiprtCreateContextは3.1.x向けにビルドされたバイナリを拒否します。実際には、旧バージョン向けにコンパイルしたものはどれも動かなくなります。

• hiprtFrameSRTにシアーのフィールドが加わり、サイズが48バイトから64バイトに増えます。アラインメントも16バイトから64バイトに上がります。
• トラバーサルとスタックの型がテンプレートエイリアスになります。これにより前方宣言が壊れ、サイズとアラインメントの定数が削除されます。
• HIPRT_ASSERTはhiprtAssert()関数に置き換えられます。
• hiprt::ptr()は削除され、hiprt::component()に置き換わります。
• ほとんどのAPI構造体で、メンバーにデフォルト値が設定されるようになりました。

このリリースのバグ修正

いくつかの修正は、メモリ破損とクラッシュに対処するものです。

• オブジェクトの移動後にBVHを更新するRefitが、gfx1201のGPUで頂点を誤ったスロットに書き込み、ノードを破損させていました。
• ペアを持たない三角形をパックすると、不正なメモリアクセスが起こることがありました。
• ベクターアクセスの未定義動作により、コンパイラーがメモリへの書き込みを省いてしまうことがありました。
• compactScenesが、各インスタンスレコードの半分しかコピーしていませんでした。
• マルチGPUシステムでは、コンパイラーが、その時点でカレントになっているコンテキストではなく、HIPRTのコンテキストを使うようになりました。
• 「AMD Instinct MI250X / MI250」のようにスラッシュを含むデバイス名で、カーネルキャッシュが壊れなくなりました。
• GPUコードが16進数として解析されるようになり、gfx115Eが途中で切り詰められなくなりました。

開発者にとっての意味

当面は本番環境で3.1を使い続けてください。バージョン3.2はプレリリースなので、まずブランチでテストしてください。切り替える前に、同じシーンで3.1とレンダリング結果を比べてください。

そのまま差し替えるのではなく、再ビルドを前提に計画してください。APIバージョンのチェックはコンテキスト作成時に失敗するため、古いバイナリが妙なバグを抱えたまま何とか動き続けることはありません。起動を拒否するので、テストで見つけやすくなります。

変換データを手作業でコピーしているコードはすべて確認してください。アプリがhiprtFrameSRTの値を48バイト固定のストライドでGPUバッファーに詰めている場合、そのレイアウトはもう正しくありません。サイズ64バイト、アラインメント64バイトということは、オフセットが変わり、バッファーも大きくなるということです。

削除された名前をコードから検索してください。HIPRT_ASSERT、hiprt::ptr()、トラバーサル型の前方宣言はいずれもコンパイルに失敗します。修正は機械的な作業ですが、モノレポでは呼び出し箇所が多いかもしれません。

修正されたバグのいずれかに遭遇しているなら、早めにアップグレードしてください。gfx1201でBVHのリフィットが破損している、あるいはWindowsでhipErrorInvalidImageエラーが出ているチームには、3.2を早く試す理由があります。リリースノートによると、明示的なオフロードターゲットは、一部のツールチェーンで出るそのエラーを狙ったものです。

Blenderなどのアプリを通してHIPRTを使っているだけなら、何もする必要はありません。その変更は、アプリが同梱しているコピーを更新したときに届きます。