AMD Jaguar: základ pro PS4 a Xbox One

Když se v současné době podíváme na AMD, největším tahákem jsou jednoznačně firemní APU, která se snaží bojovat na všech frontách svým poměrem ceny ku výkonu. AMD Jaguar je právě jedním z podobných řešení, které může být nasazeno všude tam, kde se hledí na cenu, ale zároveň je potřeba solidního výkonu. Samotný vývoj současných procesorů je do značné míry omezen spotřebou, kterou mohou při dané architektuře dosahovat. Intel v tomto případě se svou současnou architekturou Ivy Bridge pokrývá široké spektrum produktů, kde se TDP počítá od několik málo desítek wattů po 130 wattů u vlajkových lodí pro desktopové účely.

AMD stejně jako Intel razí strategii portfolia, kde jedna architektura pokrývá systémy, kde se hledí na spotřebu, respektive celkové provozní vlastnosti (např. Bobcat), a ty, kde se hledí na výkon a provozní vlastnosti jsou až na druhém místě (Bulldozer). Intel na tom je velmi podobně se svým Atomem u low-cost systémů nebo tabletů a s architekturou Core iX pro dražší desktopy a notebooky. Zatímco Intel se opět pomalu stává zcela dominantním hráčem na trhu s desktopovými procesory, tak AMD se snaží své opodstatnění najít jinde.

AMD svůj Bobcat pilovalo a samozřejmě od roku 2010 došlo na několik faceliftů. AMD např. tento základ použilo u platforem SoC Ontario a Zacate jako součást platformy Brazos. Společnost nelenila a plnila trh updatovanými verzemi téhož (Brazos 2.0), které ovšem mnoho nového nepřinesly. Tímto se ovšem dostáváme až k uvedení zbrusu nových APU Kabini a Temash, které využívají značně pozměněné architektury Bobcat, kterou AMD pojmenovalo Jaguar. Doufejme tedy, že to bude skutečně dravec a ne obtloustlá kočka domácí.

Pokud se podíváme na architekturu Jaguaru, tak si řekneme, že se toho mnoho nezměnilo a vše vypadá tak nějak povědomě. Máme zde stejnou out-of-order (dual-issue) architekturu, kterou již několik let důvěrně známe od roku 2010. Když jdeme dále, tak se toho mnoho nemění, což zahrnuje L1 cache a stejná písnička je to také u výpočetních bloků a front-endu. Zajímavá je tato strategie pokud vše srovnáme s posledními výkřiky ARM, kde se z původního konceptu dual-issue out-of-order (Cortex A9) postoupilo k three-issue out-of-order architektuře (Cortex A15). AMD se v tomto ohledu soustředilo na to, aby Jaguar měl při zachování stejného nebo nižšího TDP podstatně vyšší výkon. Nicméně, přechodem na three-issue architekturu by se jednoznačně docílilo vyššího výkonu.
Původní Bobcat nalezl útočiště především v levných noteboocích (netboocích) a dalších zařízeních, kde nebyly nároky na výkon příliš velké. Teď se před AMD ovšem otevírá trh, který se zvětšuje závratným způsobem. Ano, mluvím samozřejmě tabletech, kde by architektura Jaguar mohla velmi lehce znamenat levnější a minimálně stejně výkonnou alternativu k Intelu a jeho Atomu, který se začíná prosazovat také v tabletech s Windows 8. AMD zřejmě ani do budoucna zatím nepočítá s tím, že by vytvořilo platformu vhodnou pro smartphony, kde je již beztak konkurence značně vysoká. Tablety jsou ovšem jiná písnička, neboť nepotřebují tolik vymožeností jako dnešní telefony.

Pokud se podíváme na Jaguar z hlediska praktického výkonu při vykonávání instrukcí, tak zde máme stejná omezení jako v předchozích případech architektury Bobcat, kdy průměrně byla zpracována za takt méně než jedna instrukce pro většinu typický zatížení v reálných aplikacích. AMD nám zřejmě neodtajní všechny důvody, které společnost vedly k ustoupení od three-issue architektury a místo toho se prioritou stalo pilování stávající architektury.

Osobně se domnívám, že AMD pro tento projekt nemělo tolik času a finančních prostředků, aby docílilo v krátkém čase konkurenceschopné three-issue architektury při zachování pro mobilní produkty přívětivých provozních vlastností. Samozřejmě, že vývojáři mohli k názoru, že „předělání“ Bobcatu na three-issue by z hlediska obdrženého výkonu mohlo být dostatečné, ale samotná architektura by se dostala velmi blízko samotnému Bulldozeru. To se mi ale nezdá pravděpodobné, protože AMD potřebuje zoufale zabodovat na alespoň jedné frontě a tato meziproduktová řazení vzhledem ke zcela odlišným nasazením pozbývají smyslu.

Není zde ovšem vyloučeno, že se Jaguar v nějaké z dalších inkarnací zjeví jako three-issue architektura s podstatně vyšším výkonem, až i samotné AMD vyzkouší, že pro ni svět tabletů a dalších zařízení má dostatečnou výtěžnost. Proč jde AMR cestou three-issue architektury, je při větším zamyšlení poměrně jasné. Architektura ARM s jádrem Cortex má dostatečně nízkou spotřebu, ale potřebuje vyšší výkon. AMD a samozřejmě také Intel jsou v opačné situaci, kdy obě společnosti potřebují u architektur pro následující generaci produktů především snižovat spotřebu, a výkon jako takový je až druhou prioritou. K ideálnímu řešení jde tedy každý svou vlastní cestou. Jaguar tedy z toho hlediska nemůžeme označit ve srovnání architektur za nějak méněcenný a zastaralý, jak jsem se mohl dočíst v diskuzích na některých zahraničních serverech.
Celkově se dá říci, že AMD se vyvarovalo Jaguar poslat na steroidy jako celek a místo selektivně zvolilo, kde zatlačilo na pilu. Pojďme se ale ovšem podívat, co je vlastně nového pod pokličkou na konkrétních případech.

Mezi hlavní novoty patři loop buffer o velikosti 4×32 bytů, který funguje jako instrukční cache a v momentu, kdy je detekována smyčka, je místo L1 cache pro zpracování instrukcí využito právě tohoto malého specializovaného bufferu. Tento buffer ale je jednoúčelový a nejedná se trace cache nebo micro-op cache. V podstatě jedinou hlavní výhodou tohoto nového bufferu je odlehčení práce instrukční cache, která nemusí být využívána opakovaně u každé detekované smyčky. Pokud to celé přeložíme do srozumitelného jazyka, pak se jedná o cestu, jak snížit spotřebu jádra při zachování výkonu. Výkonnostní bonus zde nečekejme.

Zřejmě všem znalejším je jasné, že návrh každého procesoru je velmi specifická záležitost, která krom samotného návrhu zahrnuje i různá testování na případná úzká hrdla, která je potřeba identifikovat a eliminovat v případné další revizi architektury. Samozřejmě, že tento proces je do značné míry limitován časem a náklady vývojového týmu, kde ani jedno z nich není neomezené, neboť produkt se musí v určitém čase při určitých nákladech dostat na trh ke konečnému spotřebiteli. Ve výsledku to znamená, že při každém vývoji je sáhnuto k určitých kompromisům.

Z tohoto důvodu AMD zřejmě zůstalo u výše zmiňované dual-issue architektury front-endu nového Jaguaru. A podobně je tomu také u loop bufferu, který není micro-op cache, ale svůj účel splní. AMD zvolilo jednoznačně nejlepší kompromis mezi komplexností řešení, jeho cenou a výsledkem, kterým má být především úspora energie.

AMD u Jaguaru přišlo s vylepšeným prefetcherem pro instrukční cache, což nebylo ani tak způsobeno nutností zvýšit rychlost, ale spíše dohání resty, které byly v rámci Bobcatu opomenuty. Prefetcher instrukční cache v Jaguaru je jednoduše řečeno tak, jak jej AMD plánovalo už pro Bobcat, ale tehdy bylo pod tlakem času a nutnosti uvést na trh novou architekturu. Je zde krásně vidět, s čím vším se musí potenciální vývojář potýkat a nemůže jednoduše dělat to nejlepší, co umí, právě s ohledem na náklady a čas strávený na projektu.

Změny se odehrály také ve velikosti instrukčního bufferu mezi instrukční cache a dekodéry. Pokud se týká smyslu toho počinu, tak se to dá označit jako malý krůček směrem k větší nezávislosti fetch/decode úrovní, tak jako je tomu u desktopového Bulldozeru. Jaguar přidává krom jiného také nové instrukční sety (SSE4.1/4.2, AES, CLMUL, MOVBE, AVX, F16C, BMI1) a také 40bitové adresování.

Poslední změnou ve front-endu nového Jaguaru je přidání další dekódovací úrovně, což bylo zapříčiněno choutkami nové architektury na vyšší frekvence. Bobcat byl v tomto ohledu limitován na celkové frekvenci právě dekodérem. S touto úpravou bude Jaguar schopen bez problému pracovat na frekvenci, kterou má AMD vytyčenou jako cílovou při daném 28nm výrobním procesu.