Keresés

Hirdetés

Új hozzászólás Aktív témák

  • #06658560

    törölt tag

    válasz ukornel #2 üzenetére

    "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 ]

  • Jack@l

    veterán

    válasz ukornel #2 üzenetére

    Nem károg, csak reálisan látja a helyzetet... (nem tapsikol ész és tények nélkül)
    Kicsit talán lehetne adni a szavára, mert éppen ő az az ember aki foglalkozott már gpgpu programozással. (ellentétben a fórumozók 99%-ával)

    [ Szerkesztve ]

    A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.

  • #06658560

    törölt tag

    válasz ukornel #5 üzenetére

    "Lehet, hogy te másik cikket olvastál, én ebben a cikkben semmi ilyesmit nem láttam."

    Gondolom a másik hatvanötöt az elmúlt n évből akkor nem olvastad.

    "De ha eleged van belőlük, minek olvasod?"

    Mert érdekelne a téma a bullshitek nélkül, amit abu rendre mellé tesz.

  • Fiery

    veterán

    válasz ukornel #2 üzenetére

    "Örülök a hírnek, ugyanakkor semmi olyan sincs benne, miszerint jövőre a "HSA éve lenne"."

    Konkretan emlitve van benne a 2016-os ev; valamint hogy a Qualcomm kozel all az implementalashoz. Namost, ha kicsit lejjebb gorgetsz, es elolvasod a linkelt cikkeket ("Elozmenyek"), akkor azokbol eleg szepen kirajzolodik, hogy elvileg pont a 2016-nak kene lennie a HSA evenek. Mint ahogy a Kaveri megjelenese elott a 2014-es ev volt az, valamint a Carrizo megjelenese elott a 2015-os ev volt az. Mindig epp a kovetkezo ev a nagy attores eve. Lasd me'g David Coulthard, aki mindig a kovetkezo ev F1 vilagbajnokanak volt kikialtva :)

    "A HSA végül vagy beérik, vagy nem. Ha beérik, akkor sem lesz egy gyors, robbanásszerű folyamat - ez törvényszerű."

    Mikor is indult az egesz HSA? Akkor me'g nem annak hivtak, persze, hanem Fusionnek. Segitek, hogy ne kelljen keresgelni a PH archivumban --> Megveszi az ATI-t az AMD. Írta: Erasmus | 2006-07-24 13:10. Tehat mar 9 rohadt eve nem sikerul a gyakorlatba is atultetni az eleve hibas elkepzelest. Az elobbi mondat utolso 4 szava csupan az en velemenyemet tukrozi, nem orokervenyu igazsag. Olvass vissza, hogy miket irtam a HSA-rol ill. a GPGPU temarol elozoleg. Eddig a tortenelem nem ugy tunik, hogy ramcafolna. De oke, varjuk meg, amig a HSA-bol lesz valami, hiszen ahogy irod is, "akkor sem lesz egy gyors, robbanásszerű folyamat - ez törvényszerű". Sz'al mar 9 eve varunk erre. Adjunk neki me'g 9 evet? En benne vagyok, csak ha ilyen hosszutavu, retesteszta-szeru folyamat ez, akkor mennyi ertelme van havonta nehany hirt pazarolni a nagy semmire? Ennyi erovel havonta ugyanannyi hirt kerek a Mars utazasrol, a Szaturnusz holdjainak betelepiteserol, a levegovel hajtott autokrol, az atomfegyverek globalis leszereleserol is.

    [ Szerkesztve ]

  • Fiery

    veterán

    válasz ukornel #39 üzenetére

    "Válasz: mert általában érdemes elolvasni, megbízható információkat ad, olyanokat is, amik nem kapnak nagy nyilvánosságot. Na, ezért örömmel látom, ha hozzászól, és nagyot csalódok, amikor szakértő mezbe bújtatott, harsány és bántón megfogalmazott véleményt találok csak."

    De ha ilyen lelkesen olvasod a hozzaszolasaimat -- aminek oszinten orulok, smiley nelkul --, akkor gondolom az is feltunt mar, hogy a sokszor tomor, velos, szurkalodo kommentjeim leginkabb csak arra iranyulnak, hogy aztan egy erdekes es izgalmas diskurzus bontakozzon ki? Mert a nyito komment utan nem tuntem el, hanem sot, reszletesen kifejtettem azt, amit a nyito postbol hianyoltal. Remelem, igy mar oke a dolog, es megbocsatod a nyito postot :R

  • Fiery

    veterán

    válasz ukornel #52 üzenetére

    Az egesz hir azt sugallja, hogy a 2016 lesz az attores eve. Le van irva, hogy 2016-ban mi mindenre lesz lehetoseg, hogy mennyire kozel all a Qualcomm, hogy a MediaTek is jol halad, lent pedig linkelve van a Snapdragon 820 hir, aminek a cimet is eleg elolvasni. Rakd ossze a puzzle darabokat, ha mar Abu nem hajlando leirni, hogy 2016 lesz a HSA eve ;]

    En me'g mindig nem latok HSA-rol szolo bejelenteseket, sorry. Belinkelted, de ide is beszurom, ezt a 3 gugli kereso kifejezest es az altaluk adott talalatokat:

    hsa site:amd.com = 4330 results
    hsa site:qualcomm.com = 4 results
    hsa site:mediatek.com = 98 results

    Ez iden majus volt. Azota nem tobb, hanem _kevesebb_ talalat van a cegek site-jan, tessek csak beirni a gugliba! De az nem valtozott, hogy tovabbra is csupan az AMD beszel erdemben a HSA-rol, senki mas. Marmint a weben, de azt hittem, az is relevans, ami a weben van, nem csak az, ami elhangzik egy konferencian.

    En azt tekintenem sikernek, ha mondjuk ... nem is tudom ... lenne egyetlen nem AMD altal keszitett szoftver, ami valami ertelmeset is csinal a HSA-val :DDD Nem benchmark, nem demo, nem techdemo. Na jo, viccelek. Valojaban a siker az lenne, ha megjelenne me'g 2-3 HSA-compliant SoC, es elkezdenenek szepen csorogni a szoftverek is, amik pozitiv visszhangot valtananak ki. Olyan szoftverek, amik jok is valamire, amiknel azt mondja az ember, hogy emiatt mar erdemes mondjuk egy AMD APU-t vagy egy akarmilyen mas SoC-cal szerelt telefont/tabletet valasztani.

    "Összességében nem tartom aggasztónak, hogy 9 év alatt nem lett egy ötletszerű elképzelésből iparági sztenderd."

    Remelem, tisztaban vagy vele, hogy 9 eve me'g iPhone sem volt. 9 ev borzalmasan hosszu ido az IT iparban. A konkurens megoldasoknak, iparagi sztenderdeknek furcsamod nem kell ilyen hosszu ido, hogy kezzelfoghato eredmenyt hozzanak.

    "A gyorsítók megkönnyített munkába fogása a hibás elképzelés?"

    Az a hibas elkepzeles, hogy konnyen es egyszeruen lehessen programozni, debuggolni, validalni egy heterogen rendszert. Nem mondom, hogy specialis feladatokra nem mukodik a dolog, megfelelo programozoi rutinnal, felkeszultseggel. Vegul is, a Teslakat is van ahol imadjak, elad joparat az nVIDIA, es nem disznek. De az az elkepzeles, hogy majd egyszer teljesen transzparensen fog mukodni minden, mint ahogy most akarmilyen windowsos PC-n tudsz futtatni egy akarmilyen programot, nos, ez szerintem nem fog mukodni. Mint ahogy most sem mukodik, eddig se mukodott. Vannak megoldasok, vannak probalkozasok, de mindegyiknel ott van az X CPU vagy Y GPU mint alapfeltetel kapasbol, speci driver kell hozza, stb.

    "Akkor mi a jó francot csináljon egy kis cég? Semmit??"

    Mantle-t, peldaul. Arrol anno azt mondtam, hogy nagyon jo dolog, orulok neki. Aztan az AMD elajandekozta es beszuntette a projektet (legalabbis azt, amirol anno azt mondtak, hogy vilagmegvalto).

  • Fiery

    veterán

    válasz ukornel #85 üzenetére

    "iPhone... az egy kiválóan összerakott okostelefon (volt olyan már korábban, hogy ne lett volna), a hozzá igazított zárt op.rendszer, és szoftveres ökoszisztéma kellően minőségi összegyúrása. A siker alkotóelemei majdnem mind léteztek már korábban. Sokkal inkább finomításon, tökéletesítésen volt a hangsúly, ötletes tálaláson, ergonómián. A HSA kidolgozása ezzel szemben nem csiszolgatást jelentett, hanem az alapok kidolgozását, ami a legtöbb részletében teljes újdonság."

    Ebben nem ertunk egyet. A HSA alapjat kepezi a Stream, a CUDA, az OpenCL, a D3DCS. Boven lehetett otleteket nyulni a kulonfele JIT megoldasokbol, pl. Java. Semmivel sem nagyobb melo egy HSA-t osszerakni, mint egy iPhone-t. Egyebkent az iPhone-t csupan azert emlitettem, mert az mar rohadt regen volt, talan olyan regen, hogy sokan fel sem tudjak idezni, miert volt akkora szam es hogyan nezett ki a legelso iPhone. Es a Fusion/HSA fejlesztese me'g annal is regebben kezdodott.

    "É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.
    Remélem, nem így lesz."

    Mutass nekem 3 olyan konkret programozot, aki lelkesedik a HSA-ert, _es_ aki mar OpenCL-ben vagy CUDA-ban is nyomult elozoleg, tehat kepben van GPGPU vonalon. Aki alig varja, hogy mas procin is fusson, mint az AMD APU-jai. Olyat is mutass, aki mar eloallt HSA koddal, barmilyen celbol. Nyilvan lehetne ilyen embereket talalni, de miutan megvannak ok, nezzuk meg, hanyan tolonganak az Android fejlesztoi szekcioban a StackOverflow-n. Vagy a CUDA forumokban. Vagy barhol, lenyegeben. Minden hulyesegre lehet fanokat talalni, a legnehezebb programozoi feladatokat is megoldjak paran, de az igazi merce valojaban az, hogy mi a mainstream.

    "Csókolom, a HSA kb olyan ambíciózus, a lapok az iparágban újraosztani hivatott kezdeményezés, mint a Mantle a grafikában, külső laikus szemmel legalábbis. Egyik jó, a másik nem?"

    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. De ha mindenaron akarod, felolem hasonlithatjuk oket egymashoz, abszolut nem professzionalis modon. A Mantle ugyanaz pepitaban, mint ami anno a Glide volt, valojaban semmi extra, csak egy jo pillanatban egy felutott magas labda lecsapasa. De mivel en nagy rajongoja vagyok a custom API-knak -- mert valojaban csak azokkal lehet egy adott architekturabol kihozni a maximumot, es biztositani a konzisztens teljesitmenyt --, a Mantle kapasbol megtetszett. A HSA ezzel szemben egy alapjaiban rossz elkepzeles (GPGPU) plusz absztrakcios retegekkel valo megfejelese, annak remenyeben, hogy az alapveto hulyeseget hasznalhato szintre tudja hozni. A low-level custom 3D API alapjaiban jo otlet, mig a HSA alapjaiban hibas elkepzeles. Ez az en velemenyem a temarol :) A jatek fejlesztok meg biztos maskepp gondoljak, legalabbis a Mantle kapcsan.

    [ Szerkesztve ]

  • #06658560

    törölt tag

    válasz ukornel #85 üzenetére

    "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

    válasz ukornel #95 üzenetére

    "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

    válasz ukornel #97 üzenetére

    ""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.

  • Jack@l

    veterán

    válasz ukornel #99 üzenetére

    De akkor mi értelme az apunak, ha úgyis raksz mellé erős kártyát adatpárhuzamos appokhoz? Még mindig a felhasználói programok pár százalékáról beszélünk amúgy, a többi progi mind cpu-n fut csak. Ott meg megint elvérzik a gyengécske apu. (már amelyikbe "erős" gpu részt pakolnak)

    [ Szerkesztve ]

    A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.

  • #06658560

    törölt tag

    válasz ukornel #99 üzenetére

    "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.

  • Jack@l

    veterán

    válasz ukornel #105 üzenetére

    Mi baj az adatmásoplással? Szükséges rossz, de ha a számítás pár százalékát veszi csak el időben?
    Apu-n meg ott van a ddr3-4, ami baromi lassú egy dgpuhoz képest, az sztem sokkal nagyobb overhead mint a feladatok átküldése a kártyára, meg a végeredmény visszamásolása.
    Főleg hogy többször annyi mag van egy dgpu-n is, mint az apu-n. (több kártyás rendszereket már meg se említem, most is egy alap gépbe be lehet pakolni legalább 4 kártyát, a profibbakba meg többször ennyit)
    Az apu-k sikerességéhez két dolog kéne: hbm2 integrálva alaplapra, baromi sok, legalább 12-16 GB, és sokkal nagyobb igp rész, hogy már egy középkategóriás kártyát megüssön. Akkor, de csak akkor érné meg használni játékra meg compute-ra is. (amíg ez nem teljesül, addig gyerekjáték az egész, egy műanyag gagyi kínai fajta PC-ben)

    [ Szerkesztve ]

    A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.

  • #06658560

    törölt tag

    válasz ukornel #105 üzenetére

    "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

    válasz ukornel #110 üzenetére

    "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