Keresés

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

  • Jack@l

    veterán

    válasz letepem #26201 üzenetére

    Most amd kiatlálta hogy neked kell az ssd a videokártyára, csak azt felejtette el mondani hogy játékokban kb semmivel se lesz jobb mintha normál ssd-re irogatná (jellemzően pálya betöltéskor) a temporális cuccokat.
    HPC-hez kellhet, spéci compute alkalmazásokhoz, hogy a végeredményt gyorsabban helyben eltárolják.

    Én se láttam még kevesebb vramot használó dx12es játékot, pedig direkt a fejlesztők kérték a memória menedzsmentet...

    [ Szerkesztve ]

    A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.

  • Abu85

    HÁZIGAZDA

    válasz letepem #26201 üzenetére

    Nagyon leegyszerűsítve azért kevés a VRAM, ha kevés persze, mert nincs elég idejük a fejlesztőknek normálisan kialakítani egy hatékony menedzsmentet. DX11-ben azért, mert nem rajtuk múlik, DX12-ben pedig azért, mert minden rajtuk múlik, és így már túl bonyolult. A konzol az teljesen más tészta. Ott konkrétan az van, hogy a fejlesztőnek van adva x (5-6 tökmindegy) GB memória és ahhoz hozzá nem nyúl az OS, driver, semmi. Ez egy nagyon egyszerű modell így, mert van egy fix géped, fix képességekkel, és csak arra kell dolgozni. Még ha a gépek számát kettőre emelik, akkor is bőven jó.

    A PC teljesen más, mert milliónyi konfiguráció van, tehát nem tudsz egy fix konfigot kiválasztani, amire szénné optimalizálod a programot, arról nem is beszélve, hogy az OS/UMD meg sem engedi, hogy egy alkalmazásnak teljes kontrollja legyen az allokáció felett. Itt bonyolódik nagyon a dolog, és ezen a ponton veszik oda egy rakás erőforrás.
    A PC-ben is kínálnak a gyártók különböző szabványon kívüli extrákat, hogy valamit, amit a konzolon ki lehet használni, azt PC-n is ki lehessen, de ezek beépítése mind idő, azután az így keletkező speciális kódot is karban kell tartani, tehát végeredményben, ha ezt megcsinálja egy fejlesztő mondjuk mindegyik gyártó legújabb architektúráira, akkor persze javul a program futtatásának hatékonysága, de végeredményben lesz egy rakás gyártó-, sőt hardverspecifikus optimalizálása, aminek a karbantartása rohadt drága lesz, tehát bármennyire is jó ötletnek tűnt az elején, mondjuk egy év után már a háta közepére kívánja a fejlesztő az egészet, amikor dobja össze az utolsó frissítést. És ez anyagilag sem kellemes ám. Főleg amiatt, hogy a gyártók leszólhatnak, hogy "fugyimá, csinálunk némi módosítást a meghajtóban, és a ti kódotok már nem lesz kompatibilis, írjátok má át eszerint, köszi-puszi".

    Végeredményben mindig oda lyukad ki az ipar, hogy vagy legyen egy működő szabvány, vagy ha ez bizonyos dolgokra nehezen megvalósítható, akkor legyen egy hardveres megoldás.

    A Vega a legtöbb programban eleve ebben a legacy módban fog működni. A hardveres lapmenedzsmenthez kellenek eszközök, hogy kihasznált, elsődlegesen API-k, vagy API módosítások. Esetleg API interoperability. Utóbbi a legvalószínűbb, tehát DX12-Mantle és Vulkan-Mantle. Ezzel a programod szabványos maradhat, miközben ki lehet használni a hardveres lapmenedzsmentet a Vegán. Most is van ilyen modulja az AMD-nek, ami a LiquidVR. Az is DX11-Mantle interoperability-vel működik.
    Szóval, ha nem használod ezt a képességet, akkor a HBM2 egy sima VRAM lesz. Ha viszont használod, akkor már az új konstrukció is bevethető.

    A VRAM törléssel az a gond, hogy DX11-ben nagyon drága művelet. DX12 és Vulkan alatt ez már kedvezőbb, de kevés a tapasztalat arról, hogy mikor mi az ideális feldolgozási modell. Itt már meg lehet oldani egy relatíve hatékony rendszert, de biztosan jóval tovább tart a kifejlesztése, mint szimplán rábízni a hardverre az egész problémát.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

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