- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Windows 10
- Anyagi katasztrófára figyelmezteti az Apple-t a brit média
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Programozás topic
- Sweet.tv - internetes TV
- Linux kezdőknek
- Netflix
- A Google helyét akarja az OpenAI, hétfőn jöhet az AI-alapú kereső
- Asustor NAS
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
#35434496
#9506
üzenetére
Az Ashes of the Singularity az. Egy csomó játékmód nem is lesz elindítható DX11 alatt. Nem lenne meg a sebesség a futtatáshoz.
(#9507) wjbhbdux: Lesz DX12 only játék. A Fable Legends és a Rise of the Tomb Raider. De újabban arról van szó, hogy a Gears of War felújításból is kiveszik a DX11 módot, mert csak időpazarlás lenne az optimalizálása.
(#9509) gbors: Az aszinkron compute-ot minden DX12-es drivernek vissza kell jeleznie. Ezen belül jelezni kell a program felé, hogy valóban ott van a képesség a hardverben, vagy pusztán a követelmények teljesítése érdekében jelzi a támogatást. Ez azért kell, mert tisztán aszinkron compute-ra írt kód esetében a szoftveres emuláció ronthat a teljesítményen, így a programba nem árt belerakni egy alternatív kódot is, ami csak natívan grafikai parancslistába dolgozik. A driver visszajelzése alapján az egyik opció kiválasztható. Az NV drivere azt jelzi vissza, hogy tudja a hardver ezt a képességet, és ez technikailag így van, de az API és a program már nem képes értelmezni, hogy a hardver belül hogyan tud futtatni párhuzamosan feladatokat. Szerintem itt az alapprobléma az, hogy az API-nak ezt a részét az AMD építette, és a Microsoft csak úgy átvette. A GCN stateless architektúra, tehát a compute feladatok futtatásához nem kell beállítani hardverállapotot, vagyis akármit is futtat a rendszer mellette biztosan futtatható több compute feladat. A Maxwell parancsprocesszora képes fogadni a compute és grafikai feladatokat, de a compute is hardverállapothoz kötött, ha a compute feladat már hardverállapotot igényel, mint a futtatott grafikai feladat, akkor állapotváltásra van szükség, ami előfordulhat, hogy lassabb, mintha soros lenne a végrehajtás. Valószínűleg az Ashes of the Singularity ebbe a hibába esett bele, olyan compute feladatot futtat a grafikai mellett, amire a Maxwell képtelen, annak ellenére, hogy elvben a támogatás hardveres szinten is megvan, legalábbis abban a formában, ahogy az API megköveteli. Ezt úgy orvosolták, hogy a programon belül kapott a rendszer egy tiltást, hogy Maxwellen annak ellenére se fusson aszinkron compute, hogy a driver erre a támogatást hardveres szinten jelzi. Ebbe a hibába egyébként sokan beleeshetnek, mert a DX12 és a Vulkan is logikailag úgy kezeli a hardvereket, hogy azok stateless compute képességgel rendelkeznek, tehát nincs lehetőség programkódban ellenőrizni, hogy milyen feladatokhoz milyen állapot beállítása szükséges. Ezért nem jó, ha egy hardvergyártó tervezi az API-kat, mert jó eséllyel nem gondol a konkurens architektúrák működésére. Most tulajdonképpen hiába felelnek meg az Intel és az NV új megoldásai a multi-engine képességnek, ezek a kódok esetleg lassíthatják a feldolgozást. Nem véletlen, hogy az Intel drivere szoftveres szinten jelez vissza támogatást, annak ellenére, hogy megvan a hardveres is. Valószínűleg az NVIDIA számára is jobb, ha általánosan letiltják ezt a képességet, mert nem tudják majd az összes stúdió kezét fogni, és kérni a program oldali tiltást. Ha pedig ez nincs, akkor a GeForce sebességet veszíthet.
De a driver is paraméterezhető. Ma a támogatás azért problémás, mert az aszinkron compute szinkronizációt igényel, de a kiadott meghajtók ebből a szempontból nagyon korlátozottak, és esélyes, hogy a szinkronizálás lekezelése helyett inkább befűzi a sorba az elvileg aszinkron feladatot. Persze nyilván a fejlesztőknek már vannak olyan meghajtóik is, amelyek nem így működnek. Az Oxide tapasztalatai nyilván ezekre épülnek.
Egyébként nem ők az egyedüliek, akik azt mondják, hogy a GCN ebben bitang jó. A Fable Legends fejlesztői is utaltak arra, hogy az AMD-nek ez az újítás nagyon fekszik. A kérdés, hogy ebben mennyi szerepe van annak, hogy a kódokat a konzolok miatt GCN-re írják, illetve ez mennyiben rontja a konkurens hardverek hatékonyságát. Valószínűleg a Maxwellnek abszolút nem ideális az, hogy a motorokban az egész multi-engine stratégiát a GCN-ek publikált paramétereihez konfigurálják. Jó lenne tudni, hogy ha a Maxwell dokumentálva lenne, és ezáltal tudnák a fejlesztők, hogy erre milyen konfiguráció kell, akkor ez a lassulás bekövetkezne-e, vagy gyorsulást hozna az aszinkron compute.(#9512) daveoff: A Frostbite mindenképp a Vulkan irányába megy. A WDDM 2.0 használatához nem feltétlenül szükséges a DX12, jó neki a Vulkan is. A Vulkan egyértelmű előnye az EA számára, hogy nekik a vezérplatformjuk a PS4, és arra lesz Vulkan. Nincs még bejelentve, de lesz. Emellett a Vulkan API-val képesek olyan piacokat is lefedni, amelyeket ma még nem tudnak. Például Linux (SteamOS) és Android. Emellett a Vulkan hatalmas előnye, hogy van SPIR-V támogatása, tehát nem kell magukat a HLSL-hez láncolni, ami azért egy elég öreg nyelv már. A konzolokon jobb shader nyelvek vannak, és a SPIR-V lehetővé teszi azokat a képességeket PC-n is, amelyek HLSL-ben nem használhatók ki, de a konzolon már igen.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Látszólag a DX12 implementációk nincsenek normális szinten. Nagyjából megcsinálták őket stabilra, de sebesség egyelőre nincs bennük. De a stabilitás is kérdéses, abból kiindulva, hogy az ARK DX12 patch csúszik. Szóval itt a rendszer még közel sincs kész. Emellett az Oxide is írta, hogy még jönnek Win 10 update-ek a DX12-höz, és ha ez igaz (nyilván miért hazudnának), akkor maga az API sincs teljesen összerakva. Az Intel driverével pedig egyáltalán nem indul el az AotS, tehát vannak itt még gondok. Szerintem egy jó két hónap még kell ahhoz, hogy a DX12 implementációk jobban működjenek. Persze szerencsére ez régen sem volt másképp, szóval ezt valószínűleg mindenki bekalkulálta. Azt persze jó lenne tudni, hogy a meghajtók miket kezelnek teljesen és mi az, amit egyelőre csak stabilan támogatnak, de a sebességre nincsenek kigyúrva.
Igazából a Maxwellen is működik a DX12. A batch submission time jelentősen csökkent a DX11-hez képest, tehát maga az API a várakozásoknak megfelelően teljesít. A többi része a dolognak már implementációtól függ, és itt majd az NV-nek ezt ki kell vizsgálnia. De gondolom ők is tudják, hogy milyen optimalizálások nincsenek engedélyezve.
A lassulásnak egyébként lehetnek olyan okai is, hogy a DX12 változtat a működésen a DX11-hez képest. Egy csomó dolgot a driver már nem tud befolyásolni. Például a hazárdok kezelését, az erőforrások menedzsmentjét. A GDC Europe alatt volt egy előadás, ahol azt mondták, hogy az erőforrás-kezelés nehéz lesz, mert a motorra hárul a feladat, de csak egyszer kell jól összerakni és akkor oké lesz. Erre volt az a kérdés, hogy melyik architektúrára, és az MS-es csóka mondta, hogy a dokumentációk átvizsgálása után érdemes olyan irányt keresni, ami minden architektúrának úgy ahogy jó. Ez már hozhat egy olyan mértékű változást, ami csökkenthet a tempón, mert eddig a drivert ki volt gyúrva architektúraspecifikusan, míg most a programkód teljesen kiváltja, ráadásul a fejlesztőtől függ a teljesítmény is. Aztán az aszinkron compute nem csak egy DX12 only dolog. Hivatalosan az, de a DX11-nél nem a program, hanem a driver töltötte be a feladatot a parancslistába. Függetlenül attól, hogy az alkalmazás nem, a driver ismeri a hardvert, tehát ráhackelhető némi párhuzamosítás a rendszerre. Persze ez nagyon korlátozott lesz, mert szinkronizációt a driver sem tud tökéletesen biztosítani, de valamennyi sebesség nyerhető vele. Ilyen szempontból az NV DX11-es drivere elég jó volt, de ezt a kutatást teljesen kidobhatják, mert ilyenre a DX12 már nem ad lehetőséget. Ezzel az NV inkább sebességet veszít mint nyer. Szerintem több ilyen apró trükk van a DX11 meghajtójukban, aminek az előnyeit a DX12-vel teljesen elvesztik.
A jövőben egyébként nem gondolnám, hogy az NV megmarad annál a politikánál, amit most folytatnak. Láthatóan hátrányos a program oldali optimalizálásra, hogy a fejlesztők nem ismerik eléggé a GeForce-okat. Mindenképpen szükséges lesz a dokumentációk újbóli publikálása. Legalábbis más út egyelőre nem látszik, hiszen a hardvert nagyrészt az alkalmazás fogja vezérelni.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A multi-engine kötelező funkció a DX12-ben. Ezért fogadja el rá az MS a szoftveres támogatást. Maga a validátor ki fogja adni a kódvalidálásnál, hogy mely feladatok vannak rossz engine-be töltve. Szóval itt nincs olyan, hogy nem támogatja a program. Maximum nem lesz ra szinkronizálás, de ettől egy adatfeltöltésre ki fogja adni a hibát a validátor, hogy nem a copy engine-ben van a feladat.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem kamuzott senki. A DX12 specifikációja azt követeli meg, hogy a multi-engine hardveres kezelése szempontjából a hardver képes legyen minimum egy copy, compute és grafikai feladatot egyszerre fogadni. Ennek a feltételnek a Maxwell 2 megfelel. Arra már nincs előírva specifikáció, hogy ezek a feladatok a hardverek belül is futhassanak egyszerre. Következésképpen az is elfogadott implementáció, ami nem hoz gyorsulást minden kódnál. Erre nincs is meg a lehetőség, mert nagy a fejlesztők szerepe. Az NV mindig is annyit mondott, hogy támogatják ezt a képességét, amikor erre irányult a kérdés, azt viszont sosem állították, hogy ennek a használata mindig pozitiv hatással van a sebességre.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#9583
Abu85
HÁZIGAZDA
huskydog17
#9563
Abu85
HÁZIGAZDA
válasz
huskydog17
#9563
üzenetére
Gondolom a Rise of the Tomb Raider olyan fejlesztés lesz, mint a Fable Legends. A PC-s port annyi lesz, hogy az Xbox One kód kap pár sor kiegészítést, és azt tesztelik. Az MS ezért hozza ennyire közel a konzolt és a PC-t szoftveres szempontból, hogy végtelenül egyszerű legyen portolni.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az AotS-ben csak annyit csináltak, hogy a validátor javaslatait ellenére van egy olyan path, ami minden feladatot a grafikai parancslistába tölt be. Semmi sincs igazából kikapcsolva, csak az NV kérésére írták egy validátoron hibazó szabványos kódot is. Ami azért extra munka. Nyilván puszi a hasukra érte, de a legtöbb fejlesztő a validátorra fog hallgatni. Az mondjuk megint marha jó kérdés, hogy a validátort az MS miért vette át egy az egyben az AMD-től. Tudhatták, hogy az a GCN-hez van igazítva, amikor visszajelez bizonyos problémákat. Honnan a fenéből tudja egy fejlesztő, hogy a validátor javaslata jót tesz-e a többi architektúrának. Még ha rá is jönnek a kiadás előtt, hogy nem, akkor sincs már idő lényeges módosításra. Ezért kedvezőbb a Vulkan, mert ott ugyan az AMD validátora az alap, de a nyílt specifikáció miatt lehet alternatív validátorokat fejleszteni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Szerintem te nem olvastad el a DX12 specifikációját. Ezért hiszed, hogy az aszinkron compute kikapcsolható. Ekkor ezt tegyük tisztába. A multi-engine a DX12 alap képessége. A feladatok jellege alapján ezek három motorba tölthetők: copy, compute és grafika. Így kell kötelezően írni egy DX12 alkalmazást. A fences használata, ami nem kötelező, de aki async kódot írt az biztosan használja. Innen az egész async compute csak úgy kapcsolható ki, hogy az eredeti kód mellé kerül egy olyan kód, ami a validátor javaslatai ellenére mindent a grafikai parancslistába tölt. Persze ez lényegében egyenlő a kikapcsolással, de ez nem olyan munka, hogy írnak egy sort a kódba, hogy OFF és kész.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#9605
üzenetére
Pár dolog még mindig a driver feladata. Csupán a kernel driver tűnt el. Viszont a shader fordító elci működése változatlan, persze a kiszámíthatóság miatt némileg jobb lehetőségekkel. Emellett a driver meghatározhatja a lapméretet legalabbis GPUMMU címzés mellett.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Laja333
#9606
üzenetére
Az Intel a gen8-tól kezdve több compute parancslistát kezel, illetve a gen9 a Skylake-ben már képes mixált módra is, így képes egyszerre fogadni egy grafikai is több compute parancsot. Viszont az Intel ezt a képességét a driverben letiltja. Valószínűleg nem bíznak annyira a fejlesztőknek, mint az NV, hogy a hardverük miatt több path-ot írnak. Nem véletlenül olyan a DX12 amilyen. Ha a hardverben nem jó a multi-engine, akkor a driver ne jelezze vissza rá a hardveres támogatást, és akkor minden parancs a grafikai listába kerül. Ez pont azért van így felépítve, hogy a fejlesztőknek ne legyen szükséges architektúrákra butított kódot írni. Mondjuk egy Oxide megteszi, mert pénzesek, de szerintem lesz olyan, aki nem fogja extra munkában verni magát. Mondom ezt úgy, hogy szerintem az Oxide hozzáállása tényleg példás és követendő.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem. A Nano is Fiji. Valójában egyik GCN3-as GPU-ban sincs nyolc ACE. Négy ACE van két HWS-sel. Az a lényeg, hogy egy HWS pontosan arra képes, mint két ACE, tehát lehet jelezni 8 ACE-nek vagy 4 ACE-nek és 2 HWS-nek is. A HWS extra képességei, mint a finomszemcsés preempció kezelése vagy a Quality of Services támogatása HSA, illetve LiquidVR alatt használhatók ki. Később ezekre majd lesz a szabványos API-kban is támogatás, hiszen a VR-hez kell a finomszemcsés preempció.
Technikailag csupán a DX12, Vulkan és OpenCL API-kre levetítve teljesen mindegy a blokkdiagramm. A 8 ACE és a 4 ACE+2 HWS is ugyanúgy 8 OOO logikás compute motort ad motoronként 16 parancslistával.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez nem függ a CPU-magok számától. Maga a multi-engine sem függ össze a többszálú parancskreálással. Aranyszabály erre nincs, de jelenleg egy compute, egy grafikai és egy copy motor az ajánlott, vagy elterjedt. Később a compute motorok száma kettőre nőhet, de csak akkor, ha több regiszter lesz a GPU-kban, vagy a jobb IR-ek alapján (pl.: SPIR-V) ezek allokációja javul. De ma biztos nincs olyan program, ami egynél több compute motort használ.
Azt hiszem, hogy a PS4-es Dreams lesz az első, de az full compute, hiszen signed distance fields ray tracinget használ.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Dehogy is. Ez már az új Avalanche motor, persze nem aktív benne minden, mert a fő projekt a JC3, de az alap ugyanaz lesz.
A Mad Maxet valószínűleg sietette a WB, de így is jól van optimalizálva. Később meg javíthatnak rajta a patchekkel, ahogy elkészülnek az új verziók a motorbó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 konzol is ugyanazt a leképzőt használja. Bár azt nem tudom, hogy melyik eléréssel, valszeg nem a low-levellel, de a JC3 már az lesz elvileg. Az meg nem akkora meglepetés, hogy Emil Persson ért hozzá. Ő eleg durva dolgokat csinált akkor is, amikor az ATI-nál dolgozott. Kb. olyan kaliber a srác, mint Johan Andersson.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez az egész bullshit. Az NV és az AMD rendelkezik keresztlicenc szerződéssel. Még ha le is jár úgyis megújítják. 3D Stacking technikával nem lehet ekkora teljesítményt kihozni. Ha az NV-nek nem lesz Pascalja 2016-ban, akkor az azért lesz, mert zéró tapasztalattal ugrottak neki a HBM2-nek. A Hynix többször is mondta, hogy előbb mindenki a HBM1-et implementálja.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az nincs megerősítve, hogy ki nyert, de az Imagination, az Intel és az AMD futott versenyt. Valszeg behúzta az AMD. Az Intelnek semmi esélye nem lehetett, mert nem vállaltak egyedi tervezést. Az Imagination valszeg jó esélyekkel indult, de többet érhetett, hogy hasonlítson a dizájn a két nagy konzolra.
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
#9877
üzenetére
A Samsung beszállása fontos, de maximum az AMD-nek. Az NV-nek többet ér, hogy a Hynix már élesben is dolgozott HBM-es lapkán. Azért fontos, hogy a HBM-mel a véglegesítést a memóriagyártó végzi. Ez komoly felelősség.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nincs pedig. Szinte mind a piacra megy. Kb. egy tucat kártya van tesztekre globális szinten. Ilyen helyzetben gyakorlatilag az olvasottság dönt, és ebben a TechReport nem olyan jó, mint mások, sőt kifejezetten rosszak. Egész Európába két számjegyű mennyiség érkezik a Nanoból a start hetére. Lesz olyan gyártó, aki csak egyetlen egy kártyát szállít le.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#9888
üzenetére
Mert az OEM-ek vinnék már az ünnepi szezonra. Ahhoz, hogy meglegyen a kínálat novemberben, most rendelik le a készleteket. Ide megy majdnem minden Nano, mert a pici izmos lesz a menő karácsonykor, legalábbis az OEM-ek koncepciója szerint. A Nano pedig a legerősebb apró VGA.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez normális. A sima Fury csak retail termék és az OEM-ek nem rendelik. A Fury X és Nano hivatalosan retail és OEM referenciatermék. Természetesen, ha kevés készül, akkor az OEM rendelése az elsőbbség.
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
#9892
üzenetére
Látva azt, hogy az OEM-ek milyen apró csúcsgépeken dolgoznak a Nano ezekbe nagyon jó alap lehet. Az, hogy nem mindenkit érdekel a kis méret addig nem érdekes, amig sokakat érdekel. Ezt az OEM-ek egy lefedendő piacként látják.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
wjbhbdux
#9895
üzenetére
Az aktuális tervekben egyetlen gyártó sem készít speciálisan Steam Machine PC-t. Alapvetően annyi lesz, hogy lesz pár alapgép és arra telepíthető Windows és SteamOS. A gép ugyanaz, de az előlapi logó eltérő. A legtöbb Steam Machine egyébként továbbra is Windowszal lesz szállítva, mert az MS egy rakás játékra Windows exkluzívitást kötött. Olyan játékokra, mint az új Tomb Raider. Ez azért nem kis tényező.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ki van zárva. Mondom, hogy lesz olyan gyártó, aki egyetlen egy Nano VGA-t szállít EU-ban. Az USA már három számjegyű mennyiségét kap, de a gyártók nem fogják odaadni a kereskedelmi forgalomba szánt termékeket. Akik sokat kapnak azok az OEM-ek, na ők aztán biztos nem adnak tesztre. Szóval az a pár darab lesz, amit az AMD tesztre szán, és azok kapnak, akiknek az olvasottsága magas. Akik esetleg kedveltek, de az olvasottsaguk alacsony, azok biztosan kimaradnak az NDA lejártára. Nyilvan itt az a probléma, hogy ebben a formában a kisebb oldalak vannak háttérbe szorítva a nagyobbakkal szemben. Arról például a TechReport nem tehet, hogy nem olyanok a forrásai, mint mondjuk tomnak. A TPU egészen mas kategória. Ők NDA-t szegtek régebben, és ezt manapság az AMD nem nézi el. Más Radeont sem kaptak már korábban. Ezen úgy tudnak változtatni, ha kifizetik a bírságot, ami nagyon durva pénz. Esetleg nagyon be kell puncsolni, és akkor talán újra megy a csomag.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Szerintem a VR-nél ne keverjük a szoftveres problémát a hardveressel. Az AMD implementációjának azért olyan alacsony a késleltetése, mert a VR egy VR-re tervezett API-n keresztül működik. Az NV-nek csak a szabvány API-k maradnak, amelyeket nem terveztek olyan igénybevételre, amilyet a VR követel. Függetlenül attól, hogy a hardver mire képes, a szabvány API-k nem alkalmasak a megfelelő késleltetésre. Akkor lesz ez a VR alkalmas a legtöbb hardverre, ha a szabványos VR API-k elkészülnek.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Lényegében igen. Valójában persze a Mantle kell, de az a LiquidVR alapja.
Igazából nem ez az AMD igazi VR csodafegyvere. Fontos dolog, de a Latest Data Latch miatt olyan alacsony az AMD VR csomagjának késleltetése. Ez ugyanis lehetővé teszi, hogy a fejpozició közvetlenül a GPU-s számítás előtt legyen meg. Minden más VR rendszer a jelenetszámítás előttről szerzi ezt az adatot, és ez ad hozzá az egészhez úgy 5-10 ms-os extrát.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#10057
Abu85
HÁZIGAZDA
tibcsi0407
#10054
Abu85
HÁZIGAZDA
válasz
tibcsi0407
#10054
üzenetére
Azt nem kell implementálni, mert a feldolgozási modell követeli meg a TIER3 bekötést. Arra kell írni a kódot, és azt a kódot tudja az API úgy kezelni, hogy fusson az alacsonyabb szinteken. Maga a DX12-ben nincs definiálva az, hogy csak TIER2 vagy TIER1 bekötésre írsz programot. Ilyen formában egy kód nem fut az API-n, mert a Shader Modell 5.1 hiányolni fogja a shaderekben a bekötést. Nem fogja lefordítani a kódot D3D bájtkódra, mivel az API nem fogja tudni kezelni a shaderbe írt memóriaelérés nélkül. Erre a validátor fel fogja hívni a figyelmet.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#10066
Abu85
HÁZIGAZDA
tibcsi0407
#10060
Abu85
HÁZIGAZDA
válasz
tibcsi0407
#10060
üzenetére
A naiv konzolportok rosszabbak lesznek, mert olyan kódot is át lehet hozni az Xbox One-ról, amely sokkal rosszabb hatékonysággal fut a többi architektúrán, mint például a Nitrous. Ez azért nem egy átgondolt stratégia sajnos, függetlenül attól, hogy az MS arra buzdít, hogy jó az Xbox One kód PC-re. Persze GCN-re jó, de a többire egyáltalán nem az.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#10069
Abu85
HÁZIGAZDA
tibcsi0407
#10068
Abu85
HÁZIGAZDA
válasz
tibcsi0407
#10068
üzenetére
A valós különbségről sokat elárul a Nitrous. Ezt a motort úgy építették, hogy minden gyártóval együttműködtek, és egy évvel korábban megosztották velük a teljes forráskódot. Ez a normális fejlesztés. Sajnos lesznek olyan fejlesztések, ahol megírják a kódot az Xbox One-ra, és azt egy az egyben áthozzák PC-re. Na az gáz lesz, mert sokkal rosszabbul teljesíthet benne minden nem GCN architektúra, csupán azért, mert minden döntést csak a GCN-t szem előtt tartva hoztak meg. Ebből lesz szerintem a jövőben a probléma, nem az olyan fejlesztési modellből, amit az Oxide folytat a Nitrous esetében.
Az világosan látszik, hogy az Oxide járja most a nehezebb utat azzal, hogy mindenkire optimalizálnak, viszonylag sokat. És ez előtt le a kalappal, de félő, hogy a többség csak az XO-ra fog optimalizálni.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#10082
üzenetére
Amit az Ubisoft akar az más. Oda ExecuteIndirect kell, de ezt a Unity még nem jól használta a konzolokon. Nem is igazán lehet használni magas szintű eléréssel. PC-n is csak az AMD-n érhető el ez a fícsőr DX11-ben, ráadásul ott is egy AGSL kiterjesztéssel, ami ugye a multi-draw indirect. Ilyen kiterjesztés az Intelhez és az NV-hez nincs.
A SIGGRAPH alapján az Ubi valszeg átvált teljesen DX12-re azért, hogy PC-n is működjön az ExecuteIndirect, mert annak meg nincs értelme, hogy DX11-ben csak AMD-re írnak játékot. Persze azt nem tudom, hogy más csinál-e multi-draw indirect kiterjesztést. Erre van opció, de igazából felesleges, amikor ott van szabványosan a funkció a DX12-ben. Esetleg OpenGL4-DX11 interoperabilitás lehetséges, de nem hiszem, hogy ez minden vágyuk.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#10120
üzenetére
Félrevezették, mert valójában elég egy 500 wattos Chieftec egy 290-hez. Nekem most a profilomban lévő nagyobbik gépet egy 350 wattos FSP hajtja gond nélkül. A Corsair táp kellett a szomszédnak egy időre.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#10141
Abu85
HÁZIGAZDA
FollowTheORI
#10139
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#10139
üzenetére
Nem teljesen. A VR a kulcs, mert az a piac felfutóban van, és az AMD egyedül kínál csomagot hozzá, egészen addig, amíg nem lesz szabvány. Ez érdekli őket, nem a Zen.
A Silver Lake amúgy is nagyon érdeklődik manapság a VR célpontok iránt.
[ 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
proci985
#10142
üzenetére
Az Oculus SDK nem támogatja a multi-GPU-t, de a LiquidVR igen, szóval azokon a játékokon fog működni, amelyek LiquidVR-t is használnak. A Hawaii nem rossz, de a VR-hez egy fokkal előnyösebb a finomszemcsés preempciót használó hardverek, mint a Tonga és a Fiji.
(#10143) NetTom: Az Oculus a Facebooké.
Szerintem az ilyen befektetési csoportokat annyira nem érdekli, hogy business vagy experience vonalról válik be egy dolog. De önmagában a VR egy business is lesz, mert a VRLA-n már elég sok ötlet merült fel az orvosi felhasználásról, oktatásról, stb. Lehet, hogy ez érdekli őket igazán.
Egy biztos, hogy nem a Zen érdekli őket, mert az csak egy szimpla processzor.[ 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
#10153
üzenetére
Arról van szó, hogy van két nagyon jövedelmező terület, amely befuthat a jövőben. Az egyik az AR, míg a másik a VR. Az AMD bemákolta a helyzetet úgy, hogy senki másnak nincs működő csomagja ezekre, és gyorsan alakítottak egy cégen belüli csoportot, hogy reagálni tudjanak az AR és a VR irányára. Ez lehetővé teszi, hogy hamar megoldjanak hardverekkel és szoftverekkel olyan problémákat, amelyek előreviszik ezeket a piacokat.
Ezt most ki kell használni, mert olyan többet nem lesz, hogy a konkurensek sehogy sem készültek fel egy már látható jövőképre.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Visszafelé nem portolják be a DX12. Ez biztos. Még az sincs eldöntve, hogy mibe portolják bele először. Az, hogy a motor támogatja egy jó jel arra, hogy az elkövetkező egy évben valamelyik játéktól kezdve elérhető lesz.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#10244
Abu85
HÁZIGAZDA
Dark KillerX
#10238
Abu85
HÁZIGAZDA
válasz
Dark KillerX
#10238
üzenetére
De az MS bármikor mondhatta volna nekik, hogy köszönjük értékeljük a munkátokat, de nem kérjük. Viszont ezzel sem lenne előrébb az ipar, mert akkor is kiadták volna a saját API-jukat, és akkor ott tartanánk, hogy az Intel és az NV is tervezné a sajátját. Az átmenet rossz lesz, de összességében jól jártunk azzal a váltással, amit az MS végigvitt. Lehet, hogy jövőre lesz némi kellemetlenség belőle, de két éves távlaton túl csak pozitívumokat fog hozni.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem feltétlenül függ az API-tól, hogy egy játék Win10 only-e. A Vulkan éppúgy lehet Win10 only, ahogy a DX12, mert a WDDM 2.0-ból profitál. Az valóban igaz, hogy a Vulkan esetében van esély rá, hogy egy játék elinduljon Win7/8.1/akárminamireleszVulkan, de ha egy motor valamilyen szempontból kötődik a WDDM 2.0-hoz, vagy egy hasonló modellhez, amit nem lehet igazán jól visszamappelni a WDDM 1.x-re, akkor Vulkan ide vagy oda a programhoz Win10 kell.
Ettől függetlenül a Vulkan valamivel jobb API. A DX12 nem tartalmaz olyan funkciókat, amelyeket a fejlesztők kifejezetten kértek, és elérhetők konzolon is. Mint például az ordered atomics, GPU dispatch, SIMD lane swizzle, template támogatás a shader nyelvben. Ezeket a Vulkan tudja.
[ 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
#10265
üzenetére
Csak más fog velük játszani. Bár a fejlesztők is gamerek bizonyos szinten, szóval ők is játszanak majd.
Hidd el egyébként nem hülyeségből kérnek olyan dolgokat, amelyekkel hatékonyabban tudnák programozni a GPU-kat. A mostani nyelveket a tíz évvel korábbi modellekre találták ki. A Vulkan az első API, amely lépéseket tesz annak érdekében, hogy C++11 vagy akár C++14 részhalmazának képességeit el lehessen érni. Ez az olyan cégeknek, mint az Ubisoft nagy segítség lenne, mert ők már most azon gondolkodnak, hogy átvisznek bizonyos számításokat a CPU-ról a GPU-ra. GPU-driven pipeline modell.
És itt megint csak a PC-ről van szó, mert konzolon megcsinálják, itt az a kérdés, hogy PC-re hogyan oldják meg. Nyilván első körben az executeindirect elég, de később szükségük lesz a Vulkan újításaira.
[ 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
rocket
#10248
üzenetére
Nem az AotS kapcsán volt róla szó. Az async DMA és compute egy olyan dolog, amit a konzolra dolgozó fejlesztők jó ideje használnak. Tehát semmi újdonság nincs benne, csak PC-re még nem használták sokan (csak a Thief). Elsődleges célja, hogy ingyenessé tegyen bizonyos számításokat, mert ezeket a hardveren belüli buborékokra rá lehet ütemezni. Például shadow mapoknál a shader feldolgozók 90%-a NOP-ot futtat, vagyis nem csinálnak semmit, csak várják, hogy végezzen a ROP a számítással. Ezekre a feldolgozókra ki lehet osztani feladatokat, amelyek addig végeznek, amíg a shadow mapok számítása zajlik. Ergo a teljes számítás, amit ezekre kiosztottak gyakorlatilag ingyenessé válik. Számolt a rendszer egy csomót, de közben kvázi semmit sem lassult a tempó, mert a shadow map számítása tovább tartott így is.
A multi-engine ezeknek a hardveren belüli idle buborékoknak a betömésére jó.
Aztán ott a gyakorlat, hogy ezt ki hogyan használja, mert egészen sok lehetőség adódik azzal a modellel, amit a DX12 lehetővé tesz. Nem muszáj buborékokat tömködni, akár elindítható több alacsony prioritású compute feladat is a grafikai feladatok mellett. Valószínűleg a Nitrous eleve egy nagyon kiegyensúlyozott motor, így nem sok buborékot lehet betömni, ami miatt inkább párhuzamos megközelítéssel dolgoznak a fejlesztők. De az valóban igaz, hogy a motorok 99%-a a Nitrous teljesítményének a töredékét sem képes hozni, és így logikus, hogy jóval több idle buborékok lesz a hardvereken belül. Így például ezeknél a motoroknál lehet más megközelítéssel is élni. Írtam az ezzel kapcsolatos cikkben, hogy az NV valószínűleg azért nem tiltja le csípőből ezt a képességet, mint az Intel, mert egyrészt szeretnék használni az async DMA-t, másrészt nagyon valószínű, hogy van olyan megközelítés, amitől a Maxwell 2 is gyorsul, mert valószínű, hogy a compute bizonyos grafikai state-ekre épül. Bár a Maxwell 2-ről nincs dokumentáció, de nagyon jellemző, hogy stateful hardvereken a compute és a pixel feladatok ugyanazokat a state-ket használják. Nyilván, ha az NV azt gondolná, hogy a fejlesztők nem képesek olyan kódot írni, ami a hardverükön gyorsul, akkor nem is gondolkodnának a multi-engine hardveres kezelésén.Az meg teljesen normális, hogy egy fejlesztő letilt dolgokat, bizonyos alternatív kódrészletekkel, ha az adott implementáció nem felel meg az adott hardvernek. Pontosan ezért van a Nitrousban egy NV-re kialakított kódrészlet a fő programkód mellett. Ez nem tudom, hogy miért újdonság, hiszen lassan egy évtizede folyamatosan alkalmazott praktika.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#45185024
#10296
üzenetére
Jedec szabvány, akkor gyárt ilyet a többi memóriagyártó, amikor akar. Nem a memória a probléma a HBM-nél, hanem az interposer.
(#10284) pengwin: Az MS-nek egyikhez sem kell részesedést vásárolni. Egyszerűen elég terméket rendelni.
Az AMD most abból a szempontból érdekes, hogy a VR biznisz gyakorlatilag egy jó ~180 milliárd dolláros üzletnek tűnik éves szinten, és egyedül az AMD rendelkezik olyan csomaggal, amely ezeket a VR cuccokat problémamentesen meg tudja hajtani. És most a játékokat mindenki leszarja, a nagy biznisz az orvosi, az oktatási és a professzionális felhasználás lesz. Ezért megy most a matek, hogy jó lenne az AMD-ben részesedést szerezni, mert hozzávetőleg 3 évig nem lesz még szabvány, vagyis gyakorlatilag ingyen ebéddé válik minden VR terület az AMD-nek. A Facebookkal nem akar senki sem versenyezni, mert ők eleve rohadt pénzesek, más VR eszközökre szakosodott céget meg nem akarnak venni, mert az Oculus technikailag jobb, és a Facebook pénze garantálja, hogy más ne érhesse utol őket. Innentől kezdve, ha valaki VR-ből hasznot akar, akkor a komponensgyártókat célozza meg. Egyébként nem valószínű, hogy a Microsoft vagy az Intel bármit is elér. Sokkal inkább a Silver Lake az opció, mert ők mindig nagyon rástartolnak az üzletileg kritikus területekre. Nyilván ők is számolgatják, hogy mekkora lesz a VR üzleti felhasználásból származó bevétele, mert az AMD gyakorlatilag az egyetlen jelölt a VR-es alapként legyen szó orvosi vagy oktatási felhasználásról, vagy bármiről.
A Microsoftnak stratégiailag akkor lenne lényeges az AMD-be bevásárolni magát, ha túl sok alternatív területre felhasználja a cég a Mantle-t. Az a Microsoftnak nagyon káros lenne, mert arra kényszerítené az összes gyártót, hogy fejlesszenek egy saját grafikus API-t. Emiatt talán megérné részesedést szerezni, és kierőszakolni a cégen belül, hogy a Mantle halljon meg, mert potenciálisan káros a Microsoft ökoszisztémájára nézve, hogy az AMD minden problémára képes 2-3 évvel hamarabb reagálni. Ez csökkenti a Microsoft szabadságát is a kutatásban, mert bizonyosan ott ordít mindenki a fejük felett, hogy baromira kell a VR-es DirectX, hogy tudják célozni azokat a területeket, amelyeket az AMD már elér.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Laja333
#10317
üzenetére
De azzal előrébb lennének. De az nyilván problémájuk, hogy egy ilyen megoldás nem rajtuk múlik, mert nem rendelkeznek saját grafikus API-val, mint az AMD, így a saját VR csomagjuk tervezésében sokkal korlátozottabb lehetőségeik vannak.
Az NV a fentiek miatt teljesen más opciókat fejleszt a GameWorks VR-be. Nem véletlenül adják hozzá a multi-res shadinget. Nem tudnak olyan késleltetést elérni, mint a LiquidVR, mert nem tudnak kamerapozíciót módosítani képszámítás előtt, de el tudják érni, hogy a képkockán, ami nincs középen, vagyis a szem várható fókuszpontjában az legyen rossz minőségű, tehát kevés számítást igényeljen. Ezzel szintén csökken a késleltetés, de VR-ben a szemed mozoghat, tehát rá tudsz nézni a rossz minőségű képterületekre is, ami már baj.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
válasz
Laja333
#10321
üzenetére
Csak nem mindegy, hogy mennyit érnek ezek a megoldások. A Latest Data Latch például nagyon sokat, és az így nagy előny az AMD-nek, de ilyen extrákat mindig az elején lehet szerezni. Ahogy kerülnek közel a határokhoz egyre nehezebb további előnyt szerezni, szóval az olló gyorsan záródik össze.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#10336
üzenetére
Promózni meg beszélni lehet róla. Amiről itt szó van az a technikai megvalósítás. Ebben a LiquidVR a mezőny előtt jár, elsődlegesen azért, mert nem korlátozzák a szabványos grafikus API-k a lehetőségeket. Az E3-on nem véletlenül futott minden játékbemutató LiquidVR-en. Például hiába partnere az NV az EVE: Valkyrie című játéknak, akkor sem olyan jó a GameWorks VR csomag, hogy azon mutassák be a játékot. Persze nem írták ki, hogy amin futott az a LiquidVR, mert gondolom a partnerszerződés megtiltotta, de muszáj volt azt használni.
[ 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
daveoff
#10353
üzenetére
Az E3-on is ki lehetett az NV standjánál a VR-t. De független stúdiók standjánál LiquidVR volt, még akkor is, ha NV partner volt a stúdió. Egyszerűen számottevően jobban működik az AMD megoldása. A többiek gondja ott kezdődik, hogy nincs grafikus API-juk VR-hez, az hogy hardvernek vannak hiányosságai már csak ráadás lehet. Ez a legfőbb oka, hogy az Intel és az NV nem akar VR tanácsot, mert a jelenleg előirányzott minősítési rendszerrel esélyük sem lenne arany vagy ezüst minőségre. Maximum a bronz, amit megkaphatnak, vagy az "only for multimedia" matrica.
Eleve az arany minősítés tervezett követelménye 10 ms-nál kisebb motion-to-photon latency, ami nem lehetséges Latest Data Latch nélkül.[ 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
#10362
üzenetére
Az AMD mindig úgy kommunikálta, hogy nagy hatása van a piacra, és tulajdonképpen az volt. Ha nem jött volna ki, akkor jelentősen csúsztak volna a DX12 fejlesztések is, mert nem tudták volna előre felkészíteni a motorokat a fejlesztők a low-level irányra. Ez azt eredményezte volna, hogy 2016 közepéig nem jött volna DX12-es játék. De mivel rengeteg motort előre átírtak az AMD API-jára, így ezeknél a motoroknál már csak a render back-endet kell lecserélni. Hozzávetőleg 120 fejlesztőről van szó, aki ezt megcsinálta az elmúlt másfél évben. Emiatt gyakorlatilag előkészült egy olyan terep, amelyre az elkövetkező egy évben több tucat DX12 és már Vulkan játék is jöhet, mert a render back-endet hetek alatt ki lehet cserélni.
[ 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
Valdez
#10379
üzenetére
Az AMD elmondta az E3-on, hogy minden VR játék a PC Gaming Shown LiquidVR-en futott. Egészen pontosan dual Fiji-vel. Önmagában az AMD-nek nem is biztos, hogy terve volt az adott játékkal. Egyszerűen csak kértek rá a fejlesztők csomagot, hogy ki tudják állítani.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#10409
üzenetére
Ezt már többször elmondtam, hogy a low-level API-k alapvető hátránya lesz, hogy a kernel driver megszűnésével átkerülnek a menedzsmentre vonatkozó alapok a programkódba. Így ha érkezik egy új architektúra, akkor azon nem fut olyan jól a programkód, mint a kiadáskor ismert architektúrákon. A GCN3-ra nem jött ki BF4 javítást, mert túl nagy változást igényelt a motorban, de az összes későbbi Frostbite játék már GCN3 optimalizálással érkezett.
Ugyanez lesz a DX12 és a Vulkan. Sajnos előfordulhat, hogy ha veszel egy új hardvert, akkor azzal már nem tudod már olyan részletességgel játszani a kedvenc játékodat, mint az előzővel, mivel nem tudja a gyártó a driverben a megfelelő menedzsmentet ráerőszakolni a programkódra. Erre kell egy patch-et kiadni az adott játék fejlesztőjének.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Megbízhatatlan oldalakat ahol nem mérnek (pl gamegpu) ne linkeljetek.
- Intel GPU-k jövője - amit tudni vélünk
- Hobby rádiós topik
- Samsung Galaxy S22 Ultra - na, kinél van toll?
- Otthonfelújítási program (2024.)
- Újabb lépést tesz a lineális tévézés felé az Amazon
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- E-roller topik
- PlayStation 4
- Napelem
- iPhone topik
- További aktív témák...
- AKCIÓ!! GAMER PC - RTX 3060Ti 8GB - RYZEN 5500 - 16GB DDR4 - 240GB SSD - 500GB HDD
- AKCIÓ!! GAMER PC - RTX 3060Ti 8GB - i5 10400F/11400F - 16GB DDR4 - 240GB SSD - 500GB HDD
- Apple watch S4 40mm - Space Gray
- Crucial 32GB KIT DDR4 3200MHz CL16 Ballistix Red RGB (Utánvétes Foxpost az árban!)
- Apple iPhone 13 Pro Max 256GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen