Az Intel termékei kapcsán az integrált grafikus vezérlőről messze nem a tökéletesség jut a felhasználók eszébe, de a jövő szempontjából ez lesz a legfontosabb részegység a lapkákban, így nem véletlen, hogy a vállalat komoly erőforrást fektet a fejlesztésekbe. Az Ivy Bridge-ben bemutatkozó Gen7 architektúra már egy vállalható rendszer, ami a funkcionális működés szempontjából a kornak megfelelően üzemel. Természetesen távolról sem hibátlan, hiszen a kialakítása széles spektrumon nehezen skálázható, illetve a mérnököknek a Gather4 utasításokról is igen sajátos véleményük volt. Utóbbit ugyan funkcionálisan implementálták, de elfelejtették megnégyszerezni a textúrázókban a csatornánkénti mintavételezők számát, így ez eliminálja a Gather4 utasítások alkalmazásának előnyeit. Pedig ez kifejezetten hasznos funkció, és 25-30%-kal is növeli az alkalmazások átlagos sebességét. Ezen a ponton a Haswell Gen7.5-ös architektúrára épülő IGP-je végre javít, illetve az Intel végez még apróbb módosításokat is.
Hosszabb távon természetesen új architektúrára van szükség, mivel a skálázhatóság egy rendkívül fontos eleme lesz a jövőnek, és a Gen7/Gen7.5 rendszerek mindössze három nagyobb blokkra oszthatók, miközben az AMD és az NVIDIA fejlesztései jellemzően nyolc blokknál is többet használnak. Utóbbi cégek ennek megfelelően sokkal szélesebb spektrumon képesek skálázni, illetve az architektúráik teljesítménye is közel lineárisan idomul az adott felépítéshez, ami hatalmas előny (főleg az ultramobil vonalon). Persze az Intel egyelőre még tanulja a modern grafikus hardverek hatékony működtetését, így nem sportszerű az összehasonlítás a közel 20 éves tapasztalatot birtokló konkurensekkel. Azt viszont lehet látni, hogy az Intel tényleg fejleszt, és bár a hardveres lehetőségeik korlátozottak, azért a hátrányt megpróbálják ledolgozni alternatív megoldásokkal.
Az idei GDC-n a vállalat két újítással állt elő, melyek a Haswell Gen7.5-ös architektúrára épülő IGP-jében kihasználhatók, és lesz két játék, ami használni is fogja ezeket. Az egyik újítás az InstantAccess funkció. Ez tulajdonképpen megegyezik az AMD Zacate, Ontario, Hondo, Llano, Trinity és Richland kódnevű APU-iban megtalálható, két éve bemutatott Zero Copy funkcióval. Erről a PROHARDVER! hasábjain belül keveset beszéltünk, mivel ezek a szolgáltatások bár hasznosak, de használhatóságuk limitált. Mindenesetre, ha már az Intel és az AMD is egy húron pendül, ideje megnézni, hogy mit is kínál az InstantAccess és a Zero Copy. Tulajdonképpen az a cél, hogy a lapkában CPU és IGP hatékonyabban dolgozzon össze. Ez a mai fejlesztések mellett nem olyan egyszerű, mivel mindkét részegység elkülönített memóriaterületet használ az egyébként közös rendszermemóriából. Ha a CPU átad egy feladatott az IGP-nek, akkor a CPU memóriájában található adatokat át kell másolni az IGP memóriájába, ami időveszteség. Az InstantAccess és a Zero Copy ezt úgy próbálja áthidalni, hogy létrehoz egy olyan – nem gyorsítótárazható – memóriaterületet, amit a CPU és az IGP egységesen képes írni és olvasni. Az előny egyértelmű, mivel megúszható a memóriamásolás, de van azért hátrány is. Ezt a megoldást ugyanis az adott program oldaláról direkten kell támogatni, ami nem egyszerű, de a Zero Copy támogatását számtalanszor megoldották a fejlesztők, így a hasonlóan működő InstantAccess sem jelenthet gondot.
A játékok szempontjából az AMD Zero Copy támogatására a Total War: SHOGUN 2 a legjobb példa. Ezek után talán nem meglepetés, hogy a Creative Assembly a készülő Total War: ROME II című játékban már nem csak Zero Copy, hanem az Intel InstantAccess támogatását is megoldja majd. Ezek a funkciók természetesen csak IGP-n való programfuttatás során élnek, mivel így lehet az integrálás előnyeit kihasználni.
Az Intel másik újítása PixelSync technika, ami egy igen érdekes megoldás a kor egyik legnagyobb problémájára. Manapság a játékfejlesztők egyre többször felvetik az igényt az OIT-re (Order Independent Transparency, azaz sorrendtől független átlátszóság), ami tulajdonképpen bizonyos komplex effektek megjelenítése során igen fontos elem. Nem is kell túlságosan messzire menni ezen a ponton, hiszen a Tomb Raiderben debütált TressFX hajszimuláció pontos leképzése az OIT bevetése nélkül nem oldható meg hatékonyan. Az OIT azonban így sem mondható túlzottan erőforrást kímélő megoldásnak, legalábbis az AMD által fejlesztett és Tomb Raiderben felhasznált algoritmus, amely ráadásul olyan eljárást használ, ami sebességelőnyt merít a hardverbe épített dedikált atomi feldolgozókból, és ilyenek csak a DirectX 11-es Radeon grafikus vezérlőkben vannak.
Természetes, hogy az Intel számára az AMD által fejlesztett algoritmus nem jó, mert egyrészt jobban idomul a Radeonok funkcionális képességeihez, másrészt a memóriára is komolyabb terhelést fejt ki, ami az IGP-k szempontjából nem kedvező. A PixelSync technika tulajdonképpen az OIT kérdését megpróbálja megoldani egy másik megközelítésből, vagyis alapvetően az Intel kidolgozott egy eltérő algoritmust a problémára, ami nyilván jobban idomul majd a Haswell IGP-jéhez. Ez azonban nem szabványos technika. Kihasználja, hogy a DirectX 11.1-es API bevezeti a kiterjesztéses rendszert, amelynél a gyártók a hardverek képességeihez egyéni kiterjesztéseket kreálhatnak, amit a fejlesztők ki is használhatnak. A PixelSync az Intel első DirectX 11.1-es kiterjesztése, így csak Windows 8 alatt érhető el.
A PixelSync lényegében annyit tesz, hogy az IGP-be épített speciális hardveren keresztül irányítja a memória elérését. Ez a grafikus processzorokban értékelhető változást hozhat, mivel manapság a feldolgozás nagymértékben párhuzamosítva van, de a munkafolyamatok többször is ugyanarra a pixelekre zajlanak, ami gondot jelenthet például az OIT implementálásánál. Funkcionálisan maga az eljárás tökéletesen leszámolható, csak a hardver szintjén az átlapolások az adott folyamatok leállításával és későbbi újraindításával járnak. Ez gyenge kihasználtsághoz vezet azokon a grafikus vezérlőkön, amelyek multiprocesszorai relatíve kis mennyiségű konkurens szálat futtatnak. A PixelSync kiterjesztés segítségével a szoftver megmondja a hardvernek, hogy egy adott kódrészletet bizonyos pixelekre érdemes úgymond osztályozva futtatni, mivel többet nyerhet a hardver sebességben a soros feldolgozással, mintsem a hagyományos drasztikus párhuzamosítással. Ennek a megoldásnak a nehézsége, hogy a szoftvernek nagyon pontos utasításokat kell adni, mivel ha rossz kódrészletre és pixelekre jelöli ki ezt a feldolgozási formát, akkor az drasztikusan csökkentheti a sebességet. Az elvi működés alapján a PixelSync hatékonyabb OIT implementációt tesz lehetővé.
A GRID 2 és a Total War: ROME II építeni fog a PixelSync kiterjesztésre az OIT szempontjából, mely csak a Haswell IGP-in lesz elérhető. Természetesen mindkét játék kap szabványos OIT implementációt. Mivel az OIT egészen általános eljárás, így a két megoldás között nem lesz képminőségbeli eltérés, de a teljesítményt figyelembe véve a Gen7.5-ös architektúrájú IGP-hez specifikusan optimalizált megoldás a Haswell IGP-jén gyorsabb lesz a szabványos kódnál. Ezzel lényegében mindenki jól jár, hiszen a képminőség romlása nélkül nő a Haswell IGP-ken a sebesség.
