- AMD K6-III, és minden ami RETRO - Oldschool tuning
- OLED TV topic
- HiFi műszaki szemmel - sztereó hangrendszerek
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- GoPro Topic
- Hobby elektronika
- A Gigabyte is visszaveszi alaplapjainak alapértelmezett tuningját
- Házimozi belépő szinten
- Milyen SSD-t vegyek?
- Autós kamerák
Hirdetés
-
Igencsak szerény méretekkel rendelkezik az Aetina Xe HPG architektúrás VGA-ja
ph Az 50 wattos modellt beágyazott rendszerekbe, MI-vel kapcsolatos munkafolyamatokhoz és edge applikációkhoz szánták.
-
Robotkart irányított a majom a kínai Neuralink agyi chipjével
it A mindezt lehetővé tévő Neucybert a Neuralink kínai riválisa, a Beijing Xinzhida Neurotechnology fejlesztette ki.
-
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 :)
Új hozzászólás Aktív témák
-
#06658560
törölt tag
"Ez azt jelenti, hogy addig kötélidegeket kell növeszteni annak, aki el akarja viselni a folytonos károgásodat a HSA-val kapcsolatban?
"Csak annyira, amennyire azoknak, akiknek abu a HSA mindent lesöpör jellegű cikkeiből van elegük.
Nagyon zavaró a cikkben az állandó beszélés. Szinonimát nem ismersz rá abu?
[ Szerkesztve ]
-
#06658560
törölt tag
-
#06658560
törölt tag
Igen, a hatalmas jövőbeli terjedést kész tényként leírva, eléggé random mennyiségből. Állandó hibád, hogy kitalálsz valamit, ami szimpátiád alapján tetszetős jövőkép, majd az összes, ezzel foglalkozó cikkbe beleírod, még ha nem is kellene. Kész tényként tálalva, aztán évek múlva sem következik be a leírt esemény.
-
#06658560
törölt tag
"Igen, a Qualcomm és a Samsung nem azon a szinten áll, hogy egy kockázatos, még a programozók közül is csak egy szűkebb rétegnek érthető jövőképet kelljen propagálniuk. Az idézett pletykák szerint mégis jövőre HSA1.0-képes lapkára számítani tőlük - ha ez igaznak bizonyul, teljesülhet a..."
Probléma, hogy mobil SoC esetén a fogyasztás eléggé sarkalatos pont, így minden, ki nem használt tranzisztor helyet, energiát pazarol, ezáltal kevésbé versenyképes. Mobil szintre akkor van racionális indok levinni, amikor már desktop és kompletten x86 szinten befutott.
"Én nem értek hozzá, nem tudom megítélni, de azért egy jópár fejlesztő -úgy tűnik- mégiscsak hisz benne. Nem tudom kinek van/lesz igaza. Talán mindkettő véleménynek, mert meg lehetne csinálni a dolgot, de ha nem, vagy csak fél szívvel támogatják a nagyok, akkor kevés bugos szoftver lesz csak, és elhal végül."
A HSA elméletben egy teljesen jó irány, minden számítást azzal az egységgel elvégeztetni, amelyiknek ideális feladat. Probléma a komplexitással van. Fejlessz egy "fix" hardverre, menni fog. Fejlesz komplett x86 rendszerre, meg fogsz halni a milliónyi variációtól. És attól, hogy bár debugolsz, bármikor beeshet egy vevő, hogy kéri vissza a pénzét, a terméket dobd ki az ablakon, annyira szar- mert pont az általa használt környezetben dob egy hülye, végzetes hibát. Teszem azt, APU+dGPU, s a memóriamásolások során a kódba a különböző sávszélek miatt s más adatot emel be, mint ami kell neki.
-
#06658560
törölt tag
"No offense, de baromi nagy laikusnak kell lenni ahhoz, hogy valaki a HSA es a Mantle koze egyenloseg jelet, vagy ugy altalaban barmilyen relacios jelet rakjon. Kb. annyi kozuk van egymashoz, mint a tengerjaro hajonak a futobiciklihez."
Annyiban össze lehet vetni őket, hogy ugyan azon a ponton hasalnak el- az x86 piac fragmentáltságán. Illetve pontosítok, a Mantle mivel csak AMD-re volt, így ott legalább kézben lehet tartani mi történjen. Ahogy NV oldalon CUDA esetén. De amint a Mantle átvedlik Vulkanná, DX12-vé, jelentkezik a probléma a debugolhatóság, optimalizálás, költségvetés, menetrend bermuda sokszögében.
Mindegyik irány isteni, amíg kis számú hardvervariációra kell megírni. Amint a teljes x86 világra, már jön a fejvakarás, hogy tényleg akarja-e az ember.
-
#90
#06658560
törölt tag
hugo chávez
#87
#06658560
törölt tag
válasz
hugo chávez
#87
üzenetére
A heterogén programozás problémája inkább a heterogén kódot igénylő feladatok létén múlik. Mi az a feladat, ami jobban fut hibrid környezetben, mint vagy csak CPU-n, vagy csak GPU-n futva? És itt a tényleges feladatot értem, nem a kifejezetten ilyenre kitenyésztett, de egyébként semmit nem csináló kódokat. Tehát pl. tömörítésnek jobb a vagy ez, vagy az állapotnál? CAd-nek, FEA-nak, kép-, videoszerkesztésnek? Valamilyen szimulációnak, titkosításnak? Ezen jobban múlik a siker.
-
#06658560
törölt tag
Gondolom az a baj, hogy nem programozó vagyok, így nekem nem az a szempont, nem az a munka, hogy valami kódnak kell futnia. Hanem van valami elvégzendő feladat- statisztikai, mérnöki, digitális, grafikusi, stb. Magyarul édes mindegy, milyen memóriában van tárolva, milyen alegység számolja. A probléma annyi, hogy amit el kell végezni, az mennyire párhuzamosítható, vagy egyes részei mennyire párhuzamosíthatóak. Ha jól, akkor az jó GPU-nak, ha nem, akkor CPU-n marad.
De rendben, gondolkodjunk paradigmákban. Az új paradigma a memória címzést tekinti mindenek felett állónak. És elfelejti azt, hogy hiába fér sok adat bele, azt valaminek fel kell dolgoznia.És itt bukik több ponton is a koncepció.
Vegyünk egy példát, ami jól leírja a helyzetet: FEA. Sok kis elemen végrehajtott, gyakorlatilag ugyanolyan számítás, nagy memóriaigénnyel, egyes, kevésbé párhuzamosítható elemekkel.
Problémái: A memóriaigény szembe megy az APU-k esetében a rendelkezésre álló számolóegységek és a fogyasztási keret korlátozza a teljesítményt. Amennyiben feljebb lépünk, dGPU-t veszünk figyelembe, akkor változik a helyzet, kevésbé köt a fogyasztási keret, viszont nincs egységes memória, s a memóriamásolások fogják vissza a teljesítményt. Ellenben egy APU számítási kapacitásának sokszorosa áll rendelkezésre. Még feljebb lépve pedig bejön a cluster és egyéb csemege, ahol elvileg már van egységes memória is, számítási kapacitás is. A HSA-nak is akkor van értelme, ha mindegyik lehetőséget le tudja fedni. A helyzetet rontja a különböző architektúrák memóriakezelése, kódolási igényei. Minél heterogénebb a rendszer, annál nagyobb lesz a szívás kód oldalon. Márpedig a HSA pont azt adná, hogy bármilyen, azt támogató hardveren jól menjen. Ilyen peremfeltételekkel pedig nagyon nem lehet kódot írni univerzálisan.Másik elméleti probléma: a feladat egyik része jól párhuzamosítható, másik része nem, a kettő párhuzamosan fut valameddig, s az eredményeiket utána felhasználja még. Ilyenkor a jól párhuzamosíthatót sem biztos, hogy megéri túlságosan párhuzamosra tervezni, mert nem fog gyorsabb lenni az összesített feladatvégzés, mint a leglassabb részén keresztül futó számítás. Olyankor annak igényéig érdemes menni a maradék gyorsításában is.
Mint programozó, ha nem írod elő, milyen hardveren fut kizárólagosan a programod, s véges kapacitásod van megírni, akkor szerintem teljesen logikus, hogy bele se vágsz, hanem maradsz a jól bejáratott úton, ami mindenen kiszámíthatóan fut. Pláne, ha kompatibilitási igények is vannak a vevőid részéről.
-
#06658560
törölt tag
"Nem látom az összefüggést, tekintve, hogy a desktop & x86 világnak kicsi a metszete a mobilokéval.
Másrészt az ARM említése nem jelent föltétlenül mobil irányt, hiszen az ARM már régóta feni a fogát a szerverpiacra"Nem az ARM említése jelenti a mobil irányt, hanem az android, Samsung említése, akik esetében erről szó van, illetve a Mediatek sem nagyon a szerverek irányába törekszik egyelőre. Magyarul mobil szegmens.
"Itt nem világos, mit akartál kifejezni.
Ugyanakkor az APU-k alatt nem biztos, hogy csak 35-65 W, max 95 W-os egységeket kell érteni, főleg, ha szerverfoglalatra gondolunk."Pedig pont kifejtettem: milyen igényre, körülmények közé, környezetre kell kódot fejleszteni, aminek ideálisan kellene kihasználni egyik, másik, harmadik rendszert is.
APU alatt sosem fogsz tudni csúcs CPU+GPU erőt egybe csomagolni és ki is használni, mert a hőtermelés és a szabványos méretek megkötik a kezed. A CPU+multiGPU/Coprocesszor rendszert (Tesla, Phi, stb.) Így a három lépcsőfok, mint hardverstruktúra, amire a programot jól meg kell írni, megmarad. Ha multi APU rendszer lesz, a Cache kezelése akkor is megmarad gubancnak.
[ Szerkesztve ]
-
#06658560
törölt tag
""A memóriaigénnyel szembe megy az APU-k esetében a rendelkezésre álló számolóegységek száma és a fogyasztási keret, ami korlátozza a teljesítményt."
Biztosan sietve írtad le, ezért hiányos, nem kerek a mondat, nincsenek egyeztetve a mondat részei, és így elakadt a decode egységemben."Kieg a javítás, ami kimarad félkövéren szedve.
"Persze, hogy nem tudsz, de ahol ez megkötést jelentene, ott már úgyis a foglalatok skálázódása lesz a probléma."
Nem, már egy i7, vagy dual Xeon+ Quad Fury/Firepro/stb. rendszer is szétrúgja az APU-kat, bármikori generációt nézünk a jelenben, vagy a jövőben.
-
#06658560
törölt tag
-
#06658560
törölt tag
"Ennyi foglalatban (2CPU + 4cGPU) az APUk is komoly összteljesítményt adhatnak le."
Csakhogy ennyi foglalat APU esetében a 2 CU-t jelenti. Amennyiben mellé teszel még 4 dGPU-t, vagy egyéb koprocesszort, az már nem APU. Márpedig egy foglalatnyi helyre nem fog soha beférni az akár egy top CPU+ akár 4 top dGPU számítási teljesítmény.
"Ez persze csak az elméleti csúcsteljesítményre vonatkozik, mert, ahogy magad írtad korábban, ezeknél a memóriamásolások fogják vissza a teljesítményt. "
Itt jön képbe a feladathoz igényelt hardver. Ha "kevesebb, jól párhuzamosítható, sok memóriamásolással járó a feladat, akkor megéri az APU-ra igazítani. Ha a memóriamásolások mennyisége, jellege olyan, hogy elfér egy GPU memóriájában, ritkán kell memóriamáslást alkalmazni (mert egyszer betölti a GPU memóriájába, majd azzal az adatmennyiséggel elvan egy jó ideig, s más adathoz nem kell nyúlnia), akkor a CPU+dGPU rendszer a nyerő. Amikor pedig sok a memóriamásolás és marha nagy számítási kapacitás is kell, akkor jön a HPC, render farm, stb. megoldások clusterekkel, minden egyéb mókával.
-
#06658560
törölt tag
"Miért raknánk mellé bármit az adatpárhuzamos appokhoz, ha már ott van a gyorsító (IGP) a lapkán??? Hogy újra szívhassunk az adatmásolgatásokkal? "
Esetleg azért, mert kevés a számítási kapacitás?
"Az a baj, hogy a fejekben mintha ez lenne: APU = AMD proci, gyengécske Bulldozer architektúrájú magokkal.
Felejtsd el ezt a képet! Valójában az i7 is az, csak az Intel nem használja ezt a terminológiát. Képzelj el egy i7-et és egy R9 380-nal egy lapkán - nem mondanám gyengécskének. Ez 14 nanón lehetséges."Melyik LGA 2011 foglalatos i7 APU?
Az APU egyik fontos eleme lenne a megosztott memória, ami tudtommal intel esetén még lényegesen visszafogottabb mértékben létezik, mint az AMD oldalán, így APU technológiát értelmezve az AMD a cutting edge."Persze, hogy nem fog. Az esetek többségében nem is kell"
Honnan tudod, hogy nem kell? Játékprogramot akarunk HSA-val írni, Hello World szinten, vagy valami értelmeset is?
" Ezek helyébe képzelek hat APU-t, mindegyiket a saját hűtésével, és ezek is kommunikálnak egymással."
Akkor nem fogalmaztál elég egyértelműen. Másik probléma, amint több APU-t raksz össze, máris kezd jönni a memóriamásolási probléma- minimum a Cachek szintjén, ami már négy egység esetén is jó kalamalkát okozhat a kód oldalán. Az erőforrás-menedzsment szempontjából meg pláne.
-
#06658560
törölt tag
"Vagy ugy ertetted, hogy csak a 2011-es i7-ek rugjak szet az apukat, egy 4770 (+dgpu) nem?"
Isten igazából nekem az i7 az bizony az LGA 2011, a többit valahogy mindig kihagyom onnan. Tehát pont annyira az én hibám, ahogy a tied, másik felét vettük a néven belül a csoportnak.
"Melyik levezetesre gondolsz?"
Arra, amelyikben leírtam, milyen felépítés mellett mi a probléma, s miért nehéz rá fejleszteni.
"Pl. nekem egy cuda-szeru api megfelelne, annyi plusszal, hogy nem lenne kulon device es host memory, csak memory es emiatt nem is kene mindig kuldozgetni a buszon az adatot."
Szerintem ez ott hal meg, hogy több lesz a memóriakérés a másik egységbe, a PCI-e busz terhelése nő, amit csak ront, hogy időzíteni is kell okosan, mi mikor melyik memóriához nyúljon. Eltérő memóriák, sebességek, sávszélességek, s nem tudod adott adat épp melyikben van. Szerintem ez végképp nem adna sebességbeli előnyt semmit, csak hátráltatna. Akkor lenne működőképes, ha a VGA-k saját memóriáját teljesen megszüntetnénk.
-
-
#06658560
törölt tag
"Ahha. Tehát oda lyukadunk ki, hogy a dGPU-s compute-nak mindig lesz létjogosultsága APU-k mellett is abban a szűk szegmensben, ahol nincs nagy memóriaigény, nincs intenzív adatmozgatás a kártya és a CPU/rendszermemória között, és a teljesítményigény a legerősebb APU teljesítménye és annak max. kétszerese között van."
Hülyeséget bes´zelsz itt össze vissza. Nincs nagy memóriaigény: Titan X és rokonlelkek. Adatmozgás: így ha nem nonstop kell adatot mozgatni, hanem kevesebb alkalommal, sokkal kisebb a veszteség annak mozgatásával, mint amennyit nyerni lehet a lényegesen gyorsabb számítással. Az aláhúzott gondolat milyen hülyeségként szökkent a fejedbe? Melyik APU tud egy Titan X, Fury X számítási teljesítmény felét? És ezekből négy számítási teljesítménye felét?
"Ez elég szűk rétegnek tűnik - az a kérdés, hogy pont egy szűk réteg részére fejlesztenek-e majd az elefánt méretű GPU-kat?"
Az, hogy te szűk rétegnek látod, még messze nem az, lényegesen vastagabb, mint egy APU-val bohóckodni jelenleg, bármelyiket is nézve a sok közül.
"Ha megnézed, onnan indult a történet, hogy egy szál APUt hasonlítottál össze egy komplett kétfoglalatos, quadGPUs rendszerrel. Ez így nem túl fair összevetés, viszont egyes genyó feladatokban, ahol a bika rendszered adatmásolgatásokkal tölti az idejét, az egy szál APUt még mindig nem tudja "agyonverni"!"
Nem, onnan indult a történet, hogy pár embernek fixa ideája, hogy az APU-k valamikor majd teljesítményben felveszik a versenyt a CPU+dGPU rendszerekkel, s a memóriakezelés miatt agyon fogják verni. Viszont APU terén a lehetőségek jelenleg ott állnak, hogy maximum kétutas intel megoldás, míg a CPU+dGPU esetén kétutas intel+akár négy, vagy több coprocesszor. Amit soha a büdös életben nem lehet majd utol érni, csak ha mindegyik coprocesszor helyére is APU kerül, aminek a memóriakezelése lesz majd probléma. A fizikai korlátokat nem szabad figyelmen kívül hagyni.
"Hogy jön ide az LGA2011?? Eddig szó sem volt foglalatról, ne kezdjünk már el csúsztatgatni."
Nem csúsztatás, szerinted az LGA2011 foglalatos intel CPU-k mik? APU-k, vagy kulcstartók?
"
Új hozzászólás Aktív témák
ph A Linley Processor Conference rendezvényen mindhárom cég részletezte az erre vonatkozó útitervet.
