Az Intel egyre többet foglalkozik a játékfejlesztők segítésével, így számos fontosabb eljárást dolgoztak már ki a partnerek számára. Az egyik legismertebb a processzoron futó MLAA eljárás, melyet a Need for Speed: Shift 2 Unleashed című játékban már adaptáltak is, de a SIGGRAPH 2011 alkalmával a vállalat egy prezentáció során felhívta a fejlesztők figyelmét arra, hogy a GPU-s számítások drasztikus erőltetése helyett inkább a processzorokban rejlő erőt kellene jobban kihasználni.
Az aktuális trendek alapján a grafikus processzorokat a fejlesztők egyre több általános számítással terhelik le, így például van olyan játék, ahol mesterséges intelligencia vagy éppen a fizikai számítását nem a processzormagok végzik. A vállalat úgy gondolja, hogy a klasszikus munkafolyamatokat továbbra is a processzormagokon érdemes futtatni, sőt az IGP-k tehermentesítése érdekében számos grafikai effektet a processzor erejére kellene bízni. Korlátok persze akadnak, hiszen a CPU-magok nem rendelkeznek textúrázókkal és dedikált raszterizálóval sem, ráadásul a grafikus API-k kialakítása messze nem úgy lett tervezve, hogy a jelenet számítása többször megosztható legyen a CPU és a GPU között. Ettől függetlenül az Intel szerint a Sandy Bridge, és az érkező új generációs termékek számára a terhelés megosztása lenne a legkézenfekvőbb.
Az Intel szerint számos grafikai effekt esetében előnyösebb a CPU használata, ilyenek például a post-process effektek, azaz az MLAA, a HDR, vagy a Bloom, de nagy segítséget jelenthet a processzormag shadow mapok generálása esetében, vagy esetlegesen egy Z-Prepass fázis is előnyös lehet, azaz a képkocka számításának egyes specifikus részei átadhatóak a processzornak.
A vállalat előállt egy példával a HDR-re, mely később letölthető lesz példaprogram formájában is. Az elméleti alapok úgy működnek, hogy a GPU egy render targetbe képzi le a képkocka előzetesét, majd azt el kell juttatni a processzormagokhoz, hogy a HDR ki legyen számítva rá. Ezután az eredményt vissza kell másolni a back bufferbe, ahol befejezhető a munka, és a képkocka kiküldhető a kijelzőre. Persze a GPU és a CPU közötti adatok másolgatása, még lapkán belül is nagyon sok időt emészt fel, így a vállalat a gyakorlatban egy trükkhöz folyamodik.
[+]
A fenti kép jól mutatja a lényeget. Fontos megjegyezni, hogy ez a prezentáció nagyon le van egyszerűsítve, valójában ennél sokkal bonyolultabb folyamatról van szó, de a működés megértése szempontjából csupán a HDR és a végső eredmény a lényeges elem. A teljesen GPU-s leképzésnél a jelenet után következik a HDR, majd a végső képkocka kiszámítása, és egyben megjelenítése. Látható, hogy minden részlet azonos jelenetből származik. Az Intel megoldása esetében ez nem így van, ugyanis ha minden azonos jelenetből származna, akkor az egész nem érne semmit, hiszen a CPU és a GPU egymásra várna. Éppen ezért az Intel algoritmusa a HDR-t mindig az előző jelenetből számítja, majd a végső eredmény egy képkockával korábbi információkat tartalmaz, de csak a HDR-re. Ez nem szép megoldás, de valószínűleg nem, vagy csak alig észrevehető a két elgondolás közötti eltérés. Ezzel az algoritmussal a HDR és a képkocka számítása párhuzamosan végezhető el, vagyis végeredményben gyorsul a program. Érdekes adalék lehet, hogy hasonló trükköket már most is alkalmaznak a fejlesztők az Xbox 360-ra készülő játékok esetében. Itt nem a sebességgel van a gond, hanem a Xenos GPU-hoz kapcsolt 10 MB kapacitású EDRAM szűkössége a probléma forrása, így az egyes effekteket az előző képkocka adataiból számolják, megspórolva ezzel egy render target helyigényét. Nem szabad elfelejteni, hogy az ilyen trükkök bevetése megbontja a hagyományos leképzési rendszert is, ahol aranyszabálynak mondható, hogy az egyes képkockák között a lehelő legkevesebb adatmegosztás történjen. Amennyiben a fejlesztő ezt nem tartja be, akkor az erre felkészített, AFR-re épülő SLI és CrossFire technológiák kvázi működésképtelenné válnak.
[+]
Az Intel HDR algoritmusa kapcsán szintén fontos megjegyezni, hogy a példa az eredeti jelenet felbontásának tizenhatod részével dolgozik, vagyis minőségben nem a legjobb az effekt, de a processzormagokon aligha lenne tempós a teljes felbontással való számítás, hiszen az képkockánként tizenhatszor több adat feldolgozását jelentené. Többek között ez az oka annak, hogy a HDR-t főleg GPU-n számíttatják a fejlesztők, hiszen a processzormagok felépítése nem kedvező a komoly mértékű adatmennyiség párhuzamos feldolgozására. Ebből a szempontból nem látjuk az Intel elgondolásában a rációt. A felvázolt algoritmus – az elérhető minőséget leszámítva – kétségtelenül hatékonyabb feldolgozást jelent a Sandy Bridge, és talán még az AMD Fusion APU-k esetében is, de nagymértékben rontja a processzormagoktól logikai szinten távol elhelyezkedő dedikált GPU-k, illetve az AFR-re épülő SLI és CrossFire technológiák hatékonyságát. Az utóbbi mondatrész persze az Intelt bizonyosan nem érdekli.
Sajnos az előadáson belül nagyon kevés figyelmet kapott egy valóban értékelhető alternatíva, melyre már van az Intelnek példaprogramja is. Az Onloaded Shadows esetében a cascaded shadow map generálását a processzor végzi, és ez azon kevés esetek egyike, ahol tényleges előrelépés történhet a feldolgozásban. Bár egy dedikált GPU messze jobb teljesítményre képes itt is, de az IGP-k esetében már nem ilyen egyszerű a képlet. Az Intel algoritmusa könnyen implementálható, és szükség esetén aktiválható, vagyis az adott programon belül lehet dönteni a CPU-s és a GPU-s feldolgozás mellett is. Ezzel a fejlesztők az adott rendszerekhez a lehető legjobb megoldást választhatják. Ráadásul a minőség is megegyezik, vagyis kompromisszummentes elgondolásról van szó, melynek implementálása valóban előnyös lehet a felhasználóknak.
[+]
Az Intel részletesen kimért pár teljesítményadatot. A négy diagrammon a zöld csík jelenti a GPU-s eredményt, míg a kék az Onloaded algoritmus, ami a CPU segítségével van számolva. Látható, hogy a Sandy Bridge esetében az Onloaded elgondolás gyorsabb, hiszen a feldolgozás kevesebb időbe telik. A dedikált GPU-k esetében a GPU-s eredmény messze az Onloaded algoritmus előtt van. A másik két oszlop a distributed stall optimalizálás eredményeit tartalmazza. Ez egy általánosan bevethető eljárás, melyet azért szokás alkalmazni, hogy az árnyékok generálásánál elkerülhetőek legyenek a pár másodpercenként felmerülő sebességvesztések, melyek úgynevezett mikroakadás formájában jelennek meg, és egy játékra nyilván nem lennének túl jó hatással.
Az Intel az előadás során konklúzióként levonta, hogy a mai processzorok elég erősek ahhoz, hogy számos grafikai effektet átvegyenek a GPU-tól. Ezzel több szempontból sem tudunk egyetérteni. A Sandy Bridge esetében – és esetlegesen a Fusion APU-knál – bizonyosan nő az Intel megoldásaival sebesség, de ugyanakkor a dedikált GPU-k nagyon nem reagálnak jól arra, ha a jelenleg szükségesnél többször kell az adatokat másolgatni a lassú adatbuszokon keresztül. Ráadásul a képminőség a CPU-s post process megvalósítások mellett meg sem közelíti a GPU-s megvalósítások eredményét, ami szintén nem az az előrelépés, amire sokak várnak. Ugyanakkor kétségtelen, hogy az Onloaded Shadows alapötlete nagyszerű, és valóban jól alkalmazható lehet. Véleményünk szerint az Intelnek ebben az irányban kellene gondolkodnia, hiszen ilyen alapon a lightmap, vagy akár a Global Illumination effekt esetében is jól alkalmazható lenne egy onload eljárás, és nem mellesleg tényleges előrelépést jelentene az elgondolás.
