- Igencsak szerény méretekkel rendelkezik az Aetina Xe HPG architektúrás VGA-ja
- Miniképernyős, VIA-s Epomaker billentyűzet jött a kábelmentes szegmensbe
- Különösen rendezett beltér hozható össze a Cooler Master új házában
- A középkorra és a pokolra is gondolt az új AMD Software
- Új gyártástechnológiai útitervvel állt elő a TSMC
- OLED TV topic
- Xiaomi Mi Box androidos médialejátszó 4K és HDR támogatással
- Sony MILC fényképezőgépcsalád
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- AMD GPU-k jövője - amit tudni vélünk
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Vezetékes FEJhallgatók
- Milyen SSD-t vegyek?
- Igencsak szerény méretekkel rendelkezik az Aetina Xe HPG architektúrás VGA-ja
- A régi node-okra koncentrál a szankciók miatt Kína
Hirdetés
-
Lenovo Essential Wireless Combo
lo Lehet-e egy billentyűzet karcsú, elegáns és különleges? A Lenovo bebizonyította, hogy igen, de bosszantó is :)
-
A Video AI lehet a One UI 6.1.1 ütőkártyája
ma Vagy hogy fogja a mesterséges intelligencia manipulálni a mozgóképeket?
-
A személyre szabott reklám lehet a streaming következő slágere
it A jobb célzott hirdetések érdekében adatplatformot indít a Warner Bros Discovery.
Új hozzászólás Aktív témák
-
Fiery
veterán
A GPU szamitasi teljesitmenyenek kihasznalasahoz kellene elso korben egy olyan compiler keszito, aki nem impotens modon vegzi a munkajat. Adott egy viszonylag egyszeru OpenCL 1.x kernel, ami SHA-1 digest-et szamol (hash). Remekul fut minden AMD, Intel es nVIDIA GPU-n, a legujabb driverekkel. Gyanutlan juzer felrakja a Catalyst 14.1 vagy 14.2 betat, es onnantol az eddig jol mukodo szoftver random modra hibas hash-t szamol a VLIW-es Radeonokon (GCN-en tovabbra is jo, Catalyst 13.xx szinten jo VLIW-vel is). Persze az egesz nem derul ki, hiszen a hash tipikusan nem valami olyasmi, aminek az eredmenyet tudnad vagy akarnad ellenorizni. Ennyit a GPU szamitasi teljesitmenyenek kihasznalasarol. Es ez csupan egy a sok compiler bug kozul, amivel leginkabb az AMD es Intel OpenCL compilerei fertozottek. Ha ugyanezt a hash szamitast megcsinalod AVX2-vel vagy sima x86-tal, nincs folyamatosan valtozo compiler, es nincs driver frissiteskor alattomosan magatol elromlo eredmeny. Arrol meg aztan ne is beszeljunk, hogy milyen bonyolult, nehezkes es idegesito a GPU-s fejlesztesnel a hibakereses, a profilozas (amit az AMD OpenCL implementacioja szinten hibasan vegez) es az optimalizacio is. De ha az AMD eddigi buveszkedeseit vesszuk alapul, akkor az idei evet huzzuk at megint, es irjuk le a papirra a "
2008200920102011201220132014lesz a mi evunk. Alairas: AMD+GPGPU"-hoz a 2015-ot. A remeny hal meg utoljara.[ Szerkesztve ]
-
Fiery
veterán
"Tudjuk, hogy minden alkalmat megragadsz az OpenCL lejáratására, de a béta driverek szídásával kicsit túllősz a célon"
En nem jaratok le semmit, az OpenCL meg az AMD jaratja le sajat magat es az OpenCL-t egy fust alatt ezzel a minosegi munkaval. Amugy meg szerinted az normalis, hogy ilyen alattomos hiba kerul egy betas driverbe? Pont egy olyan driverbe, amit kiehezve varnak a GCN tulajok a Mantle miatt, es eszvesztve telepitenek fel minden Radeonra? Es egyebkent azt is leirtam fentebb, hogy nem ez volt az egyetlen hiba, amit az AMD (es Intel) OpenCL compilere kapcsan talaltunk az elmult cca. 1 ev soran, es nem csak betas, hanem WHQL driverek hasznalata soran is. Nagyon szivesen visszaterek erre a temara, ha megjelenik az elso idei WHQL Catalyst, aminek azert valljuk be, ideje lenne, igy marcius eleje tajan. Nagyon kivancsi leszek, a WHQL Catalyst 14.x javitani fogja-e ezt a hibat.
Megjegyzem, ha ezek a betas driverek kizarolag egy belso kor (pl. NDA alatt) szamara lennenek elerhetoek, semmi problema nem lenne egy-egy ilyen hibaval, es en sem hoztam volna fel ezt a temat. A gond az, hogy Radeon tulajdonosok tiz- meg szazezrei telepitik fel gyanutlanul a betas Catalystokat, aztan csodalkoznak, hogy az addig jol mukodo szoftverek benazni kezdenek. Vesd ezt az esetet ossze azzal, hogy van egy pre-compiled x64/AVX/AVX2 kodod, ami nem tud elromolni csak azert, mert az egyik gyarto osszelapatolt valami bena drivert. Igen, ott a potencial a GPU-kban, de ha igy benaznak a gyartok, akkor sosem fogja az "average Joe" juzer kihasznalni azt.
"Mellesleg van már szoftver, ami kihasználja és elég szépen profitál belőle:"
Orulok, hogy egyes szamot hasznaltal. Igen, van, egy. Esetleg ketto, ha a JPEG dekodolast is szoftvernek titulaljuk (ami nem az). Vagy harom vagy negy, ha a benchmarkokat is szoftvernek cimkezzuk. A jovo szebb lesz, tudjuk. Csak en mar kezdek 3DNow! szagot erezni. Tudod, amikor ott a potencial, csak a vegen a masik gyarto hasonlo (csak epp nemileg fejlettebb) technologiaja gyoz, es az egyebkent jopofa AMD-s potencial vegul parlagon hever a CPU-ban generaciokon at.
[ Szerkesztve ]
-
Fiery
veterán
Attol, hogy csak a GCN tulajok vartak, nem csak ok fogjak felrakni. Mivel az AMD-nel a termek generaciok kulonvalasztasa nem egyertelmu, siman felrakja mindenki, akinek minimum HD7000-es GPU-ja van. Azaz, felrakjak a Trinity meg Richland tulajok is, a HD7350 es HD7450 tulajok is, stb. Arrol meg aztan ne is beszeljunk, hogy a juzerek tobbsegenek fogalma sincs, hogy melyik GCN es melyik nem. A HD6000 (VLIW) tulajok is felrakjak, valogatas nelkul, mert ujabb, mert idei, mert a havertol jokat hallottak rola, mert a mediabol meg a csapbol is az folyik allandoan, stb. Vagy Neked van ennel pontos statisztikad arrol, hogy a Catalyst 14.x tulajok kozul hany %-nak van GCN alapu Radeonja, es hanynak VLIW?
"Melyik gyártó OpenCL driverét mondanád jobbnak, az AMD-ét vagy az Intelét?"
Ez legalabb konnyu kerdes. Az nVIDIA OpenCL _compilere_ (olyan hogy OpenCL driver, nincs, csak OpenCL compiler, ami a video driver, pl. Catalyst es ForceWare resze) fenyevekkel jobb minosegu es kiforrottsagu, mint az AMD vagy Intel hasonlo termeke. Ami valahol teljesen normalis, hiszen az nVIDIA elobb is kezdte, es tobb energiat is fektetett a GPGPU-s fejlesztesekbe, mint barki mas lenyegeben. Ha irsz egy OpenCL kernelt, es szintaktikailag hibatlan, akkor jo esellyel nVIDIA GPU-n kapasbol gyonyoruen le fog futni, mindenfele kormonfont modositasok meg takolasok nelkul. A hibakezeles is szebben van megoldva, a profilozas se bugos, sz'al nagyon smooth az egesz. Nem bugmentes, pl. a szinusz fuggvennyel kicsit hadilabon all a FLOPS kerneleknel, de eddig ez volt az egyetlen bug, amit talaltunk az nVIDIA OpenCL compilerben, ami nagy szo, ha a tobbi gyartoehoz hasonlitjuk. Es hidd el, nem vagyok nVIDIA fan, sot. A GCN SZVSZ a legjobb (GP)GPU architektura, ami valaha keszult, a legkisebbtol (Temash) a legnagyobbig (Hawaii), csak epp nem eleg jo vasat gyartani, csinalni kell hozza normalis szoftver stacket is, anelkul megsutheted a vasat.
Szerk.: Kozben rajottem, hogy az AMD vs. Intel temat feszegeted
Azt mondom, 50-50. Mindketto problemas, csak maskepp. Az AMD-nel kicsit konnyebb kovetni az OpenCL compiler fejlodeset, az Intelnel a hulye driver szamozas kicsit nehezkesse teszi a dolgokat. Az Intel compilere azert is van elonyben, mert nagyjabol csak 1 architekturat kell tamogatnia (Gen7.x), es nem kell dupla pontossagu lebegopontos szamitasokkal bajlodnia. Nem fair osszevetni oket SZVSZ."AVX/AVX2-re miben fog a legtöbb programozó dolgozni, ASM-ben vagy OpenCL-ben?"
Ha az OpenCL igy halad, akkor egyertelmuen assemblyben, vagy sehogy. De azt se felejtsd el, hogy az OpenCL _GPU_ compiler mas tema, mint az OpenCL _CPU_ compiler. Lehet egy GPU compiler f*s, mikozben meg egesz jo AVX kodot fordit a CPU compiler. Ami persze nem igy van, hiszen egy nativ, kezzel optimalizalt AVX kodhoz kepest fenyevekkel le van maradva barmi, amit az AMD vagy Intel OpenCL CPU compilere kepes forditani, de bizonyos felhasznalasi teruleteknel me'g igy is jobb lehet az eredmeny, mint ha sima x86/x87 kodot hasznalna az adott szoftver.
[ Szerkesztve ]
-
Fiery
veterán
Nyilvan a CUDA sem onnan indult, ahol most tart, de velemenyem szerint a jelen helyzetrol erdemes beszelni, a mult mar elmult. Raadasul, ha visszamegyunk X evet az idoben, jo esellyel hasonlo kulonbsegeket talalnak a gyartok kozt, pl. az elejen az Intel is me'g sokkal sz*rabbat csinalt, amikor az nVIDIA OpenCL compilere csak kicsivel volt f*sabb mint most, stb. stb
"De van"
2009-es lapot idezel? Ne vicceljunk mar... Raadasul mar ott is ezt irjak: "OpenCL v1.0 Conformant GPU drivers". Ergo OpenCL-t tamogat a GPU drivere, ami a videodrivernek felel meg. A lenyeg, hogy az OpenCL-hez nem driver kell, hanem az OpenCL tamogatast kell beepiteni a videodriverbe. Onnantol pedig a videodriver reszeve valik az OpenCL compiler, meg az OpenCL API tamogatas. De ne rugozzunk ezen, hivhatjuk igy is, ugy is, a lenyeg hogy mind sz*r, csak maskepp sz*r, es fenyevekre van minosegben minden OpenCL megoldas attol, amit a programozok megszoktak mondjuk a Visual Studio vonalon. Sz*pni lehet minden programozasi feladattal, csak **rvara nem mindegy, hogy a compilerrel szivsz napokat, vagy magaval a feladattal, amin dolgozol. Kepzeld el, hogy napokig, hetekig faragod az algoritmust, megirod nagy nehezen a kernelt, es utana 3-bol 2 architekturan mukodik, az egyiken meg egyaltalan nem. Eleg idegesito tud lenni az ilyen, plane amikor nem is tudsz a dologgal mit kezdeni, mert a compiler gyartojanak kell hetek (vagy inkabb honapok) leforgasa alatt javitani a szemetre valo termeket. Es nem, nem (csak) az AMD-rol beszelek, sajnos a tobbi gyartonak is tobb hetig, gyakran honapokig tart, hogy kijavitsanak egy-egy compiler bugot. Addig meg all a fejlesztesed programozokent, vagy kiirod plecsnivel, hogy "sorry, de AMD-n/Intelen/nVIDIA-n nem mukodik a cucc". Ami meg bena es az end-user szamara nem jo uzenetet kozvetit.
-
Fiery
veterán
Az a baj tudod, hogy csak a cimeket olvasod el. Pl. a linkelt intel-fele lapon ez all a cimben:
"OpenCL™ Drivers and Runtimes for Intel® Architecture"
Viszont a szovegben meg ott a valosag:
"This software driver package will install the Intel® graphics driver with support for OpenCL"
Ergo a grafikus driver resze az OpenCL tamogatas, nem kulon driver van az OpenCL-hez.
"OpenCL v1.0 Conformant GPU drivers" = OpenCL drivers."
Akkor ezt olvasd el me'g egyszer kerlek
A "GPU drivers" szavakat kell egy adott fogalomkent ertelmezni, es onnan kiindulni. Olyan GPU driverrol van szo, ami megfelel az OpenCL 1.0-nak, azaz videodriverrol van szo, ami tamogatja az OpenCL-t. Nem OpenCL driver, mert a (GPU-khoz valo) OpenCL es ugy altalaban GPGPU tamogatas eleve ugy van megoldva (a HSA elotti idokben) Windows alatt, hogy a video driver resze kell hogy legyen. Ezt nem en talaltam ki, hanem igy talalta ki anno az nVIDIA is (bar ok a CUDA-val kezdtek), a Khronos is (OpenCL), es az AMD is (Stream)."amikor megjelentek az első OpenCL driverek, mert már akkor feltettem és használtam"
Nem mintha ez barmit is szamitana. Plusz, attol, hogy OpenCL drivernek hivjak, me'g nem lesz az. Hivhatod barminek, akkor is csak egy layer a videodriveren, mikozben maga a videodriver kell hogy tamogassa az OpenCL-t. Egy API, ami egy-ket DLL fajlbol all, me'g nem lesz driver, az kicsit mas teszta (ld. kernel driver). OpenCL runtime, az mar kozelebb all az igazsaghoz, de az megint nem driver.
-
Fiery
veterán
CUDA driver azt jelenti, hogy ForceWare, azaz olyan videodriver made by nVIDIA, ami tamogatja a CUDA-t. Olvasd el a szoveget alaposabban, es ki fog belole derulni. De ha nem is akarsz ilyen melyen belemaszni a szovegbe, akkor sincs sok ertelme kulon CUDA driverrol beszelni, hiszen mar jo nehany eve a CUDA tamogatas a ForceWare videodriverek szerves resze. Sokkal elobb lett a CUDA rendesen integralva a ForceWare-be, mint a Catalystba az OpenCL rendesen berakva, de ezt csak megjegyzem, ez nem itelet az AMD felett. Az AMD-nel a Stream meg annak az elhagyasa es az OpenCL-re atallas nagyon megkavarta a dolgokat.
[ Szerkesztve ]
-
Fiery
veterán
Tok mindegy, melyik ceg hogyan hivja, ha egyszer nem driver! Ennel egyertelmubben nem tudom elmagyarazni. De tudod mit? Fogd a legujabb Catalystot, a legujabb ForceWare-t es a legujabb IVB/HSW video drivert, es keresd meg benne az OpenCL drivert. Segitek, kernel drivert kell keresni, jo esellyel .SYS kiterjesztessel. Mutasd meg, melyik fajl lesz az. De hogy kedves legyek, me'g egyet segitek: ne faradj, mert nem fogsz ilyet talalni. Amit talalsz, az nehany DLL fajl, ami nem driver, hanem DLL.
"A HSA bevezetése előtti időt mutató képrészen az OpenCL komponens a kép alapján közvetlenül a GPU-val kommunikál. De még ha nem is közvetlenül azzal, hanem valójában a kernel mode driverrel,"
Az engem baromira nem erdekel, hogy egy sematikus abran mit hova nyilaznak. Attol me'g -- ahogy irod is -- ott a kernel driver, ami "erdekes" modon a videodriver resze, es "erdekes" modon megegyezik a kernel driverrel (ld. pl. ATIKMDAG.SYS a Catalyst eseteben vagy pl. NVLDDMKM.SYS a ForceWare eseteben). Meg ott a D3D is, amit nem raktak oda az abrara, pedig eleg fontos Achilles-sarka a jelenlegi OpenCL implementacioknak.
"Nem beszélve arról, hogy az egész OpenCL nem csak egy compiler, mint eredetileg állítottad."
En azt mondom, az OpenCL implementaciok bugos resze a compiler. Az a legkritikusabb komponens, azt lehet elcseszni a legkonnyebben. A tobbi resze engem nem erdekel, mert a tobbi resz mukodik mindharom gyartonal. Ha meg mukodik, minek foglalkozzon vele a 3rd party fejleszto, nem az o dolga.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Általában minden OpenCL cucc hamarabb működik AMD-n, mert a fejlesztők többsége az APP SDK-t használja. Ez a legátfogóbb fejlesztőkörnyezet OpenCL-re, illetve rengeteg funkciója cross-vendor szinten is működik. Például a gDEBugger 6 is, ami egy elég fejlett OCL debugger.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Fiery
veterán
"A kernel mode driver egy igen alacsony szintű réteg, ami önmagában, user mode driverek nélkül nem sokmindenre használható"
Rosszul tudod. Egy sima futtathato binaris (.EXE) is be tud tolteni es tud hasznalni egy kernel drivert gond nelkul. Csak hogy ne a sajat hazamtajarol mondjak peldat, ott van pl. a CPU-Z, ami igy mukodik. Es egy mar betoltott kernel drivert is tud hivogatni egy futtathato binaris, nem kell kozejuk feltetlenul egy DLL-nek ekelodnie.
"Honnan tudod, hogy egy adott helyzetbeni hibás működés forrása nem ez a rész?"
Ha ugy lenne, akkor se tudnek vele mit kezdeni. Ha egyszer egy csomagban kapom a gyarto OpenCL API-jat (akarmi.dll), aminek resze az OpenCL compiler, akkor hiaba van itt vagy ott a DLL-ben a bug, attol me'g a forditasi eredmeny sz*r lesz. Ha meg az eredmeny sz*r, nem az en feladatom kutatni a pontos helyet, ahol elcsuszik a forditas az adott gyarto OpenCL implementaciojan belul. Ha az altalunk keszitett szoftver bugzik egy akarmilyen hardveren, nem a hardver gyartoja fogja kideriteni, hogy a mi szoftverunkben pontosan hol a bug, nem az o feladatuk ezzel molyolni.
"Megjegyzem, pl. a WinZIP OpenCL része előbb működött AMD-n (és talán NV-n), mint Intelen."
Es? Ha minket (is) az AMD penzelne, es a lejelentett compiler bugjaikat nem heteken hanem napokon belul javitanak, a mi OpenCL kerneleink is elkeszulhetnenek eloszor AMD-re. Csak tudod mi, mint fuggetlen fejlesztok, nem adnank ki egy OpenCL kernelt, ami nem fut az egyik gyarto GPU-jan. Vagy fusson mindenhol (addig kell nyomatni a compiler fejlesztoket), vagy sehol. Nyilvan kivetel a VIA, amelyiknek a v0.1 Alpha-nal is gyatrabb allapotban ragadt meg az OpenCL implementacioja, ok egyszeruen feladtak a dolgot, nincs ra kapacitasuk.
Megjegyzem, a kulonfele OpenCL-lel kapcsolatos bugok miatt en me'g veletlenul sem biznam mondjuk az adatmenteseimet egy GPU-val gyorsitott tomorito/archivalo szoftverre. Nagyon jol es abszolut megbizhatoan mukodik az a CPU-n, nincs szukseg extra rizikora meg hogy egy videodriver frissites utan egyszercsak alattomos modon elsz*rodjanak az archivalasaink. Ami persze csak akkor derulne ki, ha mondjuk lenne egy adatvesztes es megprobalnank visszallitani a fajlokat... Az ilyen GPU-val gyorsitott WinZIP-pel szorakozas pont addig jopofa, amig nem emberi sorsok mulnak a dolgon.
[ Szerkesztve ]
-
Fiery
veterán
"szóval, nem adtok ki olyat, ami nem fut az egyiken, kivéve, amelyiken nem fut."
A VIA implementacioja nem publikus es nem mukodik rajta semmi, me'g egy egyszeru clGetDeviceInfo hivas sem. Csupan azert emlitettem meg oket, mert belekezdtek, akartak volna csinalni, de beletort a bicskajuk. Ok lettek volna a 4. szereplo.
"Korábban az Intel OpenCL drivere is kezdetleges volt, miközben az AMD-é és NV-é már nem. Akár független valaki, akár nem, nem várható, hogy félévekig várjon egy szoftver kiadásával az egyik HW gyártó miatt."
Egyreszt a multrol beszelsz, mig en a jelenrol, masreszt meg amikor a WinZIP OpenCL implementacioja elkeszult (cca. 2 eve), akkor az nVIDIA-e teljesen franko volt mar, ergo elvarhato lett volna, hogy legalabb AMD+nVIDIA-n fusson. Csak ugye az exkluzivitas nagy ur, az sokat meger az AMD-nek meg a tobbieknek is adott esetben
"Ha valós veszély lenne, amit a 4. bekezdésben írsz, szerintem a WinZIP kiadója nem vállalta volna a felelősséget."
Kar, hogy az OpenCL compilert nem ok keszitik, tehat toluk fuggetlenul barmikor elsz*rodhat az egesz GPU-gyorsitott tomorito szoftveruk
Ok meg felteszik a kezuket, hogy az "AMD volt!" De ha szamodra abszolut megnyugtatonak tunik a WinZIP GPU-gyorsitasa, nyugodtan hasznald, nekem teljesen mindegy, ki mit hasznal.[ Szerkesztve ]
-
Fiery
veterán
Nem mondtam, hogy hazudnak. De ezt az oldalt erdemes megnezni --> [link] Az URL onmagaban is felettebb erdekes. Meg az a 4 db AMD vagy AMD technologiahoz kapcsolodo logo sem arra utal, hogy ez egy fuggetlen, OpenCL-hez kotodo fejlesztes. Eleve "AMD OpenCL technology" neven hivatkoznak ra... Ha ez egy kifejezetten nem exkluzivitasra torekvo fejlesztes lett volna, akkor nem lett volna a lapon ennyi AMD logo, nem lett volna ennyiszer hangsulyozva, hogy ez egy AMD technologiakhoz kotodo fejlesztes, es ott lett volna csillag/kisbetuvel, hogy "Coming soon for nVIDIA and Intel GPUs". Ami persze utana meg is tortent, azaz elkeszult a masik 2 gyarto GPU-ira is a portolas.
Lehet, hogy ez az egesz csak arra volt jo, hogy nyomast gyakoroljon a WinZIP keszitoje (Corel) az nVIDIA-ra es Intelre, hogy szorosabban egyuttmukodjenek a WinZIP OpenCL-re portolasaban, es kijavitsak a bugos compilerekeit. Ez -- mar ha ez tortent -- a tortentek fenyeben hatott is a gyartokra, csak epp igy utolag mar nehez eldonteni, hogy mi volt a motivacio valojaban. Mindenesetre, ha emelle odatesszuk, hogy a Corel tunik a HSA legnagyobb (PC-s szoftverkeszito) tamogatojanak, akkor szamomra eleg egyertelmu a konkluzio -- de mindenki hozza meg sajat hataskorben a kovetkezteteseket es teoriakat.
((( Ezen felul vannak me'g birtokomban olyan informaciok, amik egyik iranyba billentik a merleget, de ezekrol nem lenne szep dolog beszelnem. Max. privatban egy sör es pizza mellett
)))[ Szerkesztve ]
Azt mondom, 50-50. Mindketto problemas, csak maskepp. Az AMD-nel kicsit konnyebb kovetni az OpenCL compiler fejlodeset, az Intelnel a hulye driver szamozas kicsit nehezkesse teszi a dolgokat. Az Intel compilere azert is van elonyben, mert nagyjabol csak 1 architekturat kell tamogatnia (Gen7.x), es nem kell dupla pontossagu lebegopontos szamitasokkal bajlodnia. Nem fair osszevetni oket SZVSZ.
A "GPU drivers" szavakat kell egy adott fogalomkent ertelmezni, es onnan kiindulni. Olyan GPU driverrol van szo, ami megfelel az OpenCL 1.0-nak, azaz videodriverrol van szo, ami tamogatja az OpenCL-t. Nem OpenCL driver, mert a (GPU-khoz valo) OpenCL es ugy altalaban GPGPU tamogatas eleve ugy van megoldva (a HSA elotti idokben) Windows alatt, hogy a video driver resze kell hogy legyen. Ezt nem en talaltam ki, hanem igy talalta ki anno az nVIDIA is (bar ok a CUDA-val kezdtek), a Khronos is (OpenCL), es az AMD is (Stream).
Új hozzászólás Aktív témák
ph A vállalat az Athlon és a Sempron márkanevet is visszahozza.
- Intel I7 13700K 16mag/24szál - Új, Tesztelt - Eladó! 128.000.-
- Intel I5 13600KF 14mag/20szál - Új, Tesztelt - Eladó! 88.000.-
- Beszámítás! Intel Core i7 7700K 4 mag 8 szál processzor garanciával hibátlan működéssel
- Beszámítás! AMD Ryzen 7 7800X3D 8 mag 16 szál processzor garanciával hibátlan működéssel
- Újszerű - INTEL Core i5-14600KF 14mag 20 szál 5.3GHz CPU - bolti garanciával