2. Fórumok
  3. Videokártyák
  4. Készül a DirectSR API-val a Microsoft
Keresés

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

  • #22 Abu85 HÁZIGAZDA Yutani #21
    Új Válasz #22
    Ú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 Yutani #21 üzenetére

    De a CPU a szűkös jelenleg. Ezért készült el a GPU Work Graphs.

    Ezt nem lehet majd kikapcsolni. Ha futtatható a hardveren, akkor ezzel megy, ha pedig nem, akkor a fallback kóddal. A kikapcsolás azért sem ajánlott, mert bizonyos funkciók eleve igénylik a GPU Work Graphs használatát. Például az UE5 Nanite legnagyobb baja, hogy nem működik stabilan a régi modellel, és a GPU Work Graphs az, ami meghozza a motorba a stabilitást, vagyis nem fog esetenként lefagyni maga a motor, mert nem kényszerül a Nanite API-ban nem engedélyezett művelet végrehajtására.

    Ez egy nagyon kritikus lépés, mert az ilyen Nanite szerű rendszerekkel rég túlléptük az ExecuteIndirect korlátjait, és kb. stabilra rakható csak össze a kód. Vagy a másik lehetőség a rém lassú kód, amit senki sem akar. Sokkal jobb, ha dobjuk az ExecuteIndirectet.

  • #20 Abu85 HÁZIGAZDA Yutani #19
    Új Válasz #20
    Ú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 Yutani #19 üzenetére

    A GPU Work Graphs nem a VGA-n segít, hanem a CPU-ról veszi le a terhet. Cserébe több VRAM-ot kér, mint az ExecuteIndirect. Ez egy kompromisszum. És olyan kompromisszum, amit most érdemes meglépni, mert olcsóbbá kezdenek válni a 12-16 GB-os VGA-k. De a több VRAM-ra vonatkozó igény egyébként kezelhető úgy, hogy a 8 GB-os VGA-kon a textúrarészletességet limitálják a fejlesztők. Ez konkrétan egy ajánlása a Microsoftnak, hogy ha a GPU Work Graphs aktív, akkor ügyeljenek arra, hogy beférjen az extra adat a VRAM-ba, és ez 8 GB-os VGA-knál úgy a legkönnyebb, ha gyárilag lowra korlátozzák a textúrákat.

    Ha a fejlesztők a Microsoft ajánlásait követik, akkor nem a sebesség lesz itt a kérdés, hanem az, hogy egyáltalán milyen grafikai minőséget állíthatsz be, és leginkább ez attól függ, hogy van-e elég sok VRAM-od, hogy a program korlátozásait elkerüld.

  • #18 Abu85 HÁZIGAZDA Yutani #2
    Új Válasz #18
    Ú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 Yutani #2 üzenetére

    A GPU Work Graphs követelményekkel rendelkező funkció. Nem fog minden egyes hardveren tökéletesen működni. Olyan kell, amit eléggé erre szabtak a parancsmotor szintjén.

    Itt egyébként két vezető irányzat volt a Microsoftnál. Az egyik az NV-nek a hasonló rendszere, a másik pedig az AMD-é. Végül az AMD megoldását emelték szabványba, mert az alapból kompatibilis az API összes meglévő funkciójával. Az NV megoldásához olyan változások kellenek, ami az API működését befolyásolja, és át kellene írni hozzá az alapokat is. Azt egyelőre a Microsoft nem vállalta be. Emellett az AMD megoldása is kiegészíthető úgy, ahogy az NV adta volna a sajátját, ha majd a Microsoft úgy döntene, hogy nyomnak egy resetet.

    A fentieken túl fontos, hogy a GPU Work Graphs extra VRAM-ot igényel. Esetenként nem is keveset. Tehát a CPU tehermentesítése nincs ingyen, csak a CPU-időt beváltod több VRAM-terhelésre. De jelenleg jóval több VRAM-od van, mint szabadon használható CPU-időd, hiszen már 330-ért 16 GB-os VGA-t vehetsz. Tehát most már a GPU Work Graphs hasznos, és válthatja az ExecuteIndirect funkciót. Régen ez azért nem feltétlen volt ennyire egyértelmű, mert nem volt 330-ért 16 GB-os VGA a boltokban.

    Egyébként GPU Work Graphs lényege, hogy gyorsítson, és ez minden olyan hardveren megtörténik, ami támogatja. Az extra sebesség mértéke a kérdés. Tehát ezzel rosszul nem jár egyik gyártó sem, azért is van mögötte támogatás.

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