-
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
-
HSM
félisten
válasz solfilo #26350 üzenetére
Az RX470-ben fájdalamsan ki van minden centizve, VRM, hűtések, és ugye a nagy darabszám, és az olcsóbb kevésbé válogatott vágott GPU. A GTX meg ugye az ellen van árazva. Az RX480 nekem amúgy személy szerint szimpibb, hogy kicsit prémiumabb kártya, kicsit jobban válogatott csippel, jobb hűtésekkel, VRM-el. Nyilván emellett nem reális megcélozni a 470 perf/$ arányát, de azért nem sokkal rosszabb. Emiatt én nem is a perf/$ diagramm alapján választok általában kártyát magamnak.
[ Szerkesztve ]
-
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ó.
-
HSM
félisten
válasz Jack@l #26352 üzenetére
Arról nem az AMD tehet, hogy úgy áll a fizetőeszközünk piaci értéke, ahogy.
Kb. egy régi HD5750 ára beli kártyáról beszélünk (az is "selejtes" volt), és kb. a piaci helyzete is ugyanaz.... Hát, hogy azóta ez 30K helyett majdnem 50....Amúgy nagy marhaság ezeket "selejtes" csipeknek hívni, még idézőjellel is. Egyszerűen csak így olcsóbb, kevésbé kell válogatni, kevesebb megy a kukába.
A korábbi 7750 is annyiba került, mint a 2GB-os 460. Az pedig aztán nem volt egy nagy hűha...
[ Szerkesztve ]
-
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...
-
HSM
félisten
válasz MongolZ #26354 üzenetére
Azért nem az összes, de sok. Vicces, az pl. senkit nem zavar, hogy az Intel 1100 dollárt kér egy ilyen "selejtes" 10-magosért: [link]. 1100-at. Elviselném a gépemben a "hibátlan" hatmagosom helyett. Pedig a 10-ből 2 teljes mag, és a 25MB L3-ból is le van tiltva 5Mb.
Itt meg lassan parasztlázadás lesz a topikban, hogy egy 110 dolláros (110) 16CU-s komplett VGA-ból (tehát nem csak a GPU, mint a hivatkozott procinál, hanem kompletten az egész minden 110) volt merszük csak 14CU-t engedélyezni![ Szerkesztve ]
-
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 ]
-
HSM
félisten
válasz MongolZ #26356 üzenetére
Redundáns alkatrészek. De tudtommal csak GPU-nál alkalmazzák, ahol gyakran a "fullos"csipben is vannak akár komplett tiltott CU-k, illetve CU-n belül is vannak többszörözött részek.
Viszont úgy tudom, CPU-knál ez nem bevett tervezési eljárás, ott komplett magokat illetve L3 szeleteket szoktak inkább kikapcsolni, illetve az órajellel, TDP-vel játszanak inkább.
[ Szerkesztve ]
-
szmörlock007
aktív tag
Üdv
Pár helyen felbukkant ez a pletyka: Amd to launch monster navi 10 in 2019 with next-gen Ram
Ezek alapján a navi 10-re épülő csúcsmodell 30 teraflopsot fog tudni szimpla pontosság mellet és 128 giga rammal érkezik. Mit gondoltok mennyire lehet valós?
-
Habugi
addikt
válasz szmörlock007 #26359 üzenetére
"Estimated Specifications.."
..játékokban a Depth of Field bizonyos szempontból olyan mint a zöldborsó.., szükség idején valami állat kitalálta hogy ehető...
-
nagyúr
válasz szmörlock007 #26359 üzenetére
Egyáltalán nem tűnik lehetetlennek... gyártástechnek kell időben rendelkezésre állnia hozzá főleg.
Tervezni már ma is tudnának ilyet, csak gyártani nem.[ Szerkesztve ]
Steam/Origin/Uplay/PSN/Xbox: FollowTheORI / BF Discord server: https://discord.gg/9ezkK3m
-
#45185024
törölt tag
válasz szmörlock007 #26359 üzenetére
Nagyon meglepődnék ha egy 128 Gigás gondolom HBM2 3??? nem a szerverekben nyelődne el.
-
nagyúr
kijött az amd amf 1.4, benne hevc támogatással.
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.
-
#45185024
törölt tag
bocs
[ Szerkesztve ]
-
Bethesda may have accidentally leaked AMD’s new Vega 10 GPU, to be called RX490 & will feature 8GB of VRAM [link]
Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.
-
Petykemano
veterán
válasz Archttila #26366 üzenetére
Nem világos, vajon miért hívnák még 2017-ben 490-nek.
Jön pár Vega sku, meg polaris 10xt2, meg pár rebrand, ezzel már simán lehet indítani az 500-as sort.
Szerintem ez inkább csak bennfelejtett marketing, mint az amd listájában volt.Találgatunk, aztán majd úgyis kiderül..
-
#85552128
törölt tag
válasz Archttila #26366 üzenetére
Beírták a legnagyobbat amit eddigiek alapján gondoltak, csak nem létezik ilyen... Nem leakeltek ők semmit sem.
Amúgy ez alapján: SK Hynix updates memory product catalog, HBM2 available in Q1 2017 kevesebb sávszéllel kell majd dolgoznia a Vegának mint a Pascal Titánnak vagy épp a Fury X-nek ha maradnak a hynix ramoknál.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
válasz #85552128 #26368 üzenetére
Ugyanannyival kell, egy 2 GHz-es mintát használ már most is. Ennek a tömeggyártása a Q2 elején indul.
Az olcsóbb verziók esetleg kaphatnak kisebb órajelű memóriát, de nem biztos, hogy ezen éri meg spórolni, mert a Vega esetében már nincs klasszikus értelemben vett VRAM. Emiatt a sávszél igen fontos lesz, hiszen nagyon gyorsan szedi ki a rendszer a nem használt adatokat, így ugyanaz a program feleannyi videomemóriát fog használni, mint ma.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz #45185024 #26370 üzenetére
Ez nem ilyen egyszerű. A felezett igény inkább egy átlag. Vannak jól működő motorok, ahol a memóriamenedzsment kifejezetten hatékony. Ilyen például az Asura. Ott a hardveres megoldás nem fog sokat segíteni. De vannak olyan motorok is, ahol a memóriamenedzsment problémás, és akkor már a hardveres modell sokkal célravezetőbb. Végeredményben a HBC-vel az a fő cél, hogy a fejlesztők végre elkezdhessenek nagyméretű textúrákat és játéktereket fejleszteni, mert ennek a legfőbb akadálya a motorba épített memóriamenedzsment hatékonysága. Viszont ha ezt a hardver megoldja, akkor tulajdonképpen csak a hardver határait kell belőni és ahhoz lehet kialakítani egy játékteret. És nyilván nem kell számolni azzal a veszteséggel, ami szoftverből éri a rendszert.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Jack@l
veterán
"így ugyanaz a program feleannyi videomemóriát fog használni, mint ma."
Várj, hol is hallottam ezt, ja megvan, az összes low level api ajnározásnál évek óta...
Hagyjuk a bullshitet, ugyanúgy nem fog kevesebbet használni mint eddig, vagy ha igen szép mikrolagok lesznek.[ 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
válasz Jack@l #26372 üzenetére
Eddig sem használt többet. A probléma a mostani rendszerrel az, hogy olyan adatok is ott vannak a memóriában, amelyekhez sokszor hozzá sem nyúl a rendszer. Az explicit API előtt az volt a gond, hogy drága volt őket törölni, így inkább otthagyják. Az explicit API-kkal az a gond, hogy még ha a törlésük olcsóvá is vált, akkor is rendkívül nehéz egy olyan rendszert kialakítani, amely tényleg hatékonyan tudja kezelni a szemetelés problémáját. Nem véletlen, hogy eddig csak az Asura oldotta ezt meg hatékonyan. Az előrelépés megtörtént, de nem elég nagy.
A fentiek miatt az AMD úgy döntött, hogy inkább elveszi ennek a problémának a kezelését a fejlesztők elől, mert az emberi tényező túl kiszámíthatatlan, akármilyen API-t raknak alájuk. A hardver ezután gyorsítótárazni fog, így a VRAM a hagyományos értelemben megszűnik.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
HSM
félisten
Itt van egy komoly probléma... A VRAM hiába lesz gyors, hiába törlöd ki belőle hamar a cuccokat, az utánpótlás adat ugyanúgy a csigalassú PCI-E porton kell majd átvándoroljon a VGA-ba.... Erre pedig a VGA-ra integrált SSD sem lesz megoldás.
Úgyhogy ez "így ugyanaz a program feleannyi videomemóriát fog használni, mint ma" kijelentést hiszem, ha látom. És itt persze nem arra gondolok, amiről voltak kutatások, hogy a VRAM tartalmának a fele kb. nincs sosem használva, azt ma is meg tudnák oldani okosabban bármilyen VGA-n low-level API alatt.
(#26373) Abu85: Azt értsd meg, hogy annak ott kell lennie. Mondok egy példát. Állsz egy helyen a játékban, a hátad mögött egy NPC-vel. Az NPC-t nem látod, lehet soha nem is fogod. Az adatai ott vannak a VRAM-ban. Miért? Sosincs rá szükség, ha nem nézel arra. De ha épppen gondolsz egyet és rántasz az egéren? Nos, akkor ha nem lenne a VRAM-ban az a "felesleges" adat, akkor egy bazinagy LAG lenne a jutalmad. Erre a dologra csak az a megoldás, ha több dolgot tartunk a VRAM-ban, mint amire feltétlen szükség van.
Ez a probléma nem fog megszűnni attól, hogy gyorsítótárként használod a VRAM-ot, legfeljebb automatizálódik, hogy a gyakran hazsnált dolgok legyenek benne. Kevés VRAM esetén ez ugyanaz a lagtanger lesz, legfeljebb kisebb mértékben, mert automatizálva a gyorsítótárazást ténylegesen a leggyakrabban hazsnált dolgok kerülhetnek aktuálisan a VRAM-ba. De a kismértékben lagtenger még mindig messze van a kívánatos működéstől, legalábbis az igényesebb userek szempontjából, márpedig szerintem aki Vega-t fog venni, az nem "kevésbé langtengerre" fog kiadni egy kisebb vagyont...[ Szerkesztve ]
-
Jack@l
veterán
20 évvel ezelőtt ezt úgy hívták hogy agp texture memory... (mondanom se kell hogy az is milyen hatékony volt)
UI: majd pont az amd fenomenális driverírói fogják ezt megoldani hatékonyan, lagmentesen[ 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
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
válasz Jack@l #26375 üzenetére
A meghajtónak kevés köze van ehhez. Egyébként a VRAM kezelésében pont az AMD jár az élen a meghajtó tekintetében. Ezt leginkább annak köszönhetik, hogy pénzt költenek erre a területre, míg az NVIDIA egyszerűen elfogadja, hogy a szemeteléssel nem fognak tudni mit kezdeni, így felesleges szoftveres trükkökön gondolkodni. Az AMD például eleve úgy particionálja a VRAM-ot már ma is, hogy egy 4 GB-os VGA-nál 3,5 GB-ot mutatnak a rendszer felé és 0,5 GB-ot nem jelentenek le. Ebbe a meghajtó irkál bizonyos adatokat, és mivel ez eleve el van rejtve még az OS elől is, így akármikor törölhetnek benne anélkül, hogy bármiféle ellenőrzésre kényszerítené a meghajtót a WDDM. A Vega annyiban más, hogy az hardveres megoldás. Egy gyorsítótárként működik, ahogy a processzorok L3 cache-je.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
HSM
félisten
Jó, jó, ez mind szép és jó... De processzoroknál is mi történik, ha az adat nem fért be a cache-be? Hát a lassú memóriából előkotorászás... Ami VGA-nál ugye ez esetben a rendszermemória elérését jelenti a PCI-E-en keresztül, ami továbbra is botrányosan lassú. Végeredmény: kifogy a VRAM, jön a lagtenger. Pontosan, mint eddig.
[ Szerkesztve ]
-
Jack@l
veterán
Értem, tehát ha benne van a memóriába egy textúra az rossz, de ha gyorsítótárként van benne a memóriába az jó? A fél giga vram nem hiányzik egyes játékoknak, nem fogják emiatt butítani a grafikát?
Az ultimate kérdés: Eddig állítólag sírtak a fejlesztők a saját memória menedzsmentért. Ez a low level apik egyik előnye a kb kettőből, most ezt elveszik tőlük. Akkor mire volt jó a felhajtás? Elég lett volna átírni a sima apikat hogy több szálat is használhassanak rajzoláshoz.
[ 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
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
válasz Jack@l #26381 üzenetére
Igazából egyik sem jó. Ha szoftveresen szegmentálod a VRAM-ot, azt azért teszed, hogy ritkábban forduljon elő az a szituáció, hogy ténylegesen törölni kelljen a szemetet a VRAM-ból. Az ultimate megoldás a hardveres menedzsment, csak kurvára nehéz hardvert tervezni rá.
A driver azt hazudja az egyes játékoknak, amit beállítanak neki.A saját memóriamenedzsment nem rossz. Ez előrelépés ahhoz képest, amikor kiszámíthatatlan volt az egész rendszer. Viszont még mindig egy szoftveren múlik a folyamat. Ezt a szoftvert szerencsére már meg lehet úgy írni, hogy csak a VRAM 10-20%-a legyen szemét, de ez még mindig sok, főleg amiatt, hogy a legtöbb program jó ~1 GB-ot beszemetel. Bár legalább már nem ~2 GB a szemét, mint DX11-ben. Előrelépésnek előrelépés. Ugyanakkor a hardveres konstrukció még ennél is jobbnak tűnik jelenleg.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
seolwon
tag
Itt már csak az a kérdés, hogy a közeli jövőben ez valóban szűk keresztmetszet lesz-e?
Mert ha erre fejlesztenek és valami másban meg lemaradnak, amire tényleg aktívan támaszkodnak a játékok akkor hiába az okos hardver ha semmi nem használja ki, és valós alkalmazásokban meg lemarad a konkurenstől. -
Abu85
HÁZIGAZDA
válasz seolwon #26384 üzenetére
Még nem tiszta a pontos működése, de az eddigi adatok alapján különösebb fejlesztői beavatkozást nem igényel. Mondhatni ez egy out-of-box fícsőr. Olyanra egyébként volt utalás a CES-en, hogy pusztán a Vega HBC-je miatt bizonyos partnerfejlesztők készítenek majd speciálisan erre kialakított, gigantikus felbontású textúrákat, amiket eddig nem nagyon tudtak megoldani a szoftveres memóriamenedzsment korlátjai miatt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
gyiku
nagyúr
SK Hynix 4 Gigabyte HBM2 Stack Availability Paves the way for Vega
This paves the way for mass-production and market availability of AMD's upcoming Radeon "Vega" graphics chip, which feature two such 4 GB HBM2 stacks, making up 8 GB of total memory.8GB? akkor a kicsi jon elobb?
[ Szerkesztve ]
hüllő
-
addikt
5600X 2x16GB 6800XT | i5-3570 2x4GB 1050TI | MS Surface Book | iPad Pro 12.9 | iPhone X | iMac e2008
-
nagyúr
-
HSM
félisten
Én itt azért továbbra is látok masszív korlátokat. A hardver ugyanis csak a múlt tapasztalatai alapján tud "gondolkozni", míg a fejlesztő láthatja előre is, mire lehet szükség. Emiatt bár tuti kényelmes lesz az új rendszer, én azért nagy csodát nem várok tőle. Amelyik fejlesztő nem fog jól optimalizálni, ott ugyanúgy bajos lesz a történet, legfeljebb kevesebb szeméttel.
(#26385) Abu85: "bizonyos partnerfejlesztők készítenek majd speciálisan erre kialakított, gigantikus felbontású textúrákat, amiket eddig nem nagyon tudtak megoldani a szoftveres memóriamenedzsment korlátjai miatt."
Pedig már a GCN1-ben ott volt a képesség erre (magad írtad 2011 végén a tesztben):
"Az új architektúra egyik legérdekesebb újítása a Partially Resident Textures (PRT) eljárás, mely lehetővé teszi a hardveres virtuális textúrázást (ismertebb néven megatextúrázást) és a hardveres textúra streaming algoritmusok kreálását, valamint jelentősen több adat kezelése oldható meg segítségével. Az AMD trükközéssel próbálja hasznosítani a cGPU virtuális memória támogatását, így az új funkció az OpenGL API-hoz lesz elérhető egy specifikus kiterjesztés formájában. A PRT segítségével a VRAM egyfajta hardveresen menedzselhető gyorsítótárrá válik, így tökéletesen alkalmas lesz a textúra adatok streamelésére. A Tahiti cGPU nem kevesebb mint 32 terabájtos tömörítetlen textúrát támogat a PRT kiterjesztésen keresztül."
[link]Most akkor jól látom, hogy újra fel lett találva a spanyolviasz?
[ Szerkesztve ]
-
daveoff
veterán
válasz FollowTheORI #26390 üzenetére
a másik dolog meg, hogy 1080p és 4k baromi nagy ugrás...
LG 27GL83A 27'' UltraGear™ QHD IPS 1ms Gaming Monitor with G-Sync®
-
válasz FollowTheORI #26390 üzenetére
Értem kösz, bár mintha lett volna már erről szó és úgy rémlik lehurrogták az illetőt mondván, a Vega már "nem FHD-re való".
De lehet tévedek..Egyébként az van, hogy kiesett a 1070-em a ringből és most azon morfondírozom, hogy teszek egy próbát a Vegával max ha nem jön be akkor meg eladom
Kicsit félek váltani mert az utolsó Radeon kártyám egy 9600XT volt előtte meg csak NVIDIA kártyáim voltak (TNT1 - 1070)[ Szerkesztve ]
Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.
-
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.
-
AMD re-confirms Ryzen and Vega launch dates
Vega was mentioned as well, the Vega lineup will launch in the second quarter of 2017. So that is the April, May June time frame.
[ Szerkesztve ]
Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.
-
Ren Hoek
veterán
-
addikt
válasz Ren Hoek #26399 üzenetére
Jobb mint ha azt írták volna, hogy 5. hóban rajtol, bár tuti az lesz..
Viszont itt azért szerintem a készlet jobb lesz valamivel. Erre nem fognak úgy izgulni a minerek és az OEM-ek.5600X 2x16GB 6800XT | i5-3570 2x4GB 1050TI | MS Surface Book | iPad Pro 12.9 | iPhone X | iMac e2008
Ú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
- Steam Deck
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Milyen CPU léghűtést vegyek?
- Fejhallgató erősítő és DAC topik
- Bugok, problémák a PROHARDVER lapcsaládon
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Rendkívül ütőképesnek tűnik az újragondolt Apple tv
- Bambu Lab X1/X1C, P1P-P1S és A1 mini tulajok
- A fociról könnyedén, egy baráti társaságban
- További aktív témák...