A DX12 is ilyen. A Vulkan esetében két tényező van, ami fontos még. Az egyik, hogy jellemzően OpenGL-ről váltanak erre az API-ra, amibe nagyságrendekkel kevesebb erőforrást rak minden érintett a DX11-hez viszonyítva. A másik, hogy a Khronos sokkal inkább egy közös nevezőre tervezte az API kritikus részeit, ami jó például az NV-nek, illetve alapvetően mindenkinek. A Microsoft nem igazán foglalkozott ezzel, ami jó volt az Intelnek azt specifikálták és kész. Az részletkérdés volt, hogy helyenként ezzel az NV-nek kárt csinálnak, például a parancslistáknál vagy a root signature esetében. Az AMD-vel sem igazán foglalkoztak, nekik csak szerencséjük, hogy a GCN semmire sem kényes igazán, tehát az is jó, amit a Microsoft specifikál, és az is jó, amit más ajánl, teljesítményben nagyjából ugyanott lesznek.
A DX12-vel egyébként két tipikus késbe lehet futni. Az egyik a parancslisták helyzete. Ebből sok kicsi kell, hogy az NV-nek jó legyen a program, és az Intel, illetve az AMD meghajtója nem különösebben érzékeny erre, tehát nyugodtan lehet az NV ajánlásai szerint fejleszteni, az más kérdés, hogy ez a program oldalán nem kevés extra meló, tehát mondhatja a fejlesztő, hogy "baszki erre nincs időnk, hozzatok jobb hardvert". A másik tipikus gond a root signatures. Az NV azt szereti, ha buffer viewek közvetlenül ebben vannak, míg az Intelnek ez pont nem jó, és azt kedvelik, ha a Microsoft ajánlásai szerint ebben lehetőség szerint csak közvetetten vannak buffer viewek a leírótáblákon keresztül bekötve. Az AMD-nek pedig igazából mindegy, hasonló a teljesítmény így is, úgy is.
Egyébként annak oka van, hogy a Microsoft miért így alakította ki a specifikációt. A buffer viewek esetében azért nem ideális, ha közvetlenül a root signatures részei, mert a leírótábla vagy -halmaz mögött ezek állapotát manuálisan követni kell, így ha mondjuk új információ kerül beírásra, akkor tudni kell, hogy az olyan helyre kerüljön, amit a GPU már nem használ. A root signatures részeként ez a szabály nem érvényes, vagyis minden új információt a rendszer új memóriaterületre írja, meghagyva a régi adatot is, ugyanis nem kötelező érvényű, hogy egy leképező kiderítse, hogy az használatban van-e, és jellemzően nem is teszik meg, mert a root signatures részeként nem olcsó az eljárás. Ez viszont azt jelenti, hogy a memória folyamatosan telik meg a játék előrehaladtával, amire végeredményben nagyon nehéz alkalmazásoldali menedzsmentet írni, mert csak egy bizonyos időtávon belül lehet nagy biztonsággal meghatározni, hogy mi lesz a memóriában. Hosszabb távon viszont már jönnek a gondok, ami előhozza azokat a teljesítménykritikus jelenségeket, amelyek létezése a vezető indoka volt az explicit API-k megalkotásának. Szóval a buffer viewek helyzete marhára nem egyértelmű. Igen nyomós indokok vannak arra vonatkozóan, hogy miért nem jó az NV ajánlása. És igazából a mai memóriaárak mellett a brute force módszerben sem lehet bízni, hogy majd úgyis lesz 20-30 GB VRAM a VGA-n, amit tele lehetne pakolni szeméttel.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
de az tényleg nem gyenge, hogy egyegy játék (GR Wildlands pl.) képes közel 5Gb-nyi VRAM-ot fogyasztani ultra beállítások mellett FHD-ban.. A Crysis2-nek még elég volt kb. 1-1.5Gb. Persze fejlődött a grafika és a látvány ahhoz képest, csak nagyságrendileg nem annyit, mint a hardverek. Vagy tényleg ekkora extra erőforrások kellenek némi előrelépéshez a vizuális minőségben ?
