「Lunar Lake」Deep Diveレポート - 【Part 3】Platform Controller Tileについて
前回と前々回で、Lunar LakeのCompute Tileに関連する部分はほぼ説明が終わったので、今回はPlatform Controller Tileに関連する話をまとめてご紹介したい。
Thread Director
Alder Lake世代で導入されたThread Director。Alder Lakeにおける動作はこちらで、Meteor Lakeにおける動作はこちらでそれぞれ説明しているが、コア構成が異なる事もありLunar Lakeでは当然振る舞いが変わってくる。まず基本的な動き方の違いがこちら(Photo01)。簡単にまとめると
Raptor Lake: まずP-Coreが処理を行い、その負荷次第でE-Coreに移すが、定期的にE-CoreのThreadをP-Coreに移動する
Meteor Lake: まずLP E-Coreが処理を行い、負荷が高ければCompute TileのE-Coreに、それで足りなければThreadをP-Coreに移動する。
Lunar Lake: まずE-Coreが処理を行い、それで足りなければP-CoreにThreadを移動する。
という形になる。
このMeteor LakeとLunar Lakeでどういう風に負荷分担が変わったか？ ということで、通常のWindowsのTask(Photo02,03)、あるいはTeamsでの動作状況(Photo04,05)を見るからには、「できるだけP-Coreを使わない」Schedulingが成されている様に見える。これが成立するのは前々回で述べたようにE-Coreの性能(というか、IPC)が大幅に引き上げられ、E-Coreで十分賄える処理の範囲が広がったため、と考えられる。というか、ここまで性能が高ければもうP-Core要らないんじゃないかと思わなくもないのだが、とは言え電力の制約でピーク性能が出ないのがE-Coreの実装なので、このあたりは仕方ないのだろう。
話を戻すと、Lunar LakeにおけるThread Directorの改良目標とその方法がこちら(Photo06)。この第一項目目である"Optimize right workload for right core"は、E-Coreの性能を大幅に引き上げて、そのE-Coreをなるべく使い倒すという形で実装されているのが既に説明されている。実際により負荷の高い、例えばOffice Productivityでは早いタイミングでThreadがP-Coreに移行され、こちらを使い切る形で動作する、とされている(Photo07)。これを実現するための技術として説明されているのがこちら(Photo08)である。
次のTighter OS integrationの手法として説明されているOS containment zonesは、要するに事前に処理負荷が判っているThread(というか、プログラム)に関しては、それをEfficient ZoneなりHybrid Compute Zoneに割り当てることで効果的にThreadの振り分けが出来るというものであり、このリストを更に充実させたという訳だ。ちなみにZonelessに分類されたThread(というかプログラム)に対するスケジュールのポリシーがこちら(Photo10)。とにかく可能な限りE-Coreを使い、P-Coreへのシフトはdemand ITD guidanceに従う、としている。
次のEnhance capabilities for efficiencyの手法であるPower management tie-in(Photo11)は、要するにPower ModeやOSの状況を見ながらThread DirectorのScheduleを変更する、という話である。これにより、Power Managementを行わないケースと比較してTeamsの場合で35%の消費電力節約が可能になったとしている(Photo12)。
最後はBroaden contextual inputのための手法であるConsuming platform intentであるが、これはPhoto11のPower management tie-inの仕組みの延長にある。Power management tie-inのレベルで、Thread DirectorはOSのSchedulerに対してHintを出すわけであるが、これに加えて新しくDynamic Tuning Technologyと呼ばれる新しいツールを提供、より細かくPower Managementを行う様にしているそうだ(Photo13)。
ちなみに今後のThread Directorの方向性がこちら(Photo14)。次はAIベースでのSchedulingとしているが、AIを使えば無条件に賢くなるというものでもないだけに、どういう形になるのか楽しみである。
Connectivity
Connectivityに関してはちょっと面白い実装になった。Lunar LakeではWi-Fi 7が可能になった(Photo15)としているが、そもそもWi-Fi 7に関してはDiscrete(Gale Peak 2)を利用する格好であり、そのGale Peak 2はMeteor Lakeと組み合わせによる動作デモなども既に行われていたから別に珍しい訳ではない(Photo16)のだが、Lunar LakeではWi-Fi 7とBluetooth 5.4のMAC層をPlatform Controller Tile中に搭載している(Photo17)。これによりパッケージサイズの小型化などが実現できた、としている。だったらいっそPHYも、と思わなくもないのだがこちらは国別の仕様の違いとか、そもそもN6でPHYを構築するのは不効率(もっと古いプロセスで十分賄える)、あるいは後になって仕様変更が出る(国別の法規制次第の部分があるので、ファームウェアアップデートで賄えない場合にはシリコンの更新が必要で、Platform Controller Tileに全部収めてしまうとCPU自身の取り換えが必要になる)事などを考慮して、PHYだけは別にしたものと考えられる。
Thunderbolt周りで言えば、まだThunderbolt 5の実装はなされておらず、Thunderbolt 4止まりである(Photo19)。新機能としてはThunderbolt Shareが挙げられるが、これは別にLunar Lake専用というわけではなく、既存のThunderbolt 4同士で利用できるので、あくまでもLunarLake「でも」Thunderbolt Shareが使えるという話である。
Security
最後にSecurity周りについて。Alder Lake/Raptor LakeではCSME(Converged Security&Manageability Engine)が搭載されていたが、Meteor Lakeではこれが細分化され、SSE(Silicon Security Engine)/GSC(Graphics Security Controller)/CSMEの3つに分かれる形で実装された(Photo20)。Lunar LakeではこのMeteor Lakeの構造を引き継いだ上で、新たにPSE(Partner Security Engine)が搭載された。このPSEであるが、
専用の暗号化/復号化オフロードエンジンとキーストレージ
FUSE(Provisioning Secretと呼ばれるプロセッサ固有のID)を格納するエリアとそのコントローラを独立させて搭載
NIST 800-193に準拠したSecurity Processorと、Firmware Update機能の搭載
といった特徴を持つ(Photo21)。このPSEがアクセスするメモリエリアは、SoCの他のブロックからのアクセスが一切不可能であり、逆にPSEがSoCのその他のブロックにアクセスする事も出来ない(Photo22)。こうした独自のSecurity Engineを3rd Partyに提供し、3rd Partyはこれを利用して独自のSecurity Solutionをクライアントに提供できるという訳だ。特にエンタープライズ向けでは、OEMメーカーごとに独自の管理ツールとかセキュリティソリューションを用意する場合が多いが、こうした管理ツールやセキュリティソリューションを高速に実行するために使える、という訳である。
他に、VT-Redirect Protection(Photo23)やIntel TDT(Thread Detection Technology)なども提供される。これらは恐らくConsumer向けのLunar Lakeでは無効化されるが、Business向けのSKUで利用できるようになっているだろう。
○ということで
一通りCOMPUTEXで行われたLunar Lakeに関する詳細についてご紹介し終わる事が出来た。全体として言えば、性能上限で足を引っ張っりそうなのが64bit幅に狭められたメモリバスであり、ただこのメモリバスに合わせて全体のパフォーマンスをうまく調整する事で、Snapdragon X Eliteに負けないSoCを構築した、という感じだ。もっと消費電力を増やせばピーク性能は上がるだろうが、その場合メモリ帯域がボトルネックになりやすい。64bit幅のメモリで性能を発揮できるギリギリのところに性能の目標を置いた、というのはSoCの設計目標としては不思議な気がしなくも無かったが、結果としてこれはこれでバランスの取れた構成になった、と言える。
Gaming性能とかも十分と言えるか？ と言えば怪しいのだが、Snapdragon X Eliteよりは上だろう(Ryzen AI 300シリーズに勝てるかは未だわからないが)。あくまでCopilot+搭載のミニノートあるいはスリムノート向けには良いソリューションになりえるとは思う。このように本来の用途としてはベストだろうLunar Lakeではあるが、このバランスが崩れるような、それ以上の用途を期待するものではないとは思える(将来のNUCとかにはいいかもしれない)。
Thread Director
Alder Lake世代で導入されたThread Director。Alder Lakeにおける動作はこちらで、Meteor Lakeにおける動作はこちらでそれぞれ説明しているが、コア構成が異なる事もありLunar Lakeでは当然振る舞いが変わってくる。まず基本的な動き方の違いがこちら(Photo01)。簡単にまとめると
Meteor Lake: まずLP E-Coreが処理を行い、負荷が高ければCompute TileのE-Coreに、それで足りなければThreadをP-Coreに移動する。
Lunar Lake: まずE-Coreが処理を行い、それで足りなければP-CoreにThreadを移動する。
という形になる。
このMeteor LakeとLunar Lakeでどういう風に負荷分担が変わったか？ ということで、通常のWindowsのTask(Photo02,03)、あるいはTeamsでの動作状況(Photo04,05)を見るからには、「できるだけP-Coreを使わない」Schedulingが成されている様に見える。これが成立するのは前々回で述べたようにE-Coreの性能(というか、IPC)が大幅に引き上げられ、E-Coreで十分賄える処理の範囲が広がったため、と考えられる。というか、ここまで性能が高ければもうP-Core要らないんじゃないかと思わなくもないのだが、とは言え電力の制約でピーク性能が出ないのがE-Coreの実装なので、このあたりは仕方ないのだろう。
話を戻すと、Lunar LakeにおけるThread Directorの改良目標とその方法がこちら(Photo06)。この第一項目目である"Optimize right workload for right core"は、E-Coreの性能を大幅に引き上げて、そのE-Coreをなるべく使い倒すという形で実装されているのが既に説明されている。実際により負荷の高い、例えばOffice Productivityでは早いタイミングでThreadがP-Coreに移行され、こちらを使い切る形で動作する、とされている(Photo07)。これを実現するための技術として説明されているのがこちら(Photo08)である。
次のTighter OS integrationの手法として説明されているOS containment zonesは、要するに事前に処理負荷が判っているThread(というか、プログラム)に関しては、それをEfficient ZoneなりHybrid Compute Zoneに割り当てることで効果的にThreadの振り分けが出来るというものであり、このリストを更に充実させたという訳だ。ちなみにZonelessに分類されたThread(というかプログラム)に対するスケジュールのポリシーがこちら(Photo10)。とにかく可能な限りE-Coreを使い、P-Coreへのシフトはdemand ITD guidanceに従う、としている。
次のEnhance capabilities for efficiencyの手法であるPower management tie-in(Photo11)は、要するにPower ModeやOSの状況を見ながらThread DirectorのScheduleを変更する、という話である。これにより、Power Managementを行わないケースと比較してTeamsの場合で35%の消費電力節約が可能になったとしている(Photo12)。
最後はBroaden contextual inputのための手法であるConsuming platform intentであるが、これはPhoto11のPower management tie-inの仕組みの延長にある。Power management tie-inのレベルで、Thread DirectorはOSのSchedulerに対してHintを出すわけであるが、これに加えて新しくDynamic Tuning Technologyと呼ばれる新しいツールを提供、より細かくPower Managementを行う様にしているそうだ(Photo13)。
ちなみに今後のThread Directorの方向性がこちら(Photo14)。次はAIベースでのSchedulingとしているが、AIを使えば無条件に賢くなるというものでもないだけに、どういう形になるのか楽しみである。
Connectivity
Connectivityに関してはちょっと面白い実装になった。Lunar LakeではWi-Fi 7が可能になった(Photo15)としているが、そもそもWi-Fi 7に関してはDiscrete(Gale Peak 2)を利用する格好であり、そのGale Peak 2はMeteor Lakeと組み合わせによる動作デモなども既に行われていたから別に珍しい訳ではない(Photo16)のだが、Lunar LakeではWi-Fi 7とBluetooth 5.4のMAC層をPlatform Controller Tile中に搭載している(Photo17)。これによりパッケージサイズの小型化などが実現できた、としている。だったらいっそPHYも、と思わなくもないのだがこちらは国別の仕様の違いとか、そもそもN6でPHYを構築するのは不効率(もっと古いプロセスで十分賄える)、あるいは後になって仕様変更が出る(国別の法規制次第の部分があるので、ファームウェアアップデートで賄えない場合にはシリコンの更新が必要で、Platform Controller Tileに全部収めてしまうとCPU自身の取り換えが必要になる)事などを考慮して、PHYだけは別にしたものと考えられる。
Thunderbolt周りで言えば、まだThunderbolt 5の実装はなされておらず、Thunderbolt 4止まりである(Photo19)。新機能としてはThunderbolt Shareが挙げられるが、これは別にLunar Lake専用というわけではなく、既存のThunderbolt 4同士で利用できるので、あくまでもLunarLake「でも」Thunderbolt Shareが使えるという話である。
Security
最後にSecurity周りについて。Alder Lake/Raptor LakeではCSME(Converged Security&Manageability Engine)が搭載されていたが、Meteor Lakeではこれが細分化され、SSE(Silicon Security Engine)/GSC(Graphics Security Controller)/CSMEの3つに分かれる形で実装された(Photo20)。Lunar LakeではこのMeteor Lakeの構造を引き継いだ上で、新たにPSE(Partner Security Engine)が搭載された。このPSEであるが、
専用の暗号化/復号化オフロードエンジンとキーストレージ
FUSE(Provisioning Secretと呼ばれるプロセッサ固有のID)を格納するエリアとそのコントローラを独立させて搭載
NIST 800-193に準拠したSecurity Processorと、Firmware Update機能の搭載
といった特徴を持つ(Photo21)。このPSEがアクセスするメモリエリアは、SoCの他のブロックからのアクセスが一切不可能であり、逆にPSEがSoCのその他のブロックにアクセスする事も出来ない(Photo22)。こうした独自のSecurity Engineを3rd Partyに提供し、3rd Partyはこれを利用して独自のSecurity Solutionをクライアントに提供できるという訳だ。特にエンタープライズ向けでは、OEMメーカーごとに独自の管理ツールとかセキュリティソリューションを用意する場合が多いが、こうした管理ツールやセキュリティソリューションを高速に実行するために使える、という訳である。
他に、VT-Redirect Protection(Photo23)やIntel TDT(Thread Detection Technology)なども提供される。これらは恐らくConsumer向けのLunar Lakeでは無効化されるが、Business向けのSKUで利用できるようになっているだろう。
○ということで
一通りCOMPUTEXで行われたLunar Lakeに関する詳細についてご紹介し終わる事が出来た。全体として言えば、性能上限で足を引っ張っりそうなのが64bit幅に狭められたメモリバスであり、ただこのメモリバスに合わせて全体のパフォーマンスをうまく調整する事で、Snapdragon X Eliteに負けないSoCを構築した、という感じだ。もっと消費電力を増やせばピーク性能は上がるだろうが、その場合メモリ帯域がボトルネックになりやすい。64bit幅のメモリで性能を発揮できるギリギリのところに性能の目標を置いた、というのはSoCの設計目標としては不思議な気がしなくも無かったが、結果としてこれはこれでバランスの取れた構成になった、と言える。
Gaming性能とかも十分と言えるか？ と言えば怪しいのだが、Snapdragon X Eliteよりは上だろう(Ryzen AI 300シリーズに勝てるかは未だわからないが)。あくまでCopilot+搭載のミニノートあるいはスリムノート向けには良いソリューションになりえるとは思う。このように本来の用途としてはベストだろうLunar Lakeではあるが、このバランスが崩れるような、それ以上の用途を期待するものではないとは思える(将来のNUCとかにはいいかもしれない)。
