Az IGP új képességei és a skálázás gyakorlata

Az új IGP általános felépítése mellett érdemes rátérni az extra tudásra, amit az Intel belepréselt. A Gen7.5 architektúra támogatja a DirectX 11.1-es, a DirectCompute 5.0-s, az OpenGL 4.0-s és az OpenCL 1.2-es API-t. Az OpenGL-támogatással még mindig nagyon mostohán bánik az Intel, de a többi szempontból nem érheti panasz a rendszert.

Javult a setup motor is, ami az előző körben is komoly fejlődésen ment keresztül. Alapvetően a sebesség változott, mivel az egyes fixfunkciós egységek teljesítményét megduplázta az Intel, amire azért volt szükség, mert mostantól egynél több shader és render tömböt is ki kell szolgálnia a rendszernek. A tesszellátor továbbfejlődött, de ennek teljesítményével eddig sem volt lényeges probléma. Azzal viszont már van, hogy az Intel továbbra sem figyel a hierarchikus Z túlterhelésére, így kis háromszögek mellett a feldolgozás teljesítménye nagyon visszaesik. Erre az AMD és az NVIDIA már alkalmaz egyfajta megoldást, aminek a titka abban rejlik, hogy a rendszer a raszterizálást hierarchikus Z nélkül hajtja végre a teljes képkockát több egyenlő méretű, viszonylag kicsi mozaikra osztva, és biztosítva a renderelés megfelelő sorrendjét. A hierarchikus Z algoritmus a mozaikokon lesz lefuttatva, amelyeket tovább lehet küldeni, vagy éppen el lehet dobni, ha nem tartalmaznak látható információt. Erre az Intelnek később figyelnie kell, mert nem sokat ér a gyors tesszellátor, ha nincs megfelelő körítés hozzá.

A Haswell IGP-je két órajelenként dolgoz fel egy háromszöget, ami a megcélzott kategóriában manapság vérszegénynek számít. A rendszer ugyan kellően magas órajelen jár, hogy ez ne legyen nagyon limitáló hatású, de lassan illene valami combosabb setup motort fejleszteni, lépést tartva a kor igényeivel. A raszter motor a raszterizálást négyes pixelblokkokon hajtja végre (ez általánosnak mondható a mai PC-s GPU-kon vagy IGP-ken), a teljesítménye pedig órajelenként 8 képpont. Utóbbi érték már megfelelő az IGP-k között, és ennek hála két render tömb mellett is kiegyensúlyozott a rendszer. Egy render tömbbel már sok is a raszterizálás teljesítménye, de itt a ROP úgymond túletetése a jobbik eshetőség, így ez nem jelenthet problémát.

Változás érte még a CS rövidítésű Command Streamer egységet, ami kibővült pár új funkcióval, melyek apró módosításoknak tűnnek, de radikális fordulatot eredményeznek az Intel tervezési koncepcióját tekintve, egészen pontosan a processzormagok és a grafikus vezérlő kommunikációjában. Évek óta nincs egyetértés abban, hogy érdemes-e pont a processzormagokat használni a grafikus teljesítmény maximalizálása érdekében, vagy éppenséggel a grafikus hardver parancsait kell megközelítőleg olyan egyszerűvé tenni, amilyenek az API parancsai. A grafikus processzorok fejlesztésével foglalkozó cégek az előző évtized közepe óta egyetértenek abban, hogy utóbbi elv a nyerő stratégia, így például az AMD és az NVIDIA is ezt a tervezési filozófiát követi, miközben az Intel korábbi véleménye az volt, hogy akármekkora teljesítmény beáldozható a grafikus driver egyszerűségének fenntartása érdekében.

Függetlenül attól, hogy a teljes iparág magára hagyta az Intelt fenti véleményével, nem lehet elmenni szó nélkül amellett, hogy a Santa Clara-i óriáscégnek sok szempontból igaza van az egyszerűséget illetően. A mai grafikus driverek túl bonyolultak, túl sok erőforrást kell a fejlesztésükbe ölni, és a tesztelésük is nagyon nehéz. Az Intel eddig az előbbi problémáktól teljesen mentesült pusztán azért, mert más elveket vallottak a processzormagok és a grafikus vezérlő kommunikációja szempontjából. Meggyőződésünk, hogy a vállalat véleménye ma sem változott meg, továbbra is az egyszerűséget tartják jobb iránynak, de nem nézhetik, hogy a konkurensek csupán a driver felépítésének elvi eltéréséből akár hatszoros tempóelőnyre tesznek szert egy-egy játékban.

Ezt a különbséget a hardver fejlődése sose hozná be, így az Intel a büszkeségét sutba vetve beállt a többi cég mögé, így a Haswell IGP-jének tervezésénél már azt a nézetet vallották, hogy a grafikus hardver parancsait kell megközelítőleg olyan egyszerűvé tenni, amilyenek az adott API parancsai. Ennek értelmében változott meg a Command Streamer egység, ezzel pedig esélyt ad a cég magának, hogy minimalizálják a driver többletterhelését, amivel sebességet nyerhetnek. Ennek hozományaként viszont mostantól sokkal bonyolultabb meghajtókat kell írniuk. Fontos megjegyezni, hogy az Ivy Bridge IGP-je ebből a váltásból nem vagy csak nagyon keveset profitál majd, mivel más működésre tervezték a hardvert, míg a régebbi integrált grafikus processzorokat az Intel már nem támogatja folyamatosan frissülő driverekkel.

A hardverek

A Gen7.5 architektúra részletezése után érdemes megnézni, hogy milyen konfigurációk épülnek majd a rendszerre. A legegyszerűbb ezt táblázatos formába önteni, mivel így jól láthatók az eltérések:

[+]

Az adatok magukért beszélnek, de érdekes újítás az eDRAM az Iris Pro Graphics 5200 esetében. Ez funkcionálisan egy L4 gyorsítótárként működik, és a belső gyűrűs adatbusszal van összekötve. Ennek megfelelően a processzormagok és a grafikus vezérlő is írhat bele, illetve olvasható belőle. A koncepciónak előnyei és hátrányai is vannak. Előnye, hogy az IGP gyorsabban jut adatokhoz, így mindenképp tempósabban végzi majd a feladatát. Hátránya azonban, hogy az IGP szálanként 32 kB adatot írhat bele, ráadásul oda ahova akar. Némi szoftveres kontrollt azért biztosíthat a programozó. Ez hasonlít arra a megoldásra, amit az Intel a Sandy Bridge esetében vezetett be az utolsó szintű gyorsítótárra (LLC), miközben az Ivy Bridge esetében alapértelmezett működés mellett letiltották ezt a funkciót, mert az IGP gyakorlatilag kontroll nélkül elkezdte használni az LLC-t, és a processzormagok által kiírt adatokat sorra felülírta. Ez komoly probléma volt, mivel azok eléréshez a processzormagoknak a rendszermemóriához kellett fordulnia, ami mindig jelentős időveszteség.

Az eDRAM 128 MB-os mérete mellett ez elvben ugyan még mindig probléma, de a gyakorlatban már nem, hiszen az LLC-t az IGP érintetlenül hagyja, így a processzormagok számára a legfontosabb adatok gyorsan elérhetők. Eközben az IGP lényegében kisajátíthatja a gyorsítótárként funkcionáló eDRAM-ot. Persze a rendszernek azért némi hátránya még így is van, mivel a processzormagok szempontjából rontja nagyméretű tartományokon tárolt adatok eléréséhez szükséges időt, de ez vállalható kompromisszumnak tűnik.

A cikk még nem ért véget, kérlek, lapozz!