A Microsoft a Computexen részletesen beszélt az érkező Windows 8-ról, de ügyeltek arra, hogy túlzottan sok adat ne derüljön ki. Ettől függetlenül a vállalat partnerei már megkapták az új operációs rendszer első verzióit, mely ugyan messze van a végleges állapottól, de a képességekkel kapcsolatos szivárogtatás már elkezdődött. A legfrissebb hírek szerint a Windows 8-ban a DirectX 11.1 is debütál, mely alapjaiban a kedvelt 11-es verzióra épül majd.

A DirectX 11 a Windows 7-ben került bevetésre még 2009 októberében. Azóta már 22 darab játékprogram használja a rendszer előnyeit, vagyis az adaptáció nagyon gyorsnak mondható, és jelenleg további hét olyan alkalmazás áll fejlesztés alatt, amelyek biztosan kihasználják az API képességeit. A DirectX 11 azonban kétségtelen, hogy nem tökéletes, így számos ponton szorul némi finomhangolásra. Sajnos a változásokról nincs pontos információ, de a fejlesztők az elmúlt hónapokban megtartott, valós idejű grafikai feldolgozással foglalkozó rendezvényeken vázolták a jelenlegi futószalaggal kapcsolatos problémáikat.

Az elsődleges elvárás a jelenlegi, erőforrás-pazarló tesszellációs futószalag átdolgozása. A DirectX 11 egy úgynevezett NoSplit megvalósítást használ, ami tulajdonképpen az AMD (ATI) Xenos rendszerének az öröksége. A Microsoft lényegében ugyanazokat az alapokat vette át, amelyek az Xbox 360-as konzolban működnek. A probléma azonban az, hogy az ATI a Xenos tesszellációs futószalagját nem a mikropoligonok gyors feldolgozására dolgozta ki, mivel az Xbox 360 esetében főleg az volt a követelmény, hogy a konzol szűkös rendszermemóriáját ne terheljék le a magas poligonszámú, sok helyet foglaló modellek. A PC-n azonban a fejlesztők számára a rendszermemória mennyisége nem limitált, így a DirectX 11 esetében a mikropoligonok feldolgozását kellett előtérbe helyezni. Ez természetesen lehetséges a Xenos tesszellációs rendszerével is, de rengeteg illesztési hibát generál, és borzasztóan alacsony az elérhető teljesítménye. A két problémát tulajdonképpen egy lapon érdemes említeni, ugyanis a Xenos tesszelláció az illesztési hibákat adaptív, vagy más néven nézőpontfüggő tesszellálás mellett hozza elő. Az egyes felületek különböző tesszellációs normái törést eredményeznek a modellen, amit az alábbi kép részletez.

Az adaptív tesszelláció illesztési törései [+]

A modell pirosra festett részei az illesztési hibákat jelzik, amelyeket az adaptív tesszelláció hozott elő. Ezek ki is vannak nagyítva, hogy látszódjon a lényeg, azaz a felület helyenként úgymond szétnyílik. Ebből látható, hogy a fejlesztők, miért próbálják kerülni a nézőpontfüggő tesszellálást, ugyanis a DirectX 11-es futószalagon belül semmilyen megoldás nem létezik az illesztési problémák korrigálására. Egyszerűen lehetetlen egy modellt úgy elkészíteni, hogy az bármilyen nézőpontból jól nézzen ki, tesszellálás nélküli és tesszellált kivitelben is. Éppen ezért a legtöbbször a fejlesztők minden felületre ugyanazokat a tesszellálási normákat alkalmazzák, ami viszont komolyan korlátozza a feldolgozás sebességét. Ezen a ponton kerül előtérbe a túltesszellálás fogalma, amikor olyan pici egy háromszög, hogy nem lehet hatékony raszterizálást alkalmazni rá. Korábban már írtunk arról, hogy általánosan elfogadott az a szabály, ami kimondja, hogy a képen megjelenő legkisebb háromszög is legyen minimum 16 pixel kiterjedésű, mivel így a raszterizálás jó eséllyel 90%-os hatékonyság fölött marad. A kisebb háromszögek alkalmazása már jelentősen ront a teljesítményen, így a négyes pixelblokkokon dolgozó grafikus processzorok rengeteg felesleges munkát végezhetnek.

A DirectX 11-ben alkalmazott NoSplit megvalósítás tehát nem a legjobb, így keresni kell valami hatékonyabb módszert. A lehetséges opciók között a BinSplit, az IsoSplit és a DiagSplit említhető (az utóbbi két metódus az adaptív tesszellálás illesztési hibáit is képes korrigálni). Ezekről több tanulmány is készült, és az alábbi kép tudja a legjobban szemléltetni a különbségeket.

A jelenlegi tesszellálási metódusok különbségei [+]

A kép elsőre bonyolultnak tűnik, de nagyon egyszerű értelmezni a lényeget. Az alsó, színes csík jelzi a tesszelláció minőségét, vagyis azt, hogy az adott felület alul, vagy túl van tesszellálva. Egyik opció sem jó, mivel vagy rossz lesz a minőség, vagy túlságosan sok lesz az erőforrásigény. A cél, hogy minden felület úgymond zöld legyen, ami a legjobb állapot a végső minőség szempontjából. Felmerülhet a kérdés, hogy miért nem előnyös a kisebb háromszögek alkalmazása, ha megvan hozzá a hardver teljesítménye. Erre a válasz egyszerű. A képernyőn az információk pixelek formájában jelennek meg, és a pixel színét lényegében a felületre húzott textúra határozza meg. A 16 pixeles háromszögek olyan picinek számítanak, hogy a felület kisebb háromszögekre való felbontása nem, vagy csak nagyon kis mértékben befolyásolja a pixelek színét, mivel a textúra pozíciója nem, vagy csak alig módosul. Éppen ezért a képpontok szintjén mért minőségben a 16 pixelnél kisebb háromszögek nem jelentenek érdemi előrelépést.

A mikropoligon render esetében tehát az a cél, hogy minden felületen biztosítva legyen a 16 pixeles háromszögméret. A fenti képen a zöldre színezett felületek jelentik azt, amikor ez teljesül, míg a sárguló/pirosló részek túltesszellálást, a kékülő felületek pedig az alultesszellálást jelölik. Látható, hogy a DirectX 11 futószalagja több teszt alkalmával kifogásolható minőséget ad, míg a DiagSplit metódus esetében az eredmények közel állnak a tökéleteshez. Egyedül a ZonePlate teszt alatt érzékelhető túltesszellálás, de ezt a feladatot a többi megvalósítás rendre alultesszellálja, így ez még belefér.

A quad-fragment merging hatékonysága [+]

A dizájn szempontjából persze a 16 pixeles háromszögeket igénylő szabályt nagyon nehéz követni, így érdemes hatékonnyá tenni raszterizálást kisebb háromszögméret mellett is. Erre a quad-fragment merging eljárás jelentheti a megoldást. Az elgondolás lényege, hogy a négyes pixelblokkokon dolgozó grafikus processzorok kevesebb felesleges ellenőrzést hajtsanak végre a háromszögek vizsgálatánál. Ehhez nem egy, hanem egyszerre négy, egymáshoz kapcsolódó háromszög lesz egyszerre vizsgálva a négyes pixelblokkokon blokkokon belül. Ezzel még mindig nincs megkímélve a hardver a felesleges számításoktól, de a grafikonon látható, hogy jelentős az előrelépés az összevonás nélküli megvalósításhoz képest, és a képminőségben sem vehető észre minőségromlás.

A quad-fragment merging minősége a hagyományos raszterizáláshoz viszonyítva [+]

A felújított API fejlesztése szempontjából szintén kritikus rész, hogy a fejlesztők alacsonyabb szinten érjék el a grafikus processzorokat, hiszen így növelni lehet a kiadható rajzolási parancsok számát. Ebből a szempontból a konzolok nagyon elhúztak a PC-s API-k képességeitől, ami annak köszönhető, hogy a fejlesztők a fix hardverkonfigurációnak hála direkten kezelhetik a parancspuffert. Bár az API állandóan limitálni fogja a teljesítményt, valahogy megoldást kell találni arra, hogy PC-n a rajzolási parancsok száma 15 000 fölött lehessen, anélkül, hogy a sebesség másodpercenként 60 képkocka alá esne. Ez persze még mindig nem az a szint, amit a konzolok tudnak, de a parancspuffer direkt kezelése PC-n kizárható, hiszen a programokat API-n keresztül kell írni a kompatibilitás megőrzése érdekében. Az NVIDIA korábban kidolgozott az OpenGL felületre egy bindless kiterjesztést, ami direktebb kontrollt biztosít a rajzolási parancsok számára, ugyanakkor eddig még egy játék sem használta, mivel az implementálás a fejlesztők szerint túl sok időt venne igénybe. Ettől függetlenül a Microsoftnak egy hasonló, egyszerűbben kezelhető megvalósítás megfontolandó alternatíva lehet.

Továbbra is kihangsúlyozzuk, hogy a fentebb részletezet újítások nem biztos, hogy bekerülnek a DirectX 11.1-be, csupán azt szerettük volna vázolni, hogy a fejlesztők alapvetően mely területeken várnak előrelépést. Amennyiben mindez megvalósul, igazán elégedettek lehetünk majd az új felülettel.