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

• #26515 Abu85 HÁZIGAZDA HSM #26512

  Új Válasz 2017-02-18 14:21:11 #26515

  Ú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 HSM #26512 üzenetére

  Ha lenne rá idő, akkor eleve nem létezne maga a probléma, mert időközönként át lehetne menni a teljes allokáción és meghatározni, hogy mi kell belőle és mi nem. Amiért ezt nem teszik meg PC-n a fejlesztők az az, hogy egyáltalán nem ingyenes maga az ellenőrzés, illetve a törlés utáni defragmentació sem kézenfekvő. Egyszerűen, ha ezt megcsinálnák, akkor iszonyatos mertekben csökkenne a VRAM-igény, de lenne is az ellenőrzésekkor és a defragmentlciókor úgy jó negyed másodperces akadás. Tehát nem éri meg élni ezzel. A hardveres menedzsment ezeket on-the-fly csinálja mindenféle lassítás nélkül.

  Egy mai modern memóriamenedzsment eleve olyan, hogy a program addig allokál új területet, ameddig van szabad memória. Ezen belül ma tipikusan bevett szokás a szabad kapacitás feléig a beállított mérettel dolgozni, majd utána kisebb felbontású textúrákat betölteni. Ezzel húzzák az időt, ugyanis így később telik be a VRAM. De ha betelik, akkor jön a törlés LRU alapon. Ilyenkor azért mindenképpen fájni fog a dolog, tehát a legtöbb alkalmazás úgy van kialakítva, hogy akkor töröljön egyszerre sokat, hogy a következő kritikus törlés minél később következzen be.
  A hardveres on-the-fly tud menedzselni, tehát egyrészt jóval több memória áll rendelkezésre a potenciálisan szükséges adatok betöltésére, másrészt sosem következik be a kritikus törlés problémája, mert nem várja meg a rendszer, hogy elmenjen a programfuttatás a hatáig. Emiatt radikálisán megritkul a lag lehetősége.

  [ 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