Win32PrioritySeparation：CPU フルロード時の遅延と FPS
目次
短い答え:
Win32PrioritySeparationは実際に foreground boost と CPU クォンタムポリシーの一部を制御します。私たちの過去のテストでは、普遍的に最適な値は見つかりませんでした。Windows default は平均 click-to-photon レイテンシがわずかに小さく、0x1Aは CPU 100% 負荷時の1回のテストで最高の FPS と P1 に一致しました。独立した FPS 反復と生の click samples が不足しているため、default を推奨し、0x1Aは CPU シナリオ向けの検証可能な仮説にすぎないと考えます。
ステータス: パラメータと foreground boost の関連は Microsoft によって文書化されています。パラメータの読み取りは、以前に収集された Windows 11 24H2 および 25H2 のシステムトレースで観測されました。ユーザーへの効果は過去の Windows 10 22H2 シリーズで測定されましたが、別のシステムや独立した実行では再現されていません。
検証可能な主張
Section titled “ 検証可能な主張”私たちは、統合できない3つの異なる主張を検証しました:
- パラメータが存在し、Windows スケジューラポリシーに関連している。
- 値
0x02と0x1Aは、同じ最大 foreground boost で異なるクォンタムポリシーを表す。 0x1Aは CPU 完全負荷時に FPS またはゲームのレイテンシを改善する。
最初の2つの主張は、公開ドキュメントと調査したビルドでの観測によって裏付けられています。3番目は測定を必要とし、パラメータの仕組みだけでは真にはなりません。
| 層 | 環境 | 結果 |
|---|---|---|
| 公開ドキュメント | Microsoft WMI、CPU Analysis、Windows Internals | foreground boost、quantum、歴史的なビット構造が記述されている |
| システム観測 | Windows 11 24H2 および 25H2 | パラメータの読み取りが以前に収集されたトレースで観測された |
| Click-to-photon | Windows 10 22H2、Valorant、CPU 100% | 値ごとに300回の測定、集計値を保存 |
| FPS | 同じ過去のシリーズ | 構成ごとに1つの CapFrameX capture、capture のハングにより一部の行は不適格 |
この公開資料向けの Windows 10 22H2 dynamic trace は存在しません。Windows 11 26H1 にも適切なトレースがありません。Windows 10 の測定は、繰り返さずに Windows 11 に転用することはできません。
パラメータの場所
Section titled “ パラメータの場所”| フィールド | 値 |
|---|---|
| Hive とパス | HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PriorityControl |
| 値の名前 | Win32PrioritySeparation |
| 型 | REG_DWORD |
| クライアント Windows の文書化された初期値 | 0x02 (2) |
Windows Internals は、クライアント Windows および application server として構成されていないサーバーでの初期値として 2 を挙げています。私たちの Windows 11 25H2 トレースでも、DWORD は値 2 で明示的に存在していました。
したがって、私たちは値の不在を普遍的な Windows default とは考えません。それはイメージ変更、手動削除、またはサードパーティ製ツールの操作後に見られることがありますが、現在の調査では DWORD が存在しない clean-install シナリオは動的に再現されていません。行の不在を自動的に 0 と解釈することはできません。
パラメータの仕組み
Section titled “ パラメータの仕組み”Microsoft はプロパティ Win32_OperatingSystem.ForegroundApplicationBoost を Win32PrioritySeparation に対応付け、値 0、1、2 を文書化しています: boost なし、最小および最大の foreground application boost。
公式の Windows Internals Sixth Edition サンプルは、このパラメータをフィールドの集合として説明しています:
| ビット | 目的 |
|---|---|
| 0-1 | foreground boost の程度 |
| 2-3 | 可変または固定クォンタム |
| 4-5 | 短いまたは長いクォンタム |
0x02 はクライアント Windows の文書化された初期値です: 最大 foreground boost を設定し、残りのフィールドはシステムポリシーに委ねます。クライアント Windows では歴史的に、これは明示的に 0x26 として表現できる短い可変クォンタムに対応します。0x1A は同じ最大 foreground boost で長い固定クォンタムを設定します。
オープンプロジェクト Win32PSCalculator はこの等価性を直接示しています。入力は 0x3F でマスクされ、3つの2ビットフィールドを解析し、異なる記述を12の正規の組み合わせのいずれかに還元します。これは、見た目は異なるが新しい scheduler mode を生み出さない placebo 値の検出に役立ちます。
Windows Internals の文書は歴史的なものです。私たちはフィールドの解釈にこれを使用しますが、すべての内部 quantum tables が現代のすべてのビルドで不変であるとは主張しません。
6ビットデコーダー
実モードの確認
tweak リストで見つけた値を入力してください。計算機は使用される6ビットと、同じモードの正規の組み合わせのみを表示します。コンピューター上の何も変更しません。
計算機はブラウザ内でのみ動作し、Registry を読み取りも変更もしません。その結果はビットの組み合わせの等価性を示すものであり、期待される FPS やレイテンシではありません。同じバージョンは BoosterX の設定ページ で利用できます。
結果が負荷に依存する可能性がある理由
Section titled “ 結果が負荷に依存する可能性がある理由”スケジューラは、priority、affinity、状態、残りの quantum を考慮して準備完了のスレッドを選択します。quantum を使い切ると、スレッドは同じ priority の別の準備完了スレッドにプロセッサを譲ることがあります。コンテキストスイッチにはコストがかかるため、より長いクォンタムは scheduler turnover を減らし、CPU の競合が激しい状況で throughput を維持できる可能性があります。
これは効果の起こりうる方向を説明しますが、ゲームの向上を約束するものではありません。より長い固定 quantum は、同時に他のスレッドの応答性を悪化させる可能性があります。CPU が制約でなければ、測定可能な利益はないかもしれません。
過去のテストの方法
Section titled “ 過去のテストの方法”テストは Windows 10 22H2 の Valorant で、記録された CPU 100% 負荷時に実施されました。各 Registry 値について、BoosterX のハードウェアスタンドで300回の click-to-photon 測定を行いました。Logitech G PRO X SUPERLIGHT のボタンの電気信号がタイマーを開始し、フォトセンサーが画面上の輝度変化後にそれを停止します。完全な経路は調査方法で説明されています。
表には AVG、STDDEV、MIN、MAX のレイテンシが保存されています。FPS には CapFrameX を使用しましたが、利用可能なブロックには構成ごとに1つの capture しかありません。一部の値では capture がハングしたため、これらの FPS 行は利用不可としてマークされ、推測で復元されません。
元の300の click samples、P90、分布、正確な hardware/driver manifest、独立した FPS 反復は、この古いシリーズには紐付けられていません。これは統計的結論を制限します。
| 値 | ポリシー | AVG, ms | SD, ms | MIN, ms | MAX, ms | FPS AVG | P1 | P0.1 |
|---|---|---|---|---|---|---|---|---|
0x2A |
短い、固定、高い boost | 16.61 | 2.69 | 10.53 | 21.96 | 351.3 | 226.2 | 43.9 |
0x29 |
短い、固定、中程度の boost | 17.08 | 3.02 | 10.31 | 25.09 | 336.8 | 254.9 | 14.3 |
0x28 |
短い、固定、boost なし | 17.62 | 4.94 | 10.19 | 47.04 | 該当なし | 該当なし | 該当なし |
0x26 |
default 0x02 の明示的な等価 |
15.28 | 3.12 | 9.30 | 23.08 | 334.4 | 111.6 | 36.9 |
0x25 |
短い、可変、中程度の boost | 16.90 | 2.73 | 11.42 | 23.97 | 334.7 | 102.6 | 27.6 |
0x24 |
短い、可変、boost なし | 18.71 | 4.66 | 11.88 | 32.48 | 該当なし | 該当なし | 該当なし |
0x1A |
長い、固定、高い boost | 15.68 | 3.31 | 9.97 | 23.30 | 355.1 | 256.0 | 41.0 |
0x19 |
長い、固定、中程度の boost | 16.80 | 2.61 | 10.08 | 21.95 | 352.0 | 272.9 | 21.5 |
0x18 |
長い、固定、boost なし | 22.74 | 8.81 | 11.65 | 55.10 | 該当なし | 該当なし | 該当なし |
0x16 |
長い、可変、高い boost | 16.77 | 2.88 | 11.32 | 23.97 | 346.4 | 200.1 | 34.0 |
0x15 |
長い、可変、中程度の boost | 16.13 | 2.34 | 10.08 | 20.95 | 332.1 | 144.4 | 17.8 |
0x14 |
長い、可変、boost なし | 19.87 | 5.55 | 12.43 | 52.31 | 該当なし | 該当なし | 該当なし |
н/д は、ゼロの結果ではなく、不適格または欠落した FPS capture を意味します。
default と 0x1A の比較
Section titled “default と 0x1A の比較”| メトリク | Default / 等価 0x26 |
0x1A |
観測された差 |
|---|---|---|---|
| Click-to-photon AVG | 15.28 ms | 15.68 ms | 0x1A が 0.40 ms 高い、約 2.6% |
| Click-to-photon SD | 3.12 ms | 3.31 ms | 0x1A が 0.19 ms 高い |
| FPS AVG | 334.4 | 355.1 | 0x1A が 20.7 高い、約 6.2% |
| P1 | 111.6 | 256.0 | 0x1A が 144.4 高い |
| P0.1 | 36.9 | 41.0 | 0x1A が 4.1 高い |
平均レイテンシの差 0.40 ms は、保存された約 3 ms のばらつきよりも明らかに小さいです。生の samples がなければ、信頼区間を正しく構築したり、分布の形状を検証したりすることはできません。FPS の差は記述的な数値としては大きいですが、状態ごとに1つの capture では再現性を証明できず、実行順序やバックグラウンド負荷の影響を排除できません。
確認されたこと
Section titled “ 確認されたこと”- パラメータは foreground boost と Windows スケジューラのクォンタムポリシーに関連している。
- その読み取りは、調査した Windows 11 24H2 および 25H2 で観測された。
- 過去の Windows 10 22H2 シリーズでは、値ごとに300回の click-to-photon 測定が行われた。
- 高い foreground boost の状態の中で、default 等価の
0x26が最小の平均レイテンシを示した。 - 同じ過去の capture で、
0x1Aが高い boost の状態の中で最大の FPS AVG と P1 を示した。
確認されていないこと
Section titled “ 確認されていないこと”0x1Aが常に FPS、P1、またはフレームの滑らかさを向上させること。0x1Aが click-to-photon または input latency を減少させること。- 結果が Windows 11、別の CPU、別のゲーム、または CPU 完全負荷なしで再現されること。
- 他人の tweak リストにある任意の値が有用または安全であること。
- 差が統計的に有意であること: 古いシリーズには生の samples と独立した FPS 反復がない。
過去の表には、完全に紐付けられたハードウェア manifest、ドライバーとゲームのバージョン、温度、power state、実行順序が含まれていません。1つの capture のウィンドウは独立した反復とは見なされません。CapFrameX のエラーは主に foreground boost なしの状態に影響したため、完全な FPS マトリクスを比較することはできません。
調査と使用されたツールは、この設定を提供する BoosterX の開発者に属するため、開発者は結果に直接の利害関係があります。方法と適用範囲は上記で説明されており、結論は公開データと列挙された公開ソースによって検証できます。したがって、default が推奨として残り、より高い過去の FPS 0x1A は、平均レイテンシに関する否定的な結果とすべての制限とともに公開されます。
実用的な結論
Section titled “ 実用的な結論”ほとんどのクライアント Windows 10 および 11 システムでは Windows default (0x02) のままにしてください。0x1A を普遍的な「スケジューラ最適化」として適用しないでください。Windows Server は異なる scheduler policy を持ち、測定されておらず、この推奨には含まれません。
0x1A の検証は、再現可能な CPU saturation の場合にのみ正当化されます。複数のペア実行を使用し、順序をシャッフルし、平均 FPS、P1、P0.1、frametime spikes、click-to-photon を記録してください。対象メトリクスの改善が繰り返し確認され、新たな悪化がない場合にのみ、変更を残してください。
無料設定ページと正確な戻し方: BoosterX の Win32PrioritySeparation。
比較後は、BoosterX を通じてパラメータを Windows default (0x02) に戻し、インターフェースが提案する再起動を実行してください。過去のデータセットには戻しの検証に関する個別の記録が保存されていないため、この調査は recovery を古い実験の確認された部分とは見なしません。
公開一次ソース
Section titled “ 公開一次ソース”- Win32_OperatingSystem.ForegroundApplicationBoost、Microsoft Learn - Registry mapping と foreground boost の値。
- CPU Analysis、Microsoft Learn - quantum、priority、processor selection、context switches のコスト。
- Scheduling Priorities、Microsoft Learn - round-robin、preemption、dynamic priority。
- Context Switches、Microsoft Learn - スレッド切り替え時に何が起こるか。
- Windows Internals Sixth Edition sample chapters、Microsoft Press - パラメータのフィールドとクライアントクォンタムの歴史的な説明。
- BoosterX の click-to-photon 測定の公開表 - この過去のシリーズの元の公開集計値。
- Win32PSCalculator - 下位6ビットのデコードと等価モードの検索のオープン実装。
公開ソースと文言は確認済み: 2026-08-24。
- 2026-09-20: 利益相反に関する免責事項が、調査とツールの帰属を含む完全な文言に強化されました。
- 2026-08-24: Registry value の正確な場所、文書化された初期値
0x02、Win32PSCalculator、および欠落した DWORD の解釈の境界が追加されました。 - 2026-08-24: 初回公開; 完全な過去のマトリクス、メカニズムとユーザー効果の分離、および default 推奨が追加されました。