- Olcsóbb lett a Tesla Full Self-Driving szoftvere
- OpenWRT topic
- Vodafone otthoni szolgáltatások (TV, internet, telefon)
- Asustor NAS
- SkyShowtime
- Közel 1 billió dollárt vesztettek a big tech óriásai
- Vírusirtó topic
- Olyat tett a Netflix, amire senki sem számított
- Aliexpress tapasztalatok
- Otthoni hálózat és internet megosztás
Új hozzászólás Aktív témák
-
stratova
veterán
válasz akoscomp #246 üzenetére
Szerintem kérdezz rá a boltban bios frissítésre. Ha ott nem jutnál dűlőre, nézz be az A10 témába, akad-e a lakhelyeden egy segítőkész fórumtárs, aki kölcsön tudná adni.
atti_2010: bár csak számunkra vált nemrég elérhetővé a BKDG, de lehet a gyártóknak sem volt még alkalmuk felvértezett BIOS-szal útnak engedni az FM2+ lapjaikat. Esetleg nem ismerték még a klb. p-state-khez társítandó feszültségeket (de ez csak kósza tipp). Pár oldal első tesztje is kb. végleges ES-ekkel történt saját bevallásuk szerint.
[ Szerkesztve ]
-
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...
-
Sztenn
tag
Most lehet nagy hülyeséget linkelek be, német tudásom még nem nagyon van ott a szeren...
elvileg itt láthatjátok melyik lap melyik biosával indul el a kaveri.
-
Volesz
csendes tag
Atti + xmaas-nak:
Ami biztos: a mantle alatt nincs afr, a játékfejlesztő feladata a többkártyás rendszerek támogatásának megvalósítása, ill. a Kaveri HSA, opencl képes.
Ugye INTEL alatt egy gcn vga-nak csak a mantle képességét lehet kihasználni, ez valamennyit fog gyorsítani, de dx alatt marad a jelenlegi teljesítmény szint.
Kaveri APU-val ki lehet használni a mantle api alatt az APU Dualgraphics képességét egyedi fejlesztői megvalósításban és/vagy a HSA/Opencl képességet, szintén ahogy tudják. Szerintem vagy-vagy, mindkettőt egyszerre nem tudom, hogyan lehetne megvalósítani. DX alatt pedig az AFR-s DG és/vagy HSA/Opencl, itt egyszerre a kettőt gondolom még nehezebb lenne megvalósítani.
Ezek alapján könnyen elképzelhető a teljesítményfölény a kaveri használatával az intel rendszerekkel szemben mind DX, mind Mantle alatt, de az ellentéte is, vagy vegyes, játék/api függő teljesítmény arány is.
Annyit tudunk, hogy Mantle alatt gyorsul a GCN, és hogy HSA alatt a Kaveri. Hogy ezek után az intelhez képest milyen lesz a Kaveris játék teljesítmény általánosságban, így laikusnak (mint én, és gondolom ti is) megmondani előre, szerintem csak hasra ütésnek számít.
De talán egy hozzáértőbb embernek erre nagyobb rálátása van. ABU85?
-
leviske
veterán
Nem akarlak megsérteni, de mielőtt írsz egy olyan hozzászólást, amiben lelaikusozol meg hasrautőzöl több embert, vehetnéd a fáradtságot, hogy ténylegesen utána is jársz a témának. Nincs baj azzal, ha kérdezel, de hibás kijelentéseket pláne ebben a stílusban tartsuk meg a Kaveri megjelenésével kapcsolatos cikk topikjának. Tökéletesen az a színvonal.
De azért tőmondatokban pár információ:
- Minden Mantle játék kifogja használni a Kaveri IGP részét, így az Intellel szembeni gyorsuláshoz nem lesz szükség HSA-ra a játékokban (honnan jött ez amúgy?).
- Dualgraphics-ról DirectX játékokban beszélhetünk, ahol ugyancsak megoldásra került az aszinkron feladatmegosztás a megfelelő kártyákkal (R9 290 és talán a R7 260), csak érni nem ér sokat. Mantle alatt NINCS DG, mert az összes grafikus gyorsítót egy egységként kezeli az API.
- OpenCL játékokban várhatóan pont nem fog gyorsulást felmutatni a Kaveri az Intel processzorokkal szemben, mivel az IGP le lesz terhelve egyéb feladatokkal, így nem tud segíteni a videokártyának.Remélem segítettem.
(#253) Sztenn:
Érdekes, hogy még kapni olyan Gigabyte lapokat, amik nem Kaveri "barátak", hiszen Novemberben már azokra is kint volt ilyen BIOS, ahogy látom.Ja hogy egy laphoz volt csak kint Novemberben... Nem szóltam.[ Szerkesztve ]
-
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
-
leviske
veterán
"Kiveve, ha a jatek csak 1 GPU-t tamogat"
Amiből rengeteg lesz, elvégre egy olyan megoldásról beszélünk, aminek a támogatása nem feltételezi az AMD partneri viszonyt, amiből következne a full platformtámogatás, ami a fejlesztőknek is érdeke."Remelem, igy akartad irni"
Nope. De forrást dobhatsz. -
dergander
addikt
Mantle ide vagy oda,már sokat késik,és lehet az a 45% amiről beszélnek nemis lesz semmivel jobb mint a dx,hallotunk annak idején a physxről is ezt azt mégse vált be,attól tartok ezse lesz akkora durranás
-
Volesz
csendes tag
Igazándiból csak azt akartam kihozni a hsz-emből, hogy nem lehet tudni, hogy milyen helyzetben, mely játékoknál lesz jobb az i7-gcn vagy a kaveri+gcn.
Bocs, ha valaki magára vette a laikusozást, emiatt elnézést kérek, de a hasra ütés egy kis túlzással megállja a helyét. Amíg kész számadatok nem állnak a részünkre, addig csak becsülhetünk az amd-s diákból, hogy milyen esetben mi várható a mantle/dx+kaveri vagy mantle/dx+i7 esetében. Egyébként minden cikket követtem a témával kapcsolatban, persze a tévedés jogát fenntartom. Sajnálom, hogy a hsz-ből ez szűrődött le neked, nem az amit összességében közölni akartam.A tőmondatokhoz:
A másodikhoz: mantle alatt valóban nem is DG-t értettem ezalatt, hanem hibrid crossfire-t, csak rossz kifejezést használtam. Bocs.
Az elsőnél: pl. a FIFA14 azért nem az új motorral jön PC-re, mert csak Kaveri apun lehetne jelenleg megvalósítani azt a fizikát és egyebet, amit az új generációs konzolon futó motoron megvalósítottak. És pont ezt akartam kihozni, hogy nem tudjuk hogy egy játék hogyan fogja kihasználni a közeljövőben az apu igp részét: gpuként vagy egy heterogén módon programozható apu compute unitjaiként (nem feltétlenül hsa segítségével, gondolom én, hisz cpura sem csak egy nyelven lehet programozni, a hsa csak egy példa, az opencl lett volna a másik, de a heterogén programozhatóság a lényeg), és hogy ezt milyen sikerrel történik majd meg.A lényeg, amit ki akartam hozni, hogy biztos, hogy a jövőben sok helyen előny lesz a kaveri egy gcn dgpu mellett, de ugyanúgy elképzelhető olyan eset, hogy ugyanazon api mellet egy i7+gcn dgpu lesz gyorsabb. Legalább is mostanság, a jövő meg ki tudja mit hozhat. És mindezt laikusként gondolom így, azok alapján amit eddig olvastam itt a ph-n, de nem kardoskodom egyik mellet sem teljes meggyőződéssel.
Nem akarok én senkit megbántani, mindezt építő jelleggel szántam, és lehet hogy én is félreértelmeztem korábbi dolgokat, vegyétek egy gondolatkísérlet eredményének .[ Szerkesztve ]
-
stratova
veterán
Hmm A8-7600 + R7 240 DDR3 DualGraphics* egészen bizalomgerjesztő. Mielőtt valaki legyintene, hogy ez csak egy belépő VGA tennék egy kis összehasonlítás.
A8-7600 IGP DDR3 2133 MHz
720 MHz 384:24:8 5.76 GP/s 14.4 GT/s 34.128 GB/s - 552,96 GFLOPsR7 240 DDR3 1800 MHz
730@780 MHz 320:20:8 5.84-6.24 GP/s 14.6-15.6 GT/s 28.8 GB/s - 467,2@499,2 GFLOPsHD 8730M DDR3 2000 MHz
650@700 MHz 384:24:8 5.2-5.6 GP/s 15.6-16.8 GT/s 32 GB/s - 499,2@537.6 GFLOPsHD 8850 DDR3 + i5-3230M teszt [625@775 MHz GPU 1800 MHz RAM]
575@725 v. 625@775 MHz 640:40:16 9.2 - 12.4 GP/s 23 - 31 GT/s 32 GB/s 800-992 GFLOPsIntel Ivy Bridge Guide for Gamers GTX 680M-mel (vö. i5-3230M vs.i3-3110M vs. A10-5750M)
CPU-ban A10-6700T ~= A10-5750M
*A késleltetéses grafikonhoz (a la mikroakadás).
Frame time
(ms) FPS rate
8.3 120
16.7 60
20 50
25 40
33.3 30
50 20[ Szerkesztve ]
-
leviske
veterán
Mantle játékokban legrosszabb esetben is egy szimpla egál várható az AMD és Intel közt, ha az IGP-k be vannak fogva fizikázni, vagy AI-ra. Ezzel azért nem számolt itt senki, mert ilyen játékot aktuálisan még nem jelentettek be. Az Ignite PC-re való érkezéséről még szó sem esett, a Frostbite 3 (amire a legtöbb Mantle játék épít) meg előreláthatólag arra használja egyelőre az IGP-t amivel itt mindenki számol. A teszteket mindenki várja természetesen, de ettől még írogatni lehet a témáról, elvégre sokkal több értelme van ennek, mint bőgni a linkelt topikban.
Amúgy megbocsájtok.
(#260) Fiery: Nem olvastam semmi olyat, ami az állításommal ellentétes lenne. Lehet túl késő van.
-
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.
-
leviske
veterán
A Mantle API a játékok irányába már egy egységesen kihasználható hardverként prezentálja a különálló eszközöket. Vagyis nekem ez rémlik. Nyilván nem arra gondoltam, hogy egy olyan megoldás, ami közelebb lép a konkrét hardverekhez, nem fogja érzékelni, hogy 1/2/8 GPU van a rendszerben. Ha ez nem így van, akkor sikerült nagyjából hatszorosára emelnem a felesleges hozzászólások számát a topikban és maradjunk ennyiben.
(#262) stratova: Nem teljesen értem, hogy az Adobe cuccban OpenCL alatt miért lassul mindegyik processzor. Így akkor tök felesleges volt beleépíteni.
MÁS: Visszanézegetve a bit-tech tesztjét, a 7600-as sem tűnik annyira elveszettnek.
[ Szerkesztve ]
-
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 ]
-
dezz
nagyúr
Éppen a DX - mint high level API - próbálja elfedni a programok elől a valós HW-t. A Mantle egy low(er) level API, ami többet mutat meg a HW-ből és közvetlenebb hozzáférést biztosít, eztáltal teszi lehetővé a jobb HW-kihasználást.
Nagyon nem lenne optimális, ha bizonyos dolgok az IGP-n kerülnének megvalósításra, amikhez jobban passzolna a dGPU, és fordítva (az egyiknek nagy memóriasávszél áll a rendelkezésére, viszont távol van a CPU-tól, a másiknál meg éppen ellenkezőleg) - és erre nem lenne befolyása a programozónak. A Mantle-vel nem kevesebb, hanem több befolyása van a programozónak arra, mi hogyan történjen!
(#266) Fiery: Ez most kb. olyan, mintha azt magyaráznád, hogy egy dolog, hogy gyorsabb a repülő az autónál, de lezuhanhat, ezért mennyivel jobb is az autó valójában.
-
leviske
veterán
+ Fiery: Köszönöm, akkor ezt elég csúnyán benéztem korábban. Volesz most én bocs a lekezelésért.
De amúgy az Adobe-tól csak többet várna az ember. Pláne, hogy Intelen is lassabb az a mód, pedig gondolom akkor dolgozik egyszerre a CPU és GPU.
(#269) dergander: Szerintem igen, mert a 14.1-re írták, hogy jön a DG.
[ Szerkesztve ]
-
dergander
addikt
Ahoz hogy müködjön a VGAmmal az IGP crossfireben mindenféleképp szükséges a 10.1 driver?
-
dezz
nagyúr
Nem tudom, mi a helyzet most, itt még igen szépen gyorsult pár Photoshop filter (néhány egyéb programmal együtt):
Can OpenGL And OpenCL Overhaul Your Photo Editing Experience?
Kíváncsi lennék ugyanezekre a programokra (és amik azóta születtek) Kaverin...
-
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 ]
-
dezz
nagyúr
Ezzel nem mondtál újat, mint ahogy most én sem: manapság a kóderek igen kis része dolgozik asm-ben. És nem, nem csak a pengeség hiánya miatt, vannak más szempontok is.
Én is mindig is jobban szerettem az asm-et, de van egy nagy hibája: egy adott ISA-hoz (ezzel együtt pedig legtöbbször egy adott hw platformhoz) köt. Ez egy nem elhanyagolható szempont a programozási szintek és nyelvek közötti választásban. Azt is hozzátenném, hogy nagyobb odafigyelést igényel, fárasztóbb, nem lehet vele/benne ugyanolyan gyorsan dolgozni.
Feltételezem, a kód nagy része nálatok is C(++) és csak a teszt-rutinok készülnek asm-ben, azaz az összes kód apró töredéke. Egy összetett műveletek, algoritmusok tömkelegét alkalmazó program esetén más lenne az arány.
Megjegyzem, tudomásom szerint HSA alapon lehet közvetlenül HSAIL-ben is kódolni, ami egy virtuális ISA. Azaz, lényegében úgy lehet asm-ben dolgozni, hogy közben nem leszünk egy adott hw-hez kötve. Ez azért nem semmi.
-
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 ]
-
#25954560
törölt tag
csak kozbeszurom: most portolok valamit x86_64-rol arm v7-re. egyszeruen baromsag volt kitalalnom h megcsinalom nem eleg h 64bitrol vissza kell hergelni mindent 32-re, de tele vagyunk inline intel asm-mel. azt hiszem, megvarom az a53/a57-et. akkor legalabb a problemak egy kicsi hanyada megoldodik. szoval szep es jo az assembly es szigoruan teljesitmeny-orientalt dolgokkal foglalkozunk, tehat gyakorlatilag megkerulhetetlen is, de most csak 'pain in the ass' ahogy azt a muvelt orosz mondana.
szinten nagyon off: rengeteg leiras meg eloadas van a neten, de ti mar valoszinuleg tapasztalatbol beszeltek: gpu programozast melyik forrasbol lehet konnyen tanulni? tehat az eleje szajbaragos, a vege meg hasznos.
-
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 ]
-
#25954560
törölt tag
-
dezz
nagyúr
-
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 ]
-
dezz
nagyúr
"kiveve persze ha az R&D koltsegeket is belevesszuk a kepletbe."
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.
Elvileg nem sokára sima C++ kódot is lehet majd fordítani GPU-kra. A LINPACK esetén tudtommal nem egy fix forrást kell fordítani, hanem saját kódot is lehet írni, akár OpenCL-ben, akár más.
"olyan alkalmazasbol eleg keves van, ami aggregaltan hajtja ki az FPU-t es az iGPU-t is, egyszerre. En pl. egy ilyet sem ismerek"
És ez nem igazán kedvez a Haswell kiegyenlített FPU-iGPU teljesítményének... Nos, igen, a programok vagy a CPU-ra támaszkodnak, vagy a GPU-ra. Ezért így merül fel a kérdés: 433 GFLOPS vs. 735 GFLOPS, illetve dGPU esetén akár több TFLOPS.
-
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
-
leviske
veterán
Az nVidia-t nem hiszem, hogy érdemes belekeverni a dologba, mert a másik topikban most kapott válaszból azt tudom leszűrni, hogy nekik szimplán 0% esélyük van AVX-512-t használni valaha is, így esetleg belekergetni az AMD-t annak a használatába, nem volna feltétlenül okos döntés. 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.
-
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 ]
-
korcsi
veterán
"Haswell Core i7-4770: x86 FPU = 433 GFLOPS"
Itt nagyon más számok vannak (meg máshol is), ennek mi az oka?
Az elméleti maximális CPU számítási teljesítmény azt nem úgy kell számolni, magonként egy 256 bites végrehajtó van (8 flops) szorozva az órajellel, Az nálam 8*4*3,5G=112Gflops. i5-3550-em 3,7GHz-en 100 felett teljesített linx alatt, bár lehet az rosszul tesztel.
[ Szerkesztve ]
referencia 5700(XT) plexi ARGB-s blokk eladó!
-
-
dezz
nagyúr
Elég sok procit kell eladni ahhoz, hogy visszahozzák a ~2 évente elköltött dollármilliárdokat. A másik oldalon a GloFo és a TSMC maga finanszírozza a gyártástechnológiai fejlesztéseket és gyár(át)építéseket. Persze megkéri a gyártás árát, de nem egyedül az AMD-n kell visszahozniuk ezeket a költségeket.
-
lenox
veterán
Elvileg nem sokára sima C++ kódot is lehet majd fordítani GPU-kra.
Van rola valami bovebb info? Abu is irt ilyet a multkor, de nem sikerult semmilyen forrast talalni hozza, csak homalyos projekteket, amik valami reszet tudtak, illetve egy amd slide-on volt az, hogy 'Ability to support C/C++ (like)' ami igy a like-kal egyutt azert nem biztato. Egy teljes c++ support amugy killer lenne.
-
lenox
veterán
Ez miert kell igy legyen? Azt hittem azt benchmarkolja, hogy milyen gyorsan tudja olvasni a gpu a memoriat, tehat pl. egy reduction eseten, iraskor meg mondjuk milyen gyorsan irja tele 0-val. Miert erdekes az, hogy milyen gyorsan tolja at a pcie buszon, amikor pl. valamilyen statisztikat csinalna az ember a videomemben levo adatokon (amikor is vegig kell oket olvasni).
#297 Koszi, azert mar egy ideje ismerkedem vele.
[ 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