Tiger Lake アップデート - Intelのキーマンに聞く"Tiger Lake Deep Dive"

既報の通りIntelはTiger Lakeこと第11世代Coreプロセッサを9月2日に正式発表した。上の記事の最後でお伝えしたように、発表会の後でBlueprintと呼ばれるDeep Diveセッションが行われ、そこでもう少しだけ細かい話はあったのでこれをご紹介したいが、その前にBoyd Phelp氏(VP Client Engineering Group, GM Client and Core Development Group)(Photo01)に電話会議の形で色々質問を行う事が出来たので、まずはこの内容からご紹介したいと思う。ちなみにPhelp氏はSystem Optimizationを主に担当しており、事実上Tiger Lake設計の指揮を執った担当者、との話であった。

Photo01: これはTiger Lakeの発表会でのもの。ちなみにArchitecture Dayでも10nm SuperFinプロセスの説明で登場した。

Tiger Lake Deep Dive

まず現在は4コアのTiger Lakeのみが公表されているが、これに続いて8コア製品も予定されているとの事(登場時期などは当然今回は未公表であるが)。従って、製品展開的に言えばTiger Lakeは現在のIce LakeとComet Lakeの両方の後継製品になる、という位置づけになる。ちなみにPhelp氏いわく「Ryzenみたいに8コアとかあればCineBenchみたいなBenchmarkのスコアは上がるけど、アプリケーションの性能は(動作周波数を上げた)4コアの方が効果的」と説明するが、Core i7-10810UとかCore i7-10875Hの存在を考えると、この説明にはやや矛盾があるような気もしなくはない。

次に内部構造について。Tiger LakeはDual ring microarchitectureとされるが、これは2つの32Bytes幅のRingをDual構成にした、という形になったそうだ。図1がIce Lakeまでで利用されていたRing Busで、32Bytes幅の1本のRingに対し、CPUとGPU、及びUncore(Memory ControllerやPCI Express/DMIなど)がそれぞれ1つづつRing Stopを持ち、ここでRing Busと接続される形だ。これに対してTiger Lakeでは図2の様にそれぞれのコンポーネントが2つづつRing Stopを持ち、それぞれ独立した32Bytes幅のRing Busに接続さえっることになる。この結果として、それぞれのコアは最大で64Bytes/cycleでのメモリアクセスが可能になるし、あるいは同時に複数のコアがメモリやらGPUやらにアクセスする場合の実効スループットを高める事も出来る。またTiger LakeのGPUは一種のQoS的な動作として、Memoryに対して最大64GB/secの帯域確保を行う事も可能だが、Dual Ring Busを使えばこれも容易ということになる。このRing Bus、Ice Lakeでは3GHz駆動であったが、「Tiger Lakeは3GHz以上となっており、なので実効帯域は2倍以上になっている」との事。

図1

図2

余談ながら、「なら64Bytes幅にすればいいのでは？」と聞いたところ、「それだとRing Stopまでが遠くなってしまう」という答えであった。

次にMLCについて。Tiger LakeというかWillow CoveではL2が1.25MBに増量された代わりに、キャッシュがNon-inclusiveに切り替わった。この理由について「MLCをコアあたり1.25MBに増量した結果、4コアで5MBのMLCになった。一方でLLCも増量したが、コアあたり3MBで全体では12MBでしかない。もしこれをInclusiveのままで実装すると、実質L3が7MBに減ってしまうのと同じことになる。効率的に使うためにはNon-Inclusiveにする必要がある」と説明した。なんというか、昔AMDのPhenomでL3の容量がL2と比較してそう多くなく、結果L2もExclusiveにした事を思い出したが、要するに大容量のL3を実装するのでもない限り、L2はNon-inclusiveにしないと辻褄が合わなくなるという話である。

次いで周辺回路についていくつか。まずGNA 2.0であるが、Ice Lakeに実装された初代GNAとの違いは純粋に性能や効率だけで、特に新機能は入れていないとの事。

次がIO Caching(Photo02)であるが、これは何か？と聞いたところ、「DMAの対象にLLCを利用できるようにするもの」という話であった。通常I/OでDMAを行う場合、メモリに対して転送を掛ける(メモリに書き込みorメモリから読み出し)ため、そのデータをCPUから利用するためには一度メモリに書き込まれたデータを改めてロードする、あるいは転送するデータを一度メモリに書き出して、そこから転送開始を行う形になる。ところがIO Cachingではメモリを利用せずにLLCに対してDMAを直接掛けられるというものだ。これはどんなI/O(USBとかThunderboltだけでなく、PCI Expressも対象)でも利用できる、という話であった。実装としては一種のCache Stashing(最初に実装されたのはFreescaleのe500mcだったが、最近だとArmがDynamIQのACPポートにこれを実装している)と分類されるが、恐らくはドライバの側で何らかの配慮は必要になりそうである。このあたりは早くSystem Optimization Manualが読みたいものだ。

Photo02: これはHot Chips 32におけるスライド。

そのPCI Expressであるが、実はTiger LakeではPCHとの接続は引き続きDMI3、つまりPCIe Gen3×4であり、これとは別にPCIe Gen4×4がDiscrete GraphicsとかNVMe M.2 SSDなどの接続のために用意されているとの事。で、4コア製品については外部接続はPCIe Gen4×4のみであるが、将来投入される8コア製品はPCIe Gen4×20になるという話であった。

GPUに関して言えば、Tiger Lakeは3.8MBというやけに中途半端に見えるL3を搭載するが、X^e(Xe)の場合、16個のEUで一つのSubsliceを構成。Tiger Lakeでは合計6 Subsliceで96EUとなる。一方でL3であるが、Subsliceあたり640KB、合計で3.75MBのL3を搭載するという話であった。要するにEU数が増えれば、それだけL3も増えるが、最大でも16MBという話である。逆算するとX^e(Xe)は最大でも25.6 Subsliceまで持てるという事になる。さすがに0.6 Sliceという単位は無いので、Subslice数の上限は25、EU数にして400EUが最大値になると思われる。

またこちらのスライドを見ると、Gen 11 GPUと同じPower Enveropeで最大1.65GHz、多少はみ出しても良ければ1.8GHzあたりまで動作周波数を引き上げられるとするが、実際にはCore i7-1185G7であっても1.35GHz止まりの理由は消費電力を抑えるためという話であった。ちなみに別のSKU、例えば同じX^e LP(Xe LP)を使うDG1とかは異なる消費電力枠で動くので、もっと動作周波数が高くなるらしい。また、先ほども話に出てきた8コアのTiger LakeはおそらくH SKU、つまり従来だとTDPが35Wとか45W枠のところに投入されると思われるため、ここではより動作周波数を引き上げることが可能と思われる。実際に高くするかどうか、はちょっと微妙なところである。というのは、GPUの動作周波数だけ引き上げてもメモリバスの帯域が追い付かなければ意味が無い訳で、恐らくはLPDDR5を実装可能な将来のTiger Lakeとか、Discrete GPUの形で提供されるDG1/SG1などではこのあたりの問題も解決可能であり、なので限られたSKUではもう少し動作周波数が高くなるだろうが、DDR4-3200を使っていると低めに抑えられるなんて可能性もありそうだ。

最後に消費電力絡みの話。Tiger LakeではTDPという表現が消え、代わりにOperation Rangeという用語になっている。ちなみにIntel Arkでは引き続きConfigurable TDP-up/downという表現でOperation Rangeの上限と下限を定めているので、TDPという表現そのものがなくなったわけではないが、中央値というか典型値であるTDPというものが無くなったことになる。これに関しては「我々のパートナーはそれぞれ異なった構成で最終製品を出荷するので、それぞれに応じて消費電力の構成は変わる事になる。Tiger Lakeのダイそのものは、7Wから28Wまで、パートナーの望む消費電力で駆動できる様に設定可能だ。唯一異なるのは、パッケージだ。Tiger Lakeは46.5mm×25mmのパッケージ(UP3)と26.5mm×18.5mmのパッケージ(UP4)の2つがある。UP4の方が安価だが、こちらは15Wまでにしか耐えられない。大きい方は高価だが28Wまで耐えられる。あとはパートナーが彼らの製品の構成に合わせて設定することになる」という話であった(Photo03)。