1. トップ
  2. 新着ニュース
  3. IT
  4. IT総合

Lunar LakeにはWi-Fi 7があるがPCIe x16レーンは存在しない インテル CPUロードマップ

ASCII.jp / 2024年8月5日 12時0分

 前回まででLunar Lakeのコンピュート・タイルの話は完了である。ということで残りはプラットフォーム・コントローラー・タイルの話である。

Intel Thread Directorを改良 まずEコアで実行し一定以上の負荷であればPコアに移行する

 なぜプラットフォーム・コントローラー・タイルで真っ先にThread Directorが出てくるか? というと、パワーマネジメント関係の制御が搭載されているためである。

 さて、Meteor LakeではThread Directorにずいぶん手が入ったという話は連載739回で説明した。Meteor LakeではSoCタイルにLow PowerのEコアが搭載されている関係で、まずはこのEコアで動かした上で、必要に応じてコンピュート・タイルのEコアや、それ経由でPコアに移行するという仕組みであったが、Lunar LakeではこのLow Power Eコアが存在しない関係で、またAlder Lake/Raptor Lakeに近い方法に戻ったのだが、実装が逆になった。

Meteor LakeではPコアの前にコンピュート・タイル上のEコアが先に使われるが、これはおそらくSoCタイルのLow Power Eコアからの処理の移行が容易なためだろう

 つまりAlder Lake/Raptor LakeではまずPコアで処理を行ない、ここで負荷がしきい値以下であればEコアに移行させるという方式だったのに対し、Lunar LakeではまずEコアで実行し、ここでしきい値以上の負荷であればPコアに移行する仕組みになっている。

 正直この仕組みが一番シンプルでいいとは思うのだが、Alder Lake/Raptor Lake世代でまずPコアに処理が割り振られたのは、当時のEコアでは性能が低すぎてすぐにEコア→Pコアの移行が入ってむしろオーバーヘッドが大きくなってしまうためだと考えられる。

 ところがLunar Lake世代ではEコアの性能が大幅に上がったことで、おそらくはAlder Lake/Raptor Lakeとは逆に、まずEコアで動かした方が移行のオーバーヘッドが少ない(まずPコアで動かすと、むしろPコア→Eコアの移行が多くなりすぎる)ものと考えられる。

 実際にLunar Lakeで負荷の高い処理(ここではOffice Productivity)を実行した様子が下の画像だ。まず最初にEコアで処理をスタートし、すぐにEコアからPコアに処理が移行しているのがわかる。

Meteor Lakeでかなり難しくなっていたThread Directorの動き方がだいぶシンプルになった感はある。ただArrow Lake世代でどうなるのかはまだわからない

 ちなみにこの基本的なスケジューリング方法の違いとは別に4項目の改良が成されたとしている。

"Innovations"とは言っても、新機能というよりは従来からの改善であり、これによって「どの程度改善したか」の数値は示されていないのが残念である

 1つ目の"Optimize right workload for right core"に関する説明が下の画像であるが、今ひとつ具体的になにをどうした? という話は不明ではある。

この話は次の"OS containment zone"にも絡んでくる。ちなみに"for experience continuity"というのは別にハードウェア側の話ではなく、Thread Director用の管理ソフト(というよりドライバー)の話な気がする

 ただこれまでよりもスレッドの負荷を細かく監視するほか、OSへのHint(スケジューラに対するスレッド負荷に関する情報)の出し方に、低電力/低発熱の部分を加味したことが示されている。

 2つ目の"Tighter OS integration"は、以前から事前にわかるものに関しては"Efficient Zone"/"Hybrid/Compute Zone"にあらかじめ登録しておき、Thread Directorで素早くそのスレッドを目的のコアに割り振る一方、そうした登録に入っていない"Zoneless"に関しては引き続き従来の方法(つまりまずEコアで動かし、そこで負荷が高いようならPコアに移行する)を利用する格好になるようだ。

もっとも、例えばOfficeのワークロードも、PCMark 10やProcyonで使った場合と人間が使った場合では負荷状況が違う気がするので、これをThread DirectorはZoneに入れるのか、Zonelessで扱うのか、などいろいろ疑問は尽きない

 おそらくはThread Directorで負荷状況を監視する中で、後追いでどちらのZoneにすべきか、あるいはZonelessで扱うべきかを判断してリストに入れる(これはThread Directorのドライバーの仕事だろう)ような処理が行なわれているものと思われる。下の画像にあるマイクロソフトのコメントもそれを裏付けているように思われる。

Teamsを使う時にはおそらく無条件でEコアを使うように設定してくれるので、Lunar Lakeではより長時間の利用が可能になるという話で、このあたりはOS側でThread Director経由で稼働データを収集し、これに応じてContainment Zoneの情報をアップデートしているように読める

 3つ目の"Enhance capabilities for efficiency"は、電力管理のモードにあわせてThread Directorの振る舞いを変更するという話である。

電力管理のモードにあわせてThread Directorの振る舞いを変する。これに関しては「まだ実装されてなかったのか?」という驚きの方が多いのだが、実は実装されていて、ただそれがさらに改良されたという話なのかもしれない。ちなみにITDは"Intel Thread Director"のことである

 例えばACモードとバッテリーパワーモードでは、EコアからPコアに移行するための処理負荷のしきい値が変わり、よりEコアを利用するようになる、といった設定のされ方が考えられる。

 ただ以前インテルは「長時間低消費電力のコアを動かすより、短時間高性能コアを動かした方がトータルでの消費電力が減る」といった見解を出していた時期もあったりしたので、これは要するにEコアの性能が大幅に上がり、同じ処理をするならEコアを使った方がトータルでの消費電力量(消費電力×経過時間)が減り、結局バッテリー寿命の延伸に貢献できるという目途が立ったから実装した、という可能性もある。

 実際の数字では、同じLunar Lake上であってもContainmentとPower Managementを両方有効にすることで、35%の消費電力削減が可能になった、としている。

ContainmentとPower Managementを両方有効にすることで、35%の消費電力削減が可能。アプリケーションからContainment Zoneを無効にする方法があるということだろうか?

 最後の"Consuming platform intent"は主にアプリケーション開発者向けの話であって、ハードウェア依存度を高めるのではなくQoS APIを使おうと呼びかけているわけだが、インテルだけならともかくAMDのプラットフォームもあることを考えると、これは無駄にアプリケーション開発者の負荷を高める方向に行くような気もしなくはない。ただ例えばAI PC向けのAIベースアプリケーションであれば過去への互換性はある程度無視できるので、意味があるのかもしれないが。

"Latest ISA"と言われても、AVX512を使ったらそもそもLunar Lakeは動かないし、Lunar Lakeでしか動かない命令(これはいくつかある)では他のプラットフォームとの互換性が保てないため、結局プログラムの冒頭でアーキテクチャーを判断して処理を分岐することにならざるを得ないわけで、言うほどに簡単ではない

 ちなみに今後の方向性として示されたのが下の画像だ。"Increasing scenario granularity"はわかるし、"AI-based scheduling hints"も、実装をどうするのかやや疑問ではあるが、方向性としてはわからなくもない。

"AI-based scheduling"といっても、なにをAIでやるか次第(スケジュール全部をやるわけではないだろう)なので、実装できなくはない

 謎なのが"Cross IP scheduling"で、これは単にCPU(Pコア/Eコア)だけでなくNPUやGPUまで含めたスケジュールを意味しているらしいのだが、もう少し解説が欲しいところだ(説明では軽く"CPUだけでなくNPUなんかも"で流されてしまった)。

GPU接続用のPCIe x16レーンが存在しない Lunar LakeのConnectivity(接続性)

 要するにI/O周りであるが、Lunar Lakeは従来のU/Y SKUと同程度のI/Oに留まっている。まだ細かなスペックは示されていないが、少なくともMeteor LakeにあったI/Oタイルがないため、ディスクリートGPU接続用のPCIe x16レーンがないことは確実である。

 一応Thunderbolt 4のコントローラーが内蔵されているほか、Thunderbolt Shareにも対応とするが、これは別にLunar Lake特有の話ではない。

最大3ポート。Thunderbolt 3世代と比較してポート数も増え、また帯域も上がっているとするが、ポート数はともかく帯域は当然ではある。まだThunderbolt 5は未実装
Thunderbolt Shareの説明はこちら。別にLunar LakeでなくともThunderbolt 4以上を搭載したPCならどれでも利用できる「はず」である。AMDのマシンにThunderbolt 4カードを搭載して利用できるかどうかは試してみたことがない

 またWi-Fi 7対応についてもすでにMeteor Lakeの時代から実現していたので、この観点で言えば別に新しくはないのだが、Lunar LakeではMACの機能がプラットフォーム・コントローラー・タイル内に搭載されており、この結果としてPHYのみが外付けという構成になったことで、パッケージの体積を28%小型化できたとしている。

Wi-Fi 7に対応。これはMeteor Lakeの構成。外付けでGale Peak 2を接続するかたちだ
体積を28%小型化。すべての国でWi-Fi 7が使えるようになっているわけでもないので、その場合はWi-Fi 7の機能を無効化して出荷するのか、それともBE201CRFを外してWi-Fi 6モジュールを搭載するのかは不明だ

 もっともよく図を見てみると、A2AやBTSなどのBluetooth 5.4のMAC機能のいくつかはBE201のShared Block(下側の水色の部分)に含まれており、その意味ではMACが全部プラットフォーム・コントローラー・タイルに移動したというよりは、一部の機能が移動したというべきなのだろう。

 どうせなら全部パッケージに載せてしまえば、という気もしなくはない(そもそもLunar Lakeではプラットフォーム・コントローラー・タイルの左に空きスペースがある)が、このPHY部分は国別に仕様が変わったり、あるいは後追いで法規の変更に対応(今まで不許可だった周波数帯が利用可能になったなど)するのに、パッケージに全部載せているとCPUごとの取り換えになり、実際は半田ボールで接続されているからロジックボードごとの取り換えになってしまうのであまり便利ではない。

 またRFなのでシールドも必要になるため、CPUパッケージの上に構築しにくいという話もある。M.2カードの変更だけで済むBE201の方式が一番妥当と判断されたものと思われる。ちなみにBE201はGale Peak 3というわけではなく、Gale Peak 2の派生型になる模様だ。

 なお、PCIeに関してであるが、残念ながらM.2接続用に関してもPCIe Gen4 x4のまま据え置きになるようだ。PCIe Gen5対応はArrow Lake以降に期待するしかないだろう。

新セキュリティPSEでより安全性を高める

 最後にセキュリティ周りについて説明する。これはCore Ultra向けというよりもvPro向けの機能であるのだが、Lunar Lakeでは新しくPSE(Partner Security Engine)と呼ばれる仕組みが搭載された。

Alder Lake/Raptor LakeではCSMEで統一されていたのが、Meteor LakeではSSE/GSC/CMSEの3つに分解され、Lunar LakeではそこにPSEが追加されたかたちである

 PSEは名前の通り、サードパーティのセキュリティソフトのための仕組みである。このPSEであるが、セキュリティエンジンと専用のSRAM/フラッシュ、それと暗号化アクセラレーターから構成される。

PSEだけでなくSSE/GSC/CMSEなどもまとめて1ヵ所に配されているが、物理的な位置は近くてもPSEは他とは分離して稼働するようになっている
PSEの構成。Security ProcessorはホストCPUとは独立してブートし、実行が始まる仕組みである

 PSEを利用する場合、専用のメモリーエリア(PSE Region)のみが利用可能であり、またPSEから他のセキュリティエンジン(SSE/GSC/CMSE)にアクセスきでない。逆にSSE/GSC/CMSEからPSEやPSE Regionにアクセスすることもできない。

 CPUは当然PSE Regionにアクセスできる(これができないとそもそもセキュリティソフトとして成立しない)が、無条件アクセスできるわけではなく、アクセスの方法は限られている。

 エンタープライズ向けでは、OEMメーカーごとに独自の管理ツールやセキュリティソリューションを用意する場合が多いが、これまではこうしたツールはCPUを利用してセキュリティの処理などをしており、ここが脆弱性になりやすいという欠点があった。

 PSEはこうした独自の管理ツールやセキュリティソリューションに対し、独自に処理を行なうエリアを提供することで、より安全性を高められるというわけだ。

 こういう話なので、冒頭で書いたようにvProなどエンタープライズ向けでしか利用されない機能であり、そもそもコンシューマー向けのLunar Lakeでは全部無効化された状態での提供になるかもしれない。

 連載777回から7回もかけてやっと説明が終わったLunar Lake。9月3日(日本時間では9月4日)に、IFA 2024に合わせて正式に発表されることが明らかにされている。

 AI PCを実現できるSnapdragon X Elite、Ryzen AI 300にやや遅れての投入であるが、さてその性能とか消費電力はどんなものか、期待が高まるのは当然であろう。

 筆者の予想としては、Snapdragon X Eliteは当然上回るが、Ryzen AI 300との比較ではやはりメモリー帯域がボトルネックになるシーンがそれなりにありそうで、けっこう厳しい戦いになるかもしれない。KTU氏の渾身のレビューが楽しみである。

この記事に関連するニュース

トピックスRSS

ランキング

記事ミッション中・・・

10秒滞在

記事にリアクションする

記事ミッション中・・・

10秒滞在

記事にリアクションする

デイリー: 参加する
ウィークリー: 参加する
マンスリー: 参加する
10秒滞在

記事にリアクションする

次の記事を探す

エラーが発生しました

ページを再読み込みして
ください