Új hozzászólás Aktív témák
-
#71
Füleske
addikt
bakagaijin
#54
Füleske
addikt
válasz
bakagaijin
#54
üzenetére
Igen , a freearc nagyon jó , több processzormaggal is , de 6 maggal az m9 már nem tud 100 % procihasználatot produkálni , olyan m7 - ig tudja 6 maggal a 100 % - ot. Több maggal gondolom még rosszabb a helyzet (jelenleg) , így is gyorsabb mint a 7-zip .
A nanozip még egy nagyon jó tömörítő , ( freearc -al külső tömörítőként , mert a saját grafikus felülete még nagyon kezdetleges) , vannak gyors és nagyon lassú opciói is , tömörítendő anyagtól nagyon függ a sebesség és a ráta.Aki tesztet akar annak itt egy nagyon jó és aktuális teszt arról hogy hol tartanak az egyes tömörítők.
-
#70
Ł-IceRocK-Ł
veterán
Ł-IceRocK-Ł
veterán
Érdekes hír, kíváncsi leszek rá.
-
dezz
nagyúr
Már miért gondolkodnék úgy? Az erős/gyenge fogalmak viszonyítás kérdése, jellemzően a konkurenciával, márpedig ugye Intel oldalon sincs mindenkinek i5, i7, vagy egyátalán SB.
Vagy te úgy értetted a gyengébb procikat, hogy régebbi? És hogy ezzel elkerülhető, hogy újabb, nagyobb teljesítményűt kelljen beszerezni? Ez egy érdekes kérdés, bár nem hiszem, hogy az AMD-nél ezt tekintenék célnak. Inkább azt, hogy APU vs. APU alapon kiegyenlítődjenek az erőviszonyok (*), vagy éppen az AMD felé billenjen a mérleg nyelve. Akkor meg főleg, ha akár APU, akár CPU mellett dGPU is jelen van. De hogy egy komolyabb dGPU mellé elég lesz-e egy kisebb teljesítményű proci...? Nos az esetre válogatja. Találkoztam már olyan OpenCL-es programmal, ami kevéssé pörgette a procit és olyannal is, ami nagyon is. Maga az OpenCL is igénybe tudja venni a procit is a GPU(-k) mellett, illetve a számítások mellett az integer prociteljesítményre is szükség lehet.
* Már ami a Trinityt illeti, mert pl. itt a Llano nem szerepelt túl jól az IB-vel szemben, compute vonalon, ami kissé meglepő. Csak hát a Trinityben sem GCN van, amivel igazán ütne.
-
Male
nagyúr
Valahogy sejtettem
(Azért a store nem feltétlenül hülyeség, van hogy én is használom... pl olyan fileoknál, amiket nem tud tömöríteni, és hiába teszed a maximumra, akkor se hoz rajta semmit.... hogy olyankor minek tömörítem: mert egy tömörített fileról gyorsan megmondható, hogy sérült-e, nem kell ellenőrző összegekkel variálni, lehet vele darabolni, recovery record adható hozzá tetszőleges arányban, titkosításra, jelszavas védelemre szintén jó, régebben pedig vírusok ellen is hatékony volt.)
-
vinibali
őstag
te úgy gondolkozol, mintha mindenkinek 4 modulos Bullja lenne, pedig köztük nagyon sokaknak AM2-AM3-as procija van valami DX11-es Radeonnal. Az AMD nem engedheti és szerintem nem is engedi meg magának, hogy a régebbi, de AMD platformmal rendelkezőket magára hagyja... erre gondoltam célozni, Pimasz Úr
szerk.: és ezért is hoztam a gyengébb CPU-s példát. -
mzso
veterán
Ja én tömörítés alatt tényleges tömörítést értettem
ha valaki leveszi store vagy valami fölöslegesen alacsony fokozatra nem tudom miért szidja a szoftvert, hiszen ő a balf@sz.Én a 7z-nél mindig ultrát használok. Szóméret maximumon. A címtár meg ram méret függő, vagyis amennyi belefér.
-
jozsef m.
tag
Valami megmozdulni látszik:
AMD and Adobe Creative Suite 6 Innovate With OpenCL and GPU Acceleration
-
apatyas
Korrektor
Azért, 21s alatt 103MB olvasás és 40MB írás nem kíván egy húde acélos IO teljesítményt (sajnos). Olvasástól lassulhat pár másodpercet, de ugyanúgy az eredeti is, relatíve nem nagy változást okoz.
Dezz: ez legalább rámragadt a fizikus képzésen, csinálj jól dokumentált mérési jegyzőkönyvet, ami alapján a kísérleted reprodukálható lesz. -
-
#58
Male
nagyúr
bakagaijin
#54
Male
nagyúr
válasz
bakagaijin
#54
üzenetére
Egy ilyen részletes teszt mehetne logoutra
-
Abu85
HÁZIGAZDA
A Corel szerint nincs kockázat. Ezért írtam meg a hírt később, mert nem értettem, hogy miért az AMD driverére korlátozzák az egészet. Erre írták vissza, hogy a tesztelés miatt. Az OpenCL kód szeptember óta kész van, és alig változott. Az egyetlen dolog, ami számított az a tesztelés. Lényegében fél éve azt tesztelik, hogy kockázat-e a GPU-val tömöríteni, de a válasz egyértelműen nem. Ellenben ez csak az AMD driverére vonatkozik. A többi drivert is ilyen alaposan meg kell vizsgálni, és nyilván pont a lehetséges kockázat miatt tiltják a szolgáltatást az Intel és az NV driverein. Lehet, hogy azokon is jó, de erre csak a tesztelés ad választ.
-
Rive
veterán
Hümm.
Örülök, hogy egyre több dologba bevonják a GPU-t de speciel pont a tömörités az, amit - pláne olyan állományoknál, könyvtáraknál ahol már számitana a tömöritési idő - hajlamos vagyok inkább kockázatként értékelni archiválás esetén, mint haszonként
Amúgy tán' még 3Dmark topikban sincs ennyire tesztelésre kihegyezve a dolog mint itt
-
#54
bakagaijin
tag
dezz
#49
bakagaijin
tag
Úgy évente csinálok teszteket, a kőkorszaktól a modernekig, netről összeollózott max beállításokkal
. Többször egymás után a freeARC volt a legjobb tömörítő. Kb a 7z méretét hozza, de úgy fele idő alatt.freearc-nál ez "-m9 -mt" opciót jelent (a max rosszabb mint az m9)
Ha az idő számít, akkor ace (a régi 1.2b "-r -s -m5", ez már támogatja az LFN-t), dupla méret a 7z-hez és arc-hoz képest, de iszony gyorsan. (Az újabb ace-ek belassultak ugyanolyan tömörítés mellett, felejtős) Az ace viszont nem free, a 7z-vel és az arc-al ellentétben.Megj: igyekeztem olyan csomagot összeállítani amiben mindenféle tartalom van.
Megj-2: 7z alatt az ULTRA beállítás értendő -
Male
nagyúr
Azért a 7-Zip a király rész eléggé változó. Van amikor a RAR tömörít nagyobb mértékben, van amikor a 7-Zip, nem anynira egyértelmű... bár tényleg többször ad kisebb filet a 7-Zip.
Illetve a rar azért több parancssori lehetőséget ad... vagy csak én nem ismerem a 7-Zip lehetőségeit eléggé, de pl RAR-al simán lehet automatikus filenév ami tartalmazza az aktuális dátumot pl. (Ezzel csinálom a backupot, így hasznos számomra.). A másik ami miatt én maradtam a WinRARnál az az, hogy folyamatosan fejlődik, míg a 7-Zipből 2010-es az utolsó verzió, azóta csak alfa meg béta verziók jönnek, ez pedig számomra nem túl jó jel a program jövője szempontjából. A WinRAR mellett szól még a recovery record lehetősége és az automatikus visszatesztelés lehetősége... ezeket én elsőre nem találtam meg a 7-Zipben, pedig szeretem alkalmazni ezeket.
-
dezz
nagyúr
Jaj, de érzékenyen kelt ma valaki!
Akkor megmagyaráznád, miért írtad ezt: "vagy csak érzik a (saját) CPU gyengeségeit?" Csak mert ugye jól párhuzamosított, számításigényes kódokat illetően nem igazán beszélhetünk gyengeségről (már egy i7-hez képest, mert ugye egy komolyabb GPU mindkettőt lemossa a színről a legtöbb hétköznapi ilyen feladatban). Egy OpenCL-nél viszont hogy jön ide pl. az egyszálas teljesítmény (amivel az OpenCL sem tud mit csinálni)?Esetleg azt lehet mondani (bár kissé más terület; és egyébként bocs, hogy helyetted leírom
), hogy a játékos teljesítményen -- amin ugye valóban van javítanivaló -- később sokat dobhat, ha pl. a fizikát a GPU-ra bízzák. Főleg, ha olyan szintű fizikáról lesz szó, ami egy i7-et is megfektet.Nincs mindenkinek 4-modulos, de i5, i7 sem.
-
vinibali
őstag
azt tudhatnád, hogy tudom. de tulajdonképpen nem is értem... mi ez a kioktató stílus?! feljössz és elmondod mindenkinek hogy mi a frankó?
mert nyilván mindenkinek a gépében 4 modulos Bulldózer van
(#4) Abu85: igen, én is úgy gondoltam, hogy ők kezdtél el hamarabb támogatni a feljesztéseket, mint ahogy mostanában szinte mindent ők kezdenek el elsőként ami innovatív -
dezz
nagyúr
A programban az Add ablak jobb alsó sarkánál van egy olyan, hogy Change Compression.
"OpenCL? Fent sincs a gepemen."
Hihi, ezt az előbb is írhattad volna, hiszen az egész topik erről szól!
Akkor viszont felmerül a kérdés: ha hiába eleve 10x gyorsabb a WinZIP, mégis a háttérbe szorul a kisebb hatékonysága miatt, akkor most ilyen 20-30% sebességnövekedéstől várják az áttörést (piacvisszaszerzést)? (Ráadásul pl. a WinRAR-ban is beállítható gyorsabb tömörítési mód.) És akkor még csak a sima ZIP-elést OpenCL-esítették!? Inkább a hatékonyabb módokat kellett volna!
Na igen, a 7-Zip a "király" (Nem is értem, miért nem azt használják "netszerte". Talán csak Windowsra van? Vagy megéri kivárni, amíg a [Win]RAR valami durvább módban mégkisebbet csinál?). Viszont a WinRAR-t 1-2 szinttel gyorsabb módban futtatva lenne egálban a WinZIP tömörítésével és úgy valószínűleg időben is sokkal jobb lenne (magához képest).
(#48) apatyas: Ez aztán kimerítő volt!
Csak azt nem árulták el, hogy a ".Zipx: Best method" tulajdonképpen melyiket jelenti a bzip2, LZMA, PPMd közül...? Esetleg ezeket egyenként még meg lehetne nézni, hátha valamelyik szintén GPU-gyorsított. (Én is szívesen megnézném, de úgy tűnik, nálam most valami miatt nem megy a gyorsítás, hiába kapcsolom be.) -
apatyas
Korrektor
No itt az én tesztem:
Brazos E-350, 110MHz ref.clock, 1760MHz cpu 1466MHz RAM, 306MHz/542MHz GPU.
friss catalist, AMD system monitor a GPU terhelés jelzésére,
Dataram RAMDisk_V3.5.130RC22b.msiACRSP.exe 46.868 MB eredeti / 17.876 BB TC-vel tömörítve.
ACRPR.exe 46.599 MB eredeti / 17.675 MB TC-vel tömörítve.
DEEP_SPACE.bmp 9.669 MB eredeti / 4.999 MB TC-vel tömörítve, nagyjából hasonló időarányt fut mint az előző exe-k.
RAMDRIVE-on elhelyezve a forrás és cél is.TC belső pkzip-je: 68s, 39.3% méret, ~50% terhelés
WinZip 16.0 legacy mode: 31s , 39.3%, 3x felment 100%ra, közte röviden leesett 40%-ra.
winzip 16.0 zipx mode : 80s , 25.6%, terhelés kb 90%-on.winzip 16.5 legacy mode: 31s , 39.3%, terhelés ua. - ez tök ugyanaz mint az előzőn.
winzip 16.5 zipx mode : 79s , 25.6%, szintén változatlan az előző verzió óta.OpenCL-lel:
winzip 16.5 legacy mode: 21-23s , 39.4% azonos méret, full CPU + 47-51-100% GPU de ezek az értékek nemigazán frissülnek közben, a gpu órajel csak tüskésen ment fel 541-re.
winzip 16.5 zipx mode : 75s , 25.6%, nem láttam GPU terhelést. zipx-nél sztem nincs GPU gyorsítás.Vagyis összegezve, saját magához képest 70-74% az időigénye GPU gyorsítással az alsóház APU kategórián, és tized százalékkal nagyobb file készült.
-
nyunyu
félisten
WinZIP hulye feluleten nem jottem ra, hogy kell bekapcsolni a ZIPX-et, mert mindenaron kicsomagolni akarta az ISOt, becsomagolni csak az add file opcioval sikerult, ott meg semmit nem lehet allitani.
OpenCL? Fent sincs a gepemen.Sima ZIP eredmenyebol nem maradt le az 1, het perc alatt vegzett.
RAR hatekonysaga csapnivalo, masfelszer annyi ideig tartott, mint 7Zippel, raadasul az utobbi kisebb archivot csinalt.
-
dezz
nagyúr
Huh, itt aztán van szórás... (A korábbi 20%-okhoz képest [1 kivétellel].)
Megjegyzem, a default beállítás nem biztos, hogy megfeleltethető és akár 1-1 hatékonysági szint váltás is nagy eltéréseket hoz időben, minimálisan kisebb file-méret mellett. Azaz, inkább úgy kellene beállítani őket, hogy azonos file-méretet adjanak (se nem light, se nem extrém beállítás mellett, hanem azért valahol középtájon) és utána megnézni az időt.
Szóval, vagy a WinRAR-ban kellene kisebbre venni a hatékonyságot (és/vagy a RAR helyett ZIP-et beállítani), vagy a WinZIP-ben beállítani valamelyik ZIPX módot...
Plusz ki tudnád esetleg próbálni OpenCL nélkül is a WinZIP-et?
Amúgy nagyon érdekes, hogy a TC 1 magon is mennyivel gyorsabb, mint a legtöbben. (Már ha nem 17:18 akart lenni.)
-
nyunyu
félisten
Forras: 4437MB-s DVD image
TC 7.56 gyari ZIP plugin: 4089MB, 7:18 (1 magot maxol ki)
TC + parancssoros RAR 4.11: 4054MB, 24:29 (4 mag*50%)
WinRAR x64 4.11: 4054MB, 23:47 (4mag*45%)
7-ZIP x64 9.20: 4021MB, 17:18 (1 mag 80%, 3 mag 40%)
WinZIP x64 16.5: 4084MB, 1:52 (4 mag*95%)Mindegyik tomorito default beallitasokkal futott.
Durva, mennyivel gyorsabb a WinZIP, mint a konkurencia.
Kulonosen a RAR lemaradasa megdobbento, holott ~20 eve komoly tomoritonek tartottam. (Na jo, akkor max ARJ, LHA, PKZIP volt a konkurencia ) -
dezz
nagyúr
Igen, a jelszótörősnél jó esetben csak az elejéből kell sok különböző jelszó-variációval próbálva kitömöríteni egy kis részt, ez nagyon jól párhuzamosítható. A másiknál egymás utáni részeket (ismert jelszóval) -- ami a kitömörítést illeti (de a betömörítés is hasonló). Ha azt feltételezzük, hogy itt sem függenek egymástól az egyes chunkok, akkor kvázi ugyanolyan jól párhuzamosíthatónak kell lennie! (Csak pl. itt többet kell egy ciklusban beolvasni, plusz írni is.)
Szóval, ez az erdedmény is valami, de lesz majd jobb is.
Ez kb. olyan, mint annó a HW-es videódekódolás támogatása. Talán a Nero készítői hoztak ki legelőször ilyen codecek, kis szépséghibája volt, hogy HW-es módban lassabb volt a dolog, mint procival (ami CPU-val akadt, ezzel méginkább).
Aztán a Cyberlink (és mások) megmutatták, hogy kell ezt csinálni, ugyanazon a konfigon röccenés nélkül ment már az 1080p. -
-
dezz
nagyúr
Szerintem erős CPU-hoz képest is jobb eredményeket kellene kapni. Pl. az a korábbi ZIP/RAR jelszótörő a többszörösére gyorsult OpenCL alapon. Nem vagyok róla meggyőződve, hogy a WinZIP csapat igazán optimális kódot képes fejleszteni...
Mondjuk érdekes lenne megnézni GCN alapú GPU-val is.
Mindenesetre szerintem előbb-utóbb a "többiek" is ráállnak a GPU-s gyorsításra, és én többet várok a WinRAR és a 7-Zip fejlesztőitől. (Valószínű éppen azért léptek először a WinZIP-esek, mert tudták, hogy a legjobbak nem lehetnek, de legalább lehetnek az uttörők. Azért némi kis bevétel-hullámuk biztos van most ebből a kis reklámból.)
-
dezz
nagyúr
.zipx formátum használata mellett ezek az újabb metódusok használhatók egyébként (ha valamelyik mond esetleg valakinek valamit):
- bzip2
- LZMA
- PPMd
(Egy esetleges átfogóbb tesznél ezeket is meg lehetne nézni.)Amúgy elég tré, hogy már ki tudja, hány éve fejlesztik, de semmi visszalejzés a tömörítési időről...
Se előre, se utólag.(#27) Abu85: Részemről a megtiszteltetés.
-
McSico
senior tag
Zúztam én is egy gyors tesztet.
Hardver: i7 980x EE CPU; Radeon HD 5870 (ref.) VGA
Bemeneti mappa mérete: 1,46 GB (vegyes fájltípus és méret)
Tömörített állomány mérete: 966 MB
A kimeneti fájl RAM Disk-re készült, hogy kevesebb legyen a hátráltató tényező.
Eredmények:
Sima zip openCL nélkül: 1:09:063
Sima zip openCL-el: 0:56:165
zip (AES-256 bit): openCL nélkül: 0:58:958
zip (AES-256 bit) openCL-el: 0:47:004A VGA leginkább az AES-256 bit-es zip tömörítése izzasztotta meg a legjobban.
CPU használat átlagban szinte ugyanannyi volt minden esetben.Remélem hasznos voltam...
-
#25
multiplikato
tag
juzer78
#22
multiplikato
tag
Ott a pont!
Most pedig mindenki horgássza elő újra a stopperét!
Egy 8 gigás ISO-t próbáltam, a winrar 1 órát írt ki rá, ez nem is vártam ki, érezhetően cammogott, a winzipnek olyan hat perc kellett, ezt is csak saccra tudom, mert a jobb sarokban néztem az órát.
Konklúzió: nem vagyok egy nagy teszter, majd akinek több türelme van, az megcsinálja pontosan
c2d 2.66 GHz + radeon HD4830 -
dezz
nagyúr
"Mintha nem is szekvenciálisan olvasna. (Ahelyett, hogy egyszerre olvasna be x megát egy bufferbe.)" -> folyt.: ez olyankor jön ki főleg látványosan, amikor ugyanarra a vinyóra történik a ki-/betömörítés. Darál a vinyó, jól belassul az egész. Az említett (double-)buffer beiktatásával ez elkerülhető lenne. Ráadásul, amikor az egyikben dolgozik (a memóriában), másik szálon kezelhetné a kiírást/beolvasást. Ilyenkor tisztára a 80-as években érzem magam (elmaradott gépeken nem DMA-zott lemezkezelés, amatőr megoldások "komoly" programokban is, stb.)...
(#22) juzer78: Előtted eggyel írtam.
-
dezz
nagyúr
Cikk: "a legújabb WinZip ugyanis már a grafikus processzor erejével is képes gyorsítani a tömörítést"
Ezt a mondatot így egészíteném ki, mert úgy tűnik, sokan máig nem érik, mi a fene ez a GPGPU-s téma: "a legújabb WinZip ugyanis már az általános számítások elvégzésére is egyre inkább alkalmas grafikus processzorok erejével is képes gyorsítani a tömörítést".
Egyébként alapból nincs engedélyezve a GPU-s gyorsítás a programban!
(#2) vinibali "ebből látszik milyen komolyan veszik a GPU erejét... vagy csak érzik a (saját) CPU gyengeségeit?"
1. Tudhatnád, hogy az összes magot kihasználni képes, kimondottan számításigényes feladazokban egálban vannak a Bulldozerek az inteles vetélytársakkal. (Már ha az adott program nem kimondottan Intelre optimalizált.)
2. Azt is tudhatnád, hogy tömörítésben még kicsivel jobb is.
3. Tehát, nem ez a fő ok. Hanem "talán" az, hogy egy komolyabb GPU 10-20x gyorsabb lehet, mint egy CPU!(#6) gyiku: RAR-t csak kitömöríteni tud. Viszont van valami új formátum (ZIPX), ami hatékonyabb, mint a sima ZIP.
(#7) Srodney: Ha annyira ráérsz, nem kell használnod...
(#8) adm: Na igen. Szerintem nagyon rosszul van megírva a WinZIP és WinRAR I/O része... Mintha nem is szekvenciálisan olvasna. (Ahelyett, hogy egyszerre olvasna be x megát egy bufferbe.)
(#13) ddekany: Nálad volt GPU-terhelés? Nálam 0% maradt, pedig más OpenCL-es programok működnek. (HD5750)
-
#18
juzer78
tag
multiplikato
#17
juzer78
tag
válasz
multiplikato
#17
üzenetére
A CPU-t tuti, egy 2 magoson megy, de a hdd-t nem hiszem 3 különböző hdd-ről indítottam. Azt gondolnám, hogy a gyengébb CPU mellett inkább a GPU-t kezdi terhelni, de véletlenül sem. 2 tömörítésnél is ez volt a helyzet. 1 tömörítésnél meg csak kis tüskék jelennek meg semmi több, akkor meg csak 80% körül van a CPU... van még mit fejleszteni ezen... egy 7xxx kártyán is kiváncsi lennék, mi a helyzet...
-
ddekany
veterán
Miért nem ZIP-el mérted a OpenCL nélküli tömörítést is? Ez így olyan sokat nem mond. Plusz, mp3-at sok tömörítő lehet hogy eleve máshogy közelít, mert ismert formátum. Próbálj meg mondjuk valami CD/DVD image-et (.iso, stb) tömöríteni. (Nekem nincs OpenCL kompatibilis kártyám...)
-
ddekany
veterán
Nálam 7zip alapértelmezett erősségű zip-be tömörítésnél kb 85-90% CPU használatot generál kétmagos 2Ghz-s Core 2 generációs Pentiumon. Igaz, ebből pár 5-10% százalék a HDD AES titkosítása lehet. De a lényeg, hogy ha simán átmásolni egy fájlt 100 egységnyi idő, akkor ugyan ez zip-be tömöríteni 160. Tehát vagy bénán bánik az I/O-val a 7zip, vagy a CPU szűk keresztmetszet.
-
Abu85
HÁZIGAZDA
A PCI Express egy VGA-nál korlátozó. A becsomagolandó állománytól függően sok lehet a kommunikáció. Ezt a buszt nagyon nem érdemes terhelni, de sajna muszáj. Nyilván a busz limitációi kihatnak a VGA kihasználására. Ezért írta a Corel, hogy APU-n van a legtöbb különbség. Ott ez a limitáció nem létezik.
-
Viktor77
titán
Csináltam egy gyors próbát.
Nem túl jó teszt, mert MP3-akat tartalmazó mappát csomagoltam be.
A mappa mérete 2.16GBZIP: 1:23
RAR: (kapaszkodjatok!) 8:38A végeredmény 2.12 illetve 2.13GB lett, szóval nagyon hasonló tömörítési arány volt.
Érdekes, hogy nem használta a ZIP annyira a VGA-t mint vártam, lényegében 15% fölé nem ment a kihasználtság.Egy 3 gigás ISO-t is kicsomagoltam, itt 15mp volt a ZIP javára (2:46 vs. 3.01).
-
Abu85
HÁZIGAZDA
A Corelt régóta érdekli a GPGPU. Próbálnak a lehető legtöbb program esetében ebbe az irányba fejleszteni. Ezt sem az AMD-nek csinálták. Egyszerűen versenyképesek akarnak maradni, mert egy fizetős tömörítőnél azért a technológiai újítás fontos. Különben ott vannak az ingyenesek, és le lesz darálva a WinZip. Most az OpenCL-en volt a sor. Az persze látszik, hogy az AMD-től kaptak segítséget, de a WinZip nem marad örökké AMD exkluzív az OpenCL-re. Az exkluzivitás csak kényszerű, mert sok tesztelés kell a gyorsításra. Nyilván a Corel nem akarja, hogy a betömörített állomány hibás legyen. Ezt egyelőre az AMD OpenCL driverén tudják biztosítani, de a további tesztelés után szerintem nincs akadálya az Intel és az NVIDIA támogatásának sem. A kód már adott.
Nem az?
Se előre, se utólag.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Oukitel OT5 tablet 12" 2K Display 12 GB memória, 256 GB háttértár, 4G LTE Dual SIM, 11000mAh Akku
- Új Thinkpad P16 Gen2, 16" QHD+ IPS 165Hz, i7-14700HX, RTX 3500 Ada, 32GB, 1TB NVMe, gar
- Samsung Galaxy A56 5G 8/256GB White
- AirPods Max 2024 A3184 Lila/Hibátlan/2026.12.13.Gar./p4261/
- Elado Corsair MP600 LPX GEN4 SSD 1TB hűtőbordás
- ÚJ Apple Macbook Air 15,3 M4 10C CPU/10C GPU/16GB/256GB - Ezüst -(2025)- 3 Ciklus-3 év gari - MAGYAR
- Samsung S23 128GB Fekete /+AJÁNDÉK ÜVEGFÓLIÁVAL/normál állapotban / 12 hónap jótállással
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5700X 16/32/64GB RAM RX 7600XT 16GB GAMER PC termékbeszámítással
- ÚJ HP EliteBook 840 G8 - 14"FHD IPS - i5-1145G7 - 32GB - 512GB SSD - Win10 - 6 hónap Garancia
- ÁRGARANCIA! Épített KomPhone Ryzen 5 5500 16/32/64GB RAM RTX 4060 12GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest