前回と前々回で、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を移動する。 という形になる。
  • 「Lunar Lake」Deep Diveレポート - 【Part 3】Platform Controller Tileについて

    Photo01: Lunar Lakeの基本的な仕組みはMeteor Lakeに近いが、LP E-Coreが無い分すっきりしたというべきか。

このMeteor LakeとLunar Lakeでどういう風に負荷分担が変わったか？ ということで、通常のWindowsのTask(Photo02,03)、あるいはTeamsでの動作状況(Photo04,05)を見るからには、「できるだけP-Coreを使わない」Schedulingが成されている様に見える。これが成立するのは前々回で述べたようにE-Coreの性能(というか、IPC)が大幅に引き上げられ、E-Coreで十分賄える処理の範囲が広がったため、と考えられる。というか、ここまで性能が高ければもうP-Core要らないんじゃないかと思わなくもないのだが、とは言え電力の制約でピーク性能が出ないのがE-Coreの実装なので、このあたりは仕方ないのだろう。

  • Photo02: Meteor LakeではまずLP E-Coreで処理が行われ、そこからE-CoreやP-CoreにThreadが移行する。

  • Photo03: Lunar LakeではずーっとE-Coreで処理が行われ、殆どP-Coreが動作しない。

  • Photo04: TeamsではE-Coreがメインに動くが、立ち上がり当初はP-Coreも結構動いている。

  • Photo05: ほぼすべての処理をE-Coreで賄っている。余程の負荷でないとP-Coreは動かない構成の様だ。

話を戻すと、Lunar LakeにおけるThread Directorの改良目標とその方法がこちら(Photo06)。この第一項目目である"Optimize right workload for right core"は、E-Coreの性能を大幅に引き上げて、そのE-Coreをなるべく使い倒すという形で実装されているのが既に説明されている。実際により負荷の高い、例えばOffice Productivityでは早いタイミングでThreadがP-Coreに移行され、こちらを使い切る形で動作する、とされている(Photo07)。これを実現するための技術として説明されているのがこちら(Photo08)である。

  • Photo06: 真っ当というか、ごく当たり前の目標ではある。

  • Photo07: この"Starts of by scheduling on E-Cores"の期間をどれだけ短くできるか、が効率化の鍵ではあるのだが、短くしすぎると誤判断が多くなりそうなのが難しいところ。

  • Photo08: アルゴリズムは兎も角として、粒度を細かくするとかに関しては、Meteor Lakeがどの程度で、それがLunar Lakeでどの程度になったのか、というのが判らないので判断しづらいところ。

次のTighter OS integrationの手法として説明されているOS containment zonesは、要するに事前に処理負荷が判っているThread(というか、プログラム)に関しては、それをEfficient ZoneなりHybrid Compute Zoneに割り当てることで効果的にThreadの振り分けが出来るというものであり、このリストを更に充実させたという訳だ。ちなみにZonelessに分類されたThread(というかプログラム)に対するスケジュールのポリシーがこちら(Photo10)。とにかく可能な限りE-Coreを使い、P-Coreへのシフトはdemand ITD guidanceに従う、としている。

  • Photo09: で、リストにないプログラムについてはZonelessに分類され、ここでは最初にE-Coreで実行し、その負荷状況をモニターしてP-Coreに移すか、E-Coreのままでやるかを判断することになる。

  • Photo10: IDTはIntel Thread Directorの略で、要するにE-CoreからP-CoreにThreadを移動する際のガイドラインがUpdateされており、これに従うという話である。そのガイドラインの説明が読みたいものである。

次のEnhance capabilities for efficiencyの手法であるPower management tie-in(Photo11)は、要するにPower ModeやOSの状況を見ながらThread DirectorのScheduleを変更する、という話である。これにより、Power Managementを行わないケースと比較してTeamsの場合で35%の消費電力節約が可能になったとしている(Photo12)。

  • Photo11: 例えばBattery Power Modeの時はP-Coreは一切使わない、なんてことも可能である訳だ(そういう実装になっているかどうかは不明だが)。

  • Photo12: これ左は一切Power Managementしない場合なので、比較として適切なのかというと「？」ではあるのだが。

最後は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)。

  • Photo13: なんというか専用ECUの利用が義務づけられているレースカーにSub ECUを外付けして専用ECUを乗っ取るような仕組みに見えなくもない。

ちなみに今後のThread Directorの方向性がこちら(Photo14)。次はAIベースでのSchedulingとしているが、AIを使えば無条件に賢くなるというものでもないだけに、どういう形になるのか楽しみである。

  • Photo14: Cross IP schedulingの意味合いが今一つ不明瞭だが、今後はCPUだけでなくGPUやNPUも管理対象に入るという事だろうか？

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だけは別にしたものと考えられる。

  • Photo15: CNVi3での改良点というか変更点は後述。Meteor LakeではCNVi3のフル機能を使っている訳では無そう。

  • Photo16: PCIeレーン経由でGale Peak 2を接続し、そのGale Peak 2の中のMACとPHYを使う格好である。

  • Photo17: ただPhoto18を見るとA2AとかDTSなど、BluetoothのMACの機能のいくつかがBE201のShared Blocksに入っており、その意味ではMACの全部ではなく一部がPlatform Controller Tileに含まれている、というべきか。

  • Photo18: ちなみにBE201はGale Peak 3という訳ではなさそうで、Gale Peak 2のVariantの一つという扱いなのだろうか？

Thunderbolt周りで言えば、まだThunderbolt 5の実装はなされておらず、Thunderbolt 4止まりである(Photo19)。新機能としてはThunderbolt Shareが挙げられるが、これは別にLunar Lake専用というわけではなく、既存のThunderbolt 4同士で利用できるので、あくまでもLunarLake「でも」Thunderbolt Shareが使えるという話である。

  • Photo19: Thunderbolt 5のコントローラが実装されるのはArrow Lake以降だろうか？

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メーカーごとに独自の管理ツールとかセキュリティソリューションを用意する場合が多いが、こうした管理ツールやセキュリティソリューションを高速に実行するために使える、という訳である。

  • Photo20: これまでIntel MEなどと呼ばれていたものが2018年にCSMEの改称されただけで、機能自体はAlder Lake以前から存在していた。基本はvProなどのビジネス/エンタープライズ向けのセキュリティ＆管理機能である。

  • Photo21: この専用セキュリティエンジンを3rd Party用に提供する、というのがポイント。

  • Photo22: PSEはブートシーケンスそのものが異なっており、要するに例えばLunar Lake全体がブートする時にも、それと関係なくPSEだけ独立してブートし、Secure Enclaveを確立する格好になる。通信は、なのでPSEとCPUの通信用に割り当てられた通常のメモリ領域の一部だけを使う形になる。

他に、VT-Redirect Protection(Photo23)やIntel TDT(Thread Detection Technology)なども提供される。これらは恐らくConsumer向けのLunar Lakeでは無効化されるが、Business向けのSKUで利用できるようになっているだろう。

  • Photo23: これは仮想化環境でページアドレスの書き換えとか誤ったアドレスへの誘導などを防ぐための機構。

  • Photo24: TDT自体は2018年位から提供されているもので、別にLunar Lakeが初めてという訳ではない。

ということで

一通りCOMPUTEXで行われたLunar Lakeに関する詳細についてご紹介し終わる事が出来た。全体として言えば、性能上限で足を引っ張っりそうなのが64bit幅に狭められたメモリバスであり、ただこのメモリバスに合わせて全体のパフォーマンスをうまく調整する事で、Snapdragon X Eliteに負けないSoCを構築した、という感じだ。もっと消費電力を増やせばピーク性能は上がるだろうが、その場合メモリ帯域がボトルネックになりやすい。64bit幅のメモリで性能を発揮できるギリギリのところに性能の目標を置いた、というのはSoCの設計目標としては不思議な気がしなくも無かったが、結果としてこれはこれでバランスの取れた構成になった、と言える。

Gaming性能とかも十分と言えるか？ と言えば怪しいのだが、Snapdragon X Eliteよりは上だろう(Ryzen AI 300シリーズに勝てるかは未だわからないが)。あくまでCopilot+搭載のミニノートあるいはスリムノート向けには良いソリューションになりえるとは思う。このように本来の用途としてはベストだろうLunar Lakeではあるが、このバランスが崩れるような、それ以上の用途を期待するものではないとは思える(将来のNUCとかにはいいかもしれない)。