Mély integráció és gyártástechnológia
Az Intel hivatalosan is leleplezte a Core M termékcsalád alapjául szolgáló Broadwell lapkát, amely a vállalat első olyan megoldása, mely közelít a mély integráció irányába, bár ezt a folyamatot az Intel több lépésben tervezi megtenni. Ennek egyszerű oka van, ugyanis ha a processzormagokat és az integrált grafikus vezérlőt egymáshoz is tervezik a lapkán belül, az egységes platformszintű funkciók összehangolása már nagyon komplex dolog. Emellett problémát jelent az is, hogy nincs egyértelműen jó irány a CPU és az IGP összehangolására, vagyis a mély integráció működésének hatékonysága csak akkor derül ki, ha már elkészült a lapka. Ha valami esetleg nem jól működik, akkor már nem lehet, pontosabban nem érdemes visszaülni a tervezőasztalhoz, hiszen legalább egy évet csúszna a fejlesztés. Hogy ez mennyire komoly gond, azt jelzi, hogy az AMD is belesétált ebbe a csapdába, hiszen a Kaveri APU sem az lett, aminek eredetileg tervezték. Bár ezt a vásárlók nem látják, hiszen az eredeti dizájn sosem került forgalomba, de a vállalat a piacra került termékre Kaveri 2.0 belső kódnévvel utalt.
Az Intel a mély integrációval egy biztonsági játékot játszik. A megvalósítás szempontjából már úgy sem lesznek elsők, hiszen három, teljes platformszinten integrált lapka is kapható már a piacon. Ezt a célt tehát kihúzták a listáról, így mostantól arra törekszenek, hogy lépésekben építsék be a mély integráció alappilléreit. Tulajdonképpen három ilyet kell támogatni: egységes memória, dinamikus parallelizmus és platformszintű atomi utasítások. A Broadwell ezek közül az egységes memóriát támogatja, illetve a rendszer alapvetően kezeli a dinamikus parallelizmust, de ahhoz, hogy ez nagyon hatékonyan működjön, újra kell tervezni az alkalmazott GPU-architektúrát. Bár utóbbi fontos szempontnak tűnhet, valójában a dinamikus parallelizmus az IGP-knél nem mindig jelent drasztikus előnyt. Természetesen hozhat gyorsulást, ám az integrált grafikus vezérlők jellegzetessége, hogy nincs túlzottan sok különálló multiprocesszor bennük. Az Intel a Broadwellhez tervezett dizájnokban maximum hat multiprocesszort használ majd, ráadásul ebből a most bemutatott Core M sorozathoz tervezett lapka esetében csak három lesz beépítve, vagyis a vállalat számára a dinamikus parallelizmusból származó előny akkor sem lenne túl nagy, ha a GPU-architektúrát a rendkívül gyors kontextusváltásokra, illetve a beérkező feladatok sorrendtől független végrehajtásához tervezték volna. Ez tisztán látszik a Kaveri APU-n is, ahol a GCN architektúrát ténylegesen a dinamikus parallelizmus igényeit figyelembe véve tervezték, de az említett lapkába épített nyolc multiprocesszor még nyolc ACE egység segítségével sem elég ahhoz, hogy drasztikusan nőjön a sebesség az említett újítás bevetésének hatására. Később persze az IGP-kben is tíznél több multiprocesszor lesz, amikor már fontossá válik azok hatékony, aszinkron elvű kihasználása.
A fentiekből már kiderülhetett, hogy a harmadik alappillérnek tekinthető platformszintű atomi utasításokat a Broadwell nem támogatja. Ez az OpenCL 2.0 szempontjából nem akkora gond, mivel a platform C11 atomics funkciója szoftveresen emulálva is működik. Nyilván a programozóknak ettől még lényeges lenne, ha a CPU és az IGP szimultán hozzáférhetne például a fastruktúrákhoz, és azokat párhuzamosan, egymással szinkronban módosíthatnák. Szoftveres emulációval a párhuzamos hozzáférés ki van zárva, hiszen a szinkronizációt egy szoftveres réteg végzi el a hardver helyett. Ez számottevően lassabb implementáció, viszont az ezt kihasználó programok ettől még futtathatóak. A platformszintű atomi utasításokat egyébként is borzalmasan nehéz hardveresen megoldani, illetve nincs egyértelműen előnyös implementáció. Ezt a funkciót jelenleg is csak az Xbox One és a PlayStation 4 konzolban használt rendszerchipek, illetve a Kaveri APU támogatja, de jól jelzi a probléma nagyságát, hogy az AMD mindhárom termékben eltérő implementációt alkalmaz. Ebben persze nyilván szerepet játszhatott az is, hogy a Sony és a Microsoft számára a Kaverihez használt opció nem felelt meg. Valószínűleg az Intel teljesen kiértékeli a lehetőségeket, és ez lehet az egyik oka annak, amiért a platformszintű atomi utasítások támogatását még nem építették be a Broadwellbe.
[+]
A gyártástechnológia, mint marketingeszköz
A Broadwell esetében az Intel a gyártástechnológiára vonatkozó fejlesztés ecsetelésére is több időt szánt. Mint ismeretes, ez az első olyan lapka, amely a cég 14 nm-es eljárásával készül. Mivel a nanométer előtti szám az utóbbi időben komoly marketingeszközzé vált, így a vállalat részletesen taglalta, hogy miben lehet jobb a saját technológiájuk a TSMC, a GlobalFoundries, a Samsung és a többi bérgyártó 14/16 nm-es megoldásánál. Utóbbiakra vonatkozóan a vállalat hangsúlyosan kiemelte, hogy nem rendelkeznek egészen pontos információkkal, így a konkurens megoldások képességeit az eddigi adatok alapján feltételezve vázolták fel. Nyilván feltételezni sok mindent lehet, és bár tényleg ki lehet indulni az eddigi adatokból, de teljes kép még így sem festhető, hiszen egészen egyértelmű, hogy az említett bérgyártók nem osztották meg az Intellel a titkaikat, ahogy az Intel sem tette ezt meg fordítva.
Vélhetőleg az Intel látja azt a problémát, hogy a TSMC, a GlobalFoundries és a Samsung igen gyorsan bevezeti a 14/16 nm eljárást, hiszen 2015-ben már mindegyik cég megkezdi a kísérleti gyártást. Ez azért gond, mert az elmúlt években az Intel, és persze a többi cég is igen egyszerűen vázolta a helyzetet, miszerint a nanométer előtti minél kisebb szám a jobb. Ezt a felhasználó megértette, mert lássuk be, egészen egyszerű állításról van szó. Ugyanakkor a nanométer előtti szám nem igazán jellemzi az adott gyártástechnológiát. Gyakorlatilag csak azért használjuk, mert egy marketingeszközről van szó, de az adott node jellemzése sokkal bonyolultabb ennél. Abban tehát maximálisan igaza van az Intelnek, hogy egy számmal nem írható le a gyártástechnológia, ám kérdés, hogy érdemes-e az adott node-ot marketingre használni. Nyilván a vállalat erről nem tett le, így új szempontként már jellemzik a gyártástechnológia minimális léptetését, amely érték a két szomszédos összeköttetés között mért távolság. Ez a 14 nm-es node esetében 52 nm lehet, ami nyilván jó hatással lesz a tranzisztorsűrűségre.
Mivel a chipgyártók egyre közelebb kerülnek egymáshoz az ISTR által besorolt mondhatni nanométer előtti szám szempontjából (amely paraméterben sokszor nem is lesz majd eltérés), minden érintett egyre több adattal fogja bombázni a felhasználókat, annak érdekében, hogy bizonyítsák a saját gyártástechnológiájuk előnyeit. Ennek lesz pozitív és negatív oldala is. Egyrészt jó, hogy több adat derül ki az adott node-ról, mert jobban össze lehet hasonlítani a konkurensek által használt opciókat, másrészt viszont a gyártástechnológia marketingeszközként egyre nehezebben használható majd, mert a potenciális vásárlóbázist egyre kevésbé érdekli, illetve nehéz is lenne megtanítani a piacnak, hogy konkrétan mi számít, azok után, hogy évekig csak egy szám formájában utaltak rá.
Mi van a Broadwellen belül?
A Broadwell esetében az Intel által megadott adatok alapján vizsgálható a processzor és az integrált grafikus vezérlő architektúrája, de ezt a vállalat csak a Core M-hez használt lapkára szűkítette. Persze ez nem jelent túl nagy gondot, hiszen a nagyobb lapkák duplaannyi processzormagot, utolsó szintű gyorsítótárat, illetve IGP multiprocesszort kaphatnak, tehát annak ellenére, hogy az Intel ezekről nem beszélt, a skálázás módja így is nyitott könyv.
A processzormagok, illetve a megosztott gyorsítótár szempontjából nincs eget rengető változás a Haswellben használt opcióhoz képest. Komolyabb változásként említhető, hogy az utasítások sorrendtől független végrehajtásáért felelős out of order logika nagyobb ütemezőt kapott, gyorsabb lett a lebegőpontos szorzás, a Radix osztómotor, illetve számos kriptográfiai utasítás, valamint a virtualizáció. Összességében ez azt jelenti, hogy bizonyos esetekben a Haswellhez képest 5%-kal nő az IPC, vagyis az egy órajelciklus alatt elvégzett műveletek száma. Azonos órajelet feltételezve a legtöbb esetben nem érdemes lényegi változásra számítani a Haswellhez képest.
Az integrált grafikus vezérlő már sokkal nagyobb módosításokon ment keresztül. Egyrészt bemutatkozik a Gen8 architektúra, amely az elődhöz hasonlóan 4 kB-os lapokkal dolgozik, de a benne elhelyezett gyorsítótárak sorainak mérete 64 bájt. Bár az említett adatokat nem szokás kiemelni, de pont erre a változásra van szükség ahhoz, hogy a Broadwell támogassa az egységes memóriát. Nem nehéz kitalálni, hogy az x86/AM64 architektúrára alapozó processzormagok is az előbb említett paraméterekkel dolgoznak. A másik lényeges újdonság, hogy az IGP kapott egy MMU-t (memóriamenedzsment egység), aminek majd a DirectX 12-ben lesz igazán komoly haszna, ahogy azt egy korábbi cikkünkben már ecseteltük.
A Core M-hez használt Broadwell lapka
A grafikus számítások szempontjából a Gen8 architektúra – elődeihez hasonlóan – továbbra is három jól elkülöníthető részre osztható. A setup motor a Haswell IGP-jéhez képest nem változott, míg a kalkulációkért a már megszokott a shader tömb felelős, amelyből az új dizájn mellett maximum hat darab kaphat helyet; tulajdonképpen ez az egység a hagyományos értelemben vett multiprocesszor. Ebben mostantól maximum 8 darab Execution Unit lesz fellelhető. Ezek továbbra is komplex feldolgozók, így megmarad bennük a két darab 128 bites vektormotor. Utóbbiak közül az egyik felel az általános operációk feldolgozásáért, míg a másik a speciális, trigonometrikus és transzcendens utasításokat támogatja, de mindkét vektoros egység kezeli az FMA-t, ami rögtön utat ad a 4+4 co-issue képességnek. Ezzel tehát az Execution Unitok továbbra is órajelenként nyolc darab, egymástól független FMA utasítást képesek végrehajtani. Természetesen a függőség kezelése kulcsfontosságú maradt, mivel az egymástól függő operációk párhuzamos feldolgozása nem lehetséges. Erről ezúttal is a Thread Dispatch egység gondoskodik, amely igyekszik úgy etetni a vektormotorokat, hogy minél többször hasznosítható legyen a 4+4 co-issue feldolgozás. Mindemellett az alaparchitektúrát érintő finomítás, hogy javult a 32 bites integer műveletek feldolgozási sebessége.
A 8 darab Execution Unit egy shader tömbön belül visszalépésnek tűnhet, valójában viszont pont, hogy előrelépés történt. Az Intel a Sandy Bridge megjelenése óta komoly utat járt be az IGP fejlesztése szempontjából. A shader tömbben található feldolgozók száma gyakorlatilag minden generációban változott, ami egyetlen más, GPU-architektúrát tervező cégre sem jellemző. Maga a folyamatos módosítás azt jelzi, hogy a mérnökök egyszerűen nem találják az optimális konfigurációt. Az Ivy Bridge Gen7-es IGP-je esetében egy shader tömb 16 feldolgozót használt, és ez a szám a Haswell Gen7.5-ös megoldásánál 10-re csökkent, majd ahogy említettük, mostmár csak 8 darab Execution Unitról beszélhetünk. Ez tulajdonképpen azt jelenti, hogy a fejlesztés visszatért ahhoz a kiindulási ponthoz, ahol az Intel az egész HD Graphics vonalat elkezdte. Egyetlen dolog változott: az Intel mérnökei tapasztaltabbak lettek, így rájöttek, hogy rossz irány a shader tömbön belüli feldolgozókat növelni.
A Gen8 architektúra új irányt vett a hatékonyság és a jobb skálázhatóság elérése érdekében: a feldolgozók helyett az L1 gyorsítótár mérete nagyot nőtt a shader tömbökön belül. Ebben van is logika, mivel az eddigi adatok szerint az Intel problémája arra vezethető vissza, hogy hiába van sok feldolgozó a rendszerben, azok etetésére nem tartható fent elég sok szál az IGP-n belül. Ez a többi GPU-architektúrával összehasonlítva is eléggé szembeötlő, hiszen amíg az Intel egy teljes IGP-re nem használ ötszáz szálnál többet, addig a konkurens AMD és NVIDIA architektúrái csupán egyetlen multiprocesszoron is ezer vagy akár több szálat futtatnak. Mivel a futtatható szálak száma eléggé kötött paraméter az efféle architektúráknál, így ennek drasztikus emelésével nem érdemes próbálkozni, hiszen az felborítaná a jól megtervezett szinkronizációt a szálak között.
Az L1 gyorsítótár mérete azonban növelhető, és ez azt eredményezi, hogy az egy Execution Uniton belül futtatható maximális hét szál közül van esély rá, hogy egy vagy két szál számára ott lesz a szükséges adat az L1 gyorsítótárban, amivel a rendszer dolgozhat addig, amíg a többi szál számára is befut a szükséges információ. A gyorsítótár növelésének biztos lesz eredménye hatékonyság tekintetében, viszont érezhető hátrány, hogy jóval méretesebb lett az IGP, mint bármikor korábban. A Core M termékekhez alkalmazott lapkán az IGP akkora területet foglal el, amelyre négy darab extra Broadwell mag is építhető a hozzájuk tartozó gyorsítótárakkal együtt. Ráadásul ez még nem is a legnagyobb IGP konfiguráció, hiszen lesz egy duplaekkora opció is, amelynek helyére nyolc darab extra Broadwell mag férne el. Persze ezek inkább elméleti adatok, de látható, hogy a gyorsítótárak méretének növelése drasztikus hatással van az IGP helyigényére, ami arra is magyarázatot ad, hogy az Intel miért próbálkozott korábban inkább a feldolgozók számának növelésével.
A Core M-hez használt Broadwell lapka IGP-je [+]
A shader tömbökben szokás szerint megmarad a 256 kB-os kapacitást kínáló URB, azaz a Unified Return Buffer, mely egy gyorsan elérhető, írható és olvasható megosztott memória az Execution Unitok között. A textúrázás szempontjából sok változás nincs, azaz egy shader tömb két darab megosztott textúrázó blokkot tartalmaz, melyek egyenként négy darab Gather4-kompatibilis textúrázó csatornát alkalmaznak. Természetesen jelen van a blokkonkénti textúrázó gyorsítótár is, mely egy 4 kB-os elsődleges és egy 24 kB-os másodlagos szintből áll. A shader tömbök mellett található a render tömb, mely a data porton keresztül érhető el. Utóbbi tartalmazza a ROP-blokkot is, melyben négy blending és négy Z mintavételező egység dolgozik. Ezen a ponton tehát nincs változás a korábbi IGP-khez képest, viszont nőtt a ROP blokkhoz tartozó gyorsítótárak mérete. Megmaradt az L3 gyorsítótár is, ami az IGP saját, szabadon felhasználható memóriája, és ide a processzormagok nem írhatnak semmit. Ráadásul ennek mérete 256 kB-ról 384 kB-ra nőtt. Ezzel kapcsolatban fontos még megjegyezni, hogy az L3 gyorsítótér felel a Local Data Share (LDS) funkció ellátásáért is.
Konfigurálás szempontjából az Intel kétféle dizájnt kínál majd. A Core M termékekhez készült lapkában három shader tömb és egy render tömb lesz, ami összesen 24 darab Execution Unitot eredményez. A nagyobbik dizájn már hat shader tömbot és két render tömböt alkalmaz, vagyis a setup motoron kívül minden meg lesz duplázva az IGP-n belül. Kiemelendő még, hogy a Broadwell Gen8-as architektúrája már nem csak a négyszeres, hanem a kétszeres mintavételi módot is támogatja az MSAA aktiválásakor, ami azt jelenti, hogy a kétmintás (2x) opcióért már nem kell a négymintás (4x) MSAA sebességével fizetni. Ezt az Intel különálló blokkokkal oldja meg, vagyis a mérnökök beépítettek egy hardveres részegységet a kétmintás és egyet a négymintás MSAA-nak is. Ez technikailag tranzisztorpazarlás, de a végeredmény tekintetében abszolút működőképes megoldás. Mint ismeretes, a Haswell IGP-je ebből a szempontból furán működött. Mindemellett egy harmadik blokk képes a nyolcmintás MSAA-ra is.
A Broadwell tudása és a multimédia
A Broadwell architektúrájából már látható, hogy a hardver tudása is javult, főleg az IGP szempontjából. A Haswellhez képes extra, hogy a rendszer támogatja a DirectX 11.2-ben bemutatott, de opcionális Tiled Resources funkciót, annak is a butább TIER_1 szintjét. Technikailag az OpenGL 4.5 támogatásával sem lehet probléma, de az Intel egyelőre OpenGL 4.3-at jelez, ami csupán azért alakult így, mert nem biztos, hogy az újabb verziókhoz készül grafikus meghajtó. Mindemellett az Intel kiemelte az OpenCL 2.0 támogatását is az első oldalon már részletezett egységes memóriával egyetemben.
Multimédiás szempontból a Gen8-as architektúra szintén javult. A Quick Sync Video szolgáltatásért felelős hardveres blokk például kétszer gyorsabb lett a Haswell IGP-jében található opcióhoz viszonyítva, tudása viszont nem változott, így továbbra is a H.264, az MPEG2 és a VC-1 kodeket támogatja. Újítás még a HEVC videók dekódolásának támogatása. Ugyanakkor a vállalat ezt nem tüntette fel a hivatalos bemutatókon, ami annak köszönhető, hogy egy szoftveres, GPGPU-s megoldásról van szó, vagyis nem fixfunkciós blokk felel majd a feldolgozásért. Utóbbi régóta téma a piac szereplői között. Egy dedikált HEVC feldolgozó mérete majdnem akkora, mint egy Broadwell processzormagé, ráadásul szükségtelen is, mert magát a HEVC szabványt alapjaitól kezdve úgy tervezték, hogy nagyon hatékony lehessen a GPGPU-s feldolgozása. Ez nem egyedi meglátás tehát, majdnem a teljes ipar mostohán néz a dedikált HEVC egységekre, mivel az IGP el tudja látni a feladatot, és a többletfogyasztás is szinte elhanyagolható mértékű.
A HEVC támogatása két részből állhat. Egyrészt az Intel elérhetővé tesz egy olyan grafikus meghajtót, amely tartalmaz egy beépített HEVC dekódolót, ami a Gen8 architektúrán is működik. Ilyen már van a legújabb eszközillesztőben, és bár ez a modul a Gen7, Gen7+ és Gen7.5 architektúrára épülő IGP-k virtuális utasításarchitektúrájára van assembly szinten lekódolva, tehát a Gen8-on még nem működik, de ennek csupán az az oka, hogy nincs engedélyezve. Elvi szinten a beépített kód üzemképes, de aktiválás előtt előbb le kell tesztelni. Másik lehetőség az OpenCL, amely felülettel bárki írhat HEVC dekódolót a hardverhez.
Duty Cycle Control [+]
Az Intel kiemelte még, hogy a Broadwell lapkát elsősorban a hatékonyságot szem előtt tartva tervezték. Ezt a vállalat konkrét, Core M termékekhez kapcsolódó adatokkal nem támasztotta még alá, de kiemelték az IGP-be épített Duty Cycle Control nevű energiatakarékos technológiát, amely nagyban csökkenti majd az adott termék üresjárati fogyasztását: az új rendszer terhelés nélkül szimplán lekapcsolhatja az IGP-t. Ez 60%-kal is megnövelheti az akkumulátor üzemidejét, amennyiben az adott mobil eszköz nincs használatban. Szintén fontos adalék, hogy az Intel szerint kétszeresére növelték a hatékonyságot, illetve a processzormag egy új turbót is kap. Ez a normál opciót egy úgynevezett PL3 fokozattal egészíti ki, ami drasztikusan megnöveli a fogyasztást, de cserébe a teljesítményt is. Ez a mód csupán ezredmásodpercekre aktiválódhat, és csak akkor, ha a belső hőmérséklet ezt lehetővé teszi.
Az Intel a Broadwellhez új vezérlőhidat is tervez, melynek különlegessége leginkább az aDSP, ami egy dedikált hangprocesszorként jellemezhető, és bizonyos feladatokban leveheti a terhet a processzorról a hangok számításánál.
Mivel hivatalosan nem beszélhetünk startról, így az Intel nem beszélt a konkrét paraméterekről, a pontos teljesítményről, illetve fogyasztásról. A Core M termékek viszont idén megérkeznek, tehát a tényleges adatok közzétételéig valószínűleg már nem kell sokat aludni.
Abu85
