Az Intel még márciusban jelentette be, hogy kidolgozták a PixelSync és az InstantAccess funkciókat, melyeket a Haswell Gen7.5-ös architektúrára épülő IGP-je kezeli, de a DirectX kiterjesztésrendszerével ezek támogatása a konkurencia által igen nehézkes. A vállalat azonban nem zárkózik el a szabványosítás elől, és erről Richard Huddy nyilatkozott is a PC Games Hardware számára.
Az Intel szóvivője általánosan beszélt a szabványos kód lehetőségéről, mely a PC-s piac számára igen kedvező lenne. Elsősorban az Intel InstantAccess funkció került középpontba, mely zömében megegyezik az AMD Zero Copy szolgáltatásával. Richard Huddy elmondta, hogy a két technológia között igen kevés eltérés van, így erre a következő DirectX-ben akár lehetne egy szabványos opciót is kínálni. Ezt az Intel Haswell, valamint az AMD Zacate, Ontario, Hondo, Llano, Trinity, Richland, Temash és Kabini kódnevű APU-k támogathatják, vagyis lényegében azok a hardverek, amelyek kezelik az InstantAccess, illetve a Zero Copy funkciót, ideértve persze a jövőben megjelenő Intel és AMD APU-kat is. Egy ilyen szabványosításban minden bizonnyal az AMD is benne lenne, hiszen az alapvetően jó mindenki számára, ha a játékfejlesztőknek nem szükséges két, lényegében megegyező funkciót eltérő kóddal támogatni.
A PixelSync kiterjesztést a GRID 2 kapcsán részletesen elemeztük. Igazából egy igen széleskörű fejlesztői igényről van szó, hiszen a jellemzően alkalmazott ODT (Order Dependent Transparency, azaz sorrendtől függő átlátszóság) helyett az OIT (Order Independent Transparency, azaz sorrendtől független átlátszóság) használata lenne célszerű. Alapvető újdonságról nincs szó, mivel évek óta foglalkoztatja a fejlesztőket, hogy miképp tudnák áttörni az ODT szabta korlátokat. Ebből a szempontból a DirectX 11 hozta az áttörést, melyre az AMD nagyjából három és fél éve elkészített egy olyan OIT implementációt, mely a fejlesztők problémáit teljesen megoldja. A gond csupán annyi, hogy mindezt igen nagy teljesítményigény mellett teszi, tehát elvi szinten rendben van, hogy a létezik megoldás a gondokra, de nem lehet csak erre építeni, mivel elég erős VGA szükséges az algoritmus megfelelő sebességű futtatásához. Például a Tomb Raider című játék a TressFX leképzéséhez az AMD OIT implementációját használja, és ez hozzájárul ahhoz, hogy igencsak lecsökken a sebesség a hajszimuláció bekapcsolása után.
A nem szabványos Intel PixelSync tulajdonképpen képes ugyanarra, mint az AMD szabványos OIT megoldása, csak sokkal gyorsabban, hiszen nagyjából 10%-os a sebességvesztés, ami bőven vállalható szinte mindegyik hardveren. Ennek köszönhetően a fejlesztők el is hagyhatják az ODT-t, hiszen nem kell figyelni arra, hogy a gyengébb hardverekben nincs elég számítási kapacitás az AMD OIT implementációjának futtatásához. Ha ebből lenne egy szabványos DirectX technika, akkor az igen sokat segítene minden fejlesztőnek. Ráadásul úgy néz ki, hogy a modernebb architektúrákra épülő hardvereken is megoldható a PixelSync, vagy egy nagyon hasonló elvű eljárás támogatása.
Leképzés ODT és OIT mellett. Megfelelő trükkök és odafigyelés nélkül az ODT-vel készült eredmény teljesen hibás. [+]
Az OIT-t mint igényt egyébként sok felhasználó lebecsüli, hiszen nincs egzakt előnye a mai játékok képminőségére nézve. Ennek azonban elsősorban az az oka, hogy a mai programok grafikai dizájnját úgy építik fel, hogy az ODT szabta korlátokon belül is jól működjön. Ez elsősorban tehát a művészek feladata, viszont éppen elég frusztráló a tudat a programozóknak, hogy a művészeket korlátok közé szorítják. Johan Andersson, a Frostbite motorok atyja korábban már elmondta, hogy az ODT jelenti az egyik legnagyobb limitációt a grafika továbbfejlesztése szempontjából. A DirectX-ben és a hasonló elven dolgozó többi API-ban egyszerűen nem működik jól az a helyzet, ha egy ablak mögött esetleg még egy ablak található, vagy akár több is. Rengeteg trükköt kell bevetni, hogy egy elfogadható eredményt kapjon a felhasználó, de még ez sem lesz mentes a leképzési hibáktól.
Az OIT bevezetése tehát alapvető szempont. Ha más nem, akkor az AMD szabványos implementációja is megteszi, hiszen már az IGP-k számítási teljesítménye is elég nagy, viszont a memóriahasználat ennél a rendszernél sok gondot okozhat. Például a Tomb Raiderben a TressFX leképzése nagyjából 200-300 MB-nyi memóriaterületet használ (függően a felbontástól). A DirectX következő frissítésében mindenképp olyan OIT megoldásra lenne szükség, ami gyors, kevés memóriát használ, illetve lehetőség szerint kompatibilis az aktuális hardverekkel.
Érdekesség egyébként, hogy az Intel a GRID 2 szempontjából reagált arra is, hogy a PixelSynchez nem szükséges az Iris Pro Graphics 5200, viszont azt a játékfejlesztő eldöntheti, hogy mely hardvereken engedélyez egy-egy effektet. Ezzel kapcsolatban furcsa változás, hogy a GRID 2 új verzióiban már nem csak a legerősebb Haswell IGP-n működik a smoke shadow effekt.
