Az Ivy Bridge és a grafika
Talán nem túlzás kijelenteni, hogy az Intel az Ivy Bridge fejlesztése során az integrált grafikus vezérlőre (IGP) koncentrált. Alapvető fontosságú volt ennek az egységnek a korszerűsítése, mivel az IGP manapság már nemcsak a grafikában számít, hanem általános számításokra is bevethető, és nem kevés esetben sokkal gyorsabb, illetve energiahatékonyabb lehet a feldolgozás, mint a processzormagokkal. Az előző generációs Sandy Bridge ebből a szempontból még nem jeleskedett, ugyanis a rendszer IGP-je túl buta volt az általános számítások hatékony feldolgozásában. Az Intel "tick-tock" stratégiája persze a "tick" kategóriába tartozó, gyártástechnológiai váltásoknál jellemzően nem kockáztat nagy volumenű változást, a vállalat azonban mégis bevállalta az IGP áttervezését, amire már mindenképpen szükség volt.
Az új IGP az Intel teljes termékskáláját tekintve hetedik generációsnak tekinthető, míg a HD Graphics sorozaton belül harmadik generációs megoldásról van szó. A vállalat az újratervezett grafikus architektúrát szimplán Gen7-nek nevezi, amiből kitalálható, hogy a Sandy Bridge IGP-je a Gen6 jelzést viselte. Rögtön az elején érdemes leszögezni, hogy a Gen6 architektúra helyenként nagyon vérzett. E sebek egy része a Sandy Bridge koncepciójából eredt, de az IGP más szempontok szerint is messze volt a korszerűtől. Minderről persze nem sokan tudnak, ami annak is köszönhető, hogy az Intel IGP részletes vizsgálatát mostanáig mellőztük, ám itt az ideje ezt az elmaradásunkat bepótolni, így alapvetően kielemezzük a Santa Clara-i óriáscég elképzelését a grafikus vezérlők szempontjából.
Az IGP felépítése
Az Intel szemszögből a Gen6-os IGP legnagyobb gondja a skálázhatósággal volt. Ez azt jelenti, hogy a rendszer elemei nagyon szorosan kapcsolódtak egymáshoz, így egyes részegységek számát ugyan meg lehetett növelni, de ez a kiegyensúlyozatlanságot is maga után vonta, ami nyilván nem kedvező jelenség. A Gen7 architektúra tehát az alapokat tekintve a HD Graphics sorozatra épít, de a fő fejlesztési szempont a skálázhatóság megteremtése volt. Az AMD és az NVIDIA a megfelelő skálázhatóságot a moduláris felépítéssel biztosítja, és nem meglepő, hogy az Intel is így tett. Az Ivy Bridge IGP-je alapvetően több részre osztható fel, amit az alábbi kép szemléltet.
[+]
Látható, hogy a grafikus számítás szempontjából három rész jól elkülöníthető. A legfontosabb a kalkulációkért felelős shader tömb, melyből egy kapott helyet. Ezen belül 16 darab shader processzor található, amit az Intel Execution Unit néven emleget. Ezek komplex feldolgozók, így két darab 128 bites vektormotorból állnak. 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. A Gen6 IGP pontosan ilyen felépítéssel rendelkezett, de az új fejlesztés némileg azért csavart a dolgok menetén. Először is az általános vektormotorok már támogatják a bitszintű utasításokat, emellett a rendszer megfelel az IEEE754-2008-as lebegőpontos szabványnak, további újítás még az FMA (Fused Multiply-Add) utasítás bevezetése, ami pontosabb számításokat tesz lehetővé. Mindezek a DirectX 11-es API követelményei, így az alkalmazásuk kötelező volt, de nyilván előnyt jelentenek az előző generációhoz képest.
Sokkal érdekesebb újítás az Execution Unitok 4+4 co-issue képessége. A Gen6 IGP esetében a speciális vektormotor csak a trigonometrikus és a transzcendens utasításokat támogatta. Amennyiben az adott shader kódban nem volt túl sok ilyen számítás, akkor a rendszer speciális vektormotorjai kihasználatlanok voltak, így az Intel a Gen7 architektúra esetében az FMA támogatását is beépítette. Ezzel tehát az Execution Unitok ó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 itt kulcsfontosságú, mivel az egymástól függő operációk párhuzamos feldolgozása nem lehetséges. Erről a Thread Dispatch egység gondoskodik, mely igyekszik megfelelően etetni a vektormotorokat, hogy minél többször hasznosítható legyen a 4+4 co-issue képesség. Mindennek érdekében az Intel megnövelte a párhuzamosan kezelt szálak számát is, illetve az Execution Unitok regiszterterülete is nagyobb lett.
A shader tömbben található még 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, emellett a 32 kB-os L1 utasítás gyorsítótár is megosztott. Itt megjegyezzük, hogy az URB felel majd a DirectX 11-ben megkövetelt Local Data Share (LDS) funkció ellátásáért is.
A textúrázás szempontjából szintén javult a rendszer. A 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. A Gather4 azonban csak formális jellegű, mivel egy csatornához csak egy mintavételező tartozik, ami nyilván teljesen eliminálja a Gather4 utasítások alkalmazásának előnyét. Ez logikátlan döntés a mérnökök részéről, hiszen a DirectX 11-es játékok aktívan használják ezt a funkciót, és jelentős teljesítmény nyerhető vele. 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 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 Gen6 IGP-hez képest, de hatalmas újítás a megosztott 256 kB-os L3 gyorsítótár megjelenése a Gen7 IGP-n belül, ami a Sandy Bridge működésének legnagyobb problémáját oldja meg. Mint ismeretes, az előző generációs architektúra a processzormagokat és az IGP-t egy MESIF koherenciaprotokollt alkalmazó, négy részre osztott utolsó szintű gyorsítótárral (LLC) kapcsolja össze, mely gyűrűs buszon keresztül kommunikál. A koncepció alapvetően az, hogy az IGP írhasson az LLC-be, ezzel gyorsan hozzáférhetővé téve az adatokat a processzormagok számára, illetve nem mellékesen a processzormagok által kiírt adatok gyors elérése is fontos. A MESIF koherenciaprotokoll azonban csak a processzorra vonatkozik, ami azt jelenti, hogy a processzormagok csak a saját LLC szeletükbe írhatnak, miközben a teljes LLC-t olvashatják.
Azonban az IGP nem kevés szállal dolgozik, és szálanként 32 kB-os adatot írhat az LLC-be, azon belül is, oda ahova akar. A kontrollt itt a programozóknak kellene biztosítani, de mivel ilyen rendszerrel még senki sem találkozott a Sandy Bridge megjelenéséig, így erre nem lehetett készülni. Az pedig könnyen kitalálható, hogy ha az IGP kvázi kontroll nélkül elkezdi írni az LLC-t, akkor a processzormagok által kiírt adatokat sorra felülírja, vagyis azok csak a rendszermemóriából érhetőek el újból. Mindez nagyon rontotta a Sandy Bridge összteljesítményét, ami egyes játékprogramok alatt másodpercekig tartó megállás formájában jelentkezett, majd a feldolgozás egy darabig ismét folyamatos volt. Az Intel a problémát a driverben oldotta meg, vagyis az előbb részletezett koncepcióra érzékeny programok esetében letiltották az IGP írási jogát az LLC-re vonatkozóan, ami a másodpercekig tartó megállásokat megszüntette, de az átlagos tempó negatív irányba mozdult el.
Az Ivy Bridge a Sandy Bridge alapkoncepcióján nem változtat, ám az IGP-ben most már ott van az Execution Unitok között megosztott L3 gyorsítótár. Ide a rendszer kedve szerint írhat, hiszen ez nem befolyásolja a processzormagok munkáját. Természetesen a fejlesztő kiírhatja az adott szál eredményét az LLC-be is, így azt a processzormagok gyorsan elérhetik, emellett az IGP az LLC tartalmát továbbra is olvashatja, vagyis az Intel alapvetően megoldotta a problémát.
A cikk még nem ért véget, kérlek, lapozz!
