Az előző év őszén már pedzegettük, hogy nagyrészt újratervezett dizájnt kap az Intel Gen10-es architektúra, és ezt most pár újabb részlettel tudjuk megerősíteni. Eszerint nem csak a parancsprocesszort éri komoly változás, hanem a teljes rendszert is.
Az Intel fő iránya igazából csak a problémákra reagál. A vállalat az elmúlt években számos kifejezetten hasznos fejlesztést hajtott végre, amelyek éreztetik a hatásukat a DirectX 11-es programokban, de hirtelen bekövetkezett egy olyan váltás az API-k piacán, amire a vállalat nem készült fel. Emiatt az olyan explicit API-kban, mint a DirectX 12 és a Vulkan kifejezetten rosszul érzi magát a vállalat architektúrája, ami elsődlegesen a limitált teljesítményű parancsprocesszornak köszönhető. Gond azonban nem csak ezzel van, hanem az alapokkal is, így például az Intelnek az az irány sem tesz jót, hogy a közeljövőben a compute futószalagok száma a játékokban kiteheti az összes futtatott futószalag felét. Itt kifejezetten a compute és grafikai futószalagok egyenlőhöz közelítő aránya a probléma, mert ha a compute vagy a grafikai futószalagok egy programban nagy többségben van, akkor az kedvez az Intel rendszerének.
Utóbbi főleg amiatt van, hogy az Intel az aktuális grafikus vezérlőit nem készítette fel konkurens feladat-végrehajtásra. Ezen azt kell érteni, hogy az Intel IGP-in vagy compute vagy grafikai futószalag futhat azonos időben, és a két üzemmód közötti váltás sajnos nem olcsó. Emiatt jelentős üresjáratokat okoznak azok az alkalmazások, amelyek állandóan üzemmódváltásra kényszerítik a hardvert. A rendkívül magas turbó órajeleket is főleg ezért alkalmazza az Intel, mivel így maximális órajelen vezényelhető le a váltással járó nagyjából ezer büntetőciklus, ami még 1 GHz-es szinten is egy mikroszekundumnyi kihagyást jelent. Ez sajnos egy kényszerű lépés, mivel minden más szempontjából hátrányt okoz az a tényező, hogy az órajel 500-900 MHz-eket ugrálhat oda-vissza pillanatok alatt.
Csak összehasonlításképpen az NVIDIA és az AMD architektúrái ebből a szempontból sokkal kedvezőbbek. Az NVIDIA Fermi, Kepler és Maxwell például képes olyan feldolgozásra, hogy a GPU-n belül konkurens compute és grafikai futószalag fusson, ugyanis az üzemmódok leosztása a multiprocesszorok szintjén történik. Ebből az is kitalálható, hogy egy multiprocesszoron belül már nincs konkurens feladat-végrehajtás. Az AMD GCN ennél is modernebb, mivel konkrétan nem rendel hardverállapotot a compute futószalagokhoz (stateless compute), így még a multiprocesszorok belül is mehet a compute és grafikai futószalag konkurens végrehajtása, mindezt dinamikus terheléselosztással, amit a hardver menedzsel. Itt megjegyezhető még, hogy az érkező NVIDIA Pascal architektúra is képes lesz egy amolyan hibrid állapot kezelésére, ami megengedi, hogy egy multiprocesszoron belül az egyik compute blokkon grafikai, míg a másikon compute futószalag fusson. Ez egy szoftveresen menedzselt, statikus terheléselosztást megvalósító mód.
Látható, hogy ezen a területen az Intel fényévekre van azoktól a működési modellektől, amelyeket az AMD és az NVIDIA használ. Ez addig nem is jelent problémát, amíg a compute futószalagok csak az összes futtatott futószalag nagyjából tíz százalékát teszik ki, de a fejlesztők által elképzelt irány mellett lépni kell. Emiatt a Gen10-es architektúra az új parancsmotor mellett erre a problémára is koncentrál, így az OEM-ekkel eddig megosztott adatok szerint lehetséges lesz a compute és a grafikai futószalagok konkurens végrehajtása a grafikus vezérlőn belül. Az viszont még kérdéses, hogy ez a multiprocesszorokon belül is igaz lesz-e. Megfelelően megtervezett dedikált compute parancsmotorok mellett még az aszinkron compute normális támogatására is lesz lehetősége az Intelnek, ami lényeges tényező a jövőt elnézve, hiszen ez az a funkció, amire minden fejlesztő rárepült a DirectX 12 és a Vulkan API esetében.
Szintén érdekes tényező, hogy az Intel csökkentené a futószalagidőt is. Azt sajnos nem lehet tudni, hogy ezt konkrétan milyen formában szeretnék elérni, de az egyik nagyon is értékelhető lehetőség az utasítás előbetöltés alkalmazása, amit például az AMD is bevezet a Polaris kódnevű generációtól kezdve. Persze más módszereket is lehet találni, mint például egy hatékony gyorsítótár struktúra, vagy az órajel drasztikus emelése, de kétségtelen tény, hogy igazi megoldást a magas futószalagidő problémájára csak az utasítás előbetöltés ad. A futószalagidővel kapcsolatos gondok egyébként újnak tekinthetők, hiszen a két új explicit API miatt alakultak ki. A jelenség abból adódik, hogy a processzor oldaláról, a többszálú parancskreálásnak hála jóval több parancs adható ki a grafikus vezérlő felé. Ugyanakkor a jellemző futószalagidőket, vagyis azt az időtartamot, ami eltelik a feladatok adatigénylése és a várt adatok beérkezése között, még a DirectX 11-hez igazították az aktuális architektúrákban. Emiatt hiába skálázódik a rendszer a processzor oldaláról, a grafikus vezérlőn belül olyan korlátok jelennek meg, amelyek korábban nem voltak tapasztalhatók, és ez csökkenti a kihasználtságot. Az egész abból adódik, hogy hiába a sok konkurens szál a multiprocesszorokon belül, azok egyszerűen az adat beérkezésére fognak várni. Ez a probléma az Intel GPU-architektúráit kifejezetten rosszul érinti, mivel az AMD és az NVIDIA dizájnjaihoz képest jóval kevesebb szálat futtatnak a multiprocesszoraikon belül, így viszonylag hamar belefutnak azokba a limitációkba, amik megakadályozzák a további skálázódást a sok rajzolási paranccsal dolgozó DirectX 12 és Vulkan API-t használó játékok alatt.
A fenti információk tudatában a Cannon Lake lapkában érkező Gen10-es GPU-architektúra izgalmasnak ígérkezik, hiszen végre valódi előrelépési lehetőségek kerülnek előtérbe, és nem használhatatlan mellékvágányokat kreálnak a mérnökök.
