RTX 3080 TiのTensor演算制限を解除：MSI Z790へのUEFI移植と約70％の実測改善

RTX 3080 TiのTensor演算性能を、UEFI段階の処理で引き上げられるか。公開プロジェクト「Windows GPU UNLOCK」をMSI Z790環境へ移植し、起動時の停止を追いながら、解除前後を同じ条件で測りました。

検証・測定：2026年10月27〜28日。公開ソース：new2xin/Windows-GPU-UNLOCK。本稿はAI支援による実装・技術検証の記録です。

測定結果：Tensor演算は約1.7倍、FP32は横ばい

最初に結果を示します。単位はTFLOPSで、1秒間にどれだけ浮動小数点演算を行えたかを表します。以下は各3回の実行について、試行ごとの中央値をさらに中央値で集約した値です。

FP16とBF16は、行列に使う数値を16ビットで保持する形式です。今回のTensor演算では積和の累積にFP32を使いました。Tensor Coreはこうした行列計算を得意とするGPU内の回路です。一方、比較用のFP32 pedanticは通常の32ビット演算を厳密な計算モードで測っています。

結果が示すのは、測定したTensor行列演算のスループット向上です。GPUのあらゆる処理が約70%高速化したという意味にはなりません。ゲームのフレームレートや、画像生成・TTS・VRChatの処理時間は今回は測定していません。

UEFIで何をするのか

移植元はimpacifist/Windows-GPU-UNLOCKです。WindowsがGPUドライバーを読み込む前のUEFI環境で対象状態を確認し、GPUの解除処理を実行して、そのままWindowsへ引き継ぐ構成を持っています。今回の移植はローカル基点849f996を用いました。

難しいのは、UEFI自身も起動画面の表示にGPUを使っていることです。GOP（Graphics Output Protocol）はUEFIの画面出力に関係する仕組みで、コンソールやドライバーとの接続を確認してから切り離す必要があります。解除本体だけをGPU名に合わせてビルドしても、この前段階やWindowsへの引継ぎが成立するとは限りません。

1. GPU、VBIOS、BIOS由来ドライバー、PCI状態、入力・コンソールの依存関係を確認する。
2. wrapperがGPUを使うUEFI表示経路を切り離し、解除本体のchildを起動する。
3. childが解除処理を1回実行し、FLR（PCI機能単位のリセット）と後処理の結果を確認する。
4. システム全体の再起動を挟まず、Windowsのブートローダーを直接起動する。

毎回の起動時に適用する方式です。カードのVBIOSを恒久的に書き換えたという検証ではありません。システム全体をリセットする操作と、処理中に使うGPU側のFLRは区別する必要があります。

検証した実機：同じGPU名だけでは移植条件にならない

プロファイルはPCI IDだけでなく、PROMのハッシュ、UEFIドライバーのコード指紋、表示・入力の接続関係なども照合します。BIOSやVBIOSが変わると、この条件も変わり得ます。今回の成功を、全メーカーの3080 Tiや別マザーボードへそのまま一般化することはできません。

最初は「Windowsが起動した」だけでは成功と判定できなかった

解除を見送ってWindowsが起動していた段階

初期の版ではWindowsが起動しましたが、ログに解除のスキップが残っていました。過去のUSB機器の列挙結果を固定して照合していたため、その時点の構成との差で判定に止まっていました。この未解除の起動を基準にした測定を、後の成功時と比較しています。

ここで必要だったのは、起動の成否と解除の成否を別々に追うことでした。Windowsの起動、USBへのファイル配置、EFIのビルド成功だけでは、解除処理を実行した証拠にはなりません。

第5版は表示が残ったまま、解除直前で停止

第5版では、表示経路の切離しとchildの起動まで進み、必要なアセットの検査も通過しました。しかしchildはstage=armingでEFI_NOT_READYを返し、解除の実行はattempted=0でした。実機では「MSI 3080 Ti FULL UNLOCK v5」の案内が残り、2分以上待ってもWindowsへ進みませんでした。

wrapper側では依存範囲を絞った検査に変えていた一方、child側には全体グラフの厳密比較が残っていました。またchildは基準採取後に入力Resetを行っていました。第5版の実機ログには失敗した条件の詳細が十分になく、特定のUSB接続変化やResetが直接の原因だったとまでは断定していません。

第6版：依存する範囲を正しく検査し、失敗理由を残す

第6版では、解除の前提を確認する範囲をwrapperとchildで整合させました。GPU、実行イメージ、コンソール、入力経路と、それらに関係するドライバーの辺を確認します。採取前後の両方から関連する辺を集めるため、必要な接続の追加や消失を見落としにくい構成です。

• 無関係なUSB列挙変化への過剰反応を抑える：解除に関係する所有者や入力経路の検査は維持します。
• MSI childの入力Resetを省く：Escの読み取りによる取消しは残し、基準採取後に余分な初期化を行わない形にしました。
• 採取を最大3回読み直す：途中の不完全な結果は破棄し、読み直し回数も制限します。
• 失敗診断を具体化する：どの段階・接続関係・読み取りで拒否したかを記録します。
• 実機の失敗グラフをホスト上で再生する：許容する変化と拒否すべき変化を分けて検証しました。

ホスト検証では、coreの112ケース、実機由来の17シナリオと765変更、release側5,274チェック、wrapper側1,572チェック、媒体照合28チェックなどを通しました。他の3プロファイルでも、それぞれcold条件180ケースとflow39ケースを確認しています。これらはGPUやEFI操作を模擬した検証で、実機で解除できたかは次のログで別に確認しました。

実解除の確認：処理結果・後処理・Windows起動を結び付ける

第6版では、2026年10月27日13:44と10月28日10:35の両方で、解除本体が実行され、後処理を終えてWindowsへ引き継がれました。主な記録は以下のとおりです。

pre-FLR selectors: ss0=0x88888888 expected=0x88888888 ss1=0x8 expected=0x8
transaction result=0 containment=0 started=1 quiesced=1 fault=0 retained=0 maps=0 FLR=1
FINAL status=0 stage=transaction attempted=1 driver_release=0 clean=1

attempted=1は解除を実行した記録、fault=0はその異常判定なし、maps=0は残留DMAマッピングなし、clean=1は後処理の正常終了です。child側のdriver_release=0は、表示ドライバーの切離しをwrapperが担当したためです。

SS0/SS1は処理対象となる状態値で、目標値への到達をFLR前後で確認しています。起動時のSS0は2回で0x11515124と0x10515124に変わりました。それぞれの起動で採取した値から処理し、両方で目標値を確認できました。

配置ファイル8点のサイズとSHA-256、解除ログ、Windowsの起動時刻も照合しました。ビルド時に未検証として保存されたフラグや、採取ツールの固定した未レビューフラグは原記録として残し、実機ログを確認した判定を別のレビュー記録にしています。

ベンチマークの測定方法と、まだ分からないこと

cuBLASを用いて4096×4096の行列積を測定しました。各精度で2秒のウォームアップ後に30標本を取り、3回の試行を実行しています。解除前・解除後で、GPU、ドライバー、CUDA/cuBLAS、ベンチマークソースを揃え、コンパイラーとcuBLAS DLLのハッシュも照合しました。

ソース・ツールの一致を確認した一方、実行ファイルは再ビルドしているため、バイナリが同一とはしていません。CUDA 12.6と既存のMSVCを組み合わせる際の-allow-unsupported-compiler使用も記録しています。新しい大容量計算環境の追加や、電力上限・オーバークロック設定の変更は行っていません。

数値の正しさは、全要素1の行列積について先頭・末尾の値が4096になることを確認しています。出力行列の全要素を検証した試験ではありません。また、別々の起動間の比較で、温度と動的ブーストクロックは固定していません。解除後の各試行末尾の温度は57・60・62℃で、thermal slowdownは各回ともNot Activeでした。

Tensor演算の改善幅は今回の試行間変動より十分大きく出ています。ただし、この短時間GEMMの結果から、長時間安定性や特定のAIモデルの生成時間を予測することはできません。

USBで自動適用：内蔵ディスクの変更を避けた運用

自動適用には既存のFAT32 USBを使いました。内蔵D:を縮小して新しいEFI領域を作る案は採用せず、既存パーティションのGUID・サイズ・オフセットが変わっていないことを確認しています。

実機では起動順を「USB → Windows Boot Manager」にし、高速スタートアップを無効にしています。USBを挿したままの無操作起動を目指した設定でしたが、10月28日のユーザー報告でBIOSからの手動選択が必要な状態と判明しました。USBからの解除とWindows起動は確認できています。自動選択の問題に対応し、USBの媒体IDと起動ファイルを明示した新しい項目を先頭に設定しました。無操作起動は確認待ちです。

媒体はドライブ文字やディスク番号に固定せず、ディスク固有ID、ボリュームID、容量、パーティション構成で照合します。配置前には既存のEFIを退避し、ビルド入力と配置後ファイルをハッシュで確認するようにしました。

通常の再起動などで必要なcold条件を満たさなければ、解除を見送る設計です。問題が起きた際はファームウェアのBoot OverrideからWindows Boot Managerを選ぶ復帰経路を確保します。USBを抜いた状態での自動フォールバックや、別BIOS・別GPUに変えた後の経路は実機未検証です。

公開したもの：解除ソース、測定値、検証記録

new2xin/Windows-GPU-UNLOCKに、上流を基にしたソーススナップショット、MSI用プロファイル、修正内容、測定の各3試行JSON、レビュー済みの起動記録を公開しました。上流のライセンス・著作権表示を保持しています。

GPU個体ID、USBシリアル、パーティションGUID、NVRAM/BCDのバックアップ、採取ログ全文は公開対象から除きました。NVIDIAファームウェアと実機用EFIも同梱していません。公開版の配備スクリプトは固有IDをダミー化し、Windows ESP GUIDを必須引数にしています。このため実機用バイナリと同じハッシュを再生成できる設定という主張はしていません。

現時点で確認できた成果は、特定構成での実解除2回、Windowsへの引継ぎ、FP16/BF16 Tensor行列演算での約1.7倍の改善です。今後のアプリ実測や長時間検証は、今回の成功記録と区別して積み上げる必要があります。

参考資料

• 移植元：impacifist/Windows-GPU-UNLOCK
• 本移植の実機結果・測定条件
• 測定試行とレビュー記録
• NVIDIA公式：cuBLASドキュメント（行列演算ライブラリーの説明。今回使用した版は12.6.3）