Dolgoznának ők az NV-vel, de nincs megfelelő fejlesztőkörnyezet hozzá. Nem tudom emlékszel-e arra, amikor az Epic váltott hardvert. Készültek a Vulkan API-ra való átállásra, és lecserélték a gépparkot Radeonokra, hogy elérhető legyen a RenderDoc+RGP. Aztán bevetették először az RGP-t, és rögtön találtak a kódban egy olyan bugot, ami még az első rajzolási parancs kiadása előtt 517 darab erőforrás-áthelyezést csinált, és ez tulajdonképpen egyenértékű a hardveren belüli gyorsítótárak 517-szer való egymás utáni ürítésével. Ez elég nagyot ment anno a Twitteren, hogy egy ilyen ordas nagy bugot nem vett észre az NV és az Intel profilozója. Egyszerűen nem látták, hogy a hardver ciklusok tömkelegét malmozza el. És ez minden GPU-t érintett, tehát lelassult a bugtól az Intel, az AMD és az NV saját rendszere is. Egy bugot viszont csak akkor lehet javítani, ha észre is veszed, tehát muszáj olyan profilozóra építened, ami ezeket a problémákat megmutatja. És abból, hogy az AMD-re áttért az Epic a Vulkanra váltás miatt, egy csomót sikerült gyorsítani az Intel és az NVIDIA GPU-in is, mert magának az engine-nek az egyes, esetenként komoly hibáit láthatóvá tette az RGP. És miután már látják a bugot, onnan már nem nehéz azt javítani.
A legtöbb hasonló bugot egyébként régen a konzolokon vették észre, de PC-n nem tudták kimutatni az RGP megjelenése előtt, mert nem volt meg az eszköz, ami látta volna őket. Persze gyanították, hogy ha a konzolon bugos a kód, akkor valószínűleg PC-n is az, csak ellenőrizni nem tudták. Az RGP óta PC-re is van nyomkövetést alkalmazó profilozó, ezért láthatók ezek a mélyen rejtett bugok.
(#47048) Kupszi: Itt nem arról van szó, hogy ki kivel szerződik. Attól, hogy az alap kódot az AMD-vel fejlesztették, még lehet egy rakás szerződést kötni az NV-vel is. De lényeges, hogy a motorok bugjait láthassák, főleg ezekkel az explicit API-kkal. Az Epic például még mindig az NVIDIA partnere, de egyszerűen a Vulkan API-ra jobb Radeonon fejleszteni. Pusztán ettől a döntéstől az NVIDIA hardverek is gyorsabbak lesznek. Ugyanígy az Ubisoftnak van szerződése az AMD-vel, az NV-vel és az Intellel is, viszont a Stadián fejlesztenek szinte mindent. Egyszerűen gyors és olcsó. De ettől még a Watch Dogs: Legion például NV-s, míg az Assassin's Creed Valhalla AMD-s cím lesz. Utóbbiak inkább üzleti döntések, mint technológiaiak, viszont az Ubi mindkét címet a Stadián fejleszti, ami egyszerűen hatékonyabb. Jobb terméket tudnak letenni az asztalra, mert utólag egy csomó mindent lehet optimalizálni, de a mélyen rejtett bugok nagyon fájnak ám, és minden gyártó számára.
(#47049) b. : Természetesen az NV is fejleszti a profilozóját, de azt a bugot, amit az RGP észrevett az UE4-ben, még mindig nem ismeri fel. De lényegesen előrébb járnak már annál, ahol jártak pár éve. Csak eközben az AMD meg csinált egy újabb megoldást, egy tipikus problémára, jelen esetben a memóriamenedzsment teljes profilozására. A legtöbb fejlesztő ma azt csinálja a memóriamenedzsment tekintetében, hogy letöltik a GitHUB-ról az AMD VMA-t vagy D3D12MA-t, és azt módosítgatják. Esetleg nem, az Ubisoft például csak bemásolja a VMA-t, és done. Ezt is lehet csinálni, csak ezeket az AMD nem teljesítménykritikusra tervezte, hanem sokkal inkább általános kompatibilitásra, hogy egyszerű legyen minden motorba integrálni, hogy csak úgy működjön. Viszont annyiféle hibalehetőség van a memóriamenedzsment tekintetében, hogy rohadt nehéz ám felkutatni a memóriaszivárgásokat, stb. Erre hozták a memóriaelemzőt, hogy ha valaki teljesítménykritikus kódban gondolkodik, akkor ne kelljen vakon dolgoznia. És ezek ugyanúgy hasznosak, az NV-nek is, mert a memóriaszivárgásra vonatkozó bugok jellemzően gyártófüggetlenek, minden terméket ugyanúgy érintenek, tehát ha az AMD-vel ki tudják szűrni, akkor az NV GPU-i is gyorsulnak tőle.
(#47050) Jack@l: A konzolokra már jó háromnegyed éve a konzolokon fejlesztenek. A végleges chipdizájnok gyártása is megindult már. Ugye a karácsonyi startra ezeket nagy mennyiségben kell szállítani a nyár végén.
Ha ez a memóriaelemző ilyen egyszerű lenne, de sajnos nem az.
[ Szerkesztve ]
