Hirdetés

  2. Fórumok
  3. Videokártyák
  4. AMD vs. INTEL vs. NVIDIA
Legfrissebb anyagok
PROHARDVER! témák
Mobilarena témák
IT café témák
GAMEPOD témák

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

  • #49375 Abu85 HÁZIGAZDA huskydog17 #49372
    Új Válasz #49375
    Ú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 huskydog17 #49372 üzenetére

    Nem kell átírni a motort, egy sornyi kódot nem szükséges beleírni, mert az UE5 gyárilag szállított megoldásokat kínál bizonyos problémákra. Csak az Epic nem tudja, hogy az egyes stúdiók milyen játékot csinálnak, tehát a stúdióknak kell megválasztani azt a paraméterezést, amivel jól fog működni az UE5.

    Például a PSO cache egy véleményes dolog. A funkciót az UE5 támogatja, de automatikusan nem aktív, mert nem mindig jó, ha az. Viszont, ha azt akarod, hogy aktív legyen, akkor az r.ShaderPipelineCache.Enabled=1 és r.ShaderPipelineCache.StartupMode=3 parancsokkal bekapcsolhatod, majd a PSO Collectorral szabályozni kell a begyűjtés módját, végül pedig a PipelineCacheToollal gyorsan betölthető formátumra lehet konvertálni a kódot.

    Ezt a procedúrát az Epic sosem fogja default engedélyezni, mert nem tudja, hogy mit fogsz csinálni az UE5-ben. Ha mindenre gyárilag engedélyeznék, akkor az iszonyatosan sok PSO kombinációt jelentene, ami akár több gigabájt is lehet. Nagyon extrém esetben több 10 GB is. Gondolj bele, hogy ezt milyen sok idő lenne legenerálni. Nemhogy kávézni mehetnél ki a játék indításakor, vagy minden driverfrissítéskor, hanem megfőzhetnéd a teljes heti menüt, és jó eséllyel még várnod kellene.

    Bónusz gond, hogy fejlesztés közben egy ilyen működésű motor nagyon sokat rontana a helyzeten, mert folyamatosan változik a tartalom. Gyakorlatilag mindig újra kellene generálni az egészet, ami jól kibaszna a kisebb fejlesztőkkel, mert fel kellene szerelkezniük 192 magos EPYC procikkal, hogy a fejlesztési idő 80%-a ne abból álljon, hogy várják a generálást.

    A legjobb módszer a fentiek miatt az, ha egyénileg meg tudja határozni a fejlesztő, hogy mit gyűjtsön be a rendszer, mert így minden szempontból optimális lehet az eredmény. És erre szánniuk kell némi időt az életükből, mert az Epic sosem fogja megcsinálni helyettük. Az Epic csak eszközt tud adni nekik arra, amivel optimalizálhatják a készülő játékot minden aspektusból.

    Az Epic nem tud mit kezdeni a köztudattal, ami összekapcsolja az UE5-öt a stutterrel. Nyilván elkezdhetik elmagyarázni az embereknek, hogy miért van default így beállítva az UE5, de az emberek döntő többségének halvány fingja sincs arról, hogy mi az a shader, így nem értenék meg a döntéseiket. Egyszerűen az egyes akadásokat a játékot fejlesztő stúdiónak kell kezelnie. Erre az Epic nem és sosem lesz képes, amíg a grafikus API-k működése olyan jellegű, amilyen.

    És elárulom neked, hogy az Epic foglalkozik nagyon is a problémával. Az ARM-tól tudom, hogy olyan intenzíven benne vannak egy univerzális megoldás keresésében, hogy nagyon kardoskodnak azért, hogy legyen egy egységes vISA a gyártók számára, ami lehetővé teheti a mostani bonyolult shader fordítási rendszer mellőzését, és konzolszerűvé válna az egész működési modell. És ebben egyébként a Qualcomm és a Samsung eléggé támogatja őket, méghozzá úgy, hogy hajlandók lennének a HSAIL-t default vISA-jukká tenni. Csak az a gond, hogy az AMD, az Intel és az NVIDIA meg nem. Ebben nyilván az AMD állásfoglalása a szép, mert ők ezt úgy utasítják vissza, hogy közben HSA tagok. :DDD Jó persze megértem, hogy miért ez most a hozzáállásuk, ők a Sony-val dolgoznak egy saját megoldáson, amit a többiek nem kapnak meg.

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