Előreláthatóan a Windows 8 - cal fog debütálni, a DirectX 11.1
2011. július 7. 22:50
Elégedettek a fejlesztők az aktuális DirectX 10 API-val, de némi finomhangolásra és hibajavításra szükség van.
A Computexen a Microsoft 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. Ez 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. Ez az adoptáció nagyon gyorsnak mondható, és jelenleg további hét olyan alkalmazás áll fejlesztés alatt, amelyek biztosan kihasználják a 11-es 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.
Elsődleges elvárás lesz 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.Ez 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. 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. 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.
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. 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 modellezni, 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. Alkalmazásuk 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á. Á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. Ezért 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.
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. Í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. De mindezt 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ó. 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.
Forrás:
Prohardver