元半導体設計屋 筑秋 景のシリコン解体新書
Lunar Lakeの進化したスレッドディレクター
2024年10月29日 06:22
前回はLunar Lakeの革新ともいえる進化の概要を説明した。今回はその中でも特に画期的なアーキテクチャの進化といえるスレッドディレクターについて掘り下げる。
Intelはスレッドディレクターを第12世代Core(コードネームAlder Lake)から導入している。Core Ultraシリーズ2(コードネームLunar Lake)ではそのスレッドディレクターは4世代目になる。
Lunar Lakeでは、ソフトウェアのチームやレファレンスプラットフォームコード設計者、ハードウェア設計者と連携し、ソフトウェアのトレンドがどこに向かうのかや、スレッドディレクターをどのように調整すべきか、そしてパワーとパフォーマンスのメリットをエンドユーザーにいかに還元するかについて検討したという。もちろんここにはMicrosoftとの連携も含まれている。
なぜスレッドディレクターが必要になったのか
スレッドディレクターのことを少し振り返っておこう。第1世代のスレッドディレクターはコードネームAlder Lakeで登場した。Alder LakeからハイブリッドパフォーマンスPコアとEコアという2つの異なるマイクロアーキテクチャを同じSoCに搭載することになったからだ。
命令セットや機能などの観点からはその2種類のコアは同等になる。同じISA (Instruction Set Architecture: 命令セットアーキテクチャ)で設計され、同じ命令セットをサポートする。しかし、2つの異なるマイクロアーキテクチャが存在することで、特定の命令シーケンスを実行している場合、PコアとEコアのどちらでパフォーマンスが高いかを判断、選択する能力が必要になった。
それまで、OSにはどちらのコアが最適かの情報を取得する方法はなかった。その情報を提供するためにSoCに何らかの仕組みが必要になり、スレッドディレクターが誕生したわけだ。
具体的にはSoC上のコアの電力効率リストと、コアのパフォーマンスリストを提供する。OSに送られるのはハードウェアのガイダンス付きのヒントだ。そして、SoCの状況に応じて、タスクのスレッド配置を推奨するのがスレッドディレクターになる。
SoCはOSにヒントや提案を提供するが、実際のスレッドをどこに配置するかを決定するのはOSになる。OSは優先度、QOSであるサービス品質、フォアグラウンド/バックグラウンド、スレッドが準備完了キューで長時間待機しているかなど、実行中のソフトウェアに関する多くの情報を持っている。
一方、スレッドディレクターは、どのような命令が実行されているのか、プラットフォーム上の電力、放熱制約、NPUやGPUなどの他のIPでの電力消費、コアに回せる電力はどのくらいなのかなどに関する情報を持っている。
スレッドディレクターはこのすべての情報を取得し、スレッドディレクターテーブルの形式で集約し、OSに通知。そして、OSはその情報を理解、判断し、最適なスケジューリングを導き出す。ハイブリッドアーキテクチャに実装されているスレッドディレクターの基本的な動きはこのようになっている。
Lunar Lakeにおけるスレッドディレクターの進化とは
Lunar Lakeで投入された主要な新しいイノベーションは4つある。
Alder Lake、Raptor Lake、Meteor Lake各世代では、スレッドディレクターテーブルにはクラス0、1、2、3の4つのカテゴリクラスがあった。それらのスレッドディレクターはIPC、つまりPコアとEコアの1サイクルあたりの命令数を計算することで、どちらがよりパフォーマンスを発揮し、どちらがより効率的になるかを示していた。
Lunar Lakeでは、EコアとPコアのマイクロアーキテクチャがそれぞれ進化したため、カテゴリクラスを再分類する必要が出てきた。これらの変更は前世代からの改良ではなく、新規に設計したという。そして、分類粒度は、ミリ秒単位で行なわれるよう一部を変更した。このクラスの再分類と粒度の変更が1つ目のイノベーションとなる。
2つ目のイノベーションとして、新しい電源管理の機能強化をした。SoCで実行されているワークロードのタイプを調べ、SoC内部の電力管理の最適化する。このプロセスにおけるPコア/Eコアの推奨もスレッドディレクターテーブルを介して伝えられる。
3つ目のイノベーションは、Microsoftと共同で作成した機能で、OSコンテインメントと呼ばれる機能だ。OSコンテインメントには、Lunar Lakeのスレッドディレクターによる情報が必要であり、Microsoftはそれを利用することで「コンテインメント(封じ込め)ゾーン」と呼ばれる仕組みを作った。
これにより、システムの電力効率の意図をハードウェアが理解し、Teams、ビデオ通話、ビデオ再生などの低消費電力な作業を高効率のコンピュートエリア(Eコアクラスタ)で実行するといった適切な判断を下せる。これに関してこの後でも詳しく説明する。
4つ目のイノベーションは、プラットフォームの意図(性能と消費電力のバランス)を反映することとなる。これも下記で詳しく説明する。
PCメーカーのプラットフォーム最適化を反映するには
スレッドディレクターはAlder Lake世代から搭載されたが、その時点でPCメーカーから多くの依頼があったという。内容は、性能と消費電力のバランスや調整をスレッドディレクターに反映させたいというものだった。
そこでIntelはPCメーカーと議論を行ない、Microsoftとも同様な議論をしたという。そしてIntelは、スレッドディレクターにプラットフォームの意図を反映させることをMeteor Lake世代から行ない、Lunar Lakeではそれをさらに強化した。
“Bringing it All Together”というタイトルのスライドでの緑色のボックスの下に見える水色のボックスがIntelダイナミックチューニングテクノロジーのソフトウェアレイヤーになる。Intelハードウェアに対してPCメーカー側のプラットフォームの意図を反映させるためにギアと呼ばれるものを提供する。パフォーマンスを上げたい、あるいは電力効率を高めたいという要求に対して、ギア1からギア7まで用意した。プラットフォーム内でギア値を設定できる仕組みだ。
ギア1は最大パフォーマンスを意味し、数値が大きくなるほど電力効率が高くなることを意味する。そして、これはダイナミックチューニングなどのプラットフォームシステムソフトウェアと連携する。PCメーカーはそれを使用して、最も高いパフォーマンスを要求するにはギア1に設定し、最も高効率にする場合にはギア7に設定する。これらのギアは、内部リスト、SoC、および電源管理アルゴリズムに影響されないという。
サードパーティのアプリケーションは、プラットフォームとしての電力や放熱の制約を知らない。そのため直接的な入力は避け、ヒントを指定する間接的な反映をする仕掛けにしている。具体的には、ダイナミックチューニングユーティリティという、多くのPCメーカーがノートブックPCデザインで使用しているソフトウェアを、SoCへの入力として利用することにしたのだ。内部のSoC最適化(ワークロード検出など)を利用して、OSに適切な入力を提供し、パフォーマンスや電力の意向を反映するようにしている。
ユーザーが電力の効率を最大化したいのかパフォーマンスを求めるのかによって、利用するコアの選択は異なり、周波数の動作ポイントも異なる。そういった異なるユーザーの要求に応えるため、SoCがスレッドディレクターテーブルを介してOSにガイダンスを提供するわけだ。
アプリケーションがPコアで実行したい場合でも、スレッドディレクターは全体の状況を把握している。そのため、アプリケーションからの要求は、PCに対するあくまでも追加のヒントとなる。このヒントは「アプリケーションとしてはもう少しパフォーマンスが欲しい」というところまでなので、「Pコアのみで実行する」というような完全な指示にはならない。
IntelはISVパートナーにも、ソフトウェアを特定のコアに固定しないように伝えている。Pコアだけで実行することが最適とは限らないためで、ハードウェアとソフトウェアOSが協力して最適なパフォーマンスを提供するための柔軟性が必要ということだ。
スレッドディレクターは電力管理とパフォーマンス管理の両方を担っているので、システムへの要求が省電力重視か性能重視かに応じて、スレッドディレクターがシステム上のワークロードの種類を検出し、その状況を入力として取り込む。これにより、バッテリ寿命を重視するワークロード、突発的な負荷、持続的な負荷などを検出し、その意図に合わせてコアの選択やコアの周波数を調整する。
以上4点が、Lunar Lakeに投入された大きな進化点となっている。
スレッドディレクターでのスケジューリングの進化
Pコア、Eコアは世代の異なるプロセッサとして進化してきたため、スレッドディレクターを改善させるにあたって、どのように優先順位を付けるかを一度見直す必要があったという。スレッドディレクターの進化の中で、どのようにPコアとEコアのスケジューリングを行なってきたのかを見てみよう。
ハイブリッドアーキテクチャの最初の世代の目標は、MTパフォーマンスだった。そのため、常に最もパフォーマンスの高いコアからスケジューリングを開始している。ディスアグリゲーション(分散化)もされていなかったので、アンコア、リング、その他すべてをPコアとEコアともに共有していた。アンコア回路を動作させ続けるのであれば、Eコアに行くことには意味がなかったためだ。そこで、Pコアから始めて、マルチスレッドが必要な場合にはEコアに拡張するというハイパースレッドコアにした。
それに対し、Meteor Lakeではまず始めにSoCコア(LP Eコア)からスケジューリングすることになっている。SoCタイルには2つのSoCコアを搭載している。電力効率の観点から、作業がLP Eコアに収まる場合はそこに留まる。そうでない場合は、コンピュートタイルとSoCタイルの両方を維持するのは効率的ではなかったため、作業をコンピュートタイルの処理に移動させた。
そしてLunar Lakeでは低電力アイランドの定義がMeteor Lake世代とは少し変化しているのでそれをまず説明しておく。低電力アイランドの目的はMeteor Lake世代と同じで、最高の効率を提供することだ。Lunar Lakeでは、この低電力アイランドにMeteor Lake世代とは別のコンプレックスが配置されている。このコンプレックスはアーキテクチャ的にパフォーマンスコンプレックスと同時に動作・処理が可能だが、別に配置されている。
この低電圧アイランドにあるコンプレックスのみで処理を行なう場合、パフォーマンスコンプレックスを抑えることで、アンコアやその他の部分で電力を多く節約できる。
SoCの構造の観点から見ると、Meteor LakeからLunar Lakeにかけて、低電力アイランドやSoCタイルに含まれるグラフィックスコンポーネントなどの配置も変更されている。
そして、Lunar Lakeの世代ではメモリサイドキャッシュも提供されている。Meteor Lakeでは低電力アイランドに2つのEコアだったが、Lunar Lakeでは低電力アイランドには4つのEコアがあり、その性能は電力効率を考慮するとPコアを越える性能がある。これによりパフォーマンスや効率が向上させることができるようになった。
Lunar Lakeでは、Eコア(Skymont)が大きく進化し、エネルギー効率だけでなく高いパフォーマンスを得た。そのため、Lunar Lakeでは、スレッドディレクターはEコアから始めることができるようになった。言い換えるとEコアは通常のコンピュートタスク処理において優れたコアに進化したということだ。
そして、タスクの要求性能がEコアの能力を超える、または並列処理で実行するタスクがまだある、つまりEコアで処理可能な4スレッドを越えてくる場合は、Pコアに移行する。
前述の通り、スレッドディレクターがOSに公開したクラスは4つある。PコアとEコアの間のIPC比がどのようになるかに応じて、命令を異なるクラスに配置するという仕組みだ。それに応じてIPCのデルタも変化することになる。そのため、クラス0、1、2、3 に分類されるものを調整し、それに応じてスレッドディレクターからOSに情報提供する。
また、SoCとしてのワークロード分類も細かくなっていった。これはLunar Lakeの新機能として追加されたもので、非常に低電力な放熱シナリオにおいてOSに対する重要なヒントとなる。これは、システムの動作中に突然の変更がユーザーに認識されないように、システムのユーザーエクスペリエンスの継続性を与えるためものだという。細かいワークロード分類の中にはかなり新しいものもあり、Lunar Lake世代で追加されることになった。
スレッドディレクターでのAIワークロードとは
AIワークロードについても触れておこう。ワークロードがPコアとEコアのコンピュートタイルに割り当てられた時、スレッドディレクターはどのように役立つのかという点だ。
まずはCPU上で動作するAIタスクがあり、これは新しいベクトルニューラル命令であるVNNIを使用する。
GPUまたはNPUで実行されるAIタスクもある。一部のAIタスクは非常に高負荷なワークロードであり、処理するエンジンではより多くの電力、高い周波数を必要とする。AIをGPUまたはNPUで実行することで、CPUコアでの処理能力を空けることができる。そして、AI用IP側により多くの電力を与えて処理の効率を上げることになる。
この時、スレッドディレクターは、そのフィードバックを理解し、CPUコア側に割り当てられる電力が少なくなるため、クラス0の命令を実行している場合は、EコアのほうがPコアよりもパフォーマンスが高いと判断する。使える電力を抑えた状態での性能が高いからだ。そして、その状況をスレッドテーブルの中で更新し、そのガイダンスをOSに提供する。
AI処理をCPU上で実行する場合、AI用IPへの電力分配は考慮しなくてよくなる。その代わりに、スレッドディレクターのフィードバックを見て、このAI処理がクラス2の命令と判断した場合、クラス2の命令はPコア(高性能コア)で実行すると依然としてかなりのメリットがあるので、これらはPコアで実行されることになる。
現在、Pコア性能とEコア性能の差(デルタ)は縮小しているというが、異なるワークロードの混在時、性能差は7～8%になるという。この性能差がスレッドの割り当てには重要になってくる。これらの情報はスレッドディレクターが適切なコアに適切な作業を優先的に割り当てるのに役立つ。
スレッドディレクターとコンテインメントゾーン
4つの進化の1つである、コンテインメント(封じ込め)ゾーンについてもう少し掘り下げる。Microsoftと提携して実現した機能だということは前述している。
スレッドディレクターはテーブルを初期化し、OSはハードウェアを初期化してデータを読み込む。OSは、どのコアがPコアで、どのコアがEコアかを確認し、タイル構成などを見て、コンテインメントゾーンを作成する。
もう一度OS Containment Zoneのスライドを見ていただきたい。Eコアとしてマークされたコアはエフィシェント(効率)ゾーンに配置される。次に、ハイブリッドゾーンと呼ばれるものがある。Lunar Lakeは省電力やTDPなどの理由によりコンピュートタイル上のEコアはリング回路とLLCには接続されていない。代わりにメモリサイドキャッシュに接続されている(Meteor LakeではコンピュートタイルのEコアはリング回路とLLCに接続されている)。
そのため、コンピュートタイル上のPコアはハイブリッドゾーンとして設定され、Lunar LakeではPコアとEコアの両方の利点を得ることができる。そして、ノン(None)ゾーンと呼ばれるゾーンもあり、これはすべてのゾーンが取り除かれ、すべてのコアを自由に使えることを意味する。
Microsoftが導入したこのゾーン機能の利点は、提供されたPPM(パフォーマンスパワーマネジメント)パラメータに基づいてカスタマイズできることだ。たとえば、バッテリで動作している時、Teamsの3x3(9画面)ビデオ会議コールなどの実務的なITワークロードがある場合は、エフィシェント(効率)ゾーンに作業を配置することができる。一方、パフォーマンスモードで動作している場合は、作業をPコアに移動させて、迅速な応答や最大のパフォーマンスを得ることができる。
Meteor Lakeでは、低電力アイランド(SoCダイ)に2つのコアしかない。Teamsのようなワークロードでは、同時にアクティブなスレッドの数が4になることがあるという。2つのコアだけでは4スレッドを処理できず、コンピュートタイル上のEコアで実行する必要があった。
しかし、Lunar Lakeでは、低電力アイランドに4つのEコアがあり、このEコアはパフォーマンスと効率の両方の利点を兼ね備えている。従って、Teamsのように一度に4つのスレッドが必要になる場合でも、作業をエフィシェント(効率)ゾーンに保持することができ、Pコアへのスレッドの移動が少なくなる。これにより、コンピュートタイル上のPコアの使用をできるだけ抑えつつ、Teamsが必要とする30fpsや15fpsの応答性とパフォーマンスを維持し、同時に優れた電力節約を実現できるという。
スレッドディレクターの今後の進化
今後のスレッドディレクターの進化はどのようになるかについて、Intelのコメントから予測してみよう。
同社によると、より快適なPC体験のため、まだ改善の余地があるらしい。たとえば、Teamsを使う場合、多くのユーザーからのフィードバックでWindowsで最高効率に設定すると、30fpsや15fpsで動作し、サービス品質も満たしながら電力消費が低くできる。
一方、パフォーマンスモードに切り替えると、同じサービス品質を維持しながら(タスクとしては同じ処理のはずなのに)電力消費が増えるのはなぜかという質問が来るらしい。そこでLunar Lakeでは、このギャップを埋めるための改善を盛りこんだ。しかし、まだ完全ではなく、同じタイプのワークロードを実行する場合で、どこで実行しても同じ効率を得られるよう、将来的にはさらに多くの改善が予定されるという。
スレッドディレクターのロードマップもある。システム上で実行されているワークロードの種類を検出し、それに基づいて分類や電力消費の方法をより改善する予定だという。特にAI処理でCPU、GPU、NPUでどのように動作させるかをスレッドディレクターを使って最適化する方法を模索しているという。
PC上のワークロードが多彩になってきたため、1種類のCPUアーキテクチャで省電力モードから高性能モードまでをカバーするのには難しくなってきた。その解決策としてIntelはPコアとEコアの2種類のコアを効率よく利用することで1種類のコアでは達成できない領域を利用できるようにしている。
これを実現しているスレッドディレクターがOSとの連携を今までにないレベルでタスクとコアとの最適解を見つけ出すことにより、今までにはなかった効率と性能を提供してくれるだろう。スレッドディレクターの調整というか味付けによって同じPCでもユーザー側の期待する体験に変化していくかもしれない将来に期待したい。