Hirdetés
-
GAMEPOD.hu
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
-
Abu85
HÁZIGAZDA
válasz
#85552128
#26108
üzenetére
Mondtam korábban, hogy ez nem az 1080 ellen jön. Még csak nem is a Pascal generáció ellen. Kétszer annyi háromszöget dolgoz fel órajelenként, mint a Titan X, plusz van egy rakás olyan funkciója, amelyet egy GPU sem támogat jelenleg. Nem véletlenül "Poor Voltáznak".
[ 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
#85552128
#26119
üzenetére
Attól függ, hogy mi lesz a Vega 10 árazása. Ez egyelőre még nincs eldöntve.
De lesz egy kisebbik Vega, ami később jön. Viszont halottam már a gyártóktól, hogy az 1070 ellen be akarnak dobni egy Polaris 10-et magasabb órajelellel, csak megvárják, amíg kijönnek a tavaszi játékok, mert a régebbi játékokban nem lesz gyorsabb, csak az új DX12-esekben.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
válasz
Ren Hoek
#26160
üzenetére
Nincs összefüggés. Az OS a VRAM-ot eleve nem is látja. Persze a WDDM érzékeli, de igazából az egész egy driver mögött van vezérelve. Amit az OS lát ebből az a virtuális memória a WDDM 2.0 óta. De GPU-nként eltérő beállítással, a legtöbb GPU-n 40 bites a címtér.
A Vegához egyébként eleve más modul kell, mert az AMD nem használ hozzá klasszikus értelemben vett VRAM-ot. A HBM2 az csak egy cache. Persze van legacy módja a legacy alkalmazásokhoz, de az egész váltás célja az, hogy a VRAM-ot kiüssék. Emiatt a driver minden játékra annyi VRAM-ot állít be, amennyit akar, persze a lefoglalható virtuális memória függvényében. Tehát effektíve a VEGA esetében a virtuális memória a VRAM, míg a fizikai memória, ami van a lapka mellett olyan, mint egy utolsó szintű cache a processzorban.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Azokra a piacokra, ahol nem 20-30 GB-os programokat futtatnak, hanem tényleg nagy adatmennyiséggel dolgoznak, konkrétan 700-800 GB-tal, oda lesznek olyan verziók, amelyeken lesz SSD, mert előnyös, ha az extrém adatmennyiség ott van a HBC mellett. A végfelhasználók nem futtatnak olyan programokat, amelyek több száz GB-nyi adattal dolgoznak. Számukra az SSD bár elméletben lehetséges lenne egy megfelelő dizájnnal, előnyt igazából nem jelentene.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Teljesen mindegy. Két külön dologról van szó.
A virtuális memória az adattárolón lesz. Ennek tölti be magának a GPU a saját memóriájába. Ez a swap állomány. Itt annyi a különbség a rendszermemóriához képest, hogy amíg a rendszermemóriát lekezeli az operációs rendszer, addig a GPU esetében a meghajtó felel majd ezért. Valószínűleg úgy lesz, hogy ha érkezik rá API támogatás, akkor egy GPU swap állományt simán lefoglal a meghajtó a telepítéskor.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#26182
üzenetére
A Samsung nem áll olyan jól a 7 nm-rel, mint a GloFo és a TSMC. A GloFo is csak azért áll nagyon jól, mert az IBM "felvásárlásával" megvették az IBM eljárását, ami ugye a legelső 7 nm-es node-nak készült. Ez 2018Q1-re lesz alkalmas a kísérleti gyártásra, ahogy a TSMC is ekkorra tervezi a kísérleti gyártást a saját node-ján.
A TSMC és a GloFo node-ja annyiban fog különbözni, hogy a TSMC a saját gyártástechnológiáját az ultramobil eszközökre optimalizálta, tehát a nagyobb lapkákhoz, GPU-khoz kevésbé illik. A GloFo ennek a fordítottja, mivel az IBM nem volt érdekelt anno az ultramobil eszközökben, így inkább a nagyobb lapkákhoz optimalizálták a fejlesztést.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Tulajdonképpen ugyanaz lesz az állomány. Sőt, elvileg a Microsoft a WDDM 2.2-ben és után csinál ilyen irányú fejlesztéseket, tehát a DirectX alatt ez az egész szabvány lesz.
A swap technikailag nem kötelező. OS szinten ez is kikapcsolható, csak kitalálhatod, hogy borzalmasan sűrűn fogod látni a kifogytál a memóriából hibaüzenetet, és ezzel az ilyen méretű tartalmakkal készített programok kényszerű bezárását. De nyilván az API-knak lesz legacy módja, ahol legacy VRAM-hoz hasonlóan fog működni a hardver. Annyi különbség lesz, hogy így lassabb lesz a programfuttatás. De ha neked megér -50-80%-nyi teljesítményt, hát kapcsold ki a swapet. Természetesen eldöntheted, hogy milyen minőségben és milyen gyorsan akarsz játszani.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem. Ettől még nem egységes a címtartomány. Az adattárolón lesz a virtuális memória, méghozzá két részletben. Ha meg nem engeded, akkor nem lesz, és akkor ott vége lesz a programfuttatásnak, amit betelt a hardveren lévő memória, és jön az üzenet.
Nyilván hosszabb távon az egységes címtartomány a jövő, de az inkább az évtized vége felé jöhet. Akkor már a virtuális memória kikapcsolhatatlan, hiszen másképp el sem fog indulni a program.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
leviske
#26198
üzenetére
Fejlesztőként az a feladat, hogy minden éppen elérhető architektúrára felkészítsd a kódodat, legalább minimálisan. Nem egyszerűbb hagyni a fenébe a Vegát, és megkérni a hardvert, hogy csinálja meg helyetted az erőforrás-menedzsmentet? Olcsóbb és gyorsabban megvan.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
letepem
#26201
üzenetére
Nagyon leegyszerűsítve azért kevés a VRAM, ha kevés persze, mert nincs elég idejük a fejlesztőknek normálisan kialakítani egy hatékony menedzsmentet. DX11-ben azért, mert nem rajtuk múlik, DX12-ben pedig azért, mert minden rajtuk múlik, és így már túl bonyolult. A konzol az teljesen más tészta. Ott konkrétan az van, hogy a fejlesztőnek van adva x (5-6 tökmindegy) GB memória és ahhoz hozzá nem nyúl az OS, driver, semmi. Ez egy nagyon egyszerű modell így, mert van egy fix géped, fix képességekkel, és csak arra kell dolgozni. Még ha a gépek számát kettőre emelik, akkor is bőven jó.
A PC teljesen más, mert milliónyi konfiguráció van, tehát nem tudsz egy fix konfigot kiválasztani, amire szénné optimalizálod a programot, arról nem is beszélve, hogy az OS/UMD meg sem engedi, hogy egy alkalmazásnak teljes kontrollja legyen az allokáció felett. Itt bonyolódik nagyon a dolog, és ezen a ponton veszik oda egy rakás erőforrás.
A PC-ben is kínálnak a gyártók különböző szabványon kívüli extrákat, hogy valamit, amit a konzolon ki lehet használni, azt PC-n is ki lehessen, de ezek beépítése mind idő, azután az így keletkező speciális kódot is karban kell tartani, tehát végeredményben, ha ezt megcsinálja egy fejlesztő mondjuk mindegyik gyártó legújabb architektúráira, akkor persze javul a program futtatásának hatékonysága, de végeredményben lesz egy rakás gyártó-, sőt hardverspecifikus optimalizálása, aminek a karbantartása rohadt drága lesz, tehát bármennyire is jó ötletnek tűnt az elején, mondjuk egy év után már a háta közepére kívánja a fejlesztő az egészet, amikor dobja össze az utolsó frissítést. És ez anyagilag sem kellemes ám. Főleg amiatt, hogy a gyártók leszólhatnak, hogy "fugyimá, csinálunk némi módosítást a meghajtóban, és a ti kódotok már nem lesz kompatibilis, írjátok má át eszerint, köszi-puszi".Végeredményben mindig oda lyukad ki az ipar, hogy vagy legyen egy működő szabvány, vagy ha ez bizonyos dolgokra nehezen megvalósítható, akkor legyen egy hardveres megoldás.
A Vega a legtöbb programban eleve ebben a legacy módban fog működni. A hardveres lapmenedzsmenthez kellenek eszközök, hogy kihasznált, elsődlegesen API-k, vagy API módosítások. Esetleg API interoperability. Utóbbi a legvalószínűbb, tehát DX12-Mantle és Vulkan-Mantle. Ezzel a programod szabványos maradhat, miközben ki lehet használni a hardveres lapmenedzsmentet a Vegán. Most is van ilyen modulja az AMD-nek, ami a LiquidVR. Az is DX11-Mantle interoperability-vel működik.
Szóval, ha nem használod ezt a képességet, akkor a HBM2 egy sima VRAM lesz. Ha viszont használod, akkor már az új konstrukció is bevethető.A VRAM törléssel az a gond, hogy DX11-ben nagyon drága művelet. DX12 és Vulkan alatt ez már kedvezőbb, de kevés a tapasztalat arról, hogy mikor mi az ideális feldolgozási modell. Itt már meg lehet oldani egy relatíve hatékony rendszert, de biztosan jóval tovább tart a kifejlesztése, mint szimplán rábízni a hardverre az egész problémát.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az aktuális WDDM 2-vel a GPU-kra vonatkozó virtuális memória eléggé egyszerű. Jóval egyszerűbb, mint amit a CPU-ra használ az OS. Effektíve csak azért van rá szükség, hogy maga a rendszer jobban passzoljon a hardverek működéséhez, mert hiába alkalmazott a Windows a 10-es verzióig szegmentált fizikai címzést, a kernel driver már ezt átfordította a háttérben virtuálisra. A WDDM 2 csak ehhez igazodott, mert az új hardverek így működnek. Persze behozta még az IOMMU címzést, ami tényleges előny.
Attól, hogy nincs swap állományod semmivel sem leszel gyorsabb, úgyis ott lesz minden a memóriába, amire szükséges van. Annyi a különbség, hogy swap állomány nélkül kockáztatod a programfuttatás összeomlását a memóriából való kifutás miatt. Ahogy írtad, ez többször is előjött nálad. Magadat szívatod vele, csak azért, mert félsz, hogy elhasználja az SSD-d, de marhára nem fogja. Meg sem érzi majd az SSD, amit egyébként eleve arra vettél, hogy használd.
Az új modell egyébként sokkal inkább olyasmi váltás, hogy a GPU-ra vonatkozó virtuális memória hasonlítson arra, amilyet a CPU alkalmaz. A CPU-nak bevált, nincs okunk azt feltételezni, hogy nem válna be a GPU-ra.
[ 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
Oliverda
#26296
üzenetére
Írtam már korábban, hogy az uncore rész nagy előrelépés, de a core rész tekintetében a GCN4 nagyobb volt, hiszen abban jött az utasítás-előbetöltés. A gyártok egyébként minden új termékre azt mondják, hogy ez a legjobb, akár öt éves távlatban. Azért vannak az újságírók, hogy ezeket a kijelentéseket megfelelő helyiértéken kezeljék.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#26298
üzenetére
A hülye újságíró beírhatja. Az okos elmagyarázza, hogy mi változott.
De egyébként ő a teljes VEGA-ra gondolt szerintem, nem csak a core részre. Mint írtam az uncore rész sokat változott. A core résznél igazából csak a packed math emelhető ki, ami persze nem rossz, de ezt ki kell használni az alkalmazás oldaláról. Meg kell mondani a hardvernek, hogy melyik számítást lehet alacsonyabb precizitással csinálni, különben 32 bites operációkkal fog dolgozni. A másik újításról nem beszéltek, de az a VWL lesz, ugyanakkor ez akkor ér valamit, ha a hardverre rendkívül rossz kódot ereszt rá a fejlesztő. A GCN-t a konzolok miatt ez nem fenyegeti jelenleg egy játékban, már csak az aszinkron compute miatt sem. Nem mellesleg a VWL működését az utasítás-előbetöltés biztosítja.
[ 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
Oliverda
#26324
üzenetére
Persze. Mert az uncore rész nem kapcsolódik szorosan az ISA-hoz. Az egész architektúra neve a VEGA. A core részé GCN5. A Polaris esetében a GCN4 szintén csak a core részt jelzi. Régen az egész architektúrának az AMD nem adott nevet, csak a core résznek. Illetve amolyan típusjelzésük volt. Például GFX IP "szám".
Ezt akkor lehet igazán megérteni, ha úgy tekintesz a GPU-ra, amilyenek ezek a lapkák valójában: heterogén módon tagolt processzorok.[ 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
#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.
-
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.
-
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.
-
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.
-
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.
-
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
válasz
TTomax
#26484
üzenetére
Az egész iparág nagyjából 7 éve azon dolgozik, hogy a pazarló memóriamenedzsment problémáját megoldjak. az első lépés az volt, hogy kezelje a program a menedzsmentet. Ezt hozta be az összes explicit API. Ennek az előnye, hogy végre akadások nélkül törölhető az allokáció, de hátrány, hogy még mindig ott az emberi tényező. Látható, hogy az Asura és a Nitrous sokkal jobban kezeli a memóriát DX12 alatt, de van ellenpélda is lásd a Quantum Break, ami DX12-ben sokkal pazarlóbb. Végeredményben az explicit API-val annyit értünk el, hogy már nem lehetetlen olyan memóriamenedzsmentet írni, ami nem pazarol el 8GB-ból 5-6-ot, de ezt még mindig meg kell írni, ami továbbra is probléma.
A másik tényező a memóriatechnológia. A HBM jó irány, mert radikálisán csökkenti a fogyasztást, de a 150 dollar alatti VGA-kra még túl drága, és az lesz 2 év múlva is. És a Samsung már jelezte a gyártóknak, hogy a GDDR5-nél sokkal hatékonyabb szabványt wideIO nélkül nem lehet csinálni, Tehát a következő generációban nem tudnak 16GB-ot rakni az olcsóbb VGA-kra, mert ennek a fogyasztása önmagában több 100 wattnál, és egy mainstream VGA eleve 60-90 watt körül fogyaszt, és ebből ma úgy 20-30 watt a 4GB memória. Ha pusztán brute force konstrukcióval fejlődik a rendszer, akkor egy mai 100-150 dolláros VGA fogyasztása a jövőben nem lesz 160 watt alatt. És ennek 70%-a a memóriából jön.
A harmadik tényező pedig a textúrák skálázása. Nem túl ismert dolog, de ma jellemzően nagyobb felbontású textúrákat készítenek a fejlesztők, csak nem, vagy nem mindig adjak ki ezeket. Ennek az elsődleges oka az, hogy pokoli meló jó memóriamenedzsmentet írni, az extrém méretű textúraminőséghez. Még a 12 GB-os VGA-k sem mindig elegek, de nem azért, mert kevés a VRAM, hanem azért, mert rossz a menedzsment, és a szoftver a futtatási idő 90%-ban egy jóval kisebb allokációra dolgozik. Ezen vagy javítanak a program kiadása utáni egy-másfél évben, vagy sosem szállítják a legjobb textúrákat. Az Vega üzenete egyszerű a fejlesztők felé. Nehézen megoldható a probléma, így ne is kezdjenek neki, a hardver maga kezelni fogja, csak meg kell adni neki az adatokat, és ennyi. Így mindenki tudja már a megjelenéskor szállítani a legnagyobb felbontású textúrákat. Ezt később a többi hardveren is be lehet majd kapcsolni, ha lesz rajtuk 32-48GB memória.Mindez egyébként egyáltalán nem egy olyan dolog, amin csak az AMD dolgozik, dolgozott. Az NV is hasonló modellen ügyködik, de az majd a Volta után jön., viszont vannak részek, amelyek már a Voltába is beépülnek.
[ 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
#26494
üzenetére
Ez ma is így van. A VRAM-ban ma sincs ott minden. A fejlesztő dönt arról, hogy mikor milyen adatmozgások következzenek be, a régi API-kkal a kernel meghajtón keresztül, míg az explicit API-kban a közvetlenül. Ebből a szempontból nem különbözik a hardveres és a szoftveres menedzsment.
A hardveres menedzsment annyiban más, hogy a VRAM egy cache lesz, igy csak a használt adatok lesznek benne, tehát nem lesz olyan, hogy van a VRAM-ban jó 2-3-4-5-6 GB-nyi adat, amihez már régóta nem ért hozzá a program. Ennyi a koncepció hardveres alapja. Ezt az alapötletet legelőször az NV hozta fel még 8-9 éve, csak később ezt a kutatást nem folytatták egy darabig, mert anno a memóriagyártók azt mondtak, hogy nem lesz probléma a brute force pazarló modellel sem.[ 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.
-
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
válasz
Jack@l
#26507
üzenetére
Na ez az, ami miatt nem értitek. Azt hiszitek, hogy a szoftveres menedzsmentnek több adat all rendelkezésre. Nem. Pont ugyanannyi. Ha mindenképpen ezt a példát akarjatok, ami szerintem hülyeség, de legyen... Szóval az történik, hogy ha elkezd esni az eső, akkor a hardveres megoldás érzékeli és kinyitja az esernyőt. A szoftveres megoldás esetében engedélyt kell kérni az esernyő kinyitására, tehát meg kell kérdezni a szoftveres menedzsmentet, hogy ezzel nem okoz-e bajt, erre kap majd egy választ a hardver, és csak utána nyithat esernyőt.
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
válasz
Jack@l
#26510
üzenetére
Senki sem beszél jósgömb menedzsmentről. Az egész alapvetően csont ugyanúgy működik, mint a szoftveres, csak áthelyezve a hardverbe, ezzel szerezve neki lényeges előnyt a hatékonyság tekintetében, mert kizárod az emberi hibát, illetve az összes többletterhelést. Önmagában a HBC nem nagy trükk, csak azt, ami ma szoftverben zajlik átnyomja hardverbe. A HBCC igazi trükkje az 512TB-os flat címzés, de ez leginkább a professzionális vonalon lesz kihasználható. De erről most nem értekeztünk, a sima Radeonokon szempontjából lényegtelen is.
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.
-
#26557
Abu85
HÁZIGAZDA
Petykemano
#26556
Abu85
HÁZIGAZDA
válasz
Petykemano
#26556
üzenetére
Nem mindegy, hogy milyen gép van a szerverben, mert ha mondjuk 1000 embert csak úgy tudsz kiszolgálni, hogy 1000 GPU-t helyezel a távoli szerverbe, akkor annak az 1000 embernek igen drága lesz a szerver fenntartási költsége. Márpedig nagyon fontos a megfelelő előfizetési díj különben a szolgáltató csődbe megy. Az SRIOV virtualizáció és a virtualizált kódolás azt teszi lehetővé, hogy a hardvert hatékonyan használd ki, így a költségek több ember között legyenek elosztva, miközben ez nem megy majd a teljesítmény rovására.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A VEGA minta 1,5 GHz-en jár. A végleges is ekörül lesz. Szóval ezzel lehet számolni.
Más friss peak adat még, hogy 12 háromszög/órajelet tud. A mostani Radeonok 4-et tudnak, a Titan X pedig 6-ot.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
válasz
füles_
#26661
üzenetére
Mivel AVFS van benne, így nyugodtan ki lehet alapból is használni a tervezett dizájn képességeit.
A tartalékot nem azért hagyják benne a cégek, mert az olyan jó, hanem azért, mert AVFS hiányában muszáj worst case-re tervezni.
Az egy gyakorlati adat volt. 12 a max. De peak értékként úgysem ennyi lesz a gyakorlat.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#26664
Abu85
HÁZIGAZDA
Malibutomi
#26663
Abu85
HÁZIGAZDA
válasz
Malibutomi
#26663
üzenetére
Az egy SSG minta volt. Csak letakarták az SSG részt.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
leviske
#26666
üzenetére
Persze, hogy nem. Ezek peak értékek, leginkább elmélet, mert gyakorlati mérés nincs. Maga a peak adat is eléggé elvont a Vegánál, mert igazából ha pusztán a hardvereket nézzük, akkor a legtöbb GPU képes lenne az aktuálisan megadott peak háromszög/órajel értékénél többre. A korlátot az elavult grafikus futószalag jelenti, és maga a peak érték is erre vonatkozik, nem tisztán a hardver elméleti képességeire. De mondjuk az aktuális GPU-kra nem tudsz olyan programot írni, ami túlmegy a megjelölt peak értéken, még akkor sem, ha a hardverbe épített egység legbelül, önállóan képes lenne több háromszöget átnyomni. A Vega onnan szerzi az extrém peak értékét, hogy bevezeti a primitive shadert, ami az elavult vertex/hull/domain/geometry shader lépcsőket egy modernebbre cseréli, és a hardver képes a valós teljesítményét biztosítani.
(#26665) Pepeeeee: Ha HBM memóriavezérlő van egy lapkában, akkor arra HBM memóriát lehet csak kötni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
A Radeon RX VEGA termékeken már nem VRAM lesz, hanem HBC. Ez óriási különbség. Lesz majd egy demó is, ami megmutatja, hogy mit tud igazából a HBC. Az kódolatlan formában több TB-nyi textúrával dolgozik. HBC-vel elég lesz a 8 GB-os VEGA, míg hagyományos VRAM-os címzéssel is futni fog, de lebutított módban. Viszont aktiválható majd a normál mód is, ha lesz egyszer 128 GB-os VRAM-mal szerelt VGA. De HBC-vel elég a 8 GB-nyi fedélzeti tár is.
Óriási különbség lesz a Vega és a régi hardverek tárkezelése között, mert a Vega hardveresen menedzseli a rendszert, míg a régi hardvereknél csak szoftveres menedzsment lehetséges. Egy már megjelent programnál ez azt jelenti, hogy 8 GB-nyi VRAM-ot 2-4 GB-nyi HBC játszva helyettesít. A még meg nem jelent, de specifikusan HBC-re épített konstrukciónál (elsődlegesen ennek szól a Bethesdával kötött szerződés, hogy az általuk kiadott játékok kapjanak HBC optimalizálást, külön textúracsomaggal) elérhető az is, hogy tizedannyi HBC kelljen a VGA-ra, mint amennyi VRAM-ra lenne amúgy szükség szoftveres menedzsment esetén. Persze ehhez bizonyos célirányos tervezési irányokat be kell tartani. Nagy átlagban egyébként a HBC hatásfokának növekedése a VRAM-hoz képest négyszeres. Ez ugye out of box fícsőr, tehát nem kötelező hozzá külön programoptimalizálást írni. DX6-11 és OpenGL programokkal helyből működik, mindenféle patch nélkül. DX12 és Vulkan alkalmazásokkal kell egy sor a programba.A hardveres menedzsment egyébként később szabványosításra kerül. Az NVIDIA GP100 is tud ilyet a CUDA-val, de mással nem, mert még nem eléggé általános a rendszer. Viszont a Volta állítólag már általánosan ilyen lesz, és az új szabvány alapja a Vega és a Volta architektúrákhoz való igazodás lesz.
[ 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
TTomax
#26786
üzenetére
Mint írtam a HBC egy out of box fícsőr. Ha a játék DX6-11 vagy OpenGL API-t használ, akkor automatikusan HBC módban működik a VGA. Ha DX12/Vulkan az API, akkor kell bele egy sor, hogy a HBC működjön. Ezt mindenki meg fogja tenni, mert egyszerűbb egy sort beírni ~száz sornyi specifikus optimalizálás helyett.
(#26788) TTomax: Amióta megjelentek az első hivatalos infók a Vegáról az AMD erről a képességről beszél. Elég sokan elmondták ezt, de ha a legrészletesebb adatokat akarod, akkor itt nyilatkozik róla Jeffrey Cheng, aki ezt a rendszert tervezte: [link]
[ 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
TTomax
#26790
üzenetére
Nem érted. A Vega esetében DX12 és Vulkan alatt két lehetőség lesz. Az egyik, hogy a fejlesztő meghívja a hardveres menedzsmentet egy függvénnyel, innen a driver tudja mit kell csinálni. Ez egy sor, és kész minden menedzsmenttel kapcsolatos munka.
A másik lehetőség, hogy a megír egy optimalizálást az eleve szükséges nagyjából félezer sornyi szoftveres menedzsmenthez. Ez nagyjából száz sor per architektúra, és a tesztelés során ennek a további optimalizálására is szükség lehet. Tehát a tíz másodpercnyi munkamennyiség áll szemben a pár hetes időigénnyel. Te melyiket választanád?Az AMD énnel sokkal durvább dolgokat elterjesztett, lásd manapság a shader intrinsics, amihez ráadásul nagyon sok munka kell, hiszen a szabványos shaderek mellé írni kell specifikusakat, és ezeket karban is kell tartani ám. Ez azért több hetes olyan optimalizálási munka, aminek csak a Radeonok látják a hasznát.
Persze végeredményben azért hozzá kell tenni, hogy a fejlesztők jellemzően azt veszik figyelembe, hogy mekkora befektetéssel mennyit lehet nyerni, vagy esetleg hogyan lehet spórolni. Sok esetben hasznosabb a shader intrinsics, mint a szabványos shadert tovább optimalizálni. Egyszerűen a hátrányok mellett is kevesebb időmennyiség szükséges a várt eredményhez. A HBC használata tiszta haszon, mivel rengeteg időt lehet spórolni, ha a program csak a függvényt hívja meg és kész. Ezt az időt a többi architektúra megfelelő optimalizálására lehet fordítani.[ 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
TTomax
#26792
üzenetére
Van amelyik már meg is kapta a frissítést. A Deus Ex: Mankind Divided például. Nem nagy kunszt, egy sort kell beírni és tesztelni sem szükséges, mert a hardver végzi a munkát. Csak az kell a fejlesztő részéről, hogy ki legyen jelölve a betöltendő adat. De DX6-11 és OpenGL alatt alapból HBC-vel működik a Vega, ezekhez semmi nem kell. Van olyan is, hogy DX12 és Vulkan alatt ez sem kell, mert olyan stratégiát is alkalmaznak a fejlesztők, hogy a streaming adat a DRAM-ból kerül betöltésre a VRAM-ba. Ilyenkor a a heapeket képes a Vega hardveresen is kezelni, tehát ekkor a program még frissítésre sem szorul. Egyszerűen a DX12 és a Vulkan driverbe kell egy alkalmazásprofil, ami HBCC-re kényszerít.
Egyedül Mantle alatt van annak esélye, hogy nem fog működni.[ 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
TTomax
#26794
üzenetére
Nem teljesen értem a kérdést. Ma a legtöbb program eleve úgy streameli a textúrákat, hogy előbb betölti a rendszermemóriába az adatokat, majd a driver vagy a program innen tölt át adatokat a VRAM-ba. Ezt az API-tól függően a driver vagy a program menedzseli. A HBC ettől annyiba különbözik, hogy a menedzsmentet átveszi szoftvertől. Természetesen ettől a rendszermemóriában ott marad az adat, annyi változik, hogy innen sokkal hatékonyabb lesz a GPU memóriájába streamelni.
A HBCC persze képes olyanra is, hogy direkten a háttértárról olvas be adatokat, de most maradjunk annál, ahogy a leginkább lesz használva a rendszer. Természetesen annál sokkal többre képes, de ezt maximum a tech demó fogja megmutatni, amit kiadnak.Ez a videó a leginformatívabb a HBC témakörben. Persze ez egy beszélgetés csak, amit a techarp felvett. Nem hivatalos tehát, viszont mentes a marketingtől. Ha marketinges videót akarsz, akkor ott az AMD csatornája, ahol van egy pár Vega videó. Ugyanezt elmondják csak nagyon leegyszerűsítve. Én inkább a technikai videót javaslom, meg a rossz hangminőség ellenére is.
[ 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
TTomax
#26796
üzenetére
Ilyenek vannak az AMD csatornáján. De azok messze nem annyira informatívak, mint ez.
Nem találták fel a spanyol viaszt. Magával a problémával jóval korábban foglalkozott már az NV is. Tulajdonképpen ők hívták fel a figyelmet erre még a Jedeckel egy évtizeddel korábban. Mint írtam a GP100-ban is van egy hasonló vezérlő, ami a CUDA programokra működik. A Vega ezt a modellt hozza általános, hardveres formában, vagyis függetlenül az API-tól.
Egyébként itt szó sincs arról, hogy minimális adatot akarnak a VRAM-ban tartani. Sokkal inkább több adatot akarnak benne tárolni, és ennek a módja az, hogy a szemetet dobják ki onnan. Jelenleg a VRAM-ban tarolt adatok fele, rosszabb esetben háromnegyede szemét. Ezek menedzselése sem könnyű, ezért is vitte át a GP100-ban az NV pár CUDA funkció menedzselését hardveres szintre. Sokkal hatékonyabb, mintha a programozón múlna az egész.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#26812
Abu85
HÁZIGAZDA
Németh Péter
#26798
Abu85
HÁZIGAZDA
válasz
Németh Péter
#26798
üzenetére
A HBC a VRAM új neve, ha a hardver gondoskodik a memória menedzsmentjéről.
Lényegében ugyanúgy működik, mint ma egy szoftveres menedzsment. A program kéri az adatot és ezt az alkalmazás áthelyezi a rendszermemóriából. De ez egy nagyon felületes leírása a hardveres működésnek. Amiben a hardveres megoldás előrébb van, hogy a már nem használt adatokat nem őrizgeti, hanem visszahelyezi a rendszermemóriába jelentős helyet felszabadítva, illetve maga a menedzsment egy DX12/Vulkan programnál nem függ az alkalmazás kódjától. Tehát ha egy fejlesztő x programba elég rossz hatásfokú menedzsmentet ír, akkor az a Vegát nem érinti majd negatívan.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Ú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.
Állásajánlatok
Cég: Ozeki Kft
Város: Debrecen
Cég: Ozeki Kft
Város: Debrecen