- iPhone topik
- Vodafone mobilszolgáltatások
- Telekom mobilszolgáltatások
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Eleglide C1 - a középérték
- Milyen okostelefont vegyek?
- Android szakmai topik
- DIGI Mobil
- Android alkalmazások - szoftver kibeszélő topik
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
Hirdetés
-
Premier előzetest kapott a V Rising
gp Napokon belül befut a teljes PC-s kiadás, az év során pedig megkapjuk a PlayStation 5 változatot.
-
Toyota Corolla Touring Sport 2.0 teszt és az autóipar
lo Némi autóipari kitekintés után egy középkategóriás autót mutatok be, ami az észszerűség műhelyében készül.
-
A legtöbb amerikai szerint a TikTok egy őket befolyásoló eszköz
it Egy felmérés szerint a legtöbb amerikai osztja azon véleményt, hogy a TikTok egy őket befolyásoló eszköz.
Új hozzászólás Aktív témák
-
Fiery
veterán
Gigabyte F2A88XM-D3H Miert pont ezt? Mert epp ez volt raktaron Persze elso korben Richland 6800K-val kellett BIOS-t frissiteni, mert a 7850K-val nem akart elindulni. A BIOS-bol nem ment a frissites, CD-rol bootolva se jott ossze a dolog, de vegul Windows alatt @BIOS-szal felfrissult szepen. Az uj BIOS-szal meg a 6800K nem akart kepet adni Windows boot elott, ugyhogy mokas volt. De vegul mukodik hibatlanul, egyedul a memoria idozitesek manualis allitgatasa nem teljesen 100-as, de majd javitjak a fiuk.
[ Szerkesztve ]
-
Fiery
veterán
Valoszinuleg az en lapommal az volt a baj, hogy F1-es, legelso BIOS volt rajta. A kovetkezovel mar velhetoen siman elindult volna a Kaveri. Kis szivas az ilyen uj konfigoknal egyebkent is benne van a pakliban, inkabb azon szoktam csodalkozni, ha valami elsore flottul uzemel.
[ Szerkesztve ]
-
Fiery
veterán
Szerintem max. 2 het kerdese, es mindenhol lesz boven. Azert ez megsem egy Core i3/i5, hogy mindenki ilyet akarjon. Teny, hogy itt a forumon sokan akarnak Kaverit, de az AMD piaci reszesedese ebben a (mainstream desktop) szegmensben nem olyan oriasi (sajnos), es a Kaverival sem fog ez drasztikusan atalakulni.
-
Fiery
veterán
A savszelesseg nem valtozik jelentosen, ha a kesleltetes nemileg valtozik (CL9 vs. CL11). Sokkal jelentosebben tud valtozni a savszelesseg, ha architekturalis fejlesztesek tortennek, meg persze ha a memoria orajel valtozik.
A WinRAR meglepoen lassu eredmenyeket tud adni Kaverin (pl. 6800K vs. 7850K), alaporajelen is. Tuningolni mi nem probaltuk a Kaverit, sz'al passz, de most mar csak par perc, es jonnek a review-k tomegevel elvileg
[ Szerkesztve ]
-
Fiery
veterán
[ Szerkesztve ]
-
Fiery
veterán
"Az Anandtech-féle kiírásokat nem teljesen értem. WinRAR alatt miért az IGP-k neve van kiemelve és a processzorok neve a háttérben? Mintha pepitában azt akarnák sugallni."
Eliras, a WinRAR nem hasznal GPU-t, nincs ertelme a GPU-t feltuntetni ott eleve.
"Mindenesetre a Mantle/BF4 nélkül ezek számomra egyszerűen nem eredmények, mert ilyesmit is vártam DX alatt."
Azert jo latni, hogy DX alatt is mar szepen porog a Kaveri iGPU-ja. A Mantle(-t hasznalo jatekok) meg a HSA sem keszult el idoben, de addig is DX alatt is jol megy a Kaveri, nincs itt gond szerintem.
-
Fiery
veterán
Haswell Core i7-4770 GT2 iGPU, alaporajelen:
- 32-bit Integer: 42,55 GIOPS
- 64-bit Integer: 12,36 GIOPSKaveri A10-7850K, szinten alaporajelen:
- 32-bit Integer: 147,1 GIOPS
- 64-bit Integer: 34,98 GIOPSAzt viszont erdemes figyelembe venni, hogy az Intel-fele OpenCL compiler finoman szolva sem szereti az integer adattipust Azon me'g boven kell dolgoznia az Intelnek.
[ Szerkesztve ]
-
Fiery
veterán
"Nincs róla valami infó, hogy pl. az x264 fejlesztői tervezik-e kihasználni az IGP-t?"
Ez csupan azon mulik, hogy az AMD mennyire sikeresen tudja a fejlesztoket meggyozni a HSA elonyeirol. Az biztos, hogy megprobaljak meggyozni oket, eleg nagy hangsulyt kapott tavaly is mar a fejlesztok gyozkodese
-
Fiery
veterán
válasz stratova #251 üzenetére
Mondjuk inkabb ugy, hogy a gyartok itt-ott elb***tak a dolgot, sajnos. A gyartoknak teljes hozzaferesuk volt mar kb. 8-9 honapja a Kaveri BKDG-hez, es a nyaron elkezdtek szallitani nekik a Kaveri ES peldanyokat is. A problemat az okozhatta, hogy tul koran kiadtak az FM2+ alaplapokat, me'g mielott normalis Kaveri tamogatasu BIOS kerulhetett volna belejuk...
-
Fiery
veterán
"Minden Mantle játék kifogja használni a Kaveri IGP részét"
Kiveve, ha a jatek csak 1 GPU-t tamogat, es epp van egy GCN dGPU is az adott konfigban.
"Mantle alatt NINCS DG, mert az összes grafikus gyorsítót egy egységként kezeli az API."
Marmint a GPU-kat egy-egy egysegkent kezeli, kulonallo eszkozkent. Remelem, igy akartad irni, csak nem feltetlenul igy jott le abbol, amit irtal
-
Fiery
veterán
Ezt irtad: "mert az összes grafikus gyorsítót egy egységként kezeli az API."
Ha ezzel azt akartad irni, hogy minden GPU-t osszefoglalva, osszefogva, egyetlen egysegkent kezel a Mantle, akkor az nem stimmel. Azaz ha van 2 GPU-d, azokat nem egy eszkozkent (device) menedzseli a Mantle, hanem 2 eszkozkent. Ha azt akartad irni, hogy minden GPU-t, egyenkent, kulonallo eszkozkent kezel a Mantle, akkor stimmel.
-
Fiery
veterán
Pont ez az, hogy a Mantle ugy fogja mutatni az applikaciok fele a GPU-kat, ahogy azok fizikailag ott vannak a gepben. Ha 1 dGPU-d van, akkor 1 db GPU-nak mutatja; ha 1 iGPU-d van meg egy 2 GPU-s videokartyad (pl. HD7990), akkor 3 db GPU-nak. Az applikacio feladata lesz ezt menedzselni.
"Nem teljesen értem, hogy az Adobe cuccban OpenCL alatt miért lassul mindegyik processzor. Így akkor tök felesleges volt beleépíteni"
Ez a szep az OpenCL-ben Sokat tud hozni, de lehet sz**ni is vele gazdagon, ha nem megfeleloen implementaljak, vagy ha a szoftver keszitoje belefut egy nyomoronc video driver (pontosabban OpenCL compiler) bugba Ezert sem feltetlenul annyira jo otlet ez az egesz HSA ize: legalabb annyi fejfajast hoz, mint amennyi teljesitmenyt lehet vele nyerni potencialisan.
Egy nativ x86 (vagy akár ARM) kodnal ha mondjuk a C++ fordito, amit hasznalsz jol mukodik es jo kodot fordit, akkor leforditod a forraskodot egy kesz binarisra (pl. AKARMI.EXE), es utana nem vagy kiteve a drivereknek (kiveve persze ha mondjuk Direct3D-t hasznalsz). HSA/OpenCL eseteben viszont megirod a forraskodot, majd ha az on-the-fly forditasra szavazol (arra erdemes egyebkent), akkor a video driver irojaban meg kell biznod annyira, hogy az majd a program futasa kozben az epp telepitett video driver segitsegevel megfelelo, stabil es gyors binarist fog a programod szamara forditani. A jelenlegi HSA implementacionak is pont ez a legnagyobb problemaja: me'g nem ert meg annyira a fordito, hogy ugyanazt a sebesseget es stabilitast tudja biztositani, amit az AMD regi (OpenCL 1.x / APP SDK) forditoja.
[ Szerkesztve ]
-
Fiery
veterán
En csak azt mondom, hogy a HSA/OpenCL-lel nyerni is lehet, de szivni is jo sokat, mert a fejleszto ki van szolgaltatva mas fejlesztoknek. Ellentetben a nativ programozassal, amikor ugyan nehezebb megtanulni adott esetben az optimalizaciot, nehezebb esetenkent AVX-re portolni egy adott program reszletet, viszont ezekutan a fejleszto nincs kiteve mas fejlesztok munkaja minosegenek. Mindenki dontse el, hogy melyik utat valasztja, nekem pl. edesmindegy hogy ki mire szavaz
[ Szerkesztve ]
-
Fiery
veterán
Kinek mi a nehez, embere valogatja. Aki assemblyben penge, annak az AVX/AVX2 sem egy oriasi mutatvany. Aki assemblyhez nem ert, annak jo esellyel az OpenCL/HSA szimpatikus lehet.
Ami nagyszeru dolog: AVX-et es OpenCL-t is tamogat mindket ceg (AMD, Intel), ugyhogy a fejlesztoknek van mibol valogatnia.
[ Szerkesztve ]
-
Fiery
veterán
En nem mondtam, hogy az assembly tokeletes Sok mas lehetoseg is van, a fejlesztok majd eldontik, merre huznak. A HSAIL valoban jo lehetoseg, csak kerdes, hogy ki fog azzal szorakozni, ha mondjuk az Intel es az nVIDIA sem tamogatja a HSA-t. Mert mig egy OpenCL 1.x kodot siman lehet HSA-ra portolni, de kozben elfutkarozik szepen Intel es nVIDIA GPU-kon is, addig egy HSAIL kod nem fog egyaltalan futni Intel es nVIDIA GPU-kon. Ergo nagyon az AMD fele kell hogy huzzon az elkepzelese valakinek ahhoz, hogy a HSAIL egyaltalan szoba keruljon. Ha pedig az SSE, AVX, AVX2, FMA (stb) assemblyt allitjuk szembe a HSAIL-lel, akkor megint az assembly all nyeresre, hiszen mindket nagy x86 CPU-gyarto tamogatja oket, lenyegeben egyforma lelkesedessel.
"és csak a teszt-rutinok készülnek asm-ben"
Nalunk kod generator van, sz'al assemblynel is kicsit kemenyebben nyomjuk Ami nem feltetlenul jo dolog, de nekunk bevalt. Ezert is mondom, hogy izlesek es pofonok.
[ Szerkesztve ]
-
Fiery
veterán
Arra az Intelre gondolsz, ami piacvezeto a PC-s CPU es a GPU piacon is, meg a szerverprocesszorok piacan is? Nehez lenne megkerulni oket, nem hinnem, hogy csak egy a sok kozul. Az nVIDIA-t szinten nehez lenne megkerulni, siman lehet, hogy utcahosszal beelozik a(z ARM-os) tobbi gyartot a Denverrel.
"az erőviszonyokban az sem elhanyagolható tényező, mivel milyen számítási teljesítményt lehet aktuálisan igába fogni"
Attol fugg, mikepp oldod ezt meg, es milyen szoftverrol van szo. Jelenleg -- ha mar "aktuálisan"-t irtal -- azert azok a szoftverek vannak elsopro tobbsegben, amik nem GPU-n futnak, legyen szo OpenCL-rol, CUDA-rol vagy epp HSA-rol. Amugy meg ha a nyers szamokat nezed, az aggregalt lebegopontos teljesitmenye eleg hasonlo a csucs Kaverinak es a csucs desktop Haswellnek. Nyilvan nehezen lehet ezeket (marmint az FPU es az iGPU nyers erejet) osszeadni, nincs sok ertelme, de akkor is erdekes, hogy mennyire kozel vannak egymashoz.
[ Szerkesztve ]
-
Fiery
veterán
válasz #25954560 #279 üzenetére
Mi az NVIDIA OpenCL JumpStart Guide-ot olvasgattuk elso korben, meg ugy altalaban elolvastunk minden prezentaciot CUDA es OpenCL ugyben, amit konnyen megtalalt a gugli. Nem konnyu az embernek az agyát atallitani a GPGPU-s temara, de ha egyszer bekattan es "heureka"-t kialtasz, onnantol mar csak az OpenCL/CUDA compilerekkel valo szivas lehet a gond Ami meg azert problema, mert ha egyszer a compiler az utadba all, es nem tudsz tovabblepni a compiler bug miatt, akkor heteket, honapokat kell varni az AMD/Intel/nVIDIA compiler bug fixre
-
Fiery
veterán
"A PC visszaszorulóban van a hétköznapokban"
Marmint ugy erted, hogy kevesebbet adnak el, mint regen. Ez nem feltetlenul jelenti azt, hogy visszaszoruloban van a hetkoznapokban, legfeljebb azt, hogy a regi PC-juk is eleg jo az embereknek azokra a celokra, amiket a PC-n muvelnek. Persze tudom en, hogy az okostelefonokra athelyezodik a hangsuly, sok mindent azon csinalunk, de attol me'g a PC megkerulhetetlenul resze marad a legtobb otthonnak, es lenyegeben az osszes cegnek. Legfeljebb notebook, ultrabook, tablet vagy 2-in-1/3-in-1/All-in-1 format olt.
"Nem érzem túl fernek a csúcs Haswellt a csúcs Kaverihez hasonlítani"
Miert? Mindket ceg csucs desktop "APU"-ja.
Ertekek:
Haswell Core i7-4770: x86 FPU = 433 GFLOPS, iGPU = 382 GFLOPS
Kaveri A10-7850K: x86 FPU = 124 GFLOPS, iGPU = 735 GFLOPSEzek mért ertekek, nem a brosurabol szarmaznak Es ugye ennel me'g van egy picivel gyorsabb desktop Haswell is.
[ Szerkesztve ]
-
Fiery
veterán
A tablet es a feltegla kozt azert van me'g jo nehany variacio, pl. ultrabook meg mini-PC.
Az ár meg ne haragudj, de nem relevans, ha csupan a nyers teljesitmenyt nezzuk. Nyilvan ha valaki processzort akar valasztani maganak, akkor szamit az ár, de ez most egy szakmai kerdeskor szerintem, itt nem az ár a donto. Az ar/ertek arányt a Kaveri nyeri, ez nem kerdeses, de ennek csupan az az oka, hogy muszaj neki olcsonak lennie, kulonben me'g ennyit sem adnanak el belole A nyers eloallitasi koltseget tekintve 100%, hogy a Kaverit dragabb eloallitani, kiveve persze ha az R&D koltsegeket is belevesszuk a kepletbe.
"Mért, de erősen szintetikus peak értékek"
Nem mondtam, hogy nem azok. Pusztan erdekessegkepp hoztam fel ezeket.
"Több relevanciával bír egy sustained SPEC, LINPACK"
Ezek futnak GPU-n? Ha nem, akkor a Haswell nyert, latatlanban
"illetve adott alkalmazásokkal végzett tesztek"
Az a baj, hogy olyan alkalmazasbol eleg keves van, ami aggregaltan hajtja ki az FPU-t es az iGPU-t is, egyszerre. En pl. egy ilyet sem ismerek, nemtom Te hogy vagy ezzel. Ha meg kulon-kulon nezzuk, es azt vesszuk, hogy mennyivel tobb alkalmazas van, ami FPU-t hasznal, mint ami GPU-t (compute), akkor az x86 CPU/FPU kepessege lesz az erdekesebb, es megint nem a Kaveri nyer
[ Szerkesztve ]
-
Fiery
veterán
"Az Intel által önállóan végzett, világelsőséget adó gyártástechnológiai fejlesztésekre költött dollármilliárdok miért is számítanának... Azokat is vissza kell ám termelni. Szerves része az árnak."
Ez egyertelmu, ezert is emlitettem meg. Csak ugye lehet kulon vizsgalni azt is, hogy egy adott CPU eloallitasi koltsege "anyagban" mennyi, pl. hogy egy waferbol hany jo processzor nyerheto ki, es egy wafer megmunkalasa mennyi penzbe kerul. A Kaveri eleg szep nagy die lett (38 %-kal nagyobb, mint a desktop 4 magos Haswell GT2 iGPU-val), nem feltetlenul olcso gyartani -- de kozben a vegtermeket olcson "kell" adnia az AMD-nek, lenyegesen olcsobban, mint egy olcsobban gyarthato konkurens termeket. De ez az egesz termeszetesen megfordul, ha az R&D is bejon a kepbe, csak ott meg nehez atlatni, hogy mondjuk egy-ket 22 nanon termelo gyar epitesi koltsege vegul pontosan hany db processzorra oszlik el az Intelnel. Az biztos, hogy potencialisan nagysagrendekkel tobbre, mint az AMD-nel, es emiatt is bonyolult ez az egesz
-
Fiery
veterán
Az nVIDIA-nak eleve nincs x86 licence, tehat reszukrol fel sem merul az AVX vagy AVX-512 Nem veletlen, hogy ARM alapokra epitenek: nincs mas lehetoseguk.
"Emellett a HSA megtagadásával egyszerűen kiszorítják magukat Androidból, ha a Google tényleg csak a HSA formájában fogja engedélyezni az OpenCL használatát."
Ez me'g nem lefutott meccs, jelen allas szerint a Google baromira nem akarja az OpenCL-t semmilyen formaban implementalni. Az egy dolog, ha megturik majd a runtime-kent valo telepitest (HSA), de mar reg nem a "don't be evil" kampany megy, ergo ha fel akarjak futtatni a RenderScriptet, akkor barmikor kitilthatjak az egesz HSA-t az Androidrol ugy ahogy van
-
Fiery
veterán
Mert az OpenCL eseteben maskepp kell ezeket ertelmezni, mint a hagyomanyos rendszermemoria olvasast/irast/masolast. A memoria olvasas azt jelenti, hogy a GPU sajat dedikalt memoriajabol (pl. videokartyan a sajat videomemoria) olvas a CPU a sajat rendszermemoriajaba, pl. a PCI Express vagy Onion buszon keresztul. Az iras ugyanez, csak a masik iranyban. A masolas viszont nem azt jelenti, hogy a GPU memoriajabol olvasol a CPU memoriajaba, majd ugyanazt visszairod a GPU memoriajaba egy masik teruletre, hanem kozvetlenul, a GPU sajat hataskoreben tortenik a masolas, a CPU-t lenyegeben kikerulve. Ezert tud a masolas -- kulonosen videokartyaknal -- sokkal magasabb lenni, mint az olvasas+iras. Persze egy SVM-enabled rendszernel elvileg nem lehet ezeket a fogalmakat ertelmezni, azonban a visszamenoleges kompatibilitast meg fogja tartani az OpenCL 2.0 is, azaz tovabbra is lesz lehetoseg nem koherens modban kezelni az iGPU-nal a memoriat, es tovabbra is masolgatni ide-oda, es annak a sebesseget benchmarkolni.
Ugy lehet egyebkent felismerni az SVM-enabled rendszert az AIDA64 GPGPU benchmark paneljen, hogy a memoria eredmenyek szep kerek nullak a GPU-nal
[ Szerkesztve ]
-
-
Fiery
veterán
Azert kell hogy igy legyen, mert az OpenCL erre ad lehetoseget direktben. Lehet memoria puffert foglalni a rendszermemoriaban ill. a GPU sajat dedikalt memoriajaban is; valamint az SVM-ready rendszereknel lehet koherens memoria blokkot foglalni, amit a CPU es a GPU is egyarant elér gond nelkul. Ha pedig lefoglaltal 1-1 ilyen blokkot, akkor kozottuk lehet masolgatni OpenCL hivassal. Arra nincs direktben lehetoseg, hogy kifillezz egy blokkot egy adott device (CPU vagy GPU) segitsegevel. Lehetne furmanyos, nyakatekert megoldasokkal erdekes benchmarkokat kesziteni, pl. mérni a (GPU) L2 cache, local data share, global data share savszelesseget is, de egyelore nem latjuk ezt igazan fontosnak es erdekesnek.
"Miert erdekes az, hogy milyen gyorsan tolja at a pcie buszon"
Nagyon is erdekes, hiszen pl. innen tudhatod, hogy ha PCIe 3.0 videokartyad van, akkor valoban PCIe 3.0 modban mukodik-e.
"amikor pl. valamilyen statisztikat csinalna az ember a videomemben levo adatokon (amikor is vegig kell oket olvasni)"
Na igen, csakhogy a GPGPU-s temanak pont az a lenyege, hogy nem olvasod vegig oket Legalabbis nem linearisan, egy szálon, hanem szetdobalod tobb ezer work item-re, sok-sok szálat indit a GPU, stb. Ergo nincs sok jelentosege a videomemoria sebessegenek onmagaban, a GPGPU-nal a legritkabb esetben okozza a videomemoria sebessege a szuk keresztmetszetet. Sokkal fontosabb pl. hogy milyen gyakran es mennyi adatot masolgatsz a PCIe csatolon at -- ez utobbi persze SVM-nel nem tema.
-
Fiery
veterán
Van egyszeres es dupla pontossagu FLOPS is.
"1 mag 32 flops-al az 1024 bites adatokat jelent akkor"
Nem egeszen, hiszen 256 bites SIMD regiszterekkel dolgozik a Haswell. Egy 256 bites regiszterben van 8 egyszeres pontossagu adat, es ezeken tud egyszerre 2 FMA muveletet vegrehajtani a Haswell --> [link] Egy FMA muvelet pedig 2 FLOPS-nak minosul (FMA = szorzas+osszeadas egy cikluson belul, ami 2 lebegopontos muvelet).
"A linkelt cikkben nekem úgy tűnik AVX2-t használtak ami elvileg tudja az FMA-t."
Az AVX2 nem egyenlo az FMA-val, ezek kulonbozo utasitaskeszlet kiterjesztesek. Egy AVX2-re optimalizalt kod me'g nem feltetlenul hasznal FMA utasitasokat.
-
Fiery
veterán
"Talán mert akkor nem kell az egész világgal szemben állni."
Ezt az Intelnel hidd el, nem igy erzik, legfeljebb Te allitod ezt be ilyen dramaian De minden cegre ez a sors var, ami egy adott piacon elsopro sikereket er el (akarmilyen modszerekkel). Egyes emberek inkabb a kisebb, szegenyebb ceg melle allnak, es elkezdik utalni a "nagyot". Ugyanez a sors var a guglira is
Egyebkent az Intel nem az egesz vilaggal all szemben jelenleg, hanem csupan az ARM-mal. Semmi mas nem erdekli oket jelenleg, csak hogy lenyomjak az ARM-ot minden vonalon, teljesitmenyben es fogyasztasban is.
[ Szerkesztve ]
-
Fiery
veterán
-
Fiery
veterán
válasz dergander #305 üzenetére
Oszinten? Szerintem a Kaverinal valami nem gombolyu a memoria vezerlo kornyeken. Eleve joval magasabb kesleltetessel dolgozik, mint a Richland (pl. Dual Channel DDR3-2133: 6800K = 60 ns, 7850K = 80 ns), es nem is skalazodik szepen. Valami bottleneck lehet a hatterben, en az uncore kornyeken nezelodnek...
-
Fiery
veterán
válasz dergander #310 üzenetére
Azonos orajelen azert a Kaverinak kellene gyoznie. A CPU Queen benchmark pedig nem hasznal tul sok memoriat, ugyhogy a memoriaval nem fog szepen skalazodni. Ha olyan benchmark erdekel, ami a CPU orajellel es a memoriasebesseggel is skalazodik, akkor inkabb a CPU PhotoWorxx-ot probalgasd.
[ Szerkesztve ]
-
Fiery
veterán
"Sokkal fontosabb pl. hogy milyen gyakran es mennyi adatot masolgatsz a PCIe csatolon at"
Alapvetoen arra gondoltam, hogy ha valaki ujonnan kerul be az OpenCL/CUDA vilagaba, akkor elso korben hajlamos beleesni a csapdaba, hogy tul sokat masolgasson ide-oda, es a vegen az osszteljesitmeny nagyon leesik. Ha mar nem kezdo az ember, akkor ezek automatikusan mennek persze, es ezert sem feltetlenul lenyeges mondjuk egy Teslanal a PCIe csatolo tempoja -- hacsak nem sulyos, tobb tiz gigabajtnyi adat halmon dolgozik az ember.
"szoval akkor a gpu mem read az valojaban azt jelenti, hogy a cpu oldalarol milyen gyorsan lehet a gpu memoriat olvasni"
Igen. Vagyis GPU Memory Read by CPU, teljes nevén Korrektebb lenne persze Device-to-Host Bandwidth-nek hivni, csak akkor meg az OpenCL/CUDA temaban kevesbe feketeoves felhasznalok (azaz a felhasznalok 99,9 %-a) nem értené, hogy mi a rak az.
[ Szerkesztve ]
Új hozzászólás Aktív témák
AMD "Kaveri" APU topik
- FM2+ tokozás
- Négy vagy két mag
- Integrált DX11.2 Radeon GPU
- Integrált PCIe 3.0 vezérlő
- DDR3-2133 RAM támogatás
- HSA / Mantle / TrueAudio
- Szorzózármentes "K" modellek
* Kaveri (Steamroller & GCN):
AMD Ax-7xx0
- Milyen TV-t vegyek?
- Gördeszka topic
- Az NVIDIA szerint a partnereik prémium AI PC-ket kínálnak
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Xbox Series X|S
- Anglia - élmények, tapasztalatok
- Konzolokról KULTURÁLT módon
- BestBuy ruhás topik
- Milyen billentyűzetet vegyek?
- 3D nyomtatás
- További aktív témák...
- Beszámítás! Intel Core i3 10105 4 mag 8 szál processzor garanciával hibátlan működéssel
- Beszámítás! Intel Core i3 9100 4 mag 4 szál processzor garanciával hibátlan működéssel
- Intel I5 13600KF 14mag/20szál - Új, Tesztelt - Eladó! 88.000.-
- Hibátlan - AMD Ryzen 5 2600 - 6 mag 12 szál 3.4GHz + gyári hűtő
- AMD Ryzen 3600 (pár napig használt)