-
Fototrend
A legtöbb kérdésre (igen, talán arra is amit éppen feltenni készülsz) már jó eséllyel megtalálható a válasz valahol a topikban. Mielőtt írnál, lapozz vagy tekerj kicsit visszább, és/vagy használd bátran a keresőt a kérdésed kulcsszavaival!
Új hozzászólás Aktív témák
-
Z10N
veterán
Megyek ebedelni, szoval csak roviden.
A lineked alapjan $170/1,7=$100 a 896/4gb. Viszont ennyiert csak 2gb-t kapsz. $20 meg igy is van rajta, ha nem a nyers teljesitmenyt nezzuk.
Amugy nezz be a topikjaba/hirekhez, mert en nem ezt latom: "A tesztek alapján a teljesítménye teljesen rendben van az árához képest gyárilag a 896 shaderrel is."
Temat lezartam, ne szemeteljunk.
# sshnuke 10.2.2.2 -rootpw="Z10N0101"
-
Z10N
veterán
"Jó, hát a topikja."
Erre most mit mondjak. Azok nyilatkozzak, hogy gyenge akik erdeklodnek iranta. Ez "validabb", mint ez: "A nevesebb oldal tesztjeinek jobban hiszek, mint a felhasználók szubjektív véleményeinek.""Nem beszélve arról, hogy ilyen ársávú kártyát tipikusan gyenge gépekbe raknak, ahol ezer+1 oka lehet, ha nem úgy megy, mint a tesztekben, vagyis ahogy kéne neki."
Pontosan. Ezek nem i7 mellett mennek. Azaz meg jobban kijon, hogy nem stimmel valami. Nem "szintetikus labor teszteknel" kell nezelodni. Ezert is szamit a nyers ero igazan, ami a duplaja minden szempontbol es nem +70%."Persze, értem, mit mondasz, de gyártási szempontból teljesen érthető, hogy nem tudják (és nem is akarják) hozni a nagytestvér (RX470) végletekig kiélezett árazását."
Es itt van a hiba. Siman lehetett volna ebbol is egy sikeres 5750/5770 vagy 7750/7770 szeriat csinalni value kategoriaban. Direkt nem budget-t mondtam, mivel oda meg mindig adosak a 450-nel (p12?)."Különben is ennek a lapkának szvsz a célja inkább a notebookok, és gyárilag beépített mindenféle szempontból limitált környezetek, így érthető, ha a kevésbé kritikus PC-s oldalról nem adják annyira kedvező áron."
Az a baj ebbol nem sok mindent lattunk. Megint csak azt hallom, hogy alig van kore epitve. Azaz nem latom, hogy a "low power" kiszolgalasa miatt lenne dragan merve desktopon.Amugy kihangsulyoznam, hogy nem a lapkaval vagy a termekkel van a gond, hanem az arazassal es a letiltassal. Itt nem arrol volt szo, hogy olcsobban megvetted a 6950 es a 290-t majd dragabb 6970/290X csinaltal belole, hanem pont forditva. Az eltolt price ponton, nem az eleve erosebbet kaptad, hanem a gyengebbet.
Ui: De tenyleg zarjuk rovidre. Jon az rx560 majd remelhetoleg 16cu-val kicsit olcsobban es rendben lesz (2/4gb $85/105).
[ Szerkesztve ]
# sshnuke 10.2.2.2 -rootpw="Z10N0101"
-
Z10N
veterán
"Mert itt nem fizetted ki a kenyér végét. Amit kifizettél, 896SP, azt meg is kaptad teljes egészében."
Ezt honnan tudod?"sajnos mi innen eldönteni nem tudjuk"
De azert allitod, hogy rossz a peldam.Csupan kivancsisagbol, mennyire araznad be ezt az uj nitro-t akkor? Mert nyilvanvaloan plusz "szelet kenyeret" kapsz az 1kg-hoz a teoriad alapjan, azt pedig kulon ki kell fizetni a kasszanal.
Ha ugye nyersen szamolunk akkor 16/14=1,142857; ami $119-s atlag arral szamolva pont $136. Ha a dobozon levo +10% teljesitmenyt vesszuk akkor $131. Ha gyarto lennek siman elkernek egy uj sku-ert +$15-t ($135).
Mennyi is most az 1050/1050TI vagy a 470? Remek pozicionalas. Ha meg ugyanennyiert kapod ($119), akkor megint nekem van igazam, mert kiszurtak azzal aki 896-t vett korabban. Hiaba lehet softmoddolni (gar, relive).
Ui: Amugy feleslegesen vitazunk. Az interjurol meg senki sem beszelt. Delelott munka kozben vegighallgattam.
[ Szerkesztve ]
# sshnuke 10.2.2.2 -rootpw="Z10N0101"
-
Jack@l
veterán
Csak ne kelljen már 40-50e-es kártyát kicsinek hívni és relatíve drágábban adni ezért... (főleg ha a selejtes csipek mennek rá)
[ 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ó.
-
MongolZ
addikt
A "teljes" értékű csipek is tele vannak letiltott részekkel (mint ahogy összes CPU, GPU, APU, stb.), annyira nevetséges, hogy egyesek a (jobban) megcsonkított hardvereket "selejtnek" hívják. Jobb lenne, ha ki sem adnák őket, és a "teljes" csipeken kellene a gyártóknak behajtani ugyanazt a hasznot? Milyen jó lenne, alig lenne választék és 2-3x annyiba kerülne minden...
-
MongolZ
addikt
Mivel technikailag nem létezik tökéletes GPU/CPU, ezért minden termék (amit teljesnek árulnak, az is) tartalmaz rengeteg selejt, letiltott részt. Ilyen szempontból értettem. (Nem jut eszembe az a kifejezés, amelyet erre mondanak, de a lényeg az, hogy a gyártás során alapvetően ~mindenből több egységet építenek be, mint amennyi szükséges, pont azért, mert nem létezik tökéletes gyártás)
De egyébként egyetértek veled.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Ez ma is pont ugyanígy van, csak ma egy extra problémát jelent a szemetelés, így nem tudsz csak úgy simán adatot másolni a VRAM-ba, hanem előtte el kell onnan tüntetni néhány allokált területet, lehetőleg olyanokat, amelyeket a hardver már rég használt. Explicit API nélkül ez komoly processzorterheléssel jár, míg explicit API-val nincs processzorterhelés, de tudnia kell a fejlesztőnek, hogy mit töröl, különben a program működése leállhat. A Vega annyit csinál, hogy ezt a menedzsmentre vonatkozó procedúrát elveszi a szoftveres rétegektől, vagy a fejlesztőktől, és a hardver maga mondja meg, hogy mi az, ami törölhető, és meg is oldja magától. Ez annyiban jelent előnyt, hogy a program oldalán a szemeteléssel nem kell foglalkozni, tehát a videomemóriába betölteni kívánt adatok előtt nem kell manuálisan eltüntetni egy rakás már nem használt allokációt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A VRAM elsődlegesen azért fogy ki, mert tele van szeméttel. 4 GB-nyi adatnak legalább a fele szemét, már nem használt adat. Emiatt nyilván szükséges lesz ezek egy részének a törlése, és utána a felszabaduló területre be kell tölteni az új adatokat. A mostani rendszerben azért fordul elő emiatt sűrűn lag, mert a meghajtók és a programok is úgy vannak felkészítve, hogy a végletekig húzzák el az allokációk törlését. De van egy pont, amikor ez már nem lehetséges. Ilyenkor a meghajtók eleve úgy vannak felkészítve, hogy dobjanak ki akkor sok dolgot, és mehet a helyükre egy csomó új adat, a DX12/Vulkan programok kicsit konzervatívabbak, valamivel finomabb ez a folyamat. De akadni fog persze.
A cache azért célszerűbb, mert akkor is törölgeti a szemetet, ha éppenséggel még nincs a hardver a határon. Tehát jóval nagyobb a valószínűsége, hogy a kért adat ott lesz a VRAM-ban, amikor szükség van rá.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Valójában csak a hardver látja, hogy mire van szüksége. A fejlesztő maximum sejteni tudja, de eleve úgy működnek a streamer rendszerek, hogy van a VRAM-ban a felhasznált terület és a rendszermemóriában a többi adat. Ha a VRAM-ban nincs benne a kért adat, akkor a rendszermemóriából áttölti a szoftver a VRAM-ba, miután ott törölt valamennyi allokációt, ha már elfogyott a hely. A hardveres megoldás is ilyen lesz, csak a hardver oldaláról a törlés jóval gördülékenyebb, illetve nem kell szoftveres beavatkozás sem, ami lelassítaná a streaminget.
A részlegesen rezidens textúrázás nem hardveres allokációt jelent. Hanem azt, hogy nem szükséges minden adatnak ott lennie a VRAM-ban, hogy működjön a textúrázás folyamata. Használja az összes Frostbite játék, az ID tech 5/6-os címek, stb.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Pont ugyan úgy kerül bele a VRAM-ba/cache-be az adat, ahogy ma, csak a menedzsment hardveres lesz, ami lehetővé teszi, hogy a hardver döntsön és ne a szoftver. Ennek két alapvető előnye lesz: jóval kevesebb memória kell hozzá, illetve jóval ritkábbak lesznek a szoftveres menedzsmentből eredő akadások. Lásd például a BF1-nél a kezdeti DX12 módot, annak az akadásai a Vegát nem érintettek volna, mert a hardver eleve nem egy felületesen optimalizált menedzsmentet használt volna, hanem a saját hardveres megoldását.
A fejlesztők igény szerint használhatják a normál működést is, de nem fogják. Az eddigi tapasztalatok szerint nagyon messze vannak a hardveres menedzsmenttől. Márpedig nem éri meg heteket optimalizálni a rosszabb eredményért.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Jack@l
veterán
Onnan indul a dolog(bullshitelés), hogy nem is a hardver fogja ezt intézni, hanem a driver "hardveres"
[ 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
Pont ugyanannyit tud előre a hardver, mint a szoftver. Az persze a hardver előnye, hogy sokkal gyorsabban reagál, mert a szoftveres menedzsmentnek mindenképpen kell ellenőrzés, ami nemi prociidőt elvesz. Jósolni pedig nem lehet. A szoftver sem képes rá, mert a te döntésed, hogy merre fordulsz és ez mindenképpen kiszámíthatatlan. A hardveres modellnek van itt annyi előnye, hogy sokkal takarékosabban bánik a memóriával, így jóval a szoftveres menedzsment előtt betölthet adatokat, amit nem biztos, hogy használni fog a program, de a menedzsment formája nem követel többletterhelést, tehát a szoftveres modellel szemben a hardveres menedzsment semmit sem veszít, ha nagyon a biztonságra játszik.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ilyeneket a szoftver nem tud. Ez nem mesterséges intelligencia, hanem memóriamenedzsment. Arról dönt a szoftver, hogy melyik adat legyen a VRAM-ban és melyik a rendszermemóriában. Ezt pedig nem egy távoli szerver 100 millió sorból írt AI-ja vezérli, ami figyeli minden mozgásodat.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
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.
-
Abu85
HÁZIGAZDA
Ha lenne loading vagy please wait felirat, akkor az működne, de sajnos manapság nincs. Ennek az oka a játékból való kizökkentés elkerülése.
De pont az van, hogy a.hardveres megoldás a lagot fogja csökkenteni.
(#26514) Jack@l: A programnak eddig is joga volt azt írni a memóriába, amit akart, illetve ez igaz volt a grafikus kernel driverre is. A Vega esetében annyi történik, hogy az AMD-nek lesz egy meghajtója, ami odaadja az adatot a VGA-nak és a hardver onnan már mindent intéz automatikusan. Persze van legacy működés és kérhetnek ilyet is a fejlesztők DX12 és Vulkán alatt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Yutani
nagyúr
Én sosem vádoltalak piros szemüveggel, nincs is bajom azzal, de azért mondjuk ki, minimum rózsaszín a szemüveged, ha nem is piros.
Ettől függetlenül persze nem kell, hogy minden tetsszen, amit az AMD csinál. Nekem nincs bajom a koncepcióval, bár nem is értek hozzá, de el tudom képzelni, hogy jól működhet, ha jól körbejárták a mérnökök a problémát és jó megoldást találtak rá.
(#26531) smc: Jó kérdés. Csak a memória IC-k száma befolyásolja a fogyasztást, vagy a kapacitása is?
[ Szerkesztve ]
#tarcsad
-
-
Petykemano
veterán
Nekem nincs, nem is kutattam.
A nerdtechgasm csatorna nevezte meg ezt, mint a skálázódás gátja, amelyet az intelligemt workload disztribútor megoldás lesz hivatott korrigálni.
Lehet, hogy csak korlátozottan logikusan hangzó ostobaság.Találgatunk, aztán majd úgyis kiderül..
-
SaGaIn
senior tag
Hát ha ez igaz, és a sávszélesség megtartása mellett lehet 4GB-t csinálni akkor van értelme egy 48SP- 4GB kombónak. De akkor is 8GB-osat venném ha lenne az tuti.
Szerény véleményem szerint 4GB kártya már a 1060 6Gb miatt sem eladható 1070 szinten meg főleg kell a 8GB.
Te vennél 120-140 ezerért 4 GB-os kártyát? Én tuti nem. Még akkor sem ha 8Gb modell 160.
[ Szerkesztve ]
"DOS addresses only 1 Megabyte of RAM because we cannot imagine any applications needing more." Microsoft in 1980 "We can" -said Google, than they made Chrome. What happend next is history.
-
nagyúr
szerintem csak a szokásos történet: elhúzódó fejlesztés => szkóp vágás a határidő tartása érdekében + humán erőforrás átcsoportosítása más projektekre.
remélhetőleg a vegába át tudták menteni, ami a fijiből kimaradt, ugyanakkor az aktuális kérdés, hogy ezúttal mi marad ki?
[ Szerkesztve ]
Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.
-
Abu85
HÁZIGAZDA
Ez ma sem lényeges a program szempontjából, mert a mai streaming rendszerek sem különösebben a VRAM-ra gyúrnak. A legtöbb motor eleve a rendszermemóriába teszi bele az adatokat, és onnan helyezgeti át manuálisan a VRAM-ba. Innen a streaming. Abból a szempontból fontos csak ez a kérdés, hogy mekkora a szemetelés mértéke, mert azt bele kell kalkulálni, hogy végül az egyes beállításoknál meg tudják adni, hogy mekkora VRAM mellett jó az adott streaming paraméterezés. A HBCC esetében ez lényegtelen tényező, mert a hardver olyan alacsony szintű információkkal rendelkezik, hogy az emberi tényezővel szemben képes jól dönteni.
Értelmetlen hazudni a programnak. Az app oldaláról az a címezhető memória számít, amit kontrollálhat. Nem tud mit kezdeni azzal, hogy a driver hazudik neki 8-12 GB-nyi VRAM-ot. Nem ez a fontos, hanem a címezhető tartomány, ami 512 TB. Ezt kell lejelenteni. A fizikailag címezhető tartománnyal nem tud mit kezdeni, mert azt a hardver vezérli.
Ott adódik egyébként a félreértés, hogy sokan azt hiszik, hogy a rendszermemória használata az valami HBCC specifikus dolog. Nem. Ma is ott vannak a VRAM-ba való adatok, csak amíg ezt ma manuálisan pakolgatja át a program vagy a driver a VRAM-ba, addig a HBCC-nél erre egy direkten kialakított hardver van. Valójában a rendszermemória használata nem fog változni, mert oda ugyanúgy bekerül ugyanannyi adat, mint korábban, csak hatékonyabb lesz a streaming vezérlése.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Csak azzal van dolga. Mást ugyanis nem kontrollálhat. Hiába adsz meg valami kamu fizikai adatot, ahhoz úgysem nyúlhat a motor. Mit kezdjen vele? Nézegesse? Itt valós adatok lesznek megadva, és a motor számára az egyetlen ami számít az a paraméter, ami felett van kontrollja, nevezetesen a címezhető virtuális tárterület. A Vega esetében ez 512 TB. Bármilyen más adatot adsz meg, nem tud vele mit kezdeni, nincs hozzáférési engedélye.
A fizikai VRAM addig érdekes, amíg a szoftver menedzseli a memóriát. De mivel ezt a hardver elvégzi saját maga, így nem tudnak a fizikai memória méretével mit kezdeni a fejlesztők.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem én nem értem, hanem te nem érted meg, hogy ez ma sem működik másképp. Ma is van a motorban egy streaming rendszer, ami a virtuális memóriába dolgozik. A fontos adatok a rendszermemóriába kerülnek, és onnan lesznek streamelve a VRAM-ba. Ebből a szempontból fontos a VRAM mérete, mert az szoftveresen menedzselhető csak, amit vagy a driver vagy a program végez az API-tól függően. Bizonyos driver modellek esetén még fizikai is a címzés, más modelleknél szeparált virtuális megoldásról van szó.
A HBCC-vel csak annyi változik, hogy nem szoftveresen lesz vezérelve a VRAM, hanem a hardver gondoskodik arról, hogy a szükséges adat oda kerüljön a rendszermemóriából, mert maga a memory paging megoldása nem specifikus, mint eddig, hanem általános, így képes közvetlenül elérni a CPU laptábláit. Emiatt már nem kell a VRAM-hoz egy szoftveres menedzsment. De csak ennyi változik, se több, se kevesebb.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A fűre vonatkozóan: Lényegtelen a generálásnál, hogy a meghajtó mit jelent le. A virtuális memória mérete fogja meghatározni, hogy meddig mehet el a program, de aki ilyet csinál az hülye. Viszont baj nem lesz belőle, csak nagyon szarul fog működni. De semmi köze az egészhez annak, hogy a VRAM menedzsmentje hardveres vagy szoftveres. Nyilván a HBCC-vel sokkal jobb lesz a programfuttatás amiatt, hogy a fejlesztő hülye volt, és értelmetlenül rakott egy rakás adatot a VRAM-ba, aminek a kezelése szoftveres menedzsment mellett rossz hatásfokú lesz.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A virtuális memóriának nem ez a lényege. A Vega esetében az 512 terabájt azt jelenti, amit a 64 bites CPU-knál a 16 exabájt. Aztán van még egy csomó tényező, de egyáltalán nem lényeg, hogy fizikailag legyen annyi memória a gépben, amennyit virtuálisan el tud érni a program. A virtuális memória ugyanis pont azt teszi lehetővé, hogy ha elfogyott fizikai memória, akkor a program ne omoljon össze.
Ezért sürgős az AMD-nek és az NV-nek a GPMP bevezetése a Vega és a Volta esetében, mert a programozó csinálhat olyan dolgokat, amelyeket a mai modellekkel már nem lehet hatékonyan tolerálni, így jobb, ha a hardver végzi a VRAM menedzsmentjét.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Mert be tudja tölteni a szükséges adatokat a rendszermemóriába valaminek a helyére.
(#28504) ->Raizen<- : [link]
Annyi történik, hogy amíg a HBCC off verziónál a szoftver kezeli a menedzsmentet, tehát igen sok felesleges adat ottmarad, és nem tudja őket normális menedzsment, illetve többletterhelés nélkül hatékonyan törölni, addig a HBCC on verzió esetében a hardvernek szabad keze van mindenre, így ugyanakkora területre vonatkozóan csak a fontos adatok maradnak ott, míg a többit törli bármilyen többletterhelés szükségszerű felvállalása nélkül.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Callisto
őstag
Szerintem is Te vagy, aki nem érti vagy csak ugyanarra gondoltok, de nem elég jól írjátok le.
Mondok egy szemléletes példát arra, hogy miért nem kell tudnia a szoftvernek, hogy mennyi a valós memória:
Adott játék összesen használ 6 GB textúrát, de a VGA-n csak 2 GB van. Az engine a 6 GB-ot fogja megcímezni és nem érdekli hogy éppen hol található az adat.
Ha az adott megcímzett textúra még nincs a VGA memóriájában, akkor szépen feltölti és onnan dolgozik vele.
A szoftvernek ismét nem fontos tudnia, hogy már ott van. Amíg van szabad VGA memória mennek felfelé a megcímzett textúrák, adatok stb. Ha elfogy, akkor a legrégebben használt és nem lockolt adatot törli a VGA memóriájából helyet adva az újonnan érkező adatoknak.
Tehát a ténylegesen használt textúrák számára kell csak a memória. Nyilván alkalmazástól függően egy minimális memóriamennyiség kell ahhoz, hogy ne legyen folyamatos streamelgetés a sebesség rovására.[ Szerkesztve ]
"A wise man can learn more from a foolish question than a fool can learn from a wise answer." - Bruce Lee
-
Callisto
őstag
Írtam én, hogy végtelen memória lesz? Nyilván rendszermemóriában ott lesznek az adatok, csak amire szükség van az átkerül a VGA memóriájába. Erről beszéltem arra utalva, hogy marhára nem kell tudnia a szoftvernek, hogy mennyi a valós VGA memória.
[ Szerkesztve ]
"A wise man can learn more from a foolish question than a fool can learn from a wise answer." - Bruce Lee
-
nagyúr
Nem akarom elrontani a szórakozásotokat , de én elég egyszerűnek látom ezt a sztorit. Kb. a következő eseteket lehetnek:
a) Játék, ami HBCC aware
b) Játék, ami nem HBCC aware, de egyszerűen fogja fel a streamelést, és teljesen a WDDM / driver hatókörbe utalja a takarítást
c) Játék, ami egyéni memória-allokációs stratégiát használ
d) Játék, ami egyéni memória-allokációs stratégiát használ, és ehhez a VGA fizikai memóriaméretét is tekintetbe vesziAz a) és a b) esetekkel nem lesz gond. A c) eset nem tudom, életszerű-e (vagy csak a d) van), de az ilyeneket jó eséllyel egyszerű profilozással meg lehet oldani. A d)-knél egyedileg meg kell vizsgálni minden játékot, és valamilyen megoldási javaslat kell a drivertől az allokációs stratégia "átverésére". Ez biztos nem fog minden esetben flottul menni, főleg nem az elején - annyi a szerencse, hogy a 4GB fizikai memória számos egzotikusabb megoldásnak elég (ie. a 2 évnél régebbieknek szinte mind), ezért kevés esetben fog komplikált célmegoldás, esetleg game patch kelleni. De az szinte biztos, hogy lesznek ilyen esetek.
Kb. ennyi.
[ Szerkesztve ]
Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...
-
TTomax
nagyúr
Hát a Fury az tényleg egy baromi jó cucc volt.... Nem is tudom mikor adott el utáljára az AMD ennyire keveset Tier1 kártyából...
★★★★★ I got too much soul, rhythm and blues R&B ya see, all that's cool, but hip-hop and rap yeah that's where my heart's at Even back when I used to break on a box ★★★★★ "Chief Rocka"
-
füles_
őstag
Azért a felépítése sem volt arányban a teljesítményével. Elcseszett front-end, sovány back-end, kevés fedélzeti memória, gyenge geometriai futószalag/tesszelátor, brutálisan sávszélessegzabáló GCN3, órajelek is lehettek volna magasabbak (20nm?)...
Így utólag tisztán látszik, hogy a Fiji csak egy teszttermék volt.
Hiába volt 64 multiprocesszora, az előbbiek limitálták az egészet.[ Szerkesztve ]
-
füles_
őstag
Kíváncsi vagyok a GCN3 vs. GCN5 meccsre. A Vega-ban kiküszöbölik a Fiji betegségeit és még pár új fasza cuccra is szert tesz. A részegységek konfigurációja ugye kvázi nem is változik.
Amúgy a Fiji-nél azt is láthattuk, hogy volt olyan eset, amikor a tengernyi feldolgozószál ellensúlyozni tudta az előző kommentemben felsorolt problémákat fél tucat AMD-s kiterjesztéssel (Doom Vulkan leképzővel). Ha jól emlékszem volt olyan beállítás, ahol megfogta még a GTX 1080-at is.
-
Kabala
csendes tag
A Fury X 21W, a fejlett és gazdaságos, takarékos HBM rammal, a 980 Ti pedig 13W, a fejletlen és energia zabáló GDDR5 rammal. Hab a tortán a sok kockából álló, már a megjelenéskor temetett GDDR5X rammal az 1080 Ti - 11W-ból.
Még mindig nem látom jogosultságát a HBM ramnak a Fury-ra, se a vegara a HBM2 ramot.
-
Abu85
HÁZIGAZDA
Az Intelnél ez normális, mert nagyon kevés állapot van a processzoron belül megkülönböztetve. A Ryzen esetében sokszorosan több a megkülönböztetett állapot, így jóval precízebb az órajel lehetséges maximumra való beállítása is. Szóval ez a jelenség elsődlegesen nem a hűtő hibája volt, hanem a processzortervezésé. Bár én hibának se mondanám, egyszerűen így skáláz.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Pug
veterán
Ennek zéró köze van a processzor belső állapotaihoz.
Őőőő, szerinted a throttling-hoz tartozó lower state-ket honnan veszi a rendszer?
Én throttling jelenségről beszéltem, amikor a processzor túlmelegszik
Plusz throttling ugye nem csak hőmérséklet limit miatt fordul el....
[ Szerkesztve ]
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új grafikus processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva. Architektúra, esélylatolgatás, érdekességek, spekulációk, stb.
- Autós topik
- ThinkPad (NEM IdeaPad)
- OLED TV topic
- Kecskemét és környéke adok-veszek-beszélgetek
- Vicces képek
- Több stúdiót is bezár költségcsökkentésként a Microsoft Xbox részlege
- Megjött az Arctic Liquid Freezer AIO-k új nemzedéke
- Távcső topik
- Mobilhasználat külföldön
- Visszavonta az Intel és a Qualcomm Huawei-hez kiadott exportlicencét az USA
- További aktív témák...
- ASUS ProArt GeForce RTX 4080 SUPER 16GB GDDR6X OC (ASUS-VC-PRO-RT4080S-O16G) Bontatlan új 3 év gar!
- MSI RTX 3070 8GB Gaming X Trio - 1 év magyar garanciával - eladó!
- PCX Garancia! MSI RTX 3080 Ti 12GB GDDR6X Gaming X TRIO Videokártya! BeszámítOK
- ÚJ GIGABYTE AORUS GeForce RTX 3080 10GB GDDR6X GAMING BOX Videokártya
- XFX RX 6600 XT SPEEDSTER SWFT 210
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen