A DirectX 12-t a Microsoft az egyik legnagyobb sikertörténeteként értékeli, amire tulajdonképpen meg is van az okuk, hiszen a grafikus API-k területén egy igen jelentős paradigmaváltást vezényeltek le, lényegében komolyabb bakik nélkül. Ugyanezt azonban elmondták gyakorlatilag minden új DirectX verzióról, tehát a redmondi óriáscég véleménye ebben a kérdésben kevésbé releváns, a saját gyermekükről úgyis csak jót fognak nyilatkozni.
A fejlesztők nézőpontjából azonban vannak megosztó vélemények. Bár az explicit API-k mindenképpen szükségesek, hiszen az egy magra levetített teljesítmény nem igazán gyorsul, viszont a magok száma igen gyorsan nő a processzorokban. Ezt a helyzetet tehát kezelni kell, vagyis a DirectX 12, illetve a Vulkan API mindenképpen marad. Általános vélekedés azonban, hogy a DirectX 12 feleslegesen sok erőforrástípust különböztet meg, ami részben a korábbi verziók következménye, de egy ekkora váltásnál többen vártak volna egy nagyobb takarítást és egyszerűsítést. Hatalmas gondot ez igazából nem okoz, maximum a kódokat teszi csúnyává, de a rendszer ettől még működik, tehát együtt lehet élni vele.
Sokkal inkább problémát jelent az a szabadság, amit a DirectX 12 biztosít a memória manuális kezelése szempontjából. Ez nagyon érdekes helyzet, ugyanis az explicit API-kat pont a szabadság miatt hozták be, ugyanakkor utólag már tudni lehet, hogy a Microsoft nem igazán hallgatott meg minden véleményt. Mondhatni pár komoly szakember állt az irány mellé, és az AMD terveit lobogtatták, hogy az mennyivel jobb alapokat ad. Mára kiderült, hogy a Microsoft egy darabig ellenállt, de végül beadták a derekukat, amikor az AMD biztosította őket arról, hogy az általuk írt prototípus kódot felhasználhatják. Később pedig nem volt lehetőség a visszalépésre, ugyanis az AMD csinált magának egy Mantle API-t ugyanarra az alapra építve, ami gyakorlatilag kikényszerítette a DirectX 12 megjelenését.
Azt érdemes tudni, hogy egy API által biztosított szabadság nem baj, de csak addig, amíg a fejlesztők többsége ezt akarja. Ugyanakkor nagyon sok programozó számára a memóriaallokáció és az erőforrások kreálása bonyolultnak hathat a korábbi API-khoz viszonyítva, aminek nyilván meg van az oka, hiszen az egész alkalmazás működéséhez rengeteg olyan kódot kell a programba írni, amelyek önmagukban nem csinálnak semmit, csak rendszer munkáját segítik a különböző automatizálásokkal. A legnagyobb gondot a videomemória kezelése okozza. Például az az erőforrás nem kerül át automatikusan a rendszermemóriába, amelynek nem allokálható kellő mennyiségű memóriaterület a VRAM-ban, és azt is le kell kezelni, ha utóbbi memória betelik. A meghajtónak van még ebben valamekkora szerepe, de lényegében a fejlesztő dönt arról, hogy a GPU memóriája hogyan lesz allokálva, illetve kezelve. Ez különösen nehézkes egy streaming textúrázást megvalósító rendszer esetén, ugyanis ki kell dolgozni egy allokációs stratégiát, amelynek egyrészt minden eshetőségre reagálnia kell, másrészt hatékonynak is kell lennie, hiszen a programfuttatás sebességét döntően befolyásolja.
A legtöbb DirectX 12-es programban a nehézségeket úgy kezelik, hogy egy bizonyos mennyiségű VRAM alatt nem engednek pár paramétert aktiválni, gondolva itt a textúrák magasabb részletességére, vagy legalábbis figyelmeztet az alkalmazás, hogy nem fog jól működni a kiválasztott beállítás. Pedig ez régebben abszolút nem volt megszokott, elvégre a streaming textúrázás pont arra szolgál, hogy csak a legszükségesebb adatokat kelljen a GPU memóriájában tartani. Ezt azonban könnyebb mondani, mint megvalósítani, és tipikus jelenségnek számít, hogy az elviekben jónak tűnő allokációs stratégia dacára is igen nagy mennyiségű nem használt adat került a VRAM-ba. Persze ezen próbálnak javítani az érintett fejlesztők, de egy alkalmazást, különösen egy játékot nem fejlesztenek örökké, így pár hónappal a megjelenés után jön esetleg egy nagyobb frissítés, és jutottak ameddig jutottak alapon a komolyabb optimalizálásnak vége is.
Ez így nem hangzik túl jól a jövőre nézve. Már az is rémisztő lehet, hogy ennek az iránynak a legnagyobb promótere, vagyis az AMD is látja ugyanezt, és az új Vega generációban elérhetővé is tette a hardveresen működő, lapalapú vezérlést, amivel a hardver nem kényszerül rá a rosszul működő memóriamenedzsment futtatására. Bizonyos nézőpontból ez is egy megoldás, de semmiképpen sem ideális, mert jelenleg csak egy architektúrát érint.
A Microsoft szerencsére figyel. Bár egyelőre a cég a shader modell 6.0 bevezetésén fáradozik, ami meg is történik a Fall Creators frissítésben, viszont a háttérben már folyik a munka azzal kapcsolatban, hogy miképp lehetne a fejlesztők életét könnyebbé tenni a memória manuális kezelése szempontjából. Ami egyelőre biztos, hogy a DirectX 12 mindenképpen ilyen marad, túl sok pénz áll benne, és már túl sok aktuális, illetve készülő játék támogatja. Ez azonban nem jelenti azt, hogy nem lehet tenni a jobb jövő érdekében, és a jelenlegi tervek között egy függvénykönyvtár szerepel, ami beépíthető lenne akármelyik videojáték-motorba, így átvenné a memóriamenedzsmenttel járó feladatokat, illetve biztosítana egy megfelelő allokációs stratégiát.
Tulajdonképpen az egész arról szólna, hogy a Microsoft biztosítaná azokat a kódokat a fejlesztőknek, amelyek önmagukban továbbra sem csinálnak semmit, de alapvetően szükségesek a rendszer működéséhez. A programozók csupán függvényeket hívnának meg, ami jóval barátibb megközelítés lenne a számukra. Persze egy általános függvénykönyvtár valószínűleg nem lenne minden környezetben ideális, még sebességbajnok sem, viszont itt minden viszonyított. Amelyik fejlesztő ezt bevetné, valószínűleg önmagától csak rosszabbat tudna írni, tehát végeredményben mindenki jól járna. Egy ilyen konstrukció előnye még, hogy hardverfüggetlen, illetve lényegében a Microsoft biztosítaná a hardver oldali specifikus optimalizálásokat, de semmilyen rendszerkomponensen sem kellene változtatni, vagyis kompatibilis lenne az egész az aktuális meghajtókkal, illetve az API sem igényelne módosítást.
Arról sajnos nem tudtunk meg semmit, hogy ebből mikor lehet kézzel fogható megoldás. Egyelőre a tervezés zajlik, tehát a konkrét munka még nem kezdődött el, viszont igény bőven lenne rá, és a Microsoft a Fall Creators frissítéssel a tervezett nagyobb változások jelentős részét befejezi, tehát tudna rá erőforrást szakítani.
