Új hozzászólás Aktív témák
-
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.[ 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
#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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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á.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A melegedés maximum a Boost órajelet csökkenti egy picit, de ilyeneket biztosan nem okoz:
És ugyanez a jelenség megfigyelhető a hidas CF-nél is. Az is inkább az SLI frame-time-jait adja vissza 4K-ban.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Értem. Tehát a mikroakadás csak az AMD-nél hiba, az NV-nél pedig úgy jó.
(#7612) TTomax: Remélem egyszer ezt a fényévekkel jobb támogatást kimutatják a tesztek is, és nem az ellenkezőjéről adnak bizonyságot, mint most.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Honnan van ez a 70? Én ennyit biztos nem mondtam. Továbbra is kb. 25-30 low level játékról tudok jövő nyárig. Bár nem kizárt, hogy az univerzális áruház megdobja a lehetőségeket. Végülis az UE4 és a Unity már támogat DX12-t, de ezekről nem tudok pontos adatot.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Igen, de ennyi kicsire nem számítottam. Értem én, hogy a Unity-ről nagyon egyszerű DX12-re váltani egy projektet, de akkor is újra kell tesztelni. Persze az X1-re lövés univerzális áruházból biztosan nagyon hízelgő.
Meg én low levelt számoltam, ami nem csak DX12.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Fable Legends UE4 és idén jön.
Q4-ben elég nagy dömping lesz. Aztán ott a Rift megjelenése a Q1-ben. Öt LiquidVR játék jön egyszerre. És a LiquidVR csak low-level API-val támogat Mantle interoperabilitást.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ 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
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#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.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#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.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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. [ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#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.
[ 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
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.
[ 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
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ó.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.[ 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
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.[ 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
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ 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
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.
[ 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
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.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#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.[ 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
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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
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. 
Ú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.
- Vicces képek
- Musk átirányította a Teslának szánt AI-chipeket
- Ukrajnai háború
- Milyen okostelefont vegyek?
- Computex 2024: a jövőt vázolta fel az NVIDIA
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- Kerékpársportok
- Azonnali VGA-s kérdések órája
- PlayStation 5
- ThinkPad (NEM IdeaPad)
- További aktív témák...
- Suzuki Swift 2005 1.3 GLX CD AC - AndroidAuto & CarPlay
- Bomba ár! HP Elite X2 1011 G1 - m5 I 8GB I 256GB SSD I 11,6" FHD Touch I CAM I W10 I Gari
- Bomba ár! Lenovo ThinkPad T490 - i5-8GEN I 8GB I 256GB SSD I 14" FHD I Cam I W10 I Garancia!
- 8db GeForce RTX 3090 Egyben
- VAST AI - VAST AI - VAST AI - GeForce RTX 3090
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen