Keresés

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

  • Abu85

    HÁZIGAZDA

    válasz Jack@l #195 üzenetére

    Igazából az NV beszélt először magáról az alapproblémáról még az előző évtizedben. Az alapvető kutatások valószínűleg elkezdődtek már úgy 2007 környékén. És ez mindkét gyártóra igaz lehetett, hiszen a Vega és a Volta támogat eszközszintű, lapalapú memóriamenedzsmentet a kompatibilis host processzorok és host interfészek mellett.
    A korábbi megoldások zárt API-khoz voltak kötve, tehát az elterjedt API-kkal üzemképtelenek voltak. De hardveres támogatás mellett már az API is lényegtelen, egyedül a beépített technológia hardveres követelményeit kell teljesíteni a működéshez.

  • GodGamer5

    addikt

    válasz Jack@l #149 üzenetére

    A konzoloknál is hbcc-jellegű memóriamenedzsment/kihasználtság van és nagyon jó a hatásfokuk 8giga rammal is, -sőt régebben még töredékével is megoldották a ps3-as időkben.

  • Abu85

    HÁZIGAZDA

    válasz Jack@l #122 üzenetére

    Minden ismert róla csak el kell olvasni.

    Mivel a HBCC eszközszintű menedzsment, így az API mindegy számára. A működése jóval az API absztrakciós szintje alatt valósul meg. Ez az oka annak, hogy a HBCC-s működését nem hátráltatja a rosszul megírt programkód, mert a menedzsment függetlenített a programtól.

    (#123) do3om: Ez nem pont a sávszéllel gazdálkodik. Van hatása rá (lásd, amit írt Gbors), de közvetlenül nem ez a célja. A HBCC alapvető feladata, hogy a lokális memóriába kerülő lapok mindegyike igényelt legyen, amivel a memóriában lévő adatok 100%-a hasznos adat lesz. A korábbi modellben nem lapalapú a menedzsment, így az allokációkat másolgatásával rengeteg olyan adat került be a lokális memóriába, amelyekre nem volt szüksége a GPU-nak, de a menedzsment nem volt elég alacsony szintű ahhoz, hogy ezt a problémát meg lehessen oldani. A lapalapú megoldásokhoz mindenképpen hardveres háttér szükséges, míg az allokációk menedzseléséhez elég a szoftveres.
    Ez egész alapjára gondolj úgy, mint a CPU-k gyorsítótárára. A koncepcionális alap nagyon hasonló. Alapvetően itt is érvényes a lokalitási elv, csak a feldolgozás mérete miatt jóval nagyobb határok mellett. De ezért van a hardveren GB-os és nem MB-os "gyorsítótár".

    (#125) gbors: A HBCC szegmensre nem érdemes úgy tekinteni, hogy extra memóriát igényel a rendszermemória oldalán. Ez gyakori tévedés. Induljunk ki az alapértelmezett Vega 10 minimumból. Az 8 GB a kártyán és 4 GB a rendszermemóriában egy 8 GB-os RAM-konfigurációval. Ilyenkor exkluzív cache mód mellett az történik, hogy a meghajtó az operációs rendszert tájékoztatja, hogy a memória felét befogta HBCC szegmensnek. Erről az operációs rendszer tudomást szerez és kap rá egy címtartományt x-től y-ig, ami pont a memória fele. Ezzel lesz 4 GB-nyi rendszermemória azoknak az adatoknak, amelyeket csak a CPU láthat, viszont a játékok igényelni fognak egy olyan szeletet is a rendszermemóriából, amelyet a CPU és a GPU egyaránt elérhet. A HBCC szegmensnél a kijelölt 4 GB használható erre a célra, míg HBCC szegmens nélkül akárhol lehet ez a tartomány. Végeredményben viszont nem lesz több rendszermemória felhasználva, csupán a CPU+GPU által elérhető terület van előre meghatározva a HBCC szegmensnél. Erre viszont HBCC szegmens nélkül is szükség van, csak nem lesz előre meghatározott fizikai címtartomány hozzá. Az adatok viszont akkor is ott lesznek a memóriában. Ha bekapcsolod a HBCC-t a driverben, akkor ugyanúgy megmarad a 8 GB-nyi rendszermemóriád. Még úgy is aktiválni lehet, hogy például egy 7 GB-ot lezabáló CPU-s program éppen fut. Elsötétül a képernyő, visszajön, és fut tovább a program. Egyedül a GPU-t inicializáló programokat kell kilőni, mert a HBCC aktiválásához újra be kell tölteni a drivert, így ezeket a programokat a rendszer lelövi. Gyakorlatilag egy TDR-rel kiszállnak.

    (#129) LionW: Eléggé esélyes igen. A hardver szintjén ez a megoldás nem drága, szóval nincs értelme kihagyni a kis VGA-kból, amelyek a legtöbbet profitálnak belőle.

  • ->Raizen<-

    veterán

    válasz Jack@l #122 üzenetére

    Hbcc nem a teljesitmeny novelesere lett kifejlesztve hanem arra, hogy a v-ram ki legyen hasznalva, es a mikro akadasok durva kihagyasok mellozve legyenek a korabbi modellek miatt.
    Most csak olyan adatok kerulnek a v-ramba ami feltetlenul szukseges, nem csak savszel kimelo a dolog , hanem kevesebb adat mozgatasa is hozza a kivant eredmenyt.
    Kerdeztem nv-rol vegara atallo usereket es valoban nem tapasztalnak akadasokat. Demozta az amd 2 gb os vegaval az uj deus ex-et max grafikaval. Es nem akadozott a jatek egyaltalan. Utobbi evek leghasznosabb technologiai ujitasa amit driverbol kell csak bekapcsolni, kiveszed a dobozbol es mukodik mindenhol dolog.

  • Dilikutya

    félisten

    válasz Jack@l #127 üzenetére

    Az ugye megvan, hogy a 4K felsőkategóriás felbontás, oda komolyabb GPU sem árthat?
    Mire gondolsz, hogy "BF1-et okosba meghúzták 4 giga vramra ultrán"? Tehát akkor az szar, mert top grafikás játékként nem kell alá egy szerverfarm, és csalás van benne? Véletlenül sem jól megírt játék (vonatkoztassunk el, milyen a sztori, milyen a multi)?

  • Abu85

    HÁZIGAZDA

    válasz Jack@l #108 üzenetére

    Bekapcsolható. Beállíthatod akármikor. Mi is aktív HBCC-vel tesztelünk.

    Alapértelmezett lesz, amikor megszűnik a Windows 7 support, vagy amikor kettéválasztják a Win 7 és Win 10 csomag tesztelését.

    (#111) janeszgol: Nem adja oda. A Win csinálja tovább, amit csinálni kell, csak jelezve van neki, hogy a fizikai címtartományon belül hova rakja a CPU+GPU által is elérhető adatokat. Ha azok ott vannak, akkor a HBCC már az operációs rendszer beavatkozása nélkül is képes dolgozni. Az exkluzív cache módnak lényegében ennyi az igénye.

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

Hirdetés