Intel Arc 140Vの内蔵GPUで、NVIDIA DLSS 5に由来するニューラルレンダリングを実ゲームへ適用する研究プロジェクトdlss-nr-on-intelが公開された。作者の測定では、Tekken 7を640×360で動かしながら処理したとき10.5fpsに達した。発端となったTom's Hardwareの記事見出しはGPUを「Arc 140T」としたが、記事本文とプロジェクトの一次資料が示す実機はLunar Lake世代のArc 140Vである。
この成果を「DLSS 5がIntel GPUへ移植された」と要約すると、重要な境界が消える。リポジトリはNVIDIAの実行コード、NGX、CUDAを使わず、推論経路をVulkanとIntelのXMX行列演算器向けに実装し直した。一方、学習済みの重みまで独自に作ったわけではない。利用者は自分が持つNVIDIAのnvngx_dlssnr.dllから重みを抽出する必要がある。公式製品の移植というより、同系統の重みを別の計算経路で走らせた研究ポートと捉えるのが正確だ。
NVIDIAのDLLを呼ばず、Vulkanレイヤーでフレームを横取り
仕組みはゲーム内へ直接DLSS 5を組み込む形ではない。VulkanレイヤーがvkQueuePresentKHRを捕捉し、表示直前のフレームをUnixソケットで常駐デーモンへ渡す。デーモンは71ブロックのU-NetをArc 140VのXMX上で実行し、処理後のフレームをゲーム側へ戻す。
ゲームとニューラルモデルを別プロセスに分けた構成である。Windows向けゲームも、Protonによって描画がVulkanへ変換される場合は対象になり得る。ただし、Windowsでそのまま動くネイティブ版が完成したという意味ではない。開発と測定はLinux、Mesa ANV、Arc 140Vで行われた。GPU側にはVulkanのVK_KHR_cooperative_matrix拡張が必要で、FP16入力とFP32累積の構成を公開していなければならない。Vulkan対応GPUなら何でも動くわけではない。
既存の非公式DLSS 5実験では、流出・同梱されたNVIDIAのDLLを別ゲームから呼び出す方式が中心だった。今回の実装はDLLから推論コードを実行せず、Intel向けの計算シェーダーと常駐ランタイムへ置き換えた。この差が、低いフレームレート以上に大きな技術的前進である。
コードは公開、重みは各自で抽出
リポジトリに入っているのはコードであり、NVIDIAのバイナリと重みは配布されない。利用者は手元のDLLを用意し、別プロジェクトのMLX-DLSSが提供するツールで論理重みを取り出す。現在のアーキテクチャ文書によれば、抽出結果は649個の名前付きテンソル、合計1億4575万5123パラメーターとなる。
大規模な行列を構成する約1億4300万パラメーターは、DLL内ではFP8 E4M3形式で1要素1バイトに圧縮されている。小規模テンソル約270万はFP16、714個のスケール値はFP32だ。抽出後に大規模行列をFP16へ展開すると、密な重みだけで291.5MBを要する。720pの処理では、活性化を含むデバイスバッファーが約2.3GiBに達するという。
モデルは5段のSwinエンコーダー、8ブロックのViT-1Dボトルネック、5段のデコーダーを持つ。入力は16チャンネルで、現在のフレーム、前フレームの出力、決定的ノイズ、階調・構造の制御値などを含む。出力はRGBの補正量と、履歴をどれだけ残すかを決める時間方向ゲートの4チャンネルだ。
ここで動いているのは超解像ではない。入力と出力の範囲は同じで、モデルが生成した補正量を元フレームへ足す。処理解像度を下げた場合も、ゲーム自身の画素を拡大するのではなく、生成した補正量を拡大して合成する。
10.5fpsの分母、1080pでは処理だけで412ms
作者が2026年9月18日に測ったデーモン単体の値は、ゲームが待つソケット往復全体の5フレーム中央値である。ゲーム描画を含むTekken 7の10.5fpsとは条件が違う。
Arc 140V上のデーモン単体処理は512x288で72ms、1920x1080で412msへ増えた。ゲーム込みのTekken 7は640x360で10.5fpsであり、デーモン単体640x360の12.5〜13.5fpsとは条件が異なる。
| 出力解像度 | 処理スケール | デーモン往復 | 上限fps |
|---|---|---|---|
| 512×288 | 0.35 | 72ms | 13.9fps |
| 640×360 | 0.35 | 74ms | 13.5fps |
| 640×360 | 0.50 | 80ms | 12.5fps |
| 854×480 | 0.50 | 105ms | 9.5fps |
| 1024×768 | 0.55 | 168ms | 6.0fps |
| 1920×1080 | 0.55 | 412ms | 2.4fps |
640×360のライブ対戦が10.5fpsだったのは、ニューラル処理にゲーム自身の描画負荷が加わるためだ。1080pではニューラル処理だけで1フレーム412msを要し、ゲームが瞬時に描けても2.4fpsを超えられない。実用品と呼べる段階ではなく、作者も「研究ポートであり製品ではない」と明記している。
負荷はニューラルネットワークの行列積に限られない。READMEによれば、720p時の488msのうちGEMMは216msだった。フレーム全体を扱うリサイズ、特徴量の組み立て、合成、データ移動も残る。作者は、データ移動だけのパスはすでにArc 140Vのメモリー帯域上限に達したとしている。処理スケールを下げても、出力解像度の全画面処理は小さくならない。
この表が証明するのは、Arc 140VでDLSS 5の製品機能が実用化したことではない。別GPU上の独立推論経路をゲームの表示ループへ接続し、連続処理できたことだ。10.5fpsは性能の勝利ではなく、移植可能性を示す実測値である。
同じ重みでも、公式DLSS 5と同じ出力にはならない
Intel実装の行列積はFP16入力、FP32累積で動く。プロジェクトが解析したNVIDIA側の218個のPTXカーネルはFP16累積を使っていた。作者の孤立GEMM試験ではFP32累積の誤差が400〜800分の1になったが、これは画質が400〜800倍向上するという話ではない。数値の丸め方が変わるため、元実装とビット単位で一致しないことを示す。
公式のDLSS 5は、ゲームエンジンが出す色とモーションベクターを基準にする。表面反射率から照明、法線までの情報も使う。開発者は複数モデルを選び、構造表現と色調表現の強度を調整し、人物や背景へ意味マスクを適用できる。NVIDIAが案内する統合経路はStreamlineまたはUnreal Engine 5プラグインだ。
独立実装は前フレームの出力を履歴として戻し、学習済みゲートで残す量を決めるところまで復元した。しかし、公式製品が受け取る入力と開発者制御をすべて再現した証拠はない。文書には、パック内の一部対応関係、設定の識別、ウィンドウシフト量など未解決項目も残る。画質比較も作者の静止画と指標に依存し、3本の格闘ゲームで効果の方向はそろっていない。
AIが書いたコードを、AIの名前で信用しない
このプロジェクトのもう一つの特徴は、コード、測定、ノートをAIエージェントが作ったと作者が開示している点だ。作者は機械とバイナリを用意し、方向を決め、判断を下した。実作業にはClaude Opus 5とAstraが使われたという。
作者はコードを1行ずつ説明できるとは主張していない。代わりに、約180件のテスト、src/bench/の測定プログラム、失敗した仮説と撤回の履歴を証拠として示す。共有メモリーのバンク競合なら大幅に速くなるという仮説は、実測では1.11倍にとどまった。存在しないドライバーバグを前提に3段階の作業が進んだことも記録した。パラメーター数と1080p性能の旧値も、後の検証で訂正されている。
誤りが残った事実は、AIエージェントが低水準GPU開発を自動化できたという物語を弱める。同時に、誤りを測定で発見し、撤回し、現行文書へ反映できる構造の重要性を強める。評価すべきはClaudeやAstraという名前ではなく、第三者が同じテストを走らせ、同じ結果へ到達できるかである。
Arc 140V上の10.5fpsは、すぐ遊べる機能の誕生を意味しない。NVIDIA専用APIから推論経路を切り離し、別GPUの行列演算器へ載せ替えられることを示した。ただし、重みの入手、速度、公式統合、配布条件、第三者再現という課題は残る。この研究ポートが越えたのは製品化の境界ではなく、「別のハードウェアでも計算できるのか」という境界である。