Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
velizare
#8675
üzenetére
Akkor csak a Google volt béna, vagy én kerestem rosszul.
Mindegy a lényegen ez nem változtat. Ha egy fejlesztő írja le azt, hogy "the code of this feature cannot be optimized" az egyáltalán nem azt jelenti, hogy itt sok engedékenység lenne. Jó lenne tudni egyébként, hogy mi van a licencszerződésben, leginkább azt, hogy a forrást és a módosítást az NVIDIA mennyi pénzért engedi meg. Ha dollárszázezres nagyságrendet szabnak meg, akkor ez csak arra van, hogy rá lehessen mondani, hogy van forrás is, de hozzányúlni senki sem fog. -
Abu85
HÁZIGAZDA
Erről beszélünk egy ideje, hogy ez probléma. Ha a Hairworkshöz valaki minőséget akar hozzáadni, akkor nincs rá lehetőség, mert beleütközik az "as long as it does not lower performance on NVIDIA GPUs" kitételbe.
A forráskód kérhető, de az pénzbe kerül. A CD Projekt Red ezt mondta a Hairworksről: "... unsatisfactory performance may be experienced as the code of this feature cannot be optimized ..." - ezt azóta törölték a fórumból.Elég kemény, hogy az NV elismeri, hogy teljes kontrolljuk van a teljesítmény felett. Szabadon eldönthetik, hogy a Pascal érkezésével a Maxwell mennyire legyen alkalmas az új GameWorks effektekre, ami eléggé aggályos, már csak azért is, mert az NV-nek üzleti érdeke lesz a Maxwell lassítása, ahogy az most a Keplerrel történik. Szerintem ez egyáltalán nem egy jó irány.
-
Abu85
HÁZIGAZDA
válasz
Anubris
#8431
üzenetére
Az a baj, hogy nincs mire váltani. Az elmúlt 8 hónapban megjelent játékok nagy többsége fennakadt a GPUView tesztünkön. Ezzel határozzuk/határozom meg, hogy egy játék mennyire terheli le a GPU-kat, és a 30%-nál rosszabb terhelésűeket nem vesszük fel a tesztbe, mert azok optimalizálása sajnos nagyon hanyag. Nyilván a 30%-os terhelés is már egy elég alacsony érték, de ma azért szerintem elvárható, hogy a GPU-k teljesítményének a 30%-át hasznosítsa egy PC-s program, de elfogadom, ha másképp gondoljátok. Ehhez képest az új játékok normája 15-25% közötti.
Eközben két éve tucatszámra érkeztek az 40-50%-ra is terhelő programok. A GTA5 is éppen átcsúszik ezen a rostán, ha még ma is 40% lenne a minimum elvárt szintünk, akkor a GTA5 is elbukna rajta. -
Abu85
HÁZIGAZDA
válasz
daveoff
#8422
üzenetére
Az nem sokat befolyásolt. A GCN-ek előrelépését a 15.200-as branch hozta.
Kevesen értik meg, hogy egy hardver teljesítménye nem állandó. Sosem volt olyan a piacon, hogy egy architektúra itt volt három évig és még három évig biztosan itt lesz. Ergo minden meghajtót nagyjából csak 3 évre terveznek csupán azért, mert három év múlva már ott az új architektúra. Az AMD most azt csinálja, hogy három évre terveztek egy alap branchet, ami eddig tartott, és a következő három évre terveznek egy újraírt branchet, amiben megváltoztatják a meghajtó működését az előző három év tapasztalataira építve. Ennek az első meghajtója a 15.200-as sorozat. Most sorra le lesz cserélve a GCN szoftveres alapja, mert sokkal jobban ismeri már az AMD a saját architektúráját, mint három éve. -
Abu85
HÁZIGAZDA
válasz
MiklosSaS
#8420
üzenetére
Elég sokat segít neki a 6 GHz-es memória. Mi is meglepődtünk, hogy ez ennyit ér, de ennyit ér tényleg. Azt fontos kiemelni, hogy a közhiedelemmel ellentétben a 390X nem teljesen 290X átnevezés, hanem egy új steppingre épülő lapka, jobb PowerTune menedzsmenttel, és nyilván nagyobb memória-sávszélességgel. Ez az AMD szerint is hoz "up to 10%-ot" a 290X-hez képest, ami a mi tesztünkben is jelentkezett, nem ~10%-os mértékben, de jelentkezett.
A másik része a dolognak a 15.200-as driver branch. Az egy általános ~3-4%-os boost volt minden GCN-re. Ezért nem értettük, hogy miért nem ezzel a driverrel adták ki az új VGA-kat, mert a 15.150-es branch ennyivel lassabb is. -
Abu85
HÁZIGAZDA
válasz
velizare
#8396
üzenetére
Mert a CCC-ben aktívan a Perfect Pictures beállítások lényegében alapértelmezetten. Ezért a shaderek egy csomó post-processt számolnak még a gyorsított tartalomra. A Fury azért nem fogyaszt már annyit, mert ott ezeket a post-process funkciók átkerültek a hardverbe, így már nem a shadert terhelik, hanem egy a DSP-t.
A magas memória-órajel két monitorhoz azért kell, mert ha órajelet vált a memória, akkor a monitorokról egy pillanatra elmehet a kép. Ez nem lesz megoldva, mert HBM lesz minden kategóriában és ott meg eleve nincs órajelállítás.
-
Abu85
HÁZIGAZDA
A HUB legnagyobb előnye, hogy tranzisztorkímélő, miközben felkínálja a teljes sávszélességet a memóriavezérlő és a back-end között. Viszont ezt egyben kínálja fel, így leginkább a véletlen elérésben jó. HBM-mel már más előnye is van, mivel nagyon széles lesz a busz, és mondjuk 4096 bitet belül nehéz megoldani. HUB-bal elég a 4096 bites HUB, de crossbarral 8 512 bites es nagyon sok 256 bites keresztbusz kell.
-
Abu85
HÁZIGAZDA
válasz
Yllgrim
#8298
üzenetére
Akkor menjenek. Előbb-utóbb vége a dedikált GPU-k piacának. Ez sajnos megmásíthatatlan. Ezért koncentrálódik a mostani rendszer az áremelésre és a fejlesztések lassítására, mert addig is keresnek rajta, amíg még van min.
(#8303) Whysperer: Én nem akarok 4K-t meg 60-70 fps-t.
Nekem azért van PC-m, mert ez a munkám, de játszani mostanában főleg PS3-on játszok. Az a baj, hogy ha egyszer rálesel egy exkluzív játékra, akkor egyszerűen mindet akarod, mert annyira brutálisak ahhoz képest, ami ma a PC-ken van. Például a Dragon's Dogma: Dark Arisen. Valami ilyesmi adrenalinlöketet várnék a PC-s játékoktól is, több tonnás szörnyekkel és taktikus csapatharccal. Fáj, hogy ezt csak egy konzoltól kapom meg. -
Abu85
HÁZIGAZDA
válasz
mcwolf79
#8296
üzenetére
Az lehet, hogy van jelentkező, de az új API-k módosítanak azon, hogy miképp érdemes a termékskálát frissíteni. A következő években valószínűleg lesz egy pilot VGA minden generációban, ugyanis számolni kell azzal, hogy ha új architektúrát hoznak, akkor a játékokon sokkal rosszabbul teljesíthet, mint az elődje, mert a driver átkerül magába a játékba. Érdemes kihozni egy olyan előzetes fejlesztést, amely az új architektúrát tartalmazza. Ez az aktuális termékskálával együtt mehet, mert igazából piaci szerepe nem lenne. Viszont amíg megérkezik a nagytesó, addig számos játékot már optimalizáltak a pilot VGA-ra, és abból a nagytesó is profitál. Ez azért fontos, mert ha a nagytesó jön először, akkor annak lesz borzalmasan gyenge a teljesítménye optimalizálás nélkül.
-
Abu85
HÁZIGAZDA
Aki az AMD-nél dolgozik az szerintem már látta a programokat. Ebből a szempontból az AMD-nek nyilván lehetőségük van arra, hogy a DX12-t hype-olják, hiszen tudják, hogy mi várható. Ugyanígy az NV-nek és az Intelnek lehetősége van arra, hogy annyira ne foglalkozzon a DX12-vel.
Az árak alakulásában az játszik főszerepet, hogy ma már csak feleannyi VGA kerül eladásra, mint négy éve. Azért ez elég komoly visszaesés, és folyamatosan csökken a kereslet. Amíg ez nem fordul meg, addig az árak csak növekedni fognak. Ezért lassultak le a fejlesztések is, mert ma már nem akkora a piac, hogy értelme legyen másfél évente a teljes termékskálát lecserélni.
-
Abu85
HÁZIGAZDA
Igen a Thief támogatja PC-n, de csak a legutolsó javítással. A BF4 a PS4-en a pilot projektje volt az async shadernek. Ezután mindegyik PS4-es Frostbite 3 játék megkapta ezt a funkciót. A jövőben ez a funkció platformfüggetlen lesz a Frostbite-tal. A kísérletezés erre vonatkozóan állandó. Az a kérdés mikor kapcsolják be a funkciót.
-
Abu85
HÁZIGAZDA
válasz
Laja333
#8258
üzenetére
A Witcher 3-nál opció a low-level mert rengeteg korábban beígért dolog a DX11 miatt maradt ki. A GTA5 esetében nehézkes mert XO és PS4 konzolokon sem low-level az elérés, szóval valószínű, hogy a motor strukturálisan sem megfelelő a DX12-re. Így azért a váltás egy jó fél éves munka lenne.
-
-
Abu85
HÁZIGAZDA
Gyakorlatilag ugyanarról a koncepcióról van szó. A Vulkan esetében is. Szerintem reális, hogy sokan várják. Csak a saját gépem példájára építve egy Dragon Age Inquisition DX11-ben nem megy 20 fps fölé, de ugyanazon a beállításon a Mantle nem megy 40 fps alá. Ezt kínálja a többi új API is. Naná hogy várja a játékos. Főleg akinek olcsó vagy régi procija van.
-
Abu85
HÁZIGAZDA
Az aszinkron compute-ot már a Frostbite 3 is támogatta, csak nem kapcsolták be egyik játékban sem, mert nagyobb fókuszt jelentett a memóriamenedzsment optimalizálása, és a validáció nagyrészt ennek az optimalizálásának a teszteléséből állt. De Johan már tartott korábban arról előadást, hogy a tiled gyorsítása aszinkron módban is elvégezhető a fények kivágási munkájával. Így csupán erre a feladatra vonatkozóan 80%-os gyorsulást értek el, de ez a feladat ma még nem teszi ki nagy részét a képfeldolgozásnak, tehát a végleges eredményre nagyjából ~10%-os boostot jelenthetett volna.
-
-
Abu85
HÁZIGAZDA
De. Egyik új EA játék sem a Frostbite 3-mal jön, hanem az új immáron számtalan verzióval, de a régi számozással ez Frostbite 4 lenne. A legfőbb előrelépés a PBR, de számos grafikai futószalagot lecserélnek hatékonyabb compute futószalagra. Változik a textúrázas, egészen pontosan a megatextúra streaming. Illetve kap egy új post process futószalagot, aminek a része egy új temporális analitikai AA. A deferred MSAA ugrik. Emellett megújul a multi-GPU mód, de azt nem tudni, hogy ez mennyire stabil. Lehet, hogy pár játékban marad az AFR, csak az a temporális AA-val nem annyira hatékony. Aszinkron DMA és compute lesz, ugye a DMA hozzáférés már most is aszinkron
-
Abu85
HÁZIGAZDA
Mit várunk versenyképesség alatt. A 380 gyorsabb, illetve a jóval nagyobb sávszélje. A 960 előnye, hogy kevesebbet fogyaszt.
A 380X nem feltétlenül szükséges, mert a 290 ott van 259 dollárért, annál nem lesz gyorsabb. Oda jönne a 380X és a 960 Ti. Az AMD ezt azért húzza el, hogy minél később legyen lemérve, hogy egyre több új játék kerüljön a tesztekbe a Windows 10-zel. Itt az NV fog előbb lépni, mert nekik nincs 259-ért termékük és nem várhatják meg az év végi játékdömpinget. Ha az AMD-n múlik elhúzza novemberig. Akkor jön a Star Wars Battlefront a Dual Fiji-vel. De legalább az új Need for Speedig érdemes kihúzni.
Azt nem árulták el, de az új EA játékokban már nem Frostbite 3 lesz. A következő variáns már PBR-es, sávszélzabáló, async shaderes/DMA-s cucc. -
Abu85
HÁZIGAZDA
válasz
daveoff
#8092
üzenetére
Mostantól a hétköznapi ember az egészet rosszul fogja tudni. Na meg kiderült, hogy a Maxwell 2 nem támogatja az aszinkron shadert. Oh wait, hiszen ennek megfelel. Valójában a legmagasabb bekötési szintet nem támogatja. Nembaj legalább a hétköznapi ember érti.
Olyan API-s legendák indultak el az elmúlt két hétben a magyar IT sajtóban, hogy az félelmetes. Egyáltalán mi az, hogy egyik GPU sem támogat minden DX12_1 szolgáltatást. Van ilyen, hogy DX12_1 egyáltalán?
Az lenne az igazság, hogy egyik hardver sem támogat minden DX12-es opcionális funkciót. A kötelező funkciókat mindegyik DX12-es hardver támogatja. -
Abu85
HÁZIGAZDA
válasz
Venyera7
#8080
üzenetére
A TIER_3-as szintet nyilván azért specifikálták, hogy később mindenki ezt használja. Azt nem tudni, hogy mikor, de egyértelműen ez a jövő, és az új generációs hardvereket is érdemes erre tervezni. Lehetőség szerint minél hamarabb, mert a low-level API-knál problémát jelent a teljes architektúra leváltása. Nagyjából két éven belül ez megtörténik.
(#8081) daveoff: Nem érhető el a BR-TIER_3 bekötés. A Maxwellnek nincs skalár egysége, amely a processzor beavatkozása nélkül el tudná intézni a bekötést. Lassabb igazából nagyon elhanyagolható mértékben lesz, mert ettől még bindless és a bekötés a mintavételezőbe történik. Ami hátrány lehet ebből, hogy nem minden effektet lehet megjeleníteni, ha elfogynak az erőforrások.
-
#8066
Abu85
HÁZIGAZDA
Petykemano
#8064
Abu85
HÁZIGAZDA
válasz
Petykemano
#8064
üzenetére
Az AMD a Zen CPU-it nem a játékosoknak csinálja. Megveheted játékra is, de ugyanabba a tokozásba lesznek APU-k, amelyek jobban kiszolgálják majd a játékosok igényeit.
A CPU erő az aktuális játékdizájnoknak nem kell. A limitek teljes egészében szoftveresek. Valójában egy totál belépő processzor minden játékra teljesen elég lenne, mert a szimuláció évek óta nem fejlődik. Az ipar nem az előrelépést tartotta szem előtt, hanem azt, hogy ugyanazt a szimulációs minőséget hozzák ki kevesebb processzoridőből. Szükség lesz majd úgy hozzávetőleg 2 évre, hogy az ipar a DX11 miatt leállított fejlesztéseket ténylegesen újrakezdje és befejezze. Ez tényleg magával hozza majd a modernebb AI-t, és egyéb szimulációkat, amit most a játékosok hiányolnak.
-
#8062
Abu85
HÁZIGAZDA
Petykemano
#8059
Abu85
HÁZIGAZDA
válasz
Petykemano
#8059
üzenetére
Nem, a DX12 lényege pont az, hogy a parancspufferek kreálása független, és akárhány szálra leosztható. Ez persze a motortól is függ, de a Nitrous ezzel a modellel 36 szálig lineárisan skálázódik, ami biztató ezekre az új API-kra nézve.
Ami itt a kérdés, hogy mivel lehet jobb eredményt elérni, mert lehet építeni négymagos CPU-t IGP-vel és nyolcmagos CPU-t IGP nélkül. A jelenlegi gyakorlati tesztekben azt látni, hogy az IGP elérhetősége többet ér, mint a kétszer több processzormag. Nem véletlen, hogy az IGP teljesítménye nő az új lapkáknál, míg a processzormagok teljesítménye inkább stagnál. Ez látható a Broadwell-K-n, a Godavarin és a Skylake-en is látható lesz. Lehet, hogy ezt még nem érti egy játékos, de a gyártók már látják, hogy a végső teljesítményt inkább az IGP határozza majd meg. -
Abu85
HÁZIGAZDA
A Windows 10 alatt az overhead nem javul. Azt az új API-k csökkentik. A régi API-k ugyanúgy működnek tovább. Persze az MS a WDDM 2.0 miatt lehetővé tesz wrappereket a DX12-höz, így bizonyos WDDM 1.3-ban nagyon korlátozó dolgok megkerülhetők. De ezt mindenki meg fogja kerülni.
A DX12 esetében a parancsfeldolgozás mindenkinek ugyanaz lesz. Az AMD-nek az előnye, hogy a GCN-es Radeonok a TIER_3 szinten futtatják a bekötést, ami többletterhelés nélküli, míg a kisebb szintek bizonyos funkciókat emulálnak, ami többletterheléssel jár. Minél kisebb a szint, annál több az emuláció.
Az aszinkron compute és DMA lényeges, mert nagyon egyszerűen kihasználható funkciók, és 15-45%-os gyorsulást kínálnak az azt támogató NV és AMD hardvereken.
-
Abu85
HÁZIGAZDA
Ja igen, az erősorrend az igazából különböző limitációkból adódik össze. Tipikus célja a tesztnek sorra terhelni mindent a maximumra, és előhozni a rendszerek limitjeit. Akárhol előjön egy limit az már rossz lesz a végső eredményre. A játékokban ezek biztosan nem így lesznek terhelve. A hasznossága azonban vitathatatlan, nagyon jól lehet látni belőle a rendszerek kiegyensúlyozottságát.
(#8055) Petykemano: Ha jönnek ilyen processzorok, akkor nem a játékok és a DirectX 12 miatt. Ez gyakorlatilag biztos. Erről pont az inteles cimbivel beszéltem a hétvégén, és az egyik legnagyobb húzófícsőrnek az IGP-k kihasználását tekintik a DX12-re dolgozó fejlesztők. Ennek többféle módja lehet, de a cél a kihasználatlan, sokszor 300-800 GFLOPS-os erőforrás befogása. Ezt nehéz lenne verni csak CPU-ból.
-
Abu85
HÁZIGAZDA
A 3DMark Overhead teszt komplexebb annál. Egyrészt nyilván nézi a parancsprocesszort, mert az egy fontos szempont, de maga a teszt procedurális, tehát minden ami megjelenik matematikai képletekkel lesz kiszámolva, tehát a GPU-t is terheli, mert compute shaderek futnak rajta, akár párhuzamosan. Ezzel számít a számítási teljesítmény és a sávszélesség is, illetve a compute parancsprocesszorok teljesítménye. Ez nem csak egy szimpla front-end teszt. Ráadásul az új verzió már nincs hat magra limitálva DX12-ben, mert kijavított az MS ezt a bugot.
-
Abu85
HÁZIGAZDA
válasz
Ren Hoek
#8013
üzenetére
Az informatikában minden nagyon gyorsan fejlődik, tehát ha egy évet csúszik egy projekt, akkor már van rá az eredetinél jobb képességű alkatrész is. Ezért nem akarja a Hynix a kockázatot felvállalni, mert nekik csak úgy éri meg, ha kifizetik, de ha nem sikerül a termék, akkor csak a gyártósor lesz meg, és a memóriákat vissza fogják mondani. De nyilván aki rendel azt kiszolgálják, szó sincs arról, hogy bárkit is korlátoznának, csak fizessék ki a rendelést. Ennyi kell a Hynixnek.
Az interposert nem az NV fejleszti, hanem a GloFo, Samsung, TSMC, UMC, stb. Attól függ, hogy kiét választják. Az AMD az UMC-t választotta például. -
#8012
Abu85
HÁZIGAZDA
Malibutomi
#8011
Abu85
HÁZIGAZDA
válasz
Malibutomi
#8011
üzenetére
A HBM1 most érhető el. Fogd fel úgy, hogy az AMD már működő megoldást szállít a piacra, míg a többieknek most van lehetőségük elkezdeni a tesztelést. Itt mindenki hátrányban van. Viszont a HMC jó példa arra, hogy a Hynix jól döntött, amikor mindenkit kizárt a fejlesztésből, mert az régebb óta készül és még mindig nincs. Tehát ennek a döntésnek voltak előnyei és hátrányai is.
Ha valaki HBM2 lapkát hoz ki, akkor Q4-ben kezdheti meg a tesztelést. A HBM1 és a HBM2 nem kompatibilis. Más interposer kell hozzájuk. -
Abu85
HÁZIGAZDA
válasz
CsonkaImo
#8005
üzenetére
A Fiji tape-outja a Tongával párhuzamosan volt, méghozzá 2013 végén. Az első implementáció nagyjából 1,5-2 év a tape-outtól számolva. A második kör nyilván a tapasztalatok miatt egyszerűbb.
Szerintem egy év múlva senki sem fog. A HBM2 kísérleti gyártása 2016Q2-ben esedékes és interposerek is Q2-Q3-ban jönnek. A tömeggyártás Q3-Q4. Ha mákjuk van akkor a 2016-os ünnepi szezon támadható. Az a baj, hogy nem rajtuk múlik. Hiába van kész a lapka a megjelenéshez kell az interposer és a memória is. -
Abu85
HÁZIGAZDA
válasz
Locutus
#8003
üzenetére
Az AMD az NV-vel semmit sem oszt meg a HBM-ről. Azt amit az AMD elvégzett magának mindenkinek végig kell járnia, mert senki sem tudja előre, hogy az adott rendszerüknek melyik implementáció a jó, nagy valószínűséggel az AMD-é biztos nem jó senki másnak. A HBM2-re pedig pont azért nem ajánlja a Hynix az ugrást a nulláról, mert simán elképzelhető, hogy egyik lehetséges implementáció sem lesz jó.
Itt a kockázatok megosztása a gond. A HBM1-nél ezek megoszthatók, így a Hynix elfogadja, ha valakinek nem sikerült. Egy csomó más HBM1-et célzó cégnek még el tudják adni a memóriát. A HBM2-nél már nem fogadják el, így ha lesz termék ha nem, a megrendelt memóriákat el kell vinni.
-
Abu85
HÁZIGAZDA
A Hynixnak igazából az a jó, ha minél többet rendelnek. Ők szívesen kiépítik a gyártósorokat, mert nekik ez nem probléma. Az a probléma, ha kiépítik és utána nem üzemelhetnek. Ők már korábban is beszéltek arról, hogy a HBM annyira bonyolult, hogy a HBM2-vel nem éri meg kezdeni. És ezt egy csomó cég meg is értette és HBM1-gyel indítanak. Ezért is érhetők el a HBM1-es minták. Ettől még lehet a HBM2-vel kezdeni, de a Hynix nem hajlandó felvállalni a termékskála törlésének kockázatát, mert az azt jelentené, hogy kiépítették a gyártósort a megrendelőnek, de az nem fog működni. Úgy biztosítják magukat, hogy igenis a megrendelést el kell vinni, akkor is, ha azt a megrendelő kidobja a kukába.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#7991
üzenetére
Írtam a másik topikban erről. A Hynix a HBM2-re előre kötött szerződésekkel dolgozik. A vállalat nem akarja felvállalni a kockázatot a gyártósorok kiépítésére, tehát akkor lesznek azok kiépítve, ha a HBM2-t rendelő réteg előre kifizeti, illetve kötelességet vállal arra, hogy megrendeli az előre megbeszélt mennyiséget. Aztán a Hynixot nem érdekli, hogy mit kezdenek a memóriákkal, még akkor sem, ha végül nem sikerül terméket piacra dobni velük.
Ez csupán a kockázat minimalizálása a Hynixnak, mert túl magas a kockázata annak, hogy a HBM1-gyel zéró tapasztalatot gyűjtő cégek nem tudnak majd HBM2-re ugrani. A Hynix csak biztosítékot akar arra, hogy ha esetleg egy teljes termékskálát törölni kell, attól még az adott gyártó a megrendelt HBM2-ket mindenképp kifizeti és elviszi. -
Abu85
HÁZIGAZDA
A user választása mindegy. Itt sokkal nagyobb probléma lesz a fejlesztés. Senki sem fog két technológiára teljesen külön fejleszteni, tehát az lesz, hogy választanak egy panelt és ahhoz rakják a vezérlőket. A gond itt annyi, hogy ha a panelt a FreeSync/A-Sync-hez igazítják, akkor G-Synchez nem jó, és fordítva. Ez igazából az Acert és az ASUS-t érinti, hiszen ők tartják még a G-Sync bástyáját. A többiek már csak A-Syncre fejlesztenek. A kérdés az, hogy az NV átvállalja-e az Acer és az ASUS G-Sync R&D-jét, vagy az már nem érné meg, és akkor hagyják őket is futni, amint lesz DP 1.2a-s palettájuk.
-
Abu85
HÁZIGAZDA
válasz
Whysperer
#7969
üzenetére
Igen, átírtam, köszi.
Megfigyelhető az egész PC-s iparágon, hogy amikor egy kiadó saját technikai csapatot tart és saját stúdiót a kutatásra, ott jellemzően az AMD a partner, mert ebben ők tudnak segíteni. Ahol erre nincs lehetőség, hanem inkább middleware-eket keresnek a saját kutatás erősítése helyett, akkor az NV a partner, mert ők meg pont erre rendezkedtek be.
Ez a kiadótól függ, hogy van-e elég pénz arra, hogy egy PC-s és egy kutatóstúdiót fenntartsanak. A jövőben valószínűleg ez lesz a domináns irány az AAA játékoknál, mert a Sony middleware nélküli exkluzív játékain látszik, hogy a middleware-ek mennyire károsak tudnak lenni a grafikai minőségre vonatkozóan, és ezek eldobásával mekkora vizuális előrelépést lehet elérni, csak azért mert egymáshoz tervezték a pipeline-okat.
-
Abu85
HÁZIGAZDA
Az EA egy dolgot favorizál, az pedig az optimalizálhatóság. Az a partner hasznos számukra, akik nyíltan dolgoznak, adnak nekik disassemblert, fejlesztőeszközöket és dokumentációt, gyakorlatilag segítik megérteni, hogy mit kellene csinálni, hogy a program gyorsabban fusson. A Frostbite Team minimum elvárja, hogy a limitált idejükben ne kelljen visszafejteni az architektúrák és a driverek működését, hanem elég legyen odamenni a gyártóhoz, és megkérdezni, hogy ezt meg azt hogyan lenne érdemes csinálni.
Ez régen is így volt. Az EA régen az NV partnere volt. A Ferminél romlott meg a kapcsolat, amikor az NV bezárkózott, és egyre kevésbé segítettek. Viszont az AMD nyitottabb lett, és az EA váltott. De meggyőződésem, hogy az EA szívesen dolgozna az NV-vel, ha megadják nekik, amit kérnek. -
Abu85
HÁZIGAZDA
válasz
CsonkaImo
#7964
üzenetére
Az EA-nek semmi baja az NV-vel. Csak annyi történt az elmúlt években, hogy beálltak egy olyan fejlesztési modellre, ahol nem tudják hasznosítani a zárt middleware-eket. Sokkal kedvezőbb számukra, ha maguk csinálnak mindent, és teljes kontrolljuk van a programfuttatás felett, így nem hasznos számukra, amit az NV kínál, mert ezekkel csak rontanak az optimalizálhatóságon, ami az EA-nek valamiért az utóbbi időben kritikussá vált.
A játékok kiállítása pedig üzlet. Ha az AMD nem kötött valamire exkluzivitást (mint például most a Star Warsra), akkor bárki kiállíthat vele gépeket. Például a Battlefield exkluzivitása az AMD-nek egy éves volt, a BF4 megjelenésétől. Miután lejárt az Intel és az NV is kiállította a Hardline-t a rendezvényeken, mert lehetőséggé vált.
-
Abu85
HÁZIGAZDA
A Mirror's Edge Catalyst semmiféle zárt forrású dolgot nem használ. A motort a játék alá a Frostbite Team szállítja. Nekik csak Havok licencük van, de minden mást saját rendszerrel oldanak meg. A Havok is csak azért maradt meg, mert megkapják a teljes forráskódot és azt korlátok nélkül átírhatják.
Ha a Frostbite Team nem kap forráskódot, akkor nehéz az integrálás, mivel a Frostbite egy mutex zárolásokkal dolgozó motor, így meg kell határozni, hogy pontosan meddig lehet egy folyamat memória-hozzáférését korlátozni. Ez még úgy is stabilitási problémákat jelentett DX11-en, hogy mindent maguk írtak.
Az EA a jövőben nem fog használni zárt forrású middleware-eket. Azért létezik a Frostbite Team, hogy minden problémát házon belül megoldjanak. Így biztosítható a legjobb sebesség és stabilitás. -
Abu85
HÁZIGAZDA
válasz
MiklosSaS
#7939
üzenetére
Ennyire ez nem egyszerű. Az elején mindenképp előny, hogy az AMD ezt az irányt két éve viszi. Egyszerűen tudják, hogy mi működik és mi nem. Nagyon számítanak a toolok. Az AMD azért kiad egy DX12-es PerfStudiot, mert az MS-nek ezt a fejlesztésüket nem adták oda. Az nagy szoftveres előny, hogy ha a fejlesztőknek kínált toolok nem omlanak össze a nagyobb programoktól. Márpedig az MS az Xbox One fejlesztőeszközére koncentrált, mivel azt várják, hogy a PC-s kód 99,9%-ban az Xbox One kód lesz. Ez igazából senkinek nem jó, bár az AMD-nek elmegy, de semmiképp sem elfogadható.
-
Abu85
HÁZIGAZDA
válasz
Venyera7
#7932
üzenetére
Játékfüggő lesz. Valószínű, hogy a kezdeti időszakban az is árnyalja majd a képet, hogy az AMD már majdnem két éve tesztelgeti ezt az irányt, míg más csak egy éve. Illetve a fejlesztőknek a Mantle-höz Radeon kellett, vagyis erre van kész optimalizáció. A többi hardverre dolgozni kell. Szóval az elején a kutatások és tapasztalatok még beleszólnak az eredményekbe. A 3DMark Overhead tesztben is annak tulajdonítható némi Radeon előny, hogy ezt mar ismerték a Futuremarknál, míg a többi hardvert még nem.
-
#7930
Abu85
HÁZIGAZDA
szupersanyi
#7929
Abu85
HÁZIGAZDA
válasz
szupersanyi
#7929
üzenetére
A Comic-conon Battlefront Radeon Furykon futott úgy tudom Mantle módban. Szerintem támogatni fogja a Vulkan API-t is, csak lehet, hogy az a mód ma meg nem olyan stabil.
-
Abu85
HÁZIGAZDA
Igazából az AMD sok információt nem oszt meg. A vállalat szerint az IT sajtó színvonala összeomlott az elmúlt években és próbálnak mindent egyszerűen megmagyarázni, hogy a nagy számú abszolút képzetlen újságíró is megértse. Na most itt az a gond, hogy így elindulnak a spekulációk, és ami a legnagyobb baj, hogy a média trehány lett általánosságban, és több oldal már a helyreigazitasokat sem teszi közzé. Egyszerűen azért, mert romlana az oldal megítélése a hozzáértés megkérdőjelezésével. Egyszerűen elfogadják, hogy fullba nyomják a hírekben a kretént mert arra nagyon kis számú olvasó jön rá. Ellenben a full spekulációk még teljesen tévesen is kattintásvonzók.
-
Abu85
HÁZIGAZDA
Van és lesz. Világosan elmondta a linkelt videóban Huddy, hogy a LiquidVR nem működik nélküle. Tényleg nem bonyolult, ami történik, csak el kell olvasni az AMD blogjában a közleményeket, vagy meghallgatni ezt a videót. A cél a problémamegoldás. Ha van valami probléma, amire nincs szabványos válasz, akkor az AMD azonnal csinál rá sajátot. Két éve az overhead volt a gond, most a VR lesz az. Ezek persze idővel kikötnek a szabványban, de annyira lassan reagálnak a szervezetek a piac változásaira, hogy az AMD nem akarja megvárni azt a 2-3 évet, amíg egy adott problémát megoldanak. Megoldják maguk a többiek pedig ráérnek évekig trécselni az ARB-ben és a GAB-ban. Bár nyilván az, hogy az AMD egy adott problémára megoldást kínál lényegében radikálisan felgyorsítja a szabvány megszületését, mert hirtelen mindenkinek érdeke lesz tartani a lépést.
Az lenne a meglepő, ha te nem ismernéd.
Viszont az gond, hogy sokan nem ismerik, és beszélni senki sem beszél róla. Erre akartam reflektálni. Egyszerűen húzzuk az időt, de egy év múlva sem lesz könnyebb elmagyarázni a vásárlóknak, hogy mik a hátrányok, ezek miért keletkeznek, és mit lehet ellenük tenni. -
Abu85
HÁZIGAZDA
Az a legnagyobb kérdés, hogy mi alapján ítélünk, amit a média ír, vagy amit az AMD mond, mert az AMD a Mantle-ről ezt mondta az E3-on. [link] - 6. percnél kezdődik. Konkrétan kijelentették, hogy a Mantle célja olyan problémákat megoldani, amelyeket a szabványos API-k nem oldanak meg. Ez korábban volt a small batch probléma, illetve az egész többletterhelés megszüntetése a hatékonyabb kihasználással. Ezt az elkövetkező fél évben a szabvány is megoldja. Az új probléma a VR, amire ott a LiquidVR, ami a Mantle-re épül. Valószínűleg 2017-ben erre az irányra is lesz szabványos megoldás, de addigra lesz megint pár probléma, amire az AMD-nek lesz megoldása azonnal, és két éven belül az egész átmegy szabványba.
Amit egyébként a média írt ezzel kapcsolatban, hogy a 300-as szériára és az új Radeonokra nincs Mantle az nem igaz. Van Mantle és működik. Még a 15.7-es meghajtóban is frissült, támogat minden GCN-es Radeont. Amiről szó van, hogy a BF4 nem támogatja hatékonyan a GCN3-at, és ehhez a játékhoz nem készült javítás, de minden más játék támogatja ezt az architektúrát, még az újabb Frostbite-osok is. És ez egyébként nem a Mantle hibája, hanem maga az explicit API jellegzetessége. Egyszerűen egy új architektúra még kis változások mellett is lassulásokat hozhat egy olyan programban, amelyet nem optimalizáltak arra az architektúrára. Ez így lesz a DX12-vel és a Vulkan API-val is. Kijön egy DX12 és Vulkan játék, és nem biztosított, hogy mondjuk a Pascal és a GCN4 jobban fogja futtatni, mint a Maxwellv2 vagy a GCN3, vagy minden korábbi architektúra. Ez az explicit API hátránya. Persze valamit valamiért. Sajnos vagy rossz hatékonyságú lesz a rendszer, de kiszámítható, vagy jó hatékonyságú, de kiszámíthatatlan. Átmenet nincs. Szerintem ez az ami még a média nagyon nagy részének egyáltalán nem esett le.
Igazából az MS, illetve a Khronos Group sem hirdeti nagyon, hogy ez egy reális probléma. Nyilván miért is mondanák el, magára a piacra nézve problémás az explicit API-k egyetlen hátránya, mert bőven előfordulhat, hogy váltanál új VGA-ra, de éppen a kedvenc játékodban lassabb, mint ami épp a gépben dolgozik. Ezt egyébként valamikor el kell kezdeni kommunikálni, mert szerintem sokkal rosszabb lesz, ha a PC-s vásárlóbázis önmaga jön rá erre, de nyilván komoly kérdés, hogy hogyan kommunikáld le a piacnak, hogy az új API-kkal az újabb VGA-k nem feltétlenül lesznek gyorsabbak, függetlenül a TFLOPS-októl és a GB/s-októl. Ezt az információt nagyon nehéz pozitívan átadni.
-
#7821
Abu85
HÁZIGAZDA
Petykemano
#7818
Abu85
HÁZIGAZDA
válasz
Petykemano
#7818
üzenetére
Valami szervercuccot. Nem tudom pontosan.
(#7819) Egon: A konzolok esetében az AMD64 x86 módjai szoftveresen vannak letiltva nem hardverben. Az egy érdekes jogi kérdés, hogy ez így jó-e. Elvileg a licenc a végtermékre vonatkozik, tehát jogi értelemben lehet mondani, hogy a végtermék maga a konzol mint csomag és nem a processzor. Az valóban igaz, hogy az Xbox One és a PlayStation 4 jelenleg csak teljes AMD64 kódot futtat, de például az Xbox One esetében ez szinte biztosan megváltozik a Windows 10-zel, mert az univerzális áruházból kaphat majd más módban futó kódot.
-
#7817
Abu85
HÁZIGAZDA
Petykemano
#7816
Abu85
HÁZIGAZDA
válasz
Petykemano
#7816
üzenetére
A konzoloknál olyannyira kőbe vésett a hardver képessége, hogy még az errata problémákat sem javítják, hanem az első hardverrevízió kiadásánál lezárják az egészet, és az újabb lapkák pontosan ugyanazokat a hibákat fogják tartalmazni. Ezeket természetesen dokumentálják.
A konzol mindig szoftveresen fejlődik. Új API-kkal, új SDK-kkal, az új firmware-rel, illetve ezeket összesítve a játékokkal. A fejlődést az biztosítja, hogy a hardver elérhető 8-10 évig, így megéri megismerni. Úgy fogd fel ezt, hogy ha vennél egy mai PC-t, és azon elvégeznék a fejlesztők ugyanazokat a kutatásokat, akkor egy adott program az újítások beépítésével 2-3 év alatt a 4-5x-örösére gyorsulna. De mivel a PC nem fix hardver, így nem éri meg pénz áldozni az architektúrák kifacsarására.
-
#7812
Abu85
HÁZIGAZDA
Petykemano
#7810
Abu85
HÁZIGAZDA
válasz
Petykemano
#7810
üzenetére
A 14 nm-es váltás nem jelenti azt, hogy a lapka magasabb órajelre kapcsolható, illetve alacsonyabb lesz a fogyasztása. A konzolok tervezésénél nem tipikus igények játszanak főszerepet. Itt az MS és a Sony is fix órajeleket kér, ha a program elindul. Ilyen körülmények között a váltás nem hoz majd olyan előrelépést, mint amit PC-n tapasztalhatunk majd. Nagyrészt nem a kisebb csíkszélesség miatt csökken egy lapka fogyasztása, hanem a tervezés következtében, hogy egyre jobbak legyenek a turbók stb. De ilyenek a konzolban nincsenek.
A konzoloknál a sematikus dizájnt nem szokott változni, tehát az sem kizárt, hogy fogyasztásnövekedést hozna a kisebb csíkszélességre való átállás, emellett a 28 nm-es node még mindig a legolcsóbb, tehát másra áttérni ma nem éri meg. -
Abu85
HÁZIGAZDA
Még annyit tennék hozzá, hogy ma sokkal nehezebb elnyerni egy konzoldizájnt, mint 2004-ben. Az X360 és a PS3 gyakorlatilag meglévő, némileg átírt API-kkal kezdtek. A Sony viszont hozott egy teljesen nulláról írt libGCM-et a PS3-ra, és ezt az MS is lekövette az X360 életciklusának vége felé. A PS4 már eleve egy libGNM-mel kezdett, és a libGNMX, mint wrapper opció. Az X1 picit lemaradt, de sokaknak elérhető már a D3D mono. Amiatt, hogy a konzol megjelenésekor kvázi rögtön van low-level API, az elsődleges rosta az GPU-architektúra dokumentációja lett, tehát eleve olyan rendszert kér a Sony és az MS, amelyhez a gyártója nyíltan áll hozzá, értsd elmondják hogyan működik. Ezért ma konzoldizájnra gyakorlatilag két cég esélyes: AMD és Imagination.
-
Abu85
HÁZIGAZDA
Bizonyosan meg lesz a mostani konzoloknál a 8-10 éves életciklus. Ez a piac csak így működőképes. A Microsoft és a Sony a fejlesztők felé ezekre garanciákat vállal, mert minden egyes konzolgeneráció leváltásánál gyakorlatilag azt mondják, hogy az előzővel nem kompatibilis, újra kell írni mindent, ha jól akarod használni, de ez jó üzlet lesz, mert 8-10 évig itt lesz az alap. És a fejlesztők számára ez az életciklus garantálja, hogy a befektetésük biztosan megtérül.
Azok a fejlesztések, amelyek ténylegesen erre a konzolgenerációra jönnek, nagyjából 2016-2017-ben érnek be. Ezek nagyrészt szoftverek, és ha az MS és a Sony 2017-ben már új konzolt hoz, akkor a fejlesztőknek az egész egy marha nagy pénzkidobás volt. Még akkor is, ha az esetleges új konzolok is AMD64 és GCN párosítások. -
#7784
Abu85
HÁZIGAZDA
huskydog17
#7782
Abu85
HÁZIGAZDA
válasz
huskydog17
#7782
üzenetére
Az 1.0 is így néz ki. Ezen is látszik a rossz élsimítás és átlátszóság. De nem ez az igazi gond, hanem a zártság. Ez egy izolált környezet. Úgy van megírva alá a motor, hogy a Hairworks összes eleme aktív lehessen. Mi van, ha a játék motorja valamit nem támogat? Például az önárnyékot, ahogy a Wither 3 esetében. Nem tudod módosítani, így le kell kapcsolni az effekt önárnyékát. Mi van, ha az MSAA-t nem támogatja a motor? Ezen működik az AA, ha nincs meg az alap hozzá, akkor le kell kapcsolni a teljes AA-t, ahogy Monster Hunter Online esetében. [link]
Ezek teljesen behatárolják a Hairworks minőségét, mert nem tudod rászabni a rendszert a motorra. -
Abu85
HÁZIGAZDA
Inkább a képminőség romlása nélkül. Az x16 beállítás után már nincs előnye a további tesszellálási szinteknek. Teljesen felesleges egy haj-/szőrszálat 350-380 szakaszból felépíteni. Nem ezen múlik az effekt minősége, mert a szőr esetében egy pixelen belül lesz körülbelül 30 szakasz, amelyből egy az, ami számít. De viszont rossz vagy nincs önárnyékolás, élsimítás és átlátszóság. A HairWorks legnagyobb problémája az, hogy annyi erőforrást elpazarol a tök felesleges számításokra, hogy a végeredményben meglátszó számításokra már nem marad elég idő. Ezért néz ki olyan spagettiszerűen a HairWorks-féle haj. Nincsenek minőséget adó számítások rajta. Maga az alap nem tűnik rossznak. Akár jobb is lehetne, mint a TressFX, ha hozzáadnák a minőséget és a sebességet.
-
Abu85
HÁZIGAZDA
A Hitman esetében mint mondtam nem tudni, hogy mit döntenek a fejlesztők. A Glacier 2 jelen pillanatban csak az AMD saját API-ját támogatja a low-level megoldások közül. Nem valószínű, hogy a két szabványos megoldás közül mindkettőt beépítik. Szóval vagy DX12 lesz belőle vagy Vulkan. Decemberre mindkettő elérhető. Azt tudom, hogy az Eidos a Dawn esetében azért választott DX12-t, mert rendszer része lesz a PureHair és PureMaterial, ami a TressFX 3.0-ra épít és ez egy HLSL-ben írt technológia. Az I/O Interactive ezt nem tervezi alkalmazni a Hitmanben. Ez nekik szabadabb választási lehetőséget ad.
Az EA Vulkan API-ra lő. Ők a HLSL-t el akarják hagyni. Vagy csinálnak saját nyelvet, vagy OpenCL-t használnak.
-
Abu85
HÁZIGAZDA
Ezért írtam low-levelt, ha elolvasod. Ez jelenthet három különböző API-t jelenleg. Például az EA a DX12 elé helyezi a Vulkan API-t, mert nekik az az átállás könnyebb. Főleg source-2-source fordítóval. Gyakorlatilag lefuttatják az AMD API-jára írt kódjukon és van lesz egy szabványos kódjuk hozzávetőleg két óra munkával. A DX12-re való átállás valószínűleg eltartana egy hétig, mert azt a kódot az Xbox One-ból kellene venni, és pár effektet bele kellene még műteni.
-
Abu85
HÁZIGAZDA
(#7684) rocket - erre akart válasz lenni csak félrenyomtam.
És csináltak belőle egy Windows 10 exkluzív címet. Hol a probléma? Lesz Windows 10 PC-re és Xbox One-ra is. Az övék az IP.
Az indie és az AAA nem zárja ki egymást. Mint írtam a Star Citizen AAA és egyben indie is.
-
Abu85
HÁZIGAZDA
válasz
Televan74
#7730
üzenetére
A következő évben a HBM1/2 termelése ténylegesen felfut. De nem valószínű, hogy az NV elsőre vállalja. Azért elég kockázatos egyszerre architektúrát, csíkszélességet váltani a nagy teljesítményű interposerekhez való kötelező igazodással. Ezek önmagukban is problémásak, egyben pedig...
A Pascal gaming szempontból igazából azért fontos, hogy az NV-nek is legyen egy VR-re tervezett hardvere, mert az AMD-nek már ott a Fiji. Ahogy látod mindegyik VR játékot fejlesztő cég AMD-n demózott az E3-on, mert nem tudnak mást tenni. Lényegesen jobb az AMD VR csomagja, és ez megvásárolható az Oculus startra. Az NV ezt lekési, de a lényeg, hogy minél hamarabb hozzák a finomszemcsés preempciót és a GPGPU compute fejlesztéseket a Pascallal, mert ez kell a VR-nek.
-
Abu85
HÁZIGAZDA
Nem. Azt mondtam, hogy low-level API-t fog támogatni, és a Glacier 2 Mantle-t támogat is. Innen pedig lehet dolgozni másra is. Ez már az I/O Interactive döntése. Azt nem tudom, hogy a DX12-t választják-e vagy a Vulkan API-t. Csak annyit, hogy a motorba már be van építve a Mantle és a TrueAudio. Még akár az is lehet, hogy DX11 és Mantle lesz csak, bár ezt nem tartom valószínűnek, amikor az AMD-nek lesz Mantle->Vulkan source-2-source fordítója.
-
Abu85
HÁZIGAZDA
Mivel kezdettől fogva crossmultira van tervezve a Fable Legends, így nehezen képzelhető el, hogy csak Xbox One-ra jön. Főleg úgy, hogy be van jelentve, hogy itt lesz PC-n is, persze csak Windows 10-hez. De nem ez lesz az egyetlen Windows 10 only játék idén. Jön egy másik Unreal Engine-es DX12 cucc ősszel.
Én is számoltam több indie címet. A Star Citizen is az például. Még mindig nem tudom, hogy az MS-nek honnan van a száma, de mint mondtam ők biztosan jobban informáltak.
(#7676) Laja333: Pláne úgy, hogy a Vulkan binding modellje egyedül GCN-en nincs emulálva. Persze ettől a shaderben kell megadni a memóriaelérést, de a CPU fogja betölteni és nem a GPU maga. Majd a Valve megköszöni a PC Worldnek, hogy aknázzák alá az üzletüket.
-
Abu85
HÁZIGAZDA
A Fable Legends egy crossplatform multis játék lesz. Az MS az év elején jelentette be, hogy egyszerre jön PC-re és Xbox One-ra, és két platformon lehet majd egymás ellen játszani.
A saját számaim nem slide-ból vannak. Egyszerűen megkérdeztem, hogy ki támogatja a low-levelt az érkező játékokban. Aki visszaírt annak behúztam magamnál egy strigulát. Sokan nem írtam vissza egyébként. Lehet, hogy ezért van az MS-től jóval nagyobb számot. Ők biztosan sokkal jobban informáltak nálam.
(#7664) gbors: Az is lehet. Én mindenesetre inkább irkálok külön a fejlesztőknek, az a biztos. Lassan válaszolgatnak.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
Inkább 20-30 ms közötti értékekről volt szó. Tartósan 60 ms feletti érték az már konkrét akadás. De értem. Az SLI így jó.
Megjegyzem nem véletlenül álltak le a frame-pacing tesztek. Úgy nem éri meg pénzelni a tesztlaborokat az FCAT-hoz szükséges (igen drága) kütyükkel, hogy az SLI ebben a tekintetben rosszabb lett az elmúlt időszakban, mint a Crossfire. -
Abu85
HÁZIGAZDA
Igen, sajnos ez történik, amikor a várt adat nem érkezik meg. Ilyenkor a GPU nem tud mit csinálni, mint vár rá. Ezért lett lecserélve a hidas megközelítés, mert már 2560x1600-ban is látszott a probléma, csak még nem volt olyan jelentős, mint 4K-ban.
Maga a jelenség nem az SLI sajátja. Ugyanúgy felfedezhető a hidas CF-en is. Egyedül az XDMA CF immúnis rá. -
Abu85
HÁZIGAZDA
Annak nem sok köze van hozzá. Az a gond, hogy az XDMA a teljes PCI Express sávszélt felhasználhatja interframe kommunikációra, míg az SLI hídja csak 500 MB/s. Egyszerűen ez kevés. Nem lehet vele mit csinálni. Ugyanúgy kevés lenne az AMD CF hídja is. Azon is látszik, hogy egyszerűen olyan limites lesz 4K-ban, mint az SLI. Még akkor is, ha 900 MB/s-ot tud. Sajna ez van.
-
Abu85
HÁZIGAZDA
Annyira azért nem érdekes. Korábban is kiderült, hogy 4K-hoz a hidas technológia korlátozó. Megfogja a skálázódást és rontja az egyenletességet. Radeonnál szimplán az XDMA előnye látszik. Jobb lesz tőle a skálázódás és kevesebb lesz az akadás. Majd a DX12-nél a híd úgyis elveszik.
-
Abu85
HÁZIGAZDA
A dedikált GPU-k jövője egyértelműen az Inteltől függ. Nekik lejár az FTC-vel kényszerítése idén szeptemberben, amely arra kötelezte őket, hogy a dedikált GPU-knak x16-os PCI Express csatolót kell biztosítani. Nyilván ez nem kedvezett az Intel terveinek, de a hatóság szava döntött. Ez 2010 augusztusa óta ismert volt. A piac szereplői 5 évet kaptak a saját lábra állásra. Szeptembertől kezdve az Intel jóakaratától függ, hogy létezhetnek-e vagy sem.
-
Abu85
HÁZIGAZDA
Azt nincs értelme kivásárolni, mert akkor csak dedikált GPU-ként használható. A dedikált GPU-k eladásai éves szinten folyamatosan esnek, és ez már öngerjesztő, mert azért emelkednek az árak és lassul a generációváltás, hogy a visszaesést kompenzálják, ami újabb visszaeséshez vezet, ami újabb áremelést von maga után kompenzálás céljából, és így megy majd tovább addig, amikor már nem éri meg fejleszteni sem erre a piacra. Senki sem fog egy olyan piacra vásárolni, amelyiknek a jövője gyakorlatilag borítékolhatóan borús.
-
Abu85
HÁZIGAZDA
Ha fel akarják vásárolni az AMD-t, akkor az ellen az Intel kardoskodni fog, mert gyakorlatilag az arra irányulna, hogy a Microsoft kitegyen mindenkit a platformjából, és saját hardvert tervezzenek. Akkor az Intelnek tényleg a bérgyártás marad. Nyilván ez nem túl kedvező számukra, így egy tényleges ajánlat esetén ahol lehet megtámadják a lehetséges akvizíciót.
-
Abu85
HÁZIGAZDA
Ha ilyen megtörténik, akkor az MS konkrétan egy második Apple lenne. Itt nem csak a konzolról lenne szó, mert az Xbox One-ért tök felesleges vásárolni, ha megveheted magát a kész hardvert, ráadásul kiszámíthatóan, hiszen előre rögzítve vannak a feltételek, és így a kockázat alacsony.
Csak úgy van értelme kiadni egy csomó pénzt, ha utána minden Windows platform alá saját hardvert raknak, de ez nagyobb váltás lenne, mint amennyit önmagában megér. Jórészt azért, mert lapkákat most is tudnak vásárolni, illetve a Qualcomm a jövőben sem fogja nekik azt mondani, hogy nem szállítanak WP-be platformot, és az AMD is bármikor készít nekik újabb egyedi megrendelésre egyedi lapkát.A Sony MIPS+Imaginationre építene a jövőben, ha megtörténik. De az aktuális szerződést nem lehet felbontani.
-
Abu85
HÁZIGAZDA
válasz
#35434496
#7386
üzenetére
A Microsoft SDK-jából származik. Van benne számos sample, hogy hogyan lehet a DX12 képességeit használni, és ezekre programok is vannak. Az async shader nevű program tartalmazza az aszinkron compute kihasználhatóságát, és azt már lehet mérni, akinek van SDK-ja. Persze még a mostani driverekkel, és mint mondtam az Intel tiltani fogja, mert nekik ez a képesség lassít.
Az aszinkron compute implementálása egyébként sokat számít. A grafikus vezérlők ma pipeline-okat futtatnak egymás után. Ezért van alacsony kihasználtságuk, mert a pipeline-ok sorban érkeznek és egyszerre csak egy fut. Ha kész, akkor jön a következő, és a következő, és a következő, és egyszer elfogynak, amikor kész lesz a képkocka. Persze akkor meg lesznek újak. Az async shader annyit tesz, hogy a queuing modellt a mai soros formáról megváltoztatja párhuzamosra. A mai modernebb GPU-knak van pár compute parancslistája, és azokon fogadhatnak compute pipeline-okat. Ezeket úgy be lehet tölteni, hogy bizonyos compute pipeline-ok párhuzamosan lefussanak grafikus pipeline-ok mellett, vagyis ne soros legyen a feladat végrehajtás a grafikus vezérlőkön belül. Ehhez a DX12 azt követeli meg, hogy a hardver képes legyen egyszerre fogadni legalább egy grafikai és egy compute parancsot. Persze lehet többet is. Ezek futtatásának ütemezése a fejlesztők feladat. Itt azt kell figyelembe venni, hogy a különböző architektúrák milyen hardverállapotban képesek compute shadert futtatni. A GCN például stateless, vagyis akármi lehet a hardverállapot mindig tud mellette compute shadert futtatni. A Maxwell 2 már a pixel/ROP state-hez köti ezt, ami kedvezőtlenebb dizájn. Például, ha egy program mondjuk tesszellálás mellett akar compute pipeline-t futtatni, akkor azt a GCN-en megteheti, de a Maxwell 2 állapotváltásra kényszerül, vagyis a hardveren belül egyszerre úgy sem futhat a hull/domain shader és a compute. Erre egyébként vannak optimalizálási javaslatok, mint az, hogy a legjobb a compute feladatokat a shadow mapok generálásakor futtatni, mert akkor a Maxwell 2-n a pixel/ROP state van betöltve. Az Intel problémája pedig speciális. Ők azzal vesztenek, hogy async shaderrel az IGP órajele alacsony lesz. Egyszerűen olyan magasra fut a terhelés, hogy nem tud turbózni, így 1200 MHz helyett 300 MHz-e történő számításra kényszerül. Nyilván ez okozza a lassulást, és ezért lesz letiltva a funkció. A GCN1 hatékonysága pedig azért van a GCN2/3 mögött, mert vannak hátrányosabb tényezői, mint a lassabb kontextusváltás. Persze ez relatíve még így is nagyon gyors, csak nem annyira jó, mint amit a GCN2/3 tud. -
Abu85
HÁZIGAZDA
válasz
mcwolf79
#7378
üzenetére
Nem láttam az üveggömbben, hanem kaptam eredményeket. Ma csak egyetlen program van, ami aszinkron compute-ot használ, ami a Thief, de csak az 1.8-as patch után. Ebben látható valamennyire az aszinkron compute, igaz, hogy lightos a terhelés, de látható a változás.
Itt a GCN2 és GCN3 az aszinkron compute miatt nagyon elhúz a minimum fps-ben mindentől. Még a 280-től is elhúz a 380, de utóbbi ugye egy átnevezett 285. És ez látszik egyébként a GCN2/3 kártyák fogyaszátásán és megelegédésén is, hogy azt az extra teljesítményt nem egy párhuzamos dimenzióból szedik elő. Itt az is látszik, amit korábban írtunk, hogy a GCN1 aszinkron compute mellett nem annyira hatékony, de még így is a második leghatékonyabb csomag a GCN2/3 után. A GCN2/3 hatékonysága nagyjából azonos.
Vannak egyébként erről DX12-es tesztek már, mert az AMD készített rá az SDK-ba egy példaprogramot. Ott a GCN1 nagyjából +15-25%-ot hoz. A GCN2/3 +35-45%-ot. A Maxwell 2 +5-15%-ot. A Broadwell IGP-je -45-60%-ot, de mivel ez negatív skálázódás, így ezt a képességet az Intel le fogja tiltani a driverben, hogy ne lassítsa a félretervezett hardverdizájn a kódot. -
Abu85
HÁZIGAZDA
Lehet, hogy kockázatos volt, sőt, biztos is, de átnyomták a változást. Tehát innentől kezdve elkönyvelhetik, hogy jól döntöttek. Egyébként nyilván semmi garancia nem volt arra, hogy a Microsoft és a Khronos elkezd építeni API-kat az AMD ötleteire és konkrét kutatásira építve, de megtörtént, ez ma már tény.
(#7275) rumkola: A kernel driver eltűnik. Ez már ismert. A user mode driver marad meg. Bizonyos allokációs funkciók és a shader fordító lesz benne. A memóriavezérlés, az allokációs stratégia, a hazárdok kezelése, stb., mind átkerül az alkalmazásba egy univerzális driverbe, ha úgy tetszik.
-
Abu85
HÁZIGAZDA
Low-level API-nál, jelen esetben Mantle-nél ugyanaz van, mint a Tonga cGPU-val. Amelyik programra nincs memóriaoptimalizálás ott az újabb architektúrára épülő GPU lassabb. A Battlefield 4-hez nem készült ilyen patch. A többi játékot már patch-ekkel felkészítették a Tongára (vagy eleve jól adták ki), és ebből az optimalizálásból a Fiji is profitál, bár nem feltétlenül ugyanúgy, ahogy a Tonga.
Ez a low-level API átka. Ha jön egy zsír új architektúra, akkor simán lehet, hogy a felét sem tudja az előző generációnak, csak azért, mert a programban van az, ami régen a kernel driverben volt, és az a programban nyilván nem cserélhető egy új driverrel.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#6760
üzenetére
Itt programozástechnikai dolgok is beleszólnak. A Maxwell egy dologban nagyon különbözik a Keplertől. Nem kell speciálisan etetni egyetlen SIMD-jét sem, mert mindegyikhez van elég szál. A Kepler esetében a hatból csak négy SIMD kaphatott szálakat, és a maradék két SIMD esetében független feladatokat kellett speciálisan leprogramozni, amit aztán a shader fordító megpróbált befűzni, hogy ki legyen használva a multiprocesszor maradék 33%-a is. Ez eléggé melós dolog, és sokszor nem lehet jól megoldani. Ma valószínűleg ez nem fókusz, és efféle optimalizálás nélkül a Kepler elveszti a shader processzorainak 33%-át. De erre továbbra is lehet optimalizálni, csak az NV nem fog.
A GTA5-nél kísérleteznek a mikrokóddal. Továbbra is gond, hogy a hiba alaplap- és nem kártyafüggő.
-
Abu85
HÁZIGAZDA
Szerintem a Kepler annyira nagy probléma elé nem néz. A gondok leginkább az újabb TWIMTBP játékokra vonatkoznak, de más játékokban nincsenek ilyen problémák. Gaming Evolved játékokban például szinte sehol. Nyilván az nem jó, hogy az NVIDIA elkezdte az amortizációt a Keplernél, de úgy gondolom, hogy maximum pár TWIMTBP játék esetben lehet teljesítményprobléma a Keplerrel. Nyilván ez üzlet. Egy elégedetlen tulaj hamarabb vált, mint egy elégedett. Valszeg az NV kiszámolta, hogy a keménymagot ugyan elvesztik, mert ők utánajárnak, hogy a Kepler csak vissza van fogva, de amíg a felméréseik azt mutatják, hogy 10-ből 9 felhasználó nem tud felbontást váltani, addig megéri szétszopatni a vásárlóidat. Az az egy hozzáértő vesz mást, de a maradék kilenc ~fele talán rávehető, hogy évente cseréljen.
-
Abu85
HÁZIGAZDA
Hát elég jó élményt adhat. De nem kell itt egymillióra gondolni, elég a 200 ember. És a szinkronizáció mindenre kiterjed, vagyis mindenki ugyanazt látja.
Vannak számításigényes megvilágítási technikák. Abban én sem vagyok biztos, hogy jó irány, de gondolkodni kell a Grid költségeire. A felhő átka az üzemköltség melletti alacsony kihasználatlanság. Akkor lehet hasznot termelni belőle, ha van sok előfizető, és ha valaki esetleg nem akar előfizetni teljes játék streamre, majd előfizet a megvilágítás streamelésére. Ha akarod, ha nem ez szükséges ahhoz, hogy a kiépített gépeket fenntartsák. Az NVIDIA keresni fog minden lehetőséget, hogy a felhasználóbázisából előfizetői bázist csináljon, különben le kell bontani a Grid központokat.
-
Abu85
HÁZIGAZDA
Abból a szempontból innovatív, hogy valószínűleg felhő nélkül nem tudnál egymillió játékost bevágni egy nagy és interaktív MMO-ba, mert meghalna a rendszer a szinkronizálásnál.
Ugyanúgy vannak olyan grafikai problémák, amelyekre a kliens oldalán nem létezik megoldás.
A felhőben csak az a nehéz, hogy milyen legyen az előfizetés. Nyilván nem fog ingyenesen üzemelni, mert a gépeket fenn kell tartani. Most is csak azért érhető el ingyen a Shieldről, mert tesztelgetik. Amint ki lesz alakítva a tartalom, számos exkluzív rendszerrel pénzt fognak érte kérni. Valószínűleg annak függvényében, hogy a mai tesztelgetésen milyen költségeket mérnek. -
Abu85
HÁZIGAZDA
Teljesen mindegy, hogy mi alakítja a cégek jövőképét. Egy innovatív gondolat, vagy az a probléma, hogy a piac a termék alatt idővel megszűnik. Mindkettőre ugyanúgy kell reagálni. Vinni előre a gondolatot.
X86 licenc nem szükséges már. A Windows 10-et is felrakod ARM-ra, és működik, ezen belül ott van az univerzális áruház, ami pont azért létezik, hogy hardverfüggetlenül legyen kezelve a rendszer. Ha Windows 10-es a cucc, akkor eléred az áruházban a programokat.Az NV gondolata a Griddel nem egyedi. A Microsoft is felhőből irányítja a Forza AI autóit az Xbox One-on. Az NV-nek az ötlete csak annyiban különbözik, hogy ők grafikát számoltatnának inkább a felhőben.
-
Abu85
HÁZIGAZDA
AZ NV-nek a Gridje egy eléggé életképes dolog lehet a jövőben. Vannak olyan tervek, hogy MMO-kat terveznek a felhőbe és ténylegesen ott lesz szimulálva az egész, vagyis nem kell a gépek között szinkronizáció. Mindenki pontosan ugyanazt fogja látni. Vagy az effektek felhőbe ültetése egy nagyon érdekes projekt, amely évekkel korábban kezdődött, és a Grid már megadja rá az alapot. Ezzel a koncepcióval a felhő kiszámolhatja a megvilágítást a játékba és a képkockát befejezi a kliens. Ami ezekben még kérdéses az a fenntarthatóság, mert egyelőre nehéz látni, hogy miért mennyi előfizetési díjat szedjen be az NV. Illetve az is kérdés, hogy mi legyen azzal, aki nem akar előfizetni, vagy elmegy a net, tehát alap megvilágítás a kliens oldalon is kell.
-
Abu85
HÁZIGAZDA
válasz
MiklosSaS
#6711
üzenetére
Mivel bénázott? Tényleg nem értem. Az Intel is mutatott Xeon rendszereket FirePro S-sel, pedig nekik ott a Xeon Phi. Ők sem bíznak a Xeon Phi-ben? Mindenki rajtuk röhög?
Az általános számítás nem olyan egyszerű, mint a grafikai, mert ott számos hátráltató tényező van. Az Intel architektúrájával az egyik, hogy kapásból elveszti a számítási teljesítményének a felét, ha függőség van a kódban, ami azért elég jellemző GPGPU-ban. Nem véletlen, hogy az AMD és az NVIDIA inkább birtokláslimites architektúrákat tervez, mert nem előnyös a függőséglimit. Erre majd az Intel is áttér, csak nem olyan egyszerű megtervezni.
-
Abu85
HÁZIGAZDA
Ez még a jövő, nem a történelem. Be is mutogatták a Builden az Unreal Engine 4-gyel, illetve a Stardock is elmondta, hogy nekik is olyan a rendszerük, hogy az IGP-t is beszámítja a feldolgozásba, ha van. Erről már volt is szó, hogy a 290X-szel egy A10-7850K +20%-ot ad, ha az IGP-je aktív. Ez egy nagyon fontos lépés, amit a Microsoft letett a WDDM 2.0-val és az IOMMU módjával, mert alapvetően erre épül számos Xbox One játék, csak ott statikus particionálással dolgoznak a fejlesztők. PC-n ez nem kell, mert eleve ott az IGP, de a funkciót lehetővé kell tenni. Valószínű egyébként, hogy a pathfinding innen szivárgott le a PC-s kutatásnak is.
A váltásnak az elsődleges előnye, hogy az IGP kihasználása a CPU-s SIMD-ekkel szemben olcsóbb és egyszerűbb. -
Abu85
HÁZIGAZDA
válasz
#85552128
#6702
üzenetére
Nem azt mondtam, hogy elég bele, hanem azt, hogy nem egyértelmű a piac iránya a gyártók számára. Még az Intel számára sem, és ezért csinálnak két processzort ugyanabba a kategóriába. A Skylake verzió a processzorrészre, míg a Broadwell-K opció az IGP-re gyúr. Az a baj, hogy annyira kiszámíthatatlanok most a fejlesztések, hogy nem tudják eldönteni melyik lesz a jobb.
Ami az egészet teljesen kiszámíthatatlanná teszi, hogy a fejlesztők olyan dolgokban is gondolkodnak, amelyet egyik érintett sem tartott lehetségesnek. A pathfinding offload kutatási irány lett, és az IGP-k is rendelkeznek minimum 200-1000 szál futtatásának lehetőségével, tehát baromira jó ötletnek tartják a stúdiók ezekre átnyomni az NPC-k AI-ját.
-
Abu85
HÁZIGAZDA
Ez teljesen válasz a kérdésre. Az E3-ra építettek rendszereket, arról van videó. Az a rendszer kereskedelmi forgalomba nem kerül.
Nem kell benne hinni vagy nem hinni. Lesz egy új lehetőség, ami nyilván ki lesz használva. A gyártók előtt ott a lehetőség, hogy ezt lefedjék a megfelelő termékekkel a Quantum projektben is, ha az alaplap Mini-ITX-es és nem fogyaszt többet a proci 95 wattnál.
-
Abu85
HÁZIGAZDA
Ezek tesztrendszerek, amelyeket az E3-ra raktak össze. Mint mondtam a gyártók nem ilyet fognak összerakni maguknak. Egy LGA1151-esben és egy Socket FM2+-osban opcióban gondolkodnak. Nyilván egyébként lehetne Broadwell-K is, ami az Intelnek a DX12-höz tervezett Gaming rendszere nagy IGP-vel, de ez drágább marad, mint a Skylake, mert jóval erősebb az IGP-je és jóval jobb lesz az IGP offloadot használó játékokban. De lehet, hogy lesz olyan cég, amely Broadwell-K-t rak bele, és azzal egyik helyen sem lesz a leggyorsabb a procirésze a rendszernek, de alapvetően mindkét irányt tisztességesen kiszolgálja. Mint írtam a Mini-ITX alaplap az egyetlen követelmény, maximum 95 wattos procival.
-
Abu85
HÁZIGAZDA
A DirectX 12 (és később a Vulkan is) kínál nagyon jó lehetőségeket az IGP használatára, és sokkal többet ér az így nyerhető gyorsulás, mint amit a processzorból ki lehet sajtolni. Ráadásul azzal, hogy az IGP számol komoly vektormatematikai problémákat, a processzormagok teljesen felszabadulnak. A WDDM 2.0 az IOMMU móddal egy nagyon jó alap lesz arra, hogy az IGP teljes egészében átvegyen olyan feladatokat, mint a tartalomkikódolás, a rendezés, vagy a kivágás view frustum cullinggal. Mindegyiket sokat alkalmazzák ma a játékokban és a processzor csinálja. De mivel egyre komplexebb jelenetre van szükség, így jól jön, ha a processzormagok helyett az IGP, azaz egy teljesen szabad erőforrás meg tudja oldani ezeket az extrém módon párhuzamosítható problémákat.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#6686
üzenetére
Amit hallok az érdeklődő gyártóktól, hogy ők két opcióban gondolkodnak. Az egyik az LGA1151, míg a másik a Socket FM2+. Ezzel a két opcióval le lehet fedni a következő érát, így lehet dönteni aszerint hogy az adott játékhoz erős procirész kell, vagy erős IGP. Egyelőre nem lehet eldönteni, hogy melyik a jó út, mert nagyon vegyes a H2 játékfelhozatal. Némelyik játék egyáltalán nem használ majd IGP-t, míg némelyik játék sokat gyorsul tőle, ha a számításokat nem kell elvinni a dGPU-ig vagy nem a CPU-n kell futtatni.
-
Abu85
HÁZIGAZDA
Ez normális. A Maxwell úgy van tervezve, mint egy ultramobil GPU-architektúra, tehát nem egy nagy széles buszra van felfűzve az összes multiprocesszor, hanem a pici buszok a multiprocesszoron belül futnak át a lapkán. Ennek az előnye, hogy rengeteg tranzisztort lehet megspórolni, de hátránya, hogy ha letiltasz egy multiprocesszort, akkor a buszok egy része is eltűnik, vagyis ez negatív hatással lesz a lapka más részeire, függetlenül attól, hogy azok teljesek-e.
A memória 970-szerű particionálása attól függ, hogy le van-e tiltva az L2 cache egy szelete. Mivel itt nincs, így a teljes memória ugyanolyan sebességgel érhető el.
-
Abu85
HÁZIGAZDA
Annyit hozzátennék, hogy az UE4 támogatni fog multi-GPU-t, csak nem olyan formában, ahogy eddig megszoktátok. A DX12-be egy olyan rendszer kerül ahol az IGP megcsinálhatja a post-process munkát, tehát dGPU+IGP multi-GPU-ra befogható lesz mindegyik DX12-es UE4-es játék. Ez a mód minden olyan IGP-vel működik, amely támogatja a DX12-t, és az IGP-hez bármilyen DX12-t támogató dGPU társítható. Persze az IGP ereje alapvetően meghatározza majd a nyerhető sebességet, de ez már hardveres kérdés.
-
#6392
Abu85
HÁZIGAZDA
Malibutomi
#6391
Abu85
HÁZIGAZDA
válasz
Malibutomi
#6391
üzenetére
Nehéz megmondani, mert ilyet PC-n még senki sem csinált. Csak konzolon volt bevett szokás újraírni a szoftverinfrastruktúrát a hosszú életciklus miatt. De a konzolokból kiindulva reális lehet a +5-30% konfigurációtól és programtól függően.
Kérdezd meg Laja333-at, neki úgy néz ki, hogy van valami előzetes tapasztalata.
Egyébként ez is szerintem egy egyszeri alkalom. Általában a PC-kben hiába van 70-80%-nyi kihasználatlan teljesítmény, akkor is mire abból valamennyit befognak a driverben már rég itt az új architektúra, tehát meg sem próbálják azt, amit a konzolokkal csinálnak a nagyobb frissítésekkor. Az AMD is csak azért tette, mert tudták, hogy legalább 5 generációt építenek GCN-re. Megéri az életciklus közepére újraírni a szoftvereket, immáron tapasztalattal.
Mindegy a lényegen ez nem változtat. Ha egy fejlesztő írja le azt, hogy "the code of this feature cannot be optimized" az egyáltalán nem azt jelenti, hogy itt sok engedékenység lenne. Jó lenne tudni egyébként, hogy mi van a licencszerződésben, leginkább azt, hogy a forrást és a módosítást az NVIDIA mennyi pénzért engedi meg. Ha dollárszázezres nagyságrendet szabnak meg, akkor ez csak arra van, hogy rá lehessen mondani, hogy van forrás is, de hozzányúlni senki sem fog.
Eközben két éve tucatszámra érkeztek az 40-50%-ra is terhelő programok. A GTA5 is éppen átcsúszik ezen a rostán, ha még ma is 40% lenne a minimum elvárt szintünk, akkor a GTA5 is elbukna rajta.
Nekem azért van PC-m, mert ez a munkám, de játszani mostanában főleg PS3-on játszok. Az a baj, hogy ha egyszer rálesel egy exkluzív játékra, akkor egyszerűen mindet akarod, mert annyira brutálisak ahhoz képest, ami ma a PC-ken van. Például a Dragon's Dogma: Dark Arisen. Valami ilyesmi adrenalinlöketet várnék a PC-s játékoktól is, több tonnás szörnyekkel és taktikus csapatharccal. Fáj, hogy ezt csak egy konzoltól kapom meg. 
Olyan API-s legendák indultak el az elmúlt két hétben a magyar IT sajtóban, hogy az félelmetes. Egyáltalán mi az, hogy egyik GPU sem támogat minden DX12_1 szolgáltatást. Van ilyen, hogy DX12_1 egyáltalán?
Ú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!
Megbízhatatlan oldalakat ahol nem mérnek (pl gamegpu) ne linkeljetek.
- Gigabyte AMD Radeon RX 9060 XT GAMING OC ICE 16GB(Bontatlan)
- ASUS RTX 5090 32GB GDDR7 ROG ASTRAL OC - Új, Bontatlan, 3 év garancia - Eladó!
- PowerColor 9070 XT Hellhound Spectral White OC 16GB - Garancia 2028.05.28 - BESZÁMÍTÁS
- MSI Radeon RX 6950 XT GAMING X 16GB DDR6 Videokártya! BeszámítOK
- PC bontás - Thermaltake ház, Fsp 650W, GIGYBYTE AB350M, AMD RYZEN 5 1600x, 16GB DDR4 3000, GTX 1080
- LG 27GS60QC-B - 27" Ívelt - 2560x1440 - 180Hz 1ms - AMD FreeSync - Bontatlan - 2 Év Gyári Garancia
- iPhone 15 Pro Max 256GB Blue Titanium -1 ÉV GARANCIA -Kártyafüggetlen, MS3957, 100% Akkumulátor
- Apple iPhone 13 /128GB /Kártyafüggetlen / 12 Hó Garancia / akku: 85%
- GYÖNYÖRŰ iPhone 13 128GB Starlight- 1 ÉV GARANCIA, Kártyafüggetlen,MS3435
- Shining3D EinScan Pro 2X 3D szkenner
Állásajánlatok
Cég: NetGo.hu Kft.
Város: Gödöllő
Cég: Laptopműhely Bt.
Város: Budapest