Új hozzászólás Aktív témák
-
#7
Heylel
csendes tag
->Raizen<-
#6
Heylel
csendes tag
válasz
->Raizen<-
#6
üzenetére
A HBCC hardveres megoldás, külön (jó nagy) chip kezeli a Vega kártyákon. A fejlesztőknek semmi dolguk nincs vele. Az más kérdés, hogy hatásfokában felér-e a több memóriával, de ezt majd csak akkor fogjuk tudni megmondani, ha már lesz összehasonlítási alapunk.
-
#8
Balrog
tag
->Raizen<-
#6
Balrog
tag
válasz
->Raizen<-
#6
üzenetére
Várjuk ki ennek a végét. Most általános hiány van a DRAM chipekből és ez jövőre sem fog változni mert egyelőre nincs elég gyártó kapacitás. Márpedig egy nvidia kártyán ezek szerint 3-4x több memória lesz mint eddig. Szerintem durván elfognak szállni az árak.
[ Szerkesztve ]
Sometimes you want orange, but life gives you lemon-lime.
-
#9
#72042496
törölt tag
->Raizen<-
#6
#72042496
törölt tag
válasz
->Raizen<-
#6
üzenetére
"Nem tudom en is inkabb 16 gb ramos vgat vennek mint egy olyat ami szoftverbol tudja csak"
Szintén, annyi eltéréssel, hogy nekem egy 8 gigás is simán elég lesz. Nem játszom gépzabáló játékokkal.
Aztán lehet, hogy a tömörítés a jövő, de tesztelni nem én fogom.
[ Szerkesztve ]
-
#19
7Heads Drago
veterán
->Raizen<-
#2
7Heads Drago
veterán
válasz
->Raizen<-
#2
üzenetére
Sztem meg egyértelmű.
A kevesebb ram kevesebb hőt termel kevesebb fogyasztással.Úgy jól laktam, mint a duda, Hála Neked, egek Ura.
-
#23
Abu85
HÁZIGAZDA
->Raizen<-
#15
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#15
üzenetére
Mindenképpen van egy rendszermemóriát használó terület, amit a GPU és a CPU is elér. A lényegi különbség az, hogy a hagyományos VRAM módban a GPU fedélzeti tárába maguk az allokációk kerülhetnek át, és ennek a menedzselését vagy a meghajtó vagy a program oldja meg. A Vega által bevezetett HBC-s megoldásnál a hardverbe épített vezérlő, azaz a HBCC csinál mindent és csak lapokat menedzsel.
A 8 GB-nyi HBC komoly terhelés mellett mindig tele van. Ez a célja ennek a modellnek. Ha nem lenne tele, akkor nem működne optimálisan a koncepció.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#31
kikikirly
senior tag
->Raizen<-
#25
kikikirly
senior tag
válasz
->Raizen<-
#25
üzenetére
Vega nem a HBM2 miatt fogyaszt sokat.Sőt GDDR5/X-el még magasabb lenne a fogyija. Úgy is mondhatjuk hogy a HBM hamarabbi alkalmazásával AMD csal a fogyasztásban.
Jézusom...
[ Szerkesztve ]
-
#33
Abu85
HÁZIGAZDA
->Raizen<-
#28
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#28
üzenetére
Egyszerűen ábrázolva ez történik:
Rohadtul elnagyolt a kép, de tök jól szemlélteti a lényeget. Fent van a rendszermemória, pontosabban annak az a szelete, amit a CPU és a GPU is elér. A HBCC nélkül az allokációk teljes egészében kerülnek át. Innen ered a hagyományos modell problémája, mert lehet egy allokáció 100 MB-os is, de abból elképzelhető, hogy csak 4 kB-nyi adat kell. Tehát ebben a példában 4 kB-ért kötelező 100 MB-nyi erőforrással fizetni a VRAM oldalán. A HBCC-vel elég csak azt a 4 kB-os lapot átmásolni, legrosszabb esetben két lapot. Vagyis csak az van ott a GPU melletti lokális memóriában, amire tényleg szükség van. Így éri el ez a modell a 100%-os hatásfokot. Olyan lap nem kerülhet bele a HBC-be, amire nincs szükség.
Visszatérve a HBCC nélküli megoldáshoz láthatod, hogy ott is ugyanúgy bekerül az adat a VRAM-ba, csak jóval több, mint ami szükséges. Ergo az egy szintén reális megoldás, hogy maga a VRAM legyen mindig jóval nagyobb, mint amire reálisan szükség lenne, mert így bőven elfér az az adat is, amihez a program az adott időszakban hozzá sem fog nyúlni, de muszáj betölteni, mert az absztrakció olyan magas szinten valósul meg, hogy nem lehet lapszinten menedzselni a lokális memória tartalmát. Persze az a "4 kB kell a 100 MB-ból" eléggé extrém eset, nagyon sokszor az allokációk 30-70%-a hasznos adat, de a különbséget jól szemlélteti az extrém példa.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#42
b.
félisten
->Raizen<-
#40
válasz
->Raizen<-
#40
üzenetére
Én a jövőben érkező generációkra gondoltam,ugye a 970 nem az RX kel versenyez ma már. A z Nv érkező megoldása van ebben a cikkben elővéve. 970 nél nem csak maga a ram mérete a probléma, hanem hogy a hardver be van csapva,és maximális kihasználtságnál a lassabb 0,5 GB ramot is ugyan úgy címezi és akarja használni, mint ha teljes értékű lenne.
Abu85(#39): itt [link] és itt [link]tesztelik elég erősen. Elő lehet manapság már idézni a HBCC-re alkalmas állapotot 4K felbontáson.
Ezen tesztek alapján erősen kérdőjeles a dolog a teljes értékű , dedikált Vramokhoz viszonyítva. ÉN biztos vagyok benne, hogy inkább az utóbbira tenném a voksom, nem csak az NV miatt.
Ráadásul pl COD WW2 höz, már magához a játékhoz is 16 GB rendszer memóriát írnak, 12 Gb aminimum. ha még dedikálni is akarok a kártyának akkor 32-48 Gb ramal szerelt gépet dobjak össze?[ Szerkesztve ]
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
#105
UnknownNoob
tag
->Raizen<-
#25
UnknownNoob
tag
válasz
->Raizen<-
#25
üzenetére
"Lathattuk mennyit er a hbm a vegan. Rohadt sokat fogyaszt a hw egy 1080 hoz kepest."
A Vega fail nagyrészt nem az AMD hibája. Memória és a gyártástechnológia sem felelt meg a beharangozott specifikációnak, amdéék viszont arra tervezték a vegát. A tervezettnél alacsonyabb órajeleket is csak egekbe szökött feszültségek mellett tudták megtartani.
Jól demonstrálja a helyzetet, hogy van néhány golden sample aminél ha leveszed a feszültséget és felviszed az órajelet, akkor még magasabb wattonkénti teljesítményt kapsz, mint a zöldeknél.
Jövőre jön a Vega 20, várhatóan addigra megoldódnak a problémák és verni fogja a Vega a Pascalt. A probléma az, hogy jelenleg nem tudnak eleget gyártani és azzal is csak a baj van ami kijön a gyárból, jövőre pedig jön a Volta.
Mindenesetre a technológia egyáltalán nem gagyi. Intelék sem véletlen akarnak Vegát és nem pedig Pascalt a nagy teljesítményű, de kis fogyasztású CPU+GPU akármicsodáikba.
[ Szerkesztve ]
-
#143
Tigerclaw
nagyúr
->Raizen<-
#142
Tigerclaw
nagyúr
válasz
->Raizen<-
#142
üzenetére
Ha a HBCC képes mindig a VRAM-ban tartani, időben odamásolni a GPU által igényelt adatokat, akkor nem lesz különbség.
Az a baj a világgal, hogy a hülyék mindenben holtbiztosak, az okosak meg tele vannak kételyekkel.
-
#160
Abu85
HÁZIGAZDA
->Raizen<-
#152
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#152
üzenetére
Nekik nem kedvez, mert pont ugyanannyira lényeges a rendszermemória HBCC-vel, mint HBCC nélkül. Az allokációk ugyanúgy ott lesznek mindkét megoldással a rendszermemóriában. Tehát a rendszermemória terhelése nem fog lényegesen változni HBCC-vel vagy HBCC nélkül.
De akkor induljunk ki egy gyakorlati példából. Van egy játék, ami a képkockák számításához tegyük fel, hogy 7-8 GB adatot igényel. Ez már eleve egy olyan tényező, ami ma még felfoghatatlannal tűnik, mert a tipikus adatigénye a játékoknak 2 GB körüli, de nyilván eljön ez az idő is. Talán nem is olyan sokára. Itt már ezek a játékok minimum 32 GB-nyi rendszermemóriát fognak igényelni, mert rengeteg adatot streamelnek. Tehát van mondjuk egy 32 GB-os géped, amiben van egy Vega 8 GB lokális memóriával.
A program igényel magának úgy kb. 5-7 GB CPU által elérhető területet, és úgy 18-20 GB CPU+GPU által elérhetőt területet. Az összes memóriaigény így 27 GB körül lesz, de ugye a dual channel miatt a hardverben muszáj 32 GB-ra ugrani, mert az a következő kétcsatornás lépcső.
A lényeg itt a 16-18 GB-nyi, GPU és CPU által is elérhető terület, ugyanis onnan kerülnek az allokációk a GPU lokális memóriájába. Ha HBCC-d van, akkor beállítasz a meghajtóban egy ideális HBCC szegmenst, és akkor a kijelölésre kerül a Windows számára, hogy hova kell helyeznie fizikailag a CPU+GPU által elérhető adatokat. Innentől kezdve az OS oda helyezi, és ebből 7-8 GB-nyi 4 kB-os lap átkerül a lokális memóriába, és ennek a menedzselése zajlik folyamatosan és hardveresen. Jobb esetben a program elvégzi az inicializálást maga, és akkor inkluzív cache módban fut az alkalmazás, ilyenkor még a meghajtót sem kell megnyitni.
Ha nincs HBCC-d, akkor egy kicsit problémásabb a helyzet, mert ugyanúgy szükséged van arra a 7-8 GB-nyi 4 kB-os lap, de ezeket nem tudod csak úgy betölteni. Ilyenkor a konkrét allokációk kerülnek betöltésre, és itt bele kell számolni, hogy egy allokációnak esetleg csak a 30-70%-a szükséges. Ilyenkor viszont be kell tölteni a teljes allokációt a 70-30%-nyi szükségtelen adattal együtt. És itt még számolni kell a különböző hardveres problémákkal, mint a csatornák keresztbe címzése, vagyis az az ideális, ha egy allokációt akár többször is elhelyezel a VRAM-ban, ugyanis ezzel a módszerrel lesz a feldolgozás a leggyorsabb. Ezt nagyrészt a programozó (program vagy driver) határozza majd meg, mivel teljesen szoftveresen menedzselt rendszerről van szó. Emiatt itt általánosítani nagyon nehéz, már csak azért is, mert a gyakorlatban tipikusan az a jellemző, hogy a program feltölti a VRAM-ot, amíg csak lehet, és amikor betelt, akkor kezdi a probléma menedzselését. Ez nem szerencsés több dolog miatt sem, például a WDDM-nek sem ideális ez a forma, de a rengeteg nehezítő körülményt beszámítva ez tűnik mégis a leginkább működő megoldásnak. Mondjuk úgy, hogy a jobb alternatívák implementálása sokkal nehezebb, és emiatt erre nem feltétlenül éri meg pénzt áldozni. Persze vannak kivételek, például a Sniper Elite 4 motorja akkor is szokott törlést kérni, amikor a terhelés egy rövid időre alacsonyabb lesz, illetve ilyenkor valós időben defragmentál is, hogy egymásra tolja a VRAM-ban található allokációkat, ezzel is helyet nyerve. Mert ugye az sem mindegy, hogy az allokációk mennyire töredezettek. Simán van olyan, hogy a memóriában van még 400-500 MB szabad hely, de esetlegesen nem tudod felhasználni, mert az nem egybefüggően van meg, hanem szétszórtan, így hiába férne be például egy 100 MB-os allokáció 4-szer is, akkor sincs 100 MB-nyi egybefüggő allokálható terület neki. A Rebellion szerencséje, hogy független stúdióként nem mondja meg egy kiadó, hogy a hatékony memóriamenedzsmentre nem ad pénzt, hiszen a játék ugyanúgy eladható a sokkal olcsóbb és bénább megoldás mellett is. Tehát végeredményben hiába kér a program csak 7-8 GB-nyi 4 kB-os lapot, azzal neked hardveres szinten legalább ~16 GB-nyi VRAM-mal kell fizetni. De ha a tipikus optimalizálási modellt nézzük, vagyis a betelik aztán majd menedzseljük koncepciót, akkor már ~24 GB-nyi VRAM kell. És a programnak nem lesz kisebb memóriaigénye a rendszermemória oldalán, ugyanúgy ajánlott lesz hozzá a 32 GB, mert a PC az nem csak egy hardver, itt nem tudsz egyetlen egy memóriakonfigurációra rátervezni mindent. Itt van egy rakás hardver, egy rakás memóriakonfigurációval, vagyis a program igényeit is teljesen általánosra kell szabni, annak érdekében, hogy valamilyen beállítással minél több memóriakonfiguráció mellett működjön. Emiatt van az, hogy amíg régebben a rendszermemória kapacitására vonatkozó igény jóval nagyobb volt, mint a VRAM-ra, addig ma már szinte ugyanannyi VRAM kell, mint rendszermemória. A programok komplexebbek és a bevált menedzsmentrendszerek hatásfoka drámai mértékben romlik.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#165
b.
félisten
->Raizen<-
#162
válasz
->Raizen<-
#162
üzenetére
Konkrétan a a 2 GB / frame többszörösére értettem.( 6-8 GB/ frame). Attól, hogy radeon kártyák kijönnek ilyen felállással, attól még a PC piac nem fog átfordulni, a konzolok meg máshogy kezelik ezt a dolgot. 4 K ra alkalmas kártyákon azért nem 4 GB van, hanem 8 ,vagy több jelenleg is.4 GB már valóban néhol szűkös lehet,( pl Rx 480- 580) ha a GPU elég erős FHD-n ,de nem jellemzően.
[ Szerkesztve ]
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
#186
Resike
tag
->Raizen<-
#174
Resike
tag
válasz
->Raizen<-
#174
üzenetére
Mert melyik lesz a gyorsabb: megjeleníteni valamit amit már ott van a memóriában vagy azt amit még be is kell húzni oda előtte?
Új hozzászólás Aktív témák
ph A következő évben nem lesz ritka a két számjegy a gigabájtok előtt, és akkor még finoman fogalmaztunk.
