元半導体設計屋 筑秋 景のシリコン解体新書
状況に応じてEコアを高性能コアにも変化させるMeteor Lake
2023年11月30日 06:14
前回の記事で3Dパフォーマンスハイブリッドアーキテクチャーの仕組みについて、コアの種類とタスクのクラス分けのところまで説明した。今回はスレッドディレクターとOSがどのように動作するのかを説明したい。
静的にも動的にも変化するPERF値とEE値
スレッドディレクターはまずクラス分けを行ない、次にEHFIテーブル(拡張ハードウェアフィードバックインターフェイス)を割り当てる。SDM(Software Developer Manual)で確認できるというテーブル内の行はコアIDになる。Pコア1、Pコア2、Pコア3といった具合で、Eコア、LP Eコアも認識され、すべてのコアが独自のIDを取得する。
そして、2つのインデックスをOSに通知する。1つはPERF値で、2つ目はエネルギー効率(EE)値になり、これらはハードウェア側の情報になる。AC電源で稼働しているか、バッテリで稼働しているか(ACアダプタが接続されているかということだけでなく)、フォアグラウンドタスクかバックグラウンドタスクなど、OS側から分からないハードウェアの状態がある。そこで、OSで実行されているタスクに対してMeteor Lakeは、OSに使用可能な2つの異なるインデックスPERF値とEE値を与え、OSはそれを参照してコアを選択できるという具合だ。
たとえば、クラス0の作業を行なっているとする。EE値が高いほど、エネルギー効率の観点からも、より望ましいコアであることを意味する。だが、ゲームのタスクなど利用可能な最もパフォーマンスの高いコアを使いたいとOSが判断をすると、PERFインデックスを参照して使用するコアを決定する。"Pコア N"にはPERFに最も高い数字が関連付けられているため、Pコア Nが選択される。
一方、ウイルススキャンを実行すると、多くの作業が行なわれる。OSは多くの作業が起こっていることは知っているが、ウイルススキャンなのでMeteor Lakeはバックグラウンドアプリケーションとしてタグ付けしているため、これはバックグラウンド作業にまわせる。その場合、OSは実行する最も効率的なコアとして、Eコアを選択する。
この例ではPERF、EEの値は静的な参照データだった。次にPERF、EEが動的に変化する例を見てみよう。
システム状態によってPERF、EEの値は変化する。コアの電力予算が低くなる状況では、システム変更または他のIPの電力制限によって、電力の割り当て調整が発生する可能性がある。高負荷のゲームを実行するとGPUがアクティブになるが、ゲームにAI処理がある場合、NPUもアクティブになる。しかし、SoCタイルの電力予算には当然制限がある。
ここからがスレッドディレクターがハイブリッドアーキテクチャで素晴らしい役割を発揮するところだ。電力予算が足りないことが分かると、スレッドディレクターテーブルが更新され、EコアNはPERF値が上がりEコアは高性能なコアとして認識されることになるのだ。実際Eコアは電力制限がある場合には、Pコアより高性能コアとしての動作できるポイントがあるのはMeteor Lakeで非常に興味深いポイントの1つだ。
このような場合、システムの状況を正しく把握して電力の最効率化をし、最も性能を出すコアの選択するために、動的な性質が重要になる。これがテーブル内の値が動的である理由になる。値が変更されるたびに、スケジュールの見直しイベントが発生し、OSに通知が送信され、OSはその情報を理解し、次のスケジュール調整で使用するのだ。
スレッドディレクターでのフィードバックの強化とスマートヒント
次にMeteor Lakeの新機能についてみてみよう。フィードバックの強化とスマートヒントに関してだ。この新機能がスレッドディレクターでの機能強化とも言える。
基本的には、アルゴリズムなどの観点からPコアの機能強化である追加のテレメトリを提供する。他のIPがSoCでの電力予算の変更が必要になってくると、動的にテーブルが更新される。1つ前の例では、他のIPがアクティブになったとき、ユーザーが期待しているのと同じパフォーマンスレベルや電力レベルを維持するために、スレッドディレクターがどうのように振る舞うかについて説明した。
スケジューリング側の例として、SoCタイルでのみ実行できるワークロードを実行している場合、スレッドディレクターはそのフィードバックを受け取ってOSに通知し、実行するにはどのコアが適切かをガイダンスする。
SoC内部の電源・電力管理に関する決定についても強化を行なっている。これには、効率的な周波数で運用するための統合も含まれており、パフォーマンスに関して確認するタイミングも理解している場合も含んでいる。効率的な動作周波数などのために統合を行なうため、エネルギー効率は重要なのでエネルギー効率が最適になっているかどうかを判断するわけだ。ここでもスレッドディレクターの推奨・ガイダンスは、OSに通知されることになる。
Meteor Lakeでは、システムで実行されているさまざまなワークロードの種類に基づいて、どのタイルがいつアクティブになっているかも分かる。高負荷、低負荷が混在したワークロードを実行している場合は、フォアグラウンド アクティビティとバックグラウンドアクティビティの両方が存在する。しかし、1つのタイルで作業を組み合わせることができれば効率も上がるので、スレッドディレクターからOSに、コアを移行させるヒント(ガイダンス・推奨)を通知し、1つのタイルで処理ができるようにコアの移行を促すのだ。
これらがMeteor Lakeのスレッドディレクターでの大きな進化と言える。この大きな進化を前の世代との比較で説明してみよう。バッテリでノートPCを動かしているとする。前の世代アーキテクチャは、図の左側に示されているようにモノリシック構造になっている。モノリシックアーキテクチャーで1つのダイ(タイル)ということになる。そして、この世代ではタスクの処理を始める導入時ではいつもPコアから作業を開始し、そのあとワークロードをEコアに展開していく。
一方Meteor Lakeでは、バッテリで作業が始まるとき、SoCタイルで開始される。その作業がLP Eコアのスレッドに収まる場合、スレッドディレクターはOSに作業をSoCタイルに残すように通知する。そこが一番効率のいいところになるからだ。
次に同時実行数を超えることが起こり、作業がSoCタイルに収まらず、より多くのコアを使用する必要がある場合か、あるいはより高い処理で動作する必要がある場合が発生すると、作業はコンピューティングタイルのEコアに移動される。この時、パフォーマンスを最大化するが、高性能のみを実現するのではなく、性能と効率を両立する相互作用を実現する。
その作業中、進行中のスプレッドシートのモデリング作業が始まるかもしれない。その場合には、Pコアが優先順位の高い作業を実行する。つまり、ユーザーが求める電力効率とパフォーマンスの両方の要件を満たすための設計がされているのだ。
スレッドディレクターとOSスケジューリングの協調
スレッドディレクターの主な機能強化は、低電力関連のドメイン、フィードバックをスケジュールの決定に組み込むことだ。しかし、優れたハードウェアとスレッドディレクターであっても、こういったバランスはOSとのコラボレーションなしでは実現することはできない。Meteor Lakeにおけるプロセッサ、電源管理の最適化、いつ作業を移動するか、使用率のしきい値、コアをいくつ使用するかなどはすべてMicrosoftと緊密に連携することで決定されたという。
実際のスレッドディレクターとOSとのスケジューリングについて見てみよう。まずはパフォーマンスが重要なタスクから始めて、後で電力効率化に移る例を紹介する。
ハイパフォーマンスタスクが始まったとする。ハイパフォーマンスタスクを処理するため、コンピューティングタイルのPコアを使用する。このあとビデオ再生が開始したとしよう。このビデオ再生タスクをSoCタイルに配置することはできるが、それでは同時に2つのタイルが起動する。そこで、すでに稼働しているものを最大限に活用すべく、コアの使用率の低い2つのバックグラウンドタスクはコンピューティングタイルのEコアに移動する。
続いて、フォアグラウンドで行なっているバッチ処理やスプレッドシート処理など、Pコアで実行していたタスクのすべてが完了し、作業タスクが終了に近くなってきた。この状況では、電力の点で理想的ではないと思われるバックグラウンドタスクがコンピューティングタイルでアクティブとなっている。
そこでスレッドディレクターが登場し、OSに「このワークロードはSoCタイルに当てはまる」と通知する。スレッドディレクターのフィードバックの提供により、その作業はSoCタイルに移動される。そのため、コンピューティング タイルを低電力状態にして、電力を節約できる。
次に、電力効率化のシナリオから始めて、パフォーマンス指向へ移行する例を見てみよう。
SoCタイルでビデオ再生を実行している中で、コンピューティングタイルで4つの基礎作業が開始されたとする。2つのタイルが稼働する状況にあるので、スレッドディレクターは、1つのタイルに統合し、もう1つのタイルの電源を切れるというヒントをOSに送る。OSはそれを採用して、作業を移動させ、パフォーマンスとパワーを提供するマルチタイルアーキテクチャのメリットを得ることができる。
スレッドディレクターにプラグインする内部電源管理の情報があり、これは電力効率とパフォーマンスの両方にとって最適なスケジューリングの決定を行なうOSを支援する上で最も高度なメカニズムの1つになっている。このタイルごとのオン/オフ、低電力モードへの移行は、従来のモノリシックアーキテクチャでは物理的に実現できないため、今後の進化がとても楽しみになってきた。他社のモノリシックアーキテクチャが追随するのか違うアーキテクチャを採用するのかも興味深い。
スレッドディレクターとOS改善によるこれらの機能強化と、スレッドをあるタイルから別のタイルに移動することについて説明したが、開発者が1対1のアフィニティを提供し、指定のコアでこのスレッドでのみ、このコードを実行するというは実現できないらしい。この点についてIntelは、アフィニティがなくても性能を出せるよう、エコシステムパートナーと協力している。
開発者がフィードバックを提供する場合は、MicrosoftのQoS APIが利用可能で、OSとスレッドディレクターで最適なスケジュール決定を行なうことで考慮される。
また、Meteor Lakeでは、スレッドライブラリ、AIライブラリ、VNNIなどの新しい命令を備えたフレームワークも最適化されている。そしてもちろん、これらすべてのISAの機能強化をしている。特にVNNIは、CPUベースのAIパフォーマンスを実現するために非常に重要だからだ。
前回と今回の記事で、ワークロードのコアへの割り当てをスレッドディレクターとOSが非常に丁寧に行なっているのがお分かりいただけたと思う。Meteor LakeではノートPCとしてのスレッドディレクターの動きがよく考えられている。OSとの連携と、ハードウェアの進化が同時に起こることでまずはMeteor Lake搭載ノートPCプラットフォームの進化に期待がかかる。さらに今後は、スレッドディレクターとOSが高性能の方向や、より省電力の小さいフォームファクターなどに、どのように応用されるのかも期待される。