syghの新フラグメント置き場

プログラミングTipsやコード断片の保管場所です。お絵描きもときどき載せます。

Windows Updateとの戦い(2018年春の陣、休止状態解除の亡霊)

Windows 10 1703にて、2018-04-18にいくつかのセキュリティアップデートを適用したら、勝手にWindowsの休止状態 (hibernation) が解除されて復帰する(PC電源が勝手に入る)問題が多発するようになりました。休止状態はメモリ内容をストレージに保存してPC電源を落とすので、スリープよりも復帰に時間がかかりますが、休止中に停電が発生しても復帰ができるというメリットがあるので、就寝前にいつも使っています。

以前、休止状態の解除が頻発して困っていたときに、キーボードやマウス、ネットワークアダプターが原因かもしれないと思って、デバイスマネージャーにて[このデバイスで、コンピューターのスタンバイ状態を解除できるようにする]のチェックをすべて外していたので、これらのデバイスが原因である可能性は最初から除外しました。

まず、コマンドプロンプトを管理者権限で起動*1し、powercfg コマンドで前回の復帰の理由を調べます。

Microsoft Windows [Version 10.0.15063]
(c) 2017 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>powercfg -lastwake
スリープ状態の解除履歴カウント - 1
スリープ状態の解除履歴 [0]
  スリープ状態の解除元カウント - 1
  スリープ状態の解除元 [0]
    種類: スリープ解除タイマー
    所有者: [SERVICE] \Device\HarddiskVolume2\Windows\System32\svchost.exe (SystemEventsBroker)
    所有者によって示された理由:

イベントビューアーのシステムログで「Power-Troubleshooter」を検索すると、以下のレコードが2018-04-20 05:35:00 (JST) に記録されていました。

システムは低電力状態から再開しました。

スリープ時間: 2018-04-19T16:44:22.759254000Z
スリープ解除時間: 2018-04-19T20:34:53.450160600Z

スリープ状態の解除元: タイマー - svchost.exe

「スリープ解除タイマー」とは何者でしょうか? 調べてみると電源オプションで無効化できるそうです。

[コントロール パネル] > [ハードウェアとサウンド] > [電源オプション]にて、現在選択されている電源プランの[プラン設定の変更] > [詳細な電源設定の変更]をクリック。
[電源オプション]ダイアログで、[スリープ] - [スリープ解除タイマーの許可]が[有効]になっていました。コイツを[無効]に変更して[OK]または[適用]ボタンをクリック。

これで一安心……と思いきや、やはり休止状態が勝手に解除されてしまいました。

もう一度powercfgとイベントビューアーで調べます。

Microsoft Windows [Version 10.0.15063]
(c) 2017 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>powercfg -lastwake
スリープ状態の解除履歴カウント - 1
スリープ状態の解除履歴 [0]
  スリープ状態の解除元カウント - 0

イベントログには2018-04-21 04:38:25 (JST) に記録があります。

システムは低電力状態から再開しました。

スリープ時間: 2018-04-20T17:57:22.602822200Z
スリープ解除時間: 2018-04-20T19:38:20.464928200Z

スリープ状態の解除元: 不明

はい原因不明でした。

UpdateOrchestratorタスクグループ

タスクスケジューラで確認したところ、UpdateOrchestratorのRebootタスクが指定日時をトリガーとして登録されていました。
UpdateOrchestratorはWindows Updateに関わるタスクグループらしく、スリープや休止状態の勝手な解除を発生させる諸悪の根源です。UpdateOrchestratorを組み込んだMSのエンジニアは、本当に頭のおかしいキチガイでしょう。Windows 8.1からWindows 10に更新した後、しょっちゅうコイツに悩まされていましたが、ここ最近は小康状態だったので油断していました。1703でWindows Updateによる再起動前のリマインダーや、更新の一時停止(最大35日間)をできる機能が追加されたので、再起動の回数自体も減っていました。
ひとまずRebootタスクの[条件]にて、[タスクを実行するためにスリープを解除する]のチェックを外しておきましたが、次回のWindows Update後にはまた勝手に復活していることでしょう。なお、1709ではこの設定がUIから変更できなくなっているそうです。ユーザーにさらなる不自由を強いるとは許せませんね*2

しかし、UpdateOrchestratorのRebootタスクを修正しても、やはり休止状態が勝手に解除されてしまいました。解除元は相変わらず不明です。

WindowsUpdateタスクグループ

WindowsUpdateのAutomatic App Updateタスク*3およびScheduled Startタスクを修正すると改善されるとの情報あり。前者は4時間ごとに無期限に繰り返すよう設定されていました。後者は指定日時をトリガーとして登録されていました。
しかし、[タスクを実行するためにスリープを解除する]はともにチェックが外れていました。
ほかに、AUSessionConnectというタスクも登録されており、これは[タスクを実行するためにスリープを解除する]にチェックが入っていました。
ひとまずAutomatic App UpdateタスクとAUSessionConnectタスクを無効化しておきました。Scheduled Startタスクは無効化しても、一定時間経つと勝手に有効化されるようです。なお、AUSessionConnectは[タスクを実行するためにスリープを解除する]のチェックを外して[OK]をクリックしても、なぜか以下のようなメッセージが表示されて、変更を反映できません。

---------------------------
タスク スケジューラ
---------------------------
タスク スケジューラ サービスが利用できません。タスク スケジューラはサービスへの再接続を試行します。
---------------------------
OK
---------------------------

しかし、Automatic App UpdateタスクとAUSessionConnectタスクを修正・無効化しても、やはり休止状態が勝手に解除されてしまいました。解除元は相変わらず不明です。

powercfgコマンドを使って、スリープ解除元のデバイスとタイマーを列挙してみます。

Microsoft Windows [Version 10.0.15063]
(c) 2017 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>powercfg -devicequery wake_armed
NONE

C:\WINDOWS\system32>powercfg -waketimers
[SERVICE] \Device\HarddiskVolume2\Windows\System32\svchost.exe (SystemEventsBroker) によって設定されたタイマーは 04:33:06 (2018-04-24) で有効期限が切れます。
  理由:

バイスは案の定存在しませんでしたが、タイマーが存在するようです。しかし「理由」が分からないのでタスクの特定ができません。

Windowsのタスクキャッシュ

Windowsの各タスクの設定情報自体は "%WinDir%/System32/Tasks" 配下にXMLファイル(拡張子は無し)の形で保存されていますが、レジストリ "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache" 上にもバイナリキャッシュが保存されているようです。またキャッシュのほうが優先されるらしく、XMLファイルを直接編集&保存してWindowsを再起動しても変更内容が反映されません。タスクスケジューラのUIによる変更を確定しようとしたときにエラーとなるのは、おそらくキャッシュが破損しているからではないかと推測されます(4月のWindows Updateで破損した?)。しかしレジストリエディターでキャッシュを削除しようとしても、タスクスケジューラのサービスによってロックされているらしく、削除操作が拒否されます。また、タスクスケジューラのサービスはユーザーが停止させることができません。

セーフモードで起動してキャッシュを消そうかとも考えましたが、いい加減疲れたので、休止状態の勝手な復帰現象の原因追及はひとまずここまでとします。結局、休止状態にした後はPC電源スイッチを切る(|→○)という原始的な方法で対処することにしました。電源スイッチのあるオーソドックスな自作デスクトップ機でよかった。

もう少し追跡してみます。Tasksフォルダー配下のすべてのファイルを対象に、

<WakeToRun>true</WakeToRun>

をグローバル検索してみたところ、前述のAUSessionConnect以外にいくつか引っかかりました。

このうち、rempl\shellUpdateOrchestrator\AC Power Download はタスクが有効(準備完了)になっていたので、前者は[タスクを実行するためにスリープを解除する]のチェックを外し、後者は無効化しました。それ以外はすでに無効になっているので放置することにします。

Microsoft Windows [Version 10.0.15063]
(c) 2017 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>powercfg -waketimers
システムにアクティブなスリープ解除タイマーがありません。

ようやくタイマーがなくなりました。ひとまずこれで様子見とします。

グラフィックスドライバーの勝手な更新

休止状態の解除問題とは直接の関係はありませんが、Windows Updateの履歴を見ると、2018-01-21に、NVIDIA GeForceドライバーが384.94から388.13に許可なく勝手に更新されていました。グラフィックスドライバーは特に相性問題を起こしやすく、たいていのパワーユーザーはドライバーの更新に慎重になるのですが、これが勝手に更新されるとなるとかなり困ります。以前はデバイスドライバーの更新に関してはオプショナル(任意)だったはずなのですが……
ひとまずグループポリシーでデバイスドライバーの更新を無効化する([Windows Updateからドライバーを除外する]を[有効]に構成する)ことで対処しました。

Windows 10更新アシスタントの無限復活

3月頃には「Windows 10更新アシスタント」が勝手にインストールされて、1709のダウンロードが始まる事案が発生しました。更新アシスタントはコントロールパネルで削除しても無限に復活する、まさにゾンビのように厄介なアプリです。グループポリシーでは無効化できず、以下のサイトを参考にしてようやく抑制できました。
www.atmarkit.co.jp

MSはどうしても1709の導入ベースを増やしたがっているようですが、だからといってユーザーの許可なく勝手にアプリをインストールするなんて破廉恥極まりないですね。年2回の大型アップデートスケジュールも、無理やりスケジュールを守ろうとして品質の確保ができなくなってしまっているのが目に見えています。機能追加のためのアップデートとスケジュールではなく、スケジュール遵守のための無理な機能開発になってしまっていて、目的と手段が完全に入れ替わってしまっていますね。お粗末としか言いようがないです。そもそも大型アップデートにより追加あるいは削除される機能のうち、大半は誰も望んでいない変更です。しかも新機能はことごとくオプトアウトなのも始末が悪いです(余計な機能がデフォルトで有効化されていて、無効化するためにはユーザーがいちいち設定を変更しなければならない)。

Windows 10はユーザーの自由と時間と情報と安眠と電気代を奪っている

Windows 8.1までは良くも悪くもエンドユーザーがWindows Updateのタイミングと内容を完全にコントロールすることができていました。翻ってWindows 10では、ユーザーにほとんど自由がありません。せっかく設定を変更して抑制しても、Windows Updateを適用すると(MSにとって都合のいいように)設定が毎回リセットされてしまいます。ましてや、余計な機能てんこ盛りで品質の低い大型アップデートを勝手にインストールして、ユーザーのシステムを台無しにするなんて、犯罪にも等しいです。また、MSは個人情報収集のためには手段を選びません。なりふり構わずあの手この手を使ってきます。知識がないライトユーザーは簡単に騙されて大量に個人情報をぶっこ抜かれてしまうでしょう。こういう汚いことを続けていれば、どんどんパワーユーザーが離れていくということにMSは気付かないんでしょうか。本当に過去最悪のOSです。Windows 10の汚らしい挙動と、MSの下品なゴリ押しのせいで、Direct3D 12*4もUWPも開発に使う気がすっかり消え失せました。開発環境としてずっと慣れ親しんできたWindowsですが、もうウンザリです。もはやWindowsプラットフォーム固有の開発には積極的に投資したくありません。

今のところゲームやクリエイティブツールの関係上、どうしてもWindowsを使わざるを得ない状況ですが、今後Wineの完成度が上がればいずれWindowsを捨ててLinuxに移行したいですね。ソフト電池のような認証ツールもWine環境に対応してくれたらいいのですが。

※2018-06-03追記:
5月度のWindows Updateを実行すると、案の定またスリープ解除タイマーが復活しました。例のごとくタスクのXMLファイル群をグローバル検索してみると、

というタスクが有効かつWakeToRunがtrueになっていたので、[タスクを実行するためにスリープを解除する]のチェックを外しておきました。

※2018-07-16追記:
6月度のWindows Updateを実行すると、以下のタスクが有効かつWakeToRunがtrueになっていたので、[タスクを実行するためにスリープを解除する]のチェックを外しておきました。Windows Updateのたびにスリープ解除タイマーを復活させやがることが分かったので、そろそろ無効化作業を自動化したいですね。

※2018-08-14追記:
7月度のWindows Updateを実行してみたところ、今回はスリープ解除タイマーを復活させていないようです。

※2018-09-17追記:
8月度のWindows Updateを実行してみたところ、今回はスリープ解除タイマーを復活させていないようです。

※2018-09-25追記:
1703のサポート期限が迫ってきたため1803に更新したところ、以下のタスクが有効かつWakeToRunがtrueになっていたので対処。

しかし、UpdateOrchestrator\Schedule Retry Scanに関してはタスクスケジューラのUIから[タスクを実行するためにスリープを解除する]をアンチェックもしくは無効化しようとすると、権限がないと言われてしまいます。以下を参考に、管理者権限で psexec を使うことでタスクを無効化できました。
ykw-note.hatenablog.com

C:\Users\XXX\PSTools>psexec -s -accepteula -nobanner schtasks /Change /TN "\Microsoft\Windows\UpdateOrchestrator\Schedule Retry Scan" /DISABLE

成功: スケジュール タスク "\Microsoft\Windows\UpdateOrchestrator\Schedule Retry Scan" のパラメーターは変更されました。
schtasks exited on <PCName> with error code 0.

※2019-03-03追記:
2019年1月度のWindows Updateを実行してみたところ、スリープ解除タイマーが復活しました。
今回は以下のタスクが有効かつWakeToRunがtrueになっていました。

しかし、タスクスケジューラのUIから[タスクを実行するためにスリープを解除する]をアンチェックもしくは無効化しようとすると、
「タスク スケジューラ サービスが利用できません。タスク スケジューラはサービスへの再接続を試行します。」と言われてしまいます。
以前のようにpsexecで対処しました。

C:\Users\XXX\PSTools>psexec -s -accepteula -nobanner schtasks /Change /TN "\Microsoft\Windows\UpdateOrchestrator\AC Power Download" /DISABLE

ちなみに UpdateOrchestrator\Schedule Retry ScanUpdateOrchestrator\Schedule Scan に改名(?)されたようです。

※2019-04-24追記:
2019年3月度のWindows Updateを実行してみたところ、スリープ解除タイマーが復活しました。
今度は UpdateOrchestrator\AC Power Download が消えて、UpdateOrchestrator\Schedule Retry Scan が復活していました。

[SERVICE] \Device\HarddiskVolume2\Windows\System32\svchost.exe (SystemEventsBroker) によって設定されたタイマーは 01:45:38 (2019-05-08) で有効期限が切れます。
  理由: Windows は、スリープ状態の解除を要求したスケジュールされたタスク 'NT TASK\Microsoft\Windows\UpdateOrchestrator\Schedule Retry Scan' を実行します。

※2019-06-22追記:
2019年5月度のWindows Updateを実行してみたところ、スリープ解除タイマーが復活しました。
今度は UpdateOrchestrator\Schedule Retry Scan が消えて、UpdateOrchestrator\AC Power Download が復活していました。

[PROCESS] \Device\HarddiskVolume2\Windows\SystemApps\ShellExperienceHost_*\ShellExperienceHost.exe によって設定されたタイマーは 00:00:00 () で有効期限が切れます。

※2019-09-12追記:
2019年7月度のWindows Updateを実行してみたところ、スリープ解除タイマーが復活しました。
今度は UpdateOrchestrator\AC Power Download が消えて、UpdateOrchestrator\Schedule Retry ScanUpdateOrchestrator\Schedule Scan が復活していました。
しかし、これらのタスクをpsexecで無効化しても、依然としてタイマーが残っています。他にWakeToRunがtrueになっている有効なタスクは見つかりません。

※2020-09-03追記:
2020年7月度のWindows Updateを実行してみたところ、スリープ解除タイマーが復活しました。

[PROCESS] \Device\HarddiskVolume2\Windows\SystemApps\Microsoft.Windows.StartMenuExperienceHost_*\StartMenuExperienceHost.exe によって設定されたタイマーは 00:00:00 () で有効期限が切れます。

[SERVICE] \Device\HarddiskVolume2\Windows\System32\svchost.exe (SystemEventsBroker) によって設定されたタイマーは 01:39:49 (2020-09-17) で有効期限が切れます。
  理由: Windows は、スリープ状態の解除を要求したスケジュールされたタスク 'NT TASK\Microsoft\Windows\UpdateOrchestrator\Backup Scan' を実行します。

StartMenuExperienceHost.exe はスタートメニュー専用のホストプロセスらしいです。Windows 10 1903にてエクスプローラーから分離されたとのこと。
とりあえず UpdateOrchestrator\Backup Scan のほうをpsexecで無効化して様子見。

C:\Users\XXX\PSTools>psexec -s -accepteula -nobanner schtasks /Change /TN "\Microsoft\Windows\UpdateOrchestrator\Backup Scan" /DISABLE

※2020-09-30追記:
いつのまにかスリープ解除タイマーが復活しました。

[SERVICE] \Device\HarddiskVolume2\Windows\System32\svchost.exe (SystemEventsBroker) によって設定されたタイマーは 07:59:29 (2020-09-30) で有効期限が切れます。
  理由: Windows は、スリープ状態の解除を要求したスケジュールされたタスク 'NT TASK\Microsoft\Windows\UpdateOrchestrator\Universal Orchestrator Start' を実行します。

[PROCESS] \Device\HarddiskVolume2\Windows\SystemApps\Microsoft.Windows.StartMenuExperienceHost_*\StartMenuExperienceHost.exe によって設定されたタイマーは 07:59:29 (2020-09-30) で有効期限が切れます。

とりあえず UpdateOrchestrator\Universal Orchestrator Start のほうをpsexecで無効化して様子見。

※2021-10-23追記:
Windows 10 21H1にて、久々にスリープ解除タイマーが復活しました。しかし原因はWindows Updateではなく、StartMenuExperienceHost.exe のようでした。

[PROCESS] \Device\HarddiskVolume2\Windows\SystemApps\Microsoft.Windows.StartMenuExperienceHost_*\StartMenuExperienceHost.exe によって設定されたタイマーは xxx (yyy) で有効期限が切れます。

xxx と yyy の部分はそれぞれ時刻と日付のはずですが、文字化けして変なデータが表示されています。2019年12月末頃に現象が発生していた環境もあるみたいですね。このタイマーはライブタイル (Live Tiles) の通知と関連があるようです。

superuser.com

グループポリシーエディターでライブタイルの通知を無効化し、OSを再起動することでタイマーがなくなりました。

以前Windows 10ではライブタイルが廃止されるとかいう噂が出ていましたが、Windows 10では一応残るものの、Windows 11では本当に廃止されたみたいですね。自分は天気アプリのライブタイルくらいしか活用していませんでした。スタートメニューの項目がちらちら変化すると視界に入って鬱陶しいんです。ニュースアプリのライブタイルとかも気が散るのでオフにしていました。モバイルとデスクトップは作法が全然違うことを理解していない企業が多すぎます。MSとかMozillaにはバカの一つ覚えの無能デザイナーしかいないんでしょうか。

※2022-02-22追記:
また本日も休止状態が勝手に解除されました。しかしpowercfgコマンドで調べても、タイマーは存在していません。
ふとデバイスマネージャーでキーボードやポインティングデバイスの電源管理プロパティを調べてみようと思ったところ、なぜか「HID キーボード デバイス」が2つ、「HID 準拠マウス」が2つリストアップされています。片方はスタンバイ解除オプションのチェックが入った状態、片方はチェックが外れた状態になっていました。気持ち悪いのでとりあえずチェックは外しておく。
イベントログには2022-02-22 03:57:57 (JST) に記録がありましたが、相変わらず原因不明で役に立ちません。

システムは低電力状態から再開しました。

スリープ時間: 2022-02-20T20:35:12.506912200Z
スリープ解除時間: 2022-02-21T18:57:47.737867700Z

スリープ状態の解除元: 不明

まあ実際の原因は十中八九Windows Update (UpdateOrchestrator) の監視タイマーだと思います。謎のシグナルを受けて深夜に勝手に再開するクソOS。本当にMSの開発者は首を吊って死ねばいいのに。
以下を参考に、グループポリシーで「Windows Update の電源管理を有効にして、システムのスリープ状態が自動的に解除され、スケジュールされた更新がインストールされるようにする」を無効化しました。ひとまず様子見とします。
itojisan.xyz

*1:余談ですが、最初のカレントディレクトリは通常権限だと「%UserProfile%」で起動する一方、管理者権限だと「%SystemRoot%\System32」で起動しますね。

*2:MSが運営している各種フォーラムには、こういった明らかにユーザーに不利益を強いているMSの姿勢すら擁護する大量のマゾ信者がグルとして涌いていて、本当に気持ち悪いです。

*3:Windowsストアアプリを自動更新するためのタスクらしいです。ところでストアアプリなんていう不自由なもの、誰が好き好んで使うんですか?

*4:Direct3DとHLSLの進化が停滞すると競合のOpenGL/VulkanとGLSLも停滞することが予想されるので、Direct3Dの更新自体は続けて欲しいのですが、個人的には今後プラットフォーム独自仕様のDirect3D/MetalよりもクロスプラットフォームなVulkanのほうが普及率が高くなり、API統一が進むのではないかと(期待を込めて)予想しています。

Vulkanグラフィックスの簡単なレンダリングサンプル

このあいだ書いた記事「VulkanシェーダーでSub-group命令を使う」では、グラフィックスをすっ飛ばしていきなりコンピュートシェーダーで拡張命令を試すという変態的なことをしましたが、GPGPUに興味のない人には退屈な内容だったかもしれません。

以前、Direct3D 12の簡単な入門記事「Direct3D 12 (DirectX 12) の簡単なサンプル」を書いたときには、コマンドリストの中で複数のPipeline State Object (PSO) を切り替えて、異なるシェーダーを適用してトライアングルをレンダリングするためのテストコードを実装しました。
今回はVulkanを使ってまったく同じことをします。レンダリング結果はD3D12バージョンとまったく同じになるようにしました。あらかじめ断っておきますが、「簡単なレンダリングサンプル」と言ったな。あれは嘘だ。

https://sygh-jp.github.io/content_hosting/my_program_ss/MyMfcSimpleVkTest1_ss_2018_04_17a.png

例のごとくMFCと公式のVulkan C++ラッパーを使って省力化していますが、それでも初期化コードが鬼のように長くなりました。Queue Family IndexやMemory Type Indexなど、ハードウェアの構成や仕様の差異にプログラマーサイドが柔軟に対応できる能力がある反面、抽象化層が極端に薄く、やはりAPIとしてはDirect3D 12を遥かにしのぐ難易度です。なかでも最難関だと感じたのは、やはりD3D12でのDescriptor Heapに相当するDescriptor Setまわりでした。頂点バッファとUniform Buffer Object (UBO) を使っているだけなのに、すでにこの有様です。分かってはいましたが、これにインデックスバッファやテクスチャ、Shader Storage Buffer Object (SSBO) といったおなじみの要素が加わってくるとなると、もうあっという間に複雑度が爆発して個人レベルでは手に負えなくなるのは目に見えています。

ちなみに、前回D3D12で使ったHLSLシェーダーを、中間言語であるSPIR-Vにコンパイルして、Vulkanでもそのまま使うことができました。一見地味ですが、HLSLシェーダーを一切変更することなく、Vulkanからも利用できるというのは驚異的ですね。これこそが中間言語の威力です。Cg言語のようなソフトウェアトランスレーターとは訳が違います。Direct3DではHLSLが登場する前から、ベンダー非依存のシェーダーアセンブラ中間言語として導入されていたことで、ハードウェアやドライバーの差異を気にすることなく開発できていましたが、OpenGLはなぜもっと早く同様のシェーダー中間言語を導入してこなかったのか、本当に惜しまれます*1

相互運用について

OpenGLDirect3D 11には、VulkanやDirect3D 12との相互運用を可能にするレイヤーや拡張が用意されています。従来のGL/D3Dアプリにおいて、Vulkan/D3D12に完全移行することはできないが、大量のドローコールのせいでボトルネックになっている箇所だけどうしても高速化したいという場合には、そういった相互運用を検討してもよいかもしれません。ただ、個人的な経験(手痛い失敗経験)から言わせてもらうと、やはり安定したアプリケーション開発のためには、あちこちに手を広げてむやみに複雑な解決策を持ち込もうとせず、できるかぎり単一のAPIのみに絞ったほうがいいと思います。理由として、複数の言語やAPIおよびフレームワークを混在させたハイブリッド開発は、コーディングがメチャクチャ疲れるうえに不具合を混入させやすいからです。また、相互運用が標準機能でなく拡張機能の場合は、ベンダーやユーザープログラマーによって十分テストされていないことから潜在的に不具合を抱える確率が高くなります。単に相互運用の能力があるということと、実際にそれを製品コードに使う、ということには大きな隔たりがあります。
CUDA/OpenCLにもGL/D3Dとの相互運用機能が存在しますが、GPGPUによるシミュレーション結果を可視化したいときは、(CUDA/OpenCLを使ったほうが効率的に記述できる場合を除いて)できるかぎりGLSL/HLSLのコンピュートシェーダーを使うべきでしょう。

*1:OpenGL 4.6でGL_ARB_gl_spirvつまりSPIR-Vのサポートが標準化されましたが、2018年4月時点でフル対応ドライバーをリリースしているのはNVIDIAだけです。本家OpenGL中間言語が早期に実現されていれば、派生規格であるOpenGL ESでも採用されていたはずで、アプリケーション開発者がベンダードライバーごとのシェーダーコンパイラーの挙動の違いなんぞに苦労することもなかったと思います。

Windows 10の右クリックメニューにコマンドプロンプトを復活させる

Windows 7エクスプローラーで、Shiftキーを押しながらコンテキストメニュー(右クリックメニュー)を表示すると、「コマンド ウィンドウをここで開く」という隠しコマンドが表示され、コマンドプロンプトのカレントディレクトリをそのディレクトリに設定した状態で起動することができます。通例、コマンドプロンプトを起動するとカレントディレクトリは%UserProfile%に設定されるので、特定のディレクトリ(フォルダー)でバッチ処理をしたくなったときにディレクトリの移動が煩雑なのですが、そういうときにこの隠しコマンドが威力を発揮します。
Windows 8.xおよびWindows 10 Anniversary Update (1607) までは同様の機能を備えていました。

しかし、Windows 10 Creators Update (1703) では、「PowerShell ウィンドウをここに開く」というメニューコマンドが追加され、逆に「コマンド ウィンドウをここで開く」は削除されてしまいました。
Windows PowerShellは確かにコマンドプロンプトと比べて遥かに強力ですが、オプション書式に互換性がなく、従来のコマンドに複雑なオプションを指定した場合はそのままでは実行できなくなっているため、依然としてコマンドプロンプトの需要は残っています。

コマンドプロンプトを起動するためのメニューコマンドを復活させるには、レジストリをいじる必要があります。

毎回手作業で実行するのは面倒ですので、今回は「コマンド ウィンドウをここで開く」コマンド復帰の手順を一発で実行するためのレジストリファイルの内容を記載しておきます。UTF-16LE形式のテキストファイルで.reg拡張子を付けて保存してください。ただしご利用は自己責任でどうぞ。

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Classes\Directory\Background\shell\cmd]
"HideBasedOnVelocityId"=dword:00000000
"ShowBasedOnVelocityId"=dword:00639bc8

なお、上記のエントリを追加しただけでは、エクスプローラー右ペインのリストビューのディレクトリアイテムに対してコンテキストメニューを表示したときにメニューコマンドが表示されませんが、それほど困ることはないと思います。カレントディレクトリに設定したいフォルダーを開いて、リストビューの余白内でメニューを表示するか、あるいはエクスプローラー左ペインのツリービューのディレクトリアイテムに対してメニューを表示することでコマンドが出現するので、必要十分ではないでしょうか。
また、上記エントリは現在のWindowsログオンユーザーのレジストリのみに追加され、ほかのユーザーには影響しません。

ちなみに、特定のディレクトリをカレントに設定した状態でコマンドプロンプトを起動する他の方法としては、エクスプローラーのアドレスバーに「cmd」と入力する手もあります。

ネットワークディレクト

ネットワークディレクトリ(\\で始まるUNCパス)は、コマンドプロンプトのカレントディレクトリとして使えないという制約があります。そのため、ネットワーク上の共有フォルダーにて「コマンド ウィンドウをここで開く」を実行すると、まずWindowsによって自動的にネットワークドライブレターが割り当てられてから、そのドライブ上で改めてコマンドプロンプトが起動するという動作をします。

コマンドプロンプトの将来

隠しコマンドにPowerShellを追加するにしても、コマンドプロンプトを残して両方使えるようにしておけばいいのに、なぜわざわざ削除したんでしょうか?
MSは将来的にレガシーなコマンドプロンプトを抹殺する気なのかもしれませんが、肝心のPowerShellが完全な上位互換でないのに移行できるわけがありません。
そんなにPowerShell推しなんだったら、まずVisual StudioのコマンドベースユーティリティをPowerShellに置き換えてみせろよと言いたいです。PowerShellのバージョンがフラグメンテーションを起こしていることもあるせいか、いまだにVisual StudioのツールはPowerShellでなくコマンドプロンプトに依存している部分が多々あります。

ascii.jp

余談

実は、Shiftコンテキストメニューには、ほかにも「パスとしてコピー」(Windows 7)あるいは「パスのコピー」(Windows 8.x/10)という便利な隠しコマンドが用意されています。このコマンドはディレクトリおよびファイル両方に対して使用でき、実行することでクリップボードにアイテムの絶対パス文字列をコピーします。
ディレクトリのパスは通例エクスプローラー上部のアドレスバーをクリックすることでも簡単に取得できますが、Windows Vistaまではファイルのパスを1アクションで取得する機能がなく不便でした。こういった細かいユーティリティは、OSの標準機能として提供されていることが一番重要です。標準機能であればどの端末でも必ず使えることが保証されているので、サードパーティ製のプラグイン/ツール/サービスをインストールできない環境を使うときや、エンドユーザーあるいは同僚に操作の指示を出したりマニュアルを作成したりするときに重宝します。OSの設定を変更することなく、最初から既定でどのユーザーでも使えるようになっていることも必須条件ですね。

VulkanシェーダーでSub-group命令を使う

NVIDIAはKepler (Compute Capability 3.0) 世代のハードウェアにおいて、Warp Shuffle命令を実装しました。WarpシャッフルはCUDAから組み込み関数 (intrinsic function) の形で利用できるSIMD命令の一種で、Warpと呼ばれるスレッドグループ内での並列データ交換を実現する機能です。NVIDIAGPUでは、ひとつのWarpは32個のハードウェアスレッドからなり、またWarp内の各スレッドはすべて同じ命令を実行します*1。つまり、ひとつのWarp内のスレッド群はすべて同期して並列動作する*2ため、Warpシャッフルを使うことで、データ列の総和を求めるリダクション演算などを、共有メモリを使うよりも高速に並列実行することができます。

Warpシャッフルに関しては、以前「CUDA Warpシャッフル命令のエミュレーション」という記事を書きましたが、CUDAの共有メモリに関する知識があれば、Warpシャッフルがいかに便利で簡潔な機能であるかを理解できると思います。

WarpシャッフルのようなSIMD命令は、汎用的な計算(GPGPU)だけでなく、グラフィックスのポストエフェクト処理などの高速化にも非常に有用なのですが、APIの停滞のせいであまり標準化が進んでいませんでした。NVIDIAWarpシャッフル命令をHLSL/GLSLから利用できるベンダー拡張を提供していますが、当然NVIDIA環境でしか使えないという制約があります。

Warpシャッフル相当の機能はまた、OpenCL 2.0の拡張機能cl_khr_subgroupsおよびOpenCL 2.1のコア機能として策定されていますが、2018年3月現在、OpenCLの実装はどのベンダーも停滞しており、OpenCLには期待できない状況です。一方、OpenGLにもARB拡張GL_ARB_shader_ballotとして存在しており、OpenCL同様にサブグループ (Sub-groupあるいはSubgroup) と呼ばれています。GL_ARB_shader_ballotはCUDAのWarpシャッフルのサブセットであるものの、GLSLを使えばOpenGLだけでなくVulkanからも基本的なサブグループの機能を利用できます。

Vulkanの学習を兼ねて、コンピュートシェーダーにてサブグループ命令を利用するサンプルコードを書いてみました。実行にはVulkan 1.0とVK_EXT_shader_subgroup_ballot拡張をサポートする環境が必要となります。NVIDIAハードウェアの場合、Kepler世代以降であれば拡張をサポートしているはずです。サンプルはWindows環境向けですが、ウィンドウシステムへのアクセスを必要としないオフスクリーンのコンピュート機能だけを使っているため、他の環境に移植するのは比較的簡単だと思います*3

以前書いた記事「Vulkan SDK付属のGLSLコンパイラー」では、Vulkan SDK付属のシェーダーコンパイラーがあまりに未完成なことを嘆いていましたが、その後着々と進化を続け、ほぼ使えるレベルに達したようです。
なお、今回はホストコードの記述量を減らすため、C++向けのラッパー (vulkan.hpp) を使っています。もともとこのラッパーはNVIDIAから寄贈されたものをベースに公式化されたらしいのですが、設計不足な点が散見されたり、一部の関数テンプレートのコンパイルが通らないというひどいバグが混入していたりと、まるでテストされていないことがありありとうかがえます。はっきり言ってプロダクションコードに使うには厳しい印象です。本気でVulkanの導入を検討する場合は、ぶっちゃけこのラッパーは使わないほうがいいでしょう。

なお、AMDAnvil*4という上位レベルのVulkanベースフレームワークを公開していますが、いつも仕事が中途半端なAMDが、この先ちゃんと継続的にメンテしてくれるのかどうか不安です。AMD APP SDKも、2015年8月にリリースされたv3.0で放置されたままという体たらくなので、正直期待できません。

Vulkan 1.1とSub-group命令

先日Vulkanのアップデートとしてv1.1が発表されましたが、Direct3D 12が先行していた、マルチGPUの活用やシェーダーモデル (SM) 6.0に対応する形で、重要な新機能が追加されているようです。サブグループ演算 (subgroup operation) に関しても、既存のOpenGL互換のARB拡張とは別のKHR拡張 (GL_KHR_shader_subgroup) およびホストAPIの正式仕様が策定され、CUDAと同等あるいはそれ以上の機能を獲得したようです。

なお、DirectXにおけるSM 6.0の目玉とも言えるのが、Sub-groupに相当するWave命令セットです。Waveは機能レベル12_0以上でないと使えないとか、そもそもDirect3D 12自体がWindows 10でないと使えないとかいう制約があり、個人的にはプラットフォーム制約の少ないVulkanのほうが有望だと思うのですが、いずれにせよこれでようやくCUDA以外でも高速なSIMD命令が標準的に利用できる土台が整い始めました。
とはいえ、HLSLもGLSLも、CUDA C++に比べるとプログラマビリティは遥かに劣ります。個人的にはC++のテンプレートが使えないのが一番痛いです。OpenCLは2.2でようやくカーネル記述言語にC++を採用しましたが、PCプラットフォームではまだどのベンダーもOpenCL 2.2をサポートしていません。純粋なGPGPU用途であれば、結局CUDAの地位は安泰であり、ただ単にNVIDIAハードウェアの能力を最大限活用できるAPIというだけでなく、地球上でもっとも生産性の高いGPGPU開発基盤であることは疑いの余地がありません。VulkanはせっかくSPIR-Vという強力なシェーダー中間言語を持って生まれたのだから、今後はシェーダーコンパイラーのさらなる飛躍と、Metalシェーディング言語のような新しいC++ベースのフロントエンドのサポートに期待したいところです。

*1:AMD GPUにおいてもWarp同様の概念としてWavefrontが存在します。Wavefrontは64個のハードウェアスレッドからなります。

*2:GPUコアの1サイクルでWarp内のすべてのスレッドが同時に駆動するとは限りませんが、論理的には必ず同期するようになっています。

*3:OpenGLでは仮にコンピュートを利用するだけであっても、GLコンテキストの作成にウィンドウハンドルを必要とし、しかも実行デバイスを明示的に選択する機能すら標準で提供されていませんでしたが、Vulkanは遥かに洗練されており、OpenCLやDirectComputeと似たような使い方ができるようになっています。

*4:Anvilとは「金床」(かなとこ)という意味ですが、UbisoftのAnvil Engineとカブっているので、できれば別の名称にして欲しかったです。

C/C++の#warning

コンパイルエラーを意図的に発生させる#errorプリプロセッサディレクティブに関しては、お馴染みの#includeや#defineなどと同様に言語仕様として標準化されているようで、おそらくすべてのC/C++処理系でサポートされています。

#ifdef __cplusplus
#error This code does not support C++!!
#endif

問題は警告のほうです。C/C++でユーザー定義の警告を発生させる方法は標準化されていません。
gccには#warningディレクティブが存在するのですが、Visual C++には存在しません。Clangにも存在しないようです。
#warningの実装は過去に提案されていたりするのですが、実現には至っていないようです。

#pragma messageはたいていの処理系でサポートされているのですが、単にメッセージを出力するだけで、警告にはならず、強制力がありません。

#ifdef NDEBUG
#pragma message("This code is compiled when release mode.")
#endif

また、#pragma messageでファイル名と行番号を出力しようとすると、__FILE__マクロと__LINE__マクロおよびトークンの文字列化と結合を駆使せねばならず、移植性のあるコードを記述するのが大変になります。

C#

一方、C#では#warningがちゃんと標準化されています。当然#errorもあります。

やはり本来は処理系ごとにどうにかするべき問題ではなく、C#のように言語仕様として標準化してほしい機能です。


え、Javaですか? そんな貧弱な言語は知りませんね。窓から投げ捨てましょう。

※2023-02-19追記:
C23およびC++23で、ついに#warningが標準化されるようです。

C#の登場から20年以上の歳月を費やし、ようやくその必要性を認めたようです。相変わらず遅すぎる。

Windowsの画面キャプチャ取得方法

Windowsにおいて、画面のキャプチャ(スクリーンショット)を取得する方法はいくつかあるのですが、下記の標準機能は遥か昔(たぶんWindows 95あたり)から搭載されています。いずれもWindowsユーザーであれば誰もが知っていないとおかしいレベルの、初歩中の初歩です。

PrintScreenキー デスクトップ全体を1つの画像として取得します。マルチディスプレイ(マルチモニター)環境の場合、合成された1つの画像となります。
Alt+PrintScreenキー アクティブなウィンドウのみのスクリーンショットを取得します。ただしMDI子ウィンドウのみのキャプチャには対応していません。アクティブでない別のウィンドウがかぶさっている場合、そのウィンドウも映り込みます。

PrintScreenキーで取得したデータは、不可視のクリップボード(システム全体で共有するグローバルメモリ領域)にビットマップ画像データとして保存されます。オンメモリなので、当然Windowsをシャットダウン/再起動すると消失する揮発性のデータです。クリップボードに保存されたビットマップ画像データをファイルとして保存する場合は、お好みのペイントツールにてキャンバスに貼り付けて、所望のフォーマットで保存します。Windowsに標準搭載されているMS Paint(ペイント)を使う場合は、あらかじめキャンバスサイズを小さくしておけば、ペースト時に画像サイズに合わせてキャンバスを自動拡張してくれます。MS Word/Excel/PowerPointなど、Office系のソフトも直接クリップボード経由でドキュメント内に画像を貼り付けることができますが、設定によってはファイル埋め込みの際に、勝手に画像の解像度を落としてしまうこともあるので注意が必要です。サードパーティ製のアプリケーションを自由にインストールできる自宅のプライベート端末では、起動と動作が軽快なIrfanViewを使ってクリップボードデータをファイル保存することが多いです。

ちなみにスクリーンショットを画像ファイルとして保存するときは、通例可逆圧縮PNGフォーマットを使います。非可逆圧縮JPEGは主に写真向けの圧縮フォーマットであり、画面スクリーンショットの保存には向いていません(色変化の激しい部分でモスキートノイズが目立ったり、PNGよりもファイルサイズが増加したりします)。

なお、スクリーンショット画像にはマウスなどポインティングデバイスのカーソルが含まれません。カーソル合成前の画像となります。特に困ることはないと思いますが、もしマニュアル作成用途などで画像にカーソルをどうしても含めたい場合は、スクリーンショットにカーソルのアイコンをオーバーレイ描画した合成画像を自動生成できるツールがあるので、そういったものを利用する方法もあります。

Windows Vista以降

Windows Vistaではキャプチャ用のSnipping Toolが搭載されました。デスクトップ全体・指定ウィンドウ以外に、選択領域のキャプチャもできます。しかし、個人的には上記のPrintScreenキーとペイントツールを使った方法よりもかえってめんどくさいので使っていません。また、PrintScreenキーを使った方法であれば、コンボボックスのドロップダウンリストを展開表示した状態や、特定のUI要素をマウスオーバーした状態でスクリーンショットを取得することができますが、Snipping Toolではそういったことができません。

Windows 8以降

Windows 8において、Windowsキー+PrintScreenキーを押すと、"%UserProfile%/Pictures/Screenshots" にデスクトップ全体のスクリーンショットPNG形式で自動保存されるようになりました。これはわりと有用な機能だと思いますが、Windows 7以前では使えないので、知っている人は少ないかもしれません。

ただし、Alt+PrintScreenのようにアクティブウィンドウのみをキャプチャして直接ファイル保存する機能がありません。この点がかなり不満です。

Windows 10

Windows 10ではゲーム録画 (Game DVR) の機能が追加され、Windows+Alt+PrintScreenでアプリのスクリーンショットを取得・保存できるようになりました。保存場所は"%UserProfile%/Videos/Captures"だそうです。「ゲーム録画」と銘打っていますが、ゲームアプリ以外でも使えます。しかし、利用にはXboxアプリへのMicrosoftアカウントを利用したサインイン(ネットワーク接続)が必要です。ローカルアカウント中心で使っているユーザーや、企業ユーザーの場合は使えない手段でしょう。Game DVRは当初既定で無効化されていたものの、Anniversary Update (1607) にて既定で有効化されたようです。以降は無効化する場合にもXboxアプリへのサインインが必要だそうで、もう意味不明ですね。Game DVRは個人情報が勝手にぶっこ抜かれる可能性があるので、自分は使っていません。

なお、Creators Update (1703) では余計な機能満載のPaint 3Dが標準インストールされるようになったのですが、さらにFall Creators Update (1709) では、従来の標準ペイントツールMS Paintが廃止・非標準になりました。完全に廃止されたわけではなく、Windowsストア(Microsoftストア)から明示的にインストールすれば使えるらしいのですが、ストアへのアクセスにはやはりサインイン(ネットワーク接続)が必要となります。電卓アプリや画像ビューアーの劣化と同じような道をたどるようです。ぶっちゃけ「Creators Update」とかいいつつ、誰も望んでいない、使えないゴミアプリを搭載しただけのアップデートです。そもそもCreatorだったらAdobe/Autodeskなどのデファクトスタンダードサードパーティ製ツールを使うのでPaint 3Dなんぞ要らないですね。

MS Paint自体はAdobe Photoshopなどと比べると大した機能を持っていませんが、これまでは標準インストールされていたことが最大の強みでした。特に仕事で、好きなペイントツールが使えない(インストールされていない/できない)端末において、取得したスクリーンショットをファイル保存するときだけはMS Paintをよく使っていました。また、機能が少ないぶんシンプルで、操作体系も昔からほとんど変わっていないため、初心者でも使いやすいというメリットがありました。しかし、今後は仕事で他の人にスクリーンショットの取得を指示する場合、まずはPaint 3DもしくはSnipping Toolに慣れてもらう必要がありそうです。

Steam

Valveが提供・運営するSteamプラットフォーム向けのゲームでは、共通してF12キーでスクリーンショット画像をファイル保存できます。ウィンドウモードでもクライアント領域のみが保存されるので、Steamの場合はこちらのほうが便利でしょう。昔はJPEGフォーマットのみでしたが、現在は劣化の無いPNGでの保存もサポートされています。
保存場所は "%ProgramFiles(x86)%/Steam/userdata/<ユーザーID>/760/remote/<作品ID>/screenshots" です。階層が深くて覚えにくいので、途中の "remote" フォルダーへのショートカットを作成しておくといいかもしれません。
Steamクライアントの「ライブラリ」から各ゲームのページを表示して、「スクリーンショット」欄の「全スクリーンショットを表示」ボタンをクリックすることで、「スクリーンショットアップローダ」ダイアログが表示され、このダイアログ上の「フォルダを表示」ボタンを押すことでもアクセスできます。ダイアログ上で各スクリーンショット画像(とサムネイルのペア)を削除したり、オンラインコミュニティにアップロードしたりすることができます。

余談

XPやVista/7はLunaやAeroといったVisualテーマを適用すると、ウィンドウの四隅が丸くなります。キャプチャすると四隅の部分は白色となりますが、個人的にはこの丸まった四隅がダサくて大嫌いでした。
また、過去のWindowsではタイトルバーにグラデーションが使われていたり、Windows Aero (Aero Glass) の機能でウィンドウが透過していたりしたのですが、これによりPNGキャプチャ画像は無駄にファイルサイズが大きくなりがちでした。なめらかに色変化する複雑な画像はPNGだと圧縮しづらいからです。Windows 8.xではデザイン方針としてModern UIを採用することでタイトルバーがシンプルな単色になり、PNGキャプチャ画像のファイルサイズも削減されました。しかし、Windows 10 1709では、Fluent Design Systemという、これまたMSの自己満足的デザイン方針が採用され、AppleiOSで採用されているような半透明のすりガラス(アクリル)効果が多用されることになったため、再びPNGキャプチャ画像のファイルサイズが無駄に増えそうです。「設定」→「個人用設定」→「色」にて「透明効果」をOFFにすることで無効化できるので、気になる人は設定変更しておいたほうがいいと思います。

2018-07-31追記:
Windows 10の次期バージョン(RS5)では、Snipping Toolが廃止予定となったようです。代わりに「Screen Sketch」とやらが導入される予定だそうですが、どうも微妙な感じのツールですね。どうせ使わない気がします。短命に終わる要らないアプリを開発してるヒマがあったら、バグのひとつでも取り除いてOS自体の品質を高めて欲しいです。

GeForceドライバー380系列のDirect3D 11バグ

3DグラフィックスとC++の研究目的で、DirectX 11 (Direct3D 11) を使った自前FBXビューアーを開発しているのですが、とある自作FBXファイル(約18,000ポリゴン程度)を開いて、カメラを回転させながら描画すると、レンダリングが停止する現象に遭遇しました。デバッグ レイヤーからは以下のようなエラーメッセージが出ます。いわゆるTDRハングアップです。

D3D11: Removing Device.
D3D11 ERROR: ID3D11Device::RemoveDevice: Device removal has been triggered for the following reason (DXGI_ERROR_DEVICE_HUNG: The Device took an unreasonable amount of time to execute its commands, or the hardware crashed/hung. As a result, the TDR (Timeout Detection and Recovery) mechanism has been triggered. The current Device Context was executing commands when the hang occurred. The application may want to respawn and fallback to less aggressive use of the display hardware). [ EXECUTION ERROR #378: DEVICE_REMOVAL_PROCESS_AT_FAULT]

具体的にどのメソッドコールやシェーダーがタイムアウトのトリガーになっているのかまでは調べ切れていないのですが、以前は同じFBXファイルをまったく問題なく表示できていました。検証した組み合わせ環境は以下の通りですが、どうやらNVIDIA GeForceドライバーを384.94に更新したことが原因のようです。Windows 7 (SP1 Platform Update) でもWindows 10でも発生します。

  • Win10 (1703) x64 + GeForce GTX 760 4GB + 384.94: hang
  • Win10 (1703) x64 + Quadro M4000 + 382.48: OK
  • Win10 (1703) x64 + Quadro M4000 + 386.01: OK

少なくともQuadro M4000では比較的新しいドライバーを適用しても問題が発生しないことを確認できています。Quadroのドライバーは基本的にGeForceよりも厳密度や品質・安定性が重視されているので当然と言えば当然かもしれません。Kepler固有の現象なのか、それともGeForceであればMaxwellPascalでも発生するのかは不明です。

Direct3D 11は現在のハイエンド3Dゲーム開発における中核ともいえるAPIで、すでに次世代ローレベルAPIであるDirect3D 12やVulkanが正式リリースされて2年ほど経つものの、アプリケーション開発のしやすさの点から言えば、いまだDirect3D 11の地位は揺るぎません。今回発見したバグは、現役のAPIに関する基本的なリグレッションなので、すでにゲーム開発者やゲーマーからNVIDIAにバグ報告が寄せられて修正されていてもいいような気がしますが、2017年12月にリリースされたドライバーでも修正されていないようです。

逆にある程度古いドライバーだとタイムアウト現象は確かに出ないのですが、古いドライバーにはセキュリティ脆弱性が潜んでいることがあるので、古いドライバーを使い続けるのも得策ではありません。もともと384.94は、重大なセキュリティ脆弱性が修正されたとかいう話だったので急遽インストールしたものです。

なお、年明け早々に大々的に報じられたCPU脆弱性Spectre/Meltdownのうち、Spectreの修正に対応した390系列のドライバーが先日公開されました。とはいってもGPU側の予測分岐機能などがシステムのセキュリティに影響を及ぼすわけではなく、たとえばWebブラウザ上で実行するJavaScriptのように、悪意のあるコードの踏み台となりえるソフトウェアプログラムが含まれていたせいか、もしくはパッチ適用によるシステム低速化を緩和させる目的で、おそらく今回の修正対象となったものと思われます。通例ドライバーはシステムメモリにカーネルモードでアクセスできるため、対策も必要となるのでしょう。近いうちに390系列も試す予定です(ただし人柱になるのは御免こうむりたいので、しばらくは様子見)。

余談:ドライバー更新時の問題

バージョン番号の新しいNVIDIAドライバーをインストール(バージョンアップ)する場合は通例上書きインストールできるものなのですが、検証などのためにロールバック(バージョンダウン)しなければならない場合、まず現在のドライバーをアンインストールするのが常套手段です。
しかし、NVIDIAのグラフィックスドライバーおよびHDオーディオドライバー*1をコントロールパネルからアンインストールした後、Windowsを再起動すると、Windowsによって勝手にハードウェアの認識と古いデフォルトドライバーのインストールが始まってしまうのが厄介です(しかも結構時間がかかる)。マウスやキーボード、フラッシュメモリなどのUSBデバイスに関しては、こういったプラグ&プレイによる自動認識動作は非常にありがたいのですが、グラフィックスやオーディオまで勝手にデフォルトドライバーをインストールされると非常に困ります。
なお、XPまではグラフィックスとオーディオのドライバーは自動インストールされず、OSインストール直後はハードウェアアクセラレーションが使えない状態となるのがデフォルト動作になっていました。このグラフィックスとオーディオのデフォルトドライバー自動インストール動作はWindows Vista以降で実装されたものです。ドライバーのインストール作業の方法が分からないビギナーにとってはありがたいものなのかもしれませんが、ドライバーバージョンを完全に自分でコントロールしたいパワーユーザーにとっては単なるおせっかいでしかない迷惑機能です。「デバイスのインストール設定」でWindows Update経由のドライバーインストールを無効化していても抑制できない模様で、またローカルのどこかにデフォルトドライバーのインストーラーパッケージを隠し持っているためか、ネットワークを切断していても抑制できません。どうやら抑制するにはレジストリ操作が必要らしく、面倒なので今回はあきらめることにしました。

*1:HDMIなど、グラフィックス以外にオーディオ伝送も可能とするインターフェイスが存在します。そういったものをグラフィックスデバイス経由でサポートする目的で、NVIDIAのドライバースイートにはオーディオドライバーも含まれています。