Legfrissebb anyagok

IT café témák

PROHARDVER! témák

Mobilarena témák

GAMEPOD.hu témák

LOGOUT.hu témák

Keresés

Új hozzászólás Aktív témák

#15 Abu85 HÁZIGAZDA Busterftw #14

Új Válasz 2020-02-18 16:27:52 #15
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

Abu85

HÁZIGAZDA

válasz Busterftw #14 üzenetére

Az NV-nek volt ezzel több gondja, de nem igazán a programkód miatt, hanem a strukturálás az oka:
AMD Vulkan memtype implementáció:
Memory type 0 Heapindex 0 Flags DEVICE_LOCAL_BIT Memory type 1 Heapindex 1 Flags HOST_VISIBLE_BIT HOST_COHERENT_BIT Memory type 2 Heapindex 2 Flags DEVICE_LOCAL_BIT HOST_VISIBLE_BIT HOST_COHERENT_BIT Memory type 3 Heapindex 1 Flags HOST_VISIBLE_BIT HOST_COHERENT_BIT HOST_CACHED_BIT
NVIDIA Vulkan memtype implementáció:
Memory type 0 Heapindex 1 Flags none Memory type 1 Heapindex 1 Flags none Memory type 2 Heapindex 1 Flags none Memory type 3 Heapindex 1 Flags none Memory type 4 Heapindex 1 Flags none Memory type 5 Heapindex 1 Flags none Memory type 6 Heapindex 1 Flags none Memory type 7 Heapindex 0 Flags DEVICE_LOCAL_BIT Memory type 8 Heapindex 0 Flags DEVICE_LOCAL_BIT Memory type 9 Heapindex 1 Flags HOST_VISIBLE_BIT HOST_COHERENT_BIT Memory type 10 Heapindex 1 Flags HOST_VISIBLE_BIT HOST_COHERENT_BIT HOST_CACHED_BIT
Nem véletlen, hogy az NV hozott gyorsan egy extra kiterjesztést a Vulkan API-ba, hogy egyáltalán működtetni lehessen a hardvereiket. Ebből mára szabvány lett, de erre nem lenne szükség, ha az NV nem így strukturálná a hardvereit. A DirectX 12-n is vannak hasonló problémák, csak arra nem ajánlott működés módok használatát javasolja az NV. Például a buffer viewek direkt bekötését a root signature-be. A Microsoft pedig legalább ennyiszer elmondja, hogy ezt nem szabad csinálni, mert az API nincs erre felkészítve. A legtöbb memóriamenedzsmentre visszavezethető gond abból ered, hogy a fejlesztő megpróbálja az összes hardvert valahogy lefedni, de eközben az eltérő strukturálás miatt nem ajánlott műveletekre kényszerülnek, ami például leakhez vezet. Ezekre eddig az volt a tipikus megoldás, hogy be kellett építeni az AMD headerjeit, amik csak úgy működtek a konkurens hardvereken is, de ezek általános megoldások, teljesítménycentrikus motorba nem igazán jók. Ezért jön egy új eszköz, ami megmondja a fejlesztőknek, hogy hol a hiba a kódban, ami például leakhez vezet. És innentől egyszerűbb lesz a különböző struktúrákra is optimalizálni, akár nem ajánlott műveletekkel is, mert megmondja a program, hogy mi okozza például a leaket. Ez az AMD-nek is jó, mert jobb lesz a végleges program, illetve az NV-nek is, mert nekik sem olyan jó ám az, ha mondjuk akadozik a DX12 mód, vagy a DX11-hez képest lassabb a sebessége.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
#19 andy19770128 aktív tag Busterftw #14

Új Válasz 2020-02-19 14:39:02 #19
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

andy19770128

aktív tag

válasz Busterftw #14 üzenetére

valóban lassabb. Fhd van. 4 K alatt viszont más a szitu. Csak úgy jászom. rengeteg játéknak ultrák kell a 12- 14 GB 4 alatt