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

• #38441 Abu85 HÁZIGAZDA atok666 #38439

  Új Válasz 2019-01-29 21:29:44 #38441

  Ú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 atok666 #38439 üzenetére

  Az allokációk lehetnek eltérő méretűek, de nem célszerű mondjuk nagyon kicsi allokációkat csinálni, mert eléggé eltérő az, ahogy az AMD, az Intel és az NV drivere kezeli a memóriát.

  DX12-ben (és Vulkan API-ban is) nem a nyers mennyiség határozza meg igazán a működést, hanem a memória strukturális felbontása:
  
  
  
  Na most egy olyan megoldás kell, ami jól működik a fenti három struktúrán belül. Tehát az nem elég jó, hogy működik AMD-vel, mert akkor az Intel és az NV szopni fog. Egy közös többszöröst kell keresni.

  Ha ez megvan, akkor ott a töredezettség problémája, vagyis vagy ugyanolyan méretű lesz minden allokáció, ami nem túl szerencsés, vagy végül a sok allokáció cseréje miatt fragmentált lesz a VRAM egy idő után. Tehát előfordulhat, hogy van szétszórtan 200 MB szabad hely, de nincs egybefüggően, tehát mindenképpen törölni kell egy allokációt, hogy egy új 200 MB-os beférjen.
  
  Itt láthatod, hogy ha azt a fekete allokációt a rendszermemóriából be akarod másolni a VRAM-ba, akkor egyszerűen nem tudod megtenni, mert nincs annyi egybefüggő szabad hely. Ki kell törölni mondjuk a pirosat és a zöldet. Ugye itt a HBCC is látható, ami lényegében azt valósítja meg, amit kvázi elgondolsz. Ne is másold az allokációt, hanem csak a szükséges lapjait. Mindegyik lap ugyanakkora, tehát a töredezettség kizárva, illetve mindig az van a memóriában, ami kell. De a jelenlegi API és WDDM kombinációja ezt a megoldást nem támogatja. Nem erre tervezték a rendszert. Meg lehetne oldani, viszont akkor nulláról kell kezdeni az egészet, vagyis új API, új display model, új meghajtók, új hardverek, új OS.

  (#38440) mormota79: Nem annyit használ, hanem jóval kevesebbet, de mivel a WDDM-et nem tervezték ilyenre, ezért az AMD meghajtója egy trükköt alkalmaz. Amikor bekapcsolod a HBCC-t, akkor keletkezik egy olyan erőforrás, aminek a fedélzeti memóriája megegyezik a beállított HBCC szegmenssel. Legyen az mondjuk 24 GB.
  
  Ilyenkor az OS felé és a programok felé az egész VGA úgy néz ki, mintha egy 24 GB VRAM-mal rendelkező hardver lenne. Ez alapvetően befolyásolja a programok által kiolvasott adatokat, hiszen a meghajtónak el kell rejtenie mindent, ami a háttérben történik ahhoz, hogy az OS felé gyakorlatilag tudjon hazudni a valós hardverről, amin fizikailag nincs 24 GB-nyi memória. Na most ezt még az AMD saját eszközei sem tudják mérni, mert nyilván hazudnia kell az adatokról a meghajtónak, hogy a háttérben a HBCC működhessen, és az AMD profilozói is ezeket a hazugságokat látják csak, ahogy például egy 3rd party program is csak ennyit tud elérni, plusz a Windows is csak ennyit lát. Egyébként létezik egy külön hardver, amit a fejlesztők igényelhetnek. Ez lehetővé teszi, hogy a HBCC mód valós működését kiolvashassák, de ehhez nem lehet hozzájutni átlagemberként. Szóval mi csak azt láthatjuk, amit a driver hazudik.

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