- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- Asztrofotózás
- Projektor topic
- Mini-ITX
- Amlogic S905, S912 processzoros készülékek
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
- Vezeték nélküli fülhallgatók
- Új gamer márka érkezik Kínából
Új hozzászólás Aktív témák
-
dezz
nagyúr
Az csak a BOLT. Az egész HSA sokkal több annál. Legfontosabb része egy az OpenCL (és társai) és a HW közötti réteg, ami többek között biztosítja, hogy az adott magas szintű kódot ne a legkülönfélébb HW-ekre kelljen optimalizálni és fordítani, hanem csak a HSA-ra, ami többit "elintézi" a HW-ekkel. Természetesen a HW-ekkel szemben is támaszt követelményeket, hogy ez a közvetítés minél egyszerűbb lehessen, buktatók nélkül.
Szóval, ez egy (nyilván heterogén orientált) virtuális ISA, ami tovább fordul az adott HW-ekre. A legeslegjobb persze az, ha az adott HW-t eleve a HSA-hoz fejlesztik, hogy ne vagy csak minimális mértékben kelljen fordítgatni.
-
mzso
veterán
Valahogy még mindig nem értem mi akar ez lenni.... Egy közönséges fügvénykönyvtár gyűjtemény OpenCL és AMD64 alapokra? Mert akkor ez sok minden csak nem forradalom.
Az igazi az lenne, ha lenne egy egységes heterogén orientált ISA. Ami teljesen egységesítené a GPU és a CPU féle architektrúrát instrukció szinten is.
-
#70
Kotomicuki
senior tag
Jim Tonic
#47
Kotomicuki
senior tag
válasz
Jim Tonic
#47
üzenetére
Hát, ha hozzátesszük, hogy mint minden elemének, amely számításokat végez a PC-ben a legfőbb visszafogója - a szoftveres/op.rendszeres(w) berendezkedésen kívül - az egymással való, megfelelő sebességű ÉS késleltetésű kommunikáció, akkor már más fényben tűnik fel az a mondat is.
Ha a számításhoz szükséges a CPU-(d)GPU közötti alacsony késleltetésű kapcsolat - az egymás által kiszámított adatokra sűrűn támaszkodó ((ehhez) nem optimalizált
) programkódnál - , akkor a (d)GPU-t a PCI-E-n keresztül használó, heterogén programkód kevéssé hatékony. Az APU-ban ezt próbálják meg helyrerakni, a CPU-GPU egyetlen lakán való elhelyezésével: ekkor már a RAM elérés/sávszélesség válik a legfőbb teljesítményromboló tényezővé - a több számítás, több/gyorsabb tárhelyigénnyel is él (itt ehhez is kell optimalizálni a kódot) és a 240-pin-s DDR3 modul (sebessége nagyjából fix, csak a csatornák számának növelésével javulna a teljesítménye, de az már messze nem pénztárcabarát megoldás) jelentős hátrányban van a 256-512 bites, 1500-1750 MHz-s(effektív 6-7GHz) DDR5 vRAM-l szemben (a GPU mellett, a VGA-n, viszonylag szabadon variálható elrendezésben és mennyiségben).Ha nem szempont a CPU-nál gyorsabb végrehajtás, akkor amúgy sincs értelme a hagyományos kódot újraírni, csak azért, hogy heterogén legyen - + a zintel-AMD processzorerőbeni különbségek. De ha számít a teljesítményben való előrelépés, akkor a fenti tényezőket is figyelembe kell venni a kód megírásánál, optimalizálásánál.
[Ha a következő RAM-generáció paraméterei rosszabbak lesznek a mostani DDR5-s vRAM-éinál, akkor az APU-ban rejlő potenciál kihasználatlan/kihasználhatatlan marad/lesz!]
-
kisza25
félisten
ha kijönnek az új konzolok akkor az onnan átportolt PC játékoknak elég kemény gépigénye lehet, ami újra generálhat magasabb eladásokat, de ha mégsem így alakul akkor szép lassan eltűnnek a diszkrét vga-k, de ebben az esetben valahogy ki kell váltani a PC játékot, felhőben való futtatással, vagy ha az IGP lesz már elég erős a játékok futtatásához, de szerintem ez az egész még azért odébb van
-
Abu85
HÁZIGAZDA
Lehetőség rengeteg dologban van, de kérdés, hogy pénz van-e benne. Az AMD és az NV nem akarja ezt lelőni, de el kell gondolkodni azon, hogy esik az eladás, ami egyértelmű üzenetként jelzi a tömeg igényét. Ennél fontosabb pedig nincs, mert a tömegben van a pénz. Ettől függetlenül ott a lehetőség támogatásra. Ez döntés kérdése. Gondolom tartható az eredeti 2014-es útiterv a dGPU-kra.
-
Taragas
aktív tag
Hát akkor lehet temetni a diszkért piacot. Pedig volt benne lehetőség, hogy APU+dVGAval alkossanak... De ezt már nem fogjuk megérni. Ezek után nem csodálkoznék, ha bejelentenék, hogy nem lesz dual graphics támogatás a trinitynél sem már, mert minek.(főleg ilyen átnevezett 6670-el
). Bocsi az offért, de egyre jobban kezdek csalódni az egészben. -
Abu85
HÁZIGAZDA
A roadmapon is szerepelt, de nem 2012-re volt ígérve, és nem az első verzióra. Dolgozni kell még ezen. A HSA útiterv ezt 2014-re tette az elmúlt évben. Mára ez eltűnt. Nyilván felmerült a kérdés, hogy megéri-e. Ha megéri megcsinálják. Ez csak attól függ, hogy a VGA-k eladása mennyivel nő az elkövetkező hónapokban.
-
#58
Abu85
HÁZIGAZDA
huskydog17
#56
Abu85
HÁZIGAZDA
válasz
huskydog17
#56
üzenetére
Gondolom azért, mert külön memóriával rendelkeznek. A HSA legnagyobb előnye az lesz, hogy közös lesz a memória. De egyébként elméletben kiterjeszthető, szóval ez inkább egy döntés miatt alakult, így, mintsem valami hardveres limitáció miatt. Azért nem nehéz észrevenni, hogy a VGA-piac nem egy jövőbiztos terület. A mobil irányt látva meg pláne nem az.
Programtól függ a sebesség. Szóval általánosítani nem lehet. -
#56
huskydog17
addikt
Abu85
#55
huskydog17
addikt
Elnézést az értetlenkedésért, de a dVGA-k esetében miért nincs értelme? Sokkal több kakaó van bennük? Esetleg a PCI-E busz miatt keletkező nagy késleltetés a hátráltató tényező? (Csakhogy tiszta legyen a kép.)
Elméletben a dVGA-knál is lehetne hozni ugyanazt a sebességet, mint az integrált termékek esetében? -
#55
Abu85
HÁZIGAZDA
huskydog17
#54
Abu85
HÁZIGAZDA
válasz
huskydog17
#54
üzenetére
A HSA nincs kiterjesztve dGPU-ra. Nem lenne értelme. Főleg az APU-nak szól ez az egész, illetve a partnereknél a SoC-ról. A dGPU-k hozzáadása később megtörténhet, de kérdés, hogy mennyi értelme van.
Benne van a cikkben, hogy a HSA MMU-val a teljes rendszermemória elérhetővé válik a CPU és az IGP számára. A memory copy minimalizálható. A sebességvesztés függ az adott programtól. -
#54
huskydog17
addikt
Abu85
#52
huskydog17
addikt
Köszi a kiegészítést!
A diszkrét VGA- közül akkor tehát az Evergreen szériától (AMD oldalon) felfelé már gond nélkül mennének a HSA alkalmazások, csak lassan ha jól értem. Milyen hardver szükségeltetik ahhoz, hogy a HSA-ban (pl. BOLT) megírt alkalmazások a full speed-en menjenek? Itt említetted, hogy a Llano esetében hiányzik egy úgynevezett MMU. Ez pontosan mit takar és mekkora sebességvesztéssel jár?
-
DRB
senior tag
(#48) Abu85, (#49) P.H.:
Köszi, igaz mindketten még mindig elég szakmai módon írtátok le, de azért, a részletektől eltekintve, már érthető miről is szól ez a történet. Főleg P.H. fórumtárs hosszú sorai világítottak rá a lényegre, mondhatnám úgy is gyújtottak némi fényt az éjszakában
, de Abu sorai is természetesen, + egy kis google a végére és így már minden jó, minden baba. 
Ennek örömére megnézek gyorsan egy meccset.
-
#52
Abu85
HÁZIGAZDA
huskydog17
#51
Abu85
HÁZIGAZDA
válasz
huskydog17
#51
üzenetére
Nem kötelező OpenCL, jó a C++ AMP is, de ott a BOLT is, illetve más nyelv is támogatható.
Az OpenCL és a C++ AMP annyiban előnyös, hogy ha megírod a programot, akkor a HSA-t nem támogató hardvereken is menni fog csak lassan.
Manapság már nem gond az OpenCL kompatibilis IGP/GPU. Mindenki ilyet tervez. Nagyon sok cégnek már van is. C++ AMP szintén nem probléma. Ha a GPU/IGP DX11-es, akkor csak egy driver kérdése az egész.A serial CPU az egy szálú programkód. A TBB az az Intel Threading Building Blocks, ami több szálra optimalizálásért felel. Intrinsics+TBB szintén. Az OpenCL-C az lényegében az OpenCL C99-re épül, számos megkötéssel. Az OpenCL-C++ az az 1.2-es verzió C++ Wrapper. A C++ AMP egyértelmű.
Túl nagy gondot a HSA nem jelent sebességvesztés szempontjából. Főleg, úgy, hogy mennyire kevés a befektetett munka. Az OpenCL is driveren keresztül működik, illetve van AMDIL is. Az AMD is sok különböző GPU ISA-t támogat. Ezt legegyszerűbb vISA-val megoldani. A HSAIL kiváltja az AMDIL-t. -
#51
huskydog17
addikt
Abu85
#50
huskydog17
addikt
Az már világos, hogy a Java-hoz hasonlítható leginkább. A Java RE azonban minden CPU-n gond nélkül megy. A HSA is ilyen lesz vagy ehhez lesz valami spéci hardverkövetelmény? Az eddigi infók alapján nekem az jön le, hogy a HSA működéséhez az OpenCL API teljes körű támogatása elengedhetetlen. Tehát a HSA-nál a CPU továbbra is mindegy, de mellé kell egy OpenCL-t támogató VGA/IGP?
A táblázatból több minden van, ami nem világos. Például:
A Serial CPU gondolom a hagyományos CPU módot takarja, vagyis itt kizárólag a CPU számol. Mellette a következő két oszlop neve sem mond semmit. Az OpenCL-nél az első változatnál a -C kapcsoló mit jelöl?
Ha jól értelmezem a grafikont, akkor az OpenCL -C a leggyorsabb mód, de a HSA Bolt esetében több lépcső kimarad, gondolom innen a sebességlöket. -
#50
Abu85
HÁZIGAZDA
huskydog17
#42
Abu85
HÁZIGAZDA
válasz
huskydog17
#42
üzenetére
Nem számít, hogy lassul egy picit, ha töredékmunkát kell belefektetned. [link]
Nincs baj azzal, ha valaki imádja az OpenCL-t, és szeret végletekig dolgozni a programkódon, hogy a lehető leggyorsabb legyen. Az viszont baj, hogy kevés programozó tartozik ide. Kell tehát valami megoldás erre. A HSA egy megoldás. Ez a mainstream programozóknak szól főleg. A hardcore programozók maradhatnak a megszokott terepükön, bár kérdés, hogy megéri-e, de a választás szabad. -
P.H.
senior tag
A HSA a leírt két definíciód között van (ahogy az említett nVidia PTX is pl.):
- API sok helyen és sok szinten van, előre megírt/megvalósított eljárások összessége, pl. legalapvetőbben OS szinten is így megvalósítható az, hogy egy-egy alkalmazás memóriát foglaljon, írjon/olvasson lemezre, mutasson valamit a képernyőn úgy, hogy ne kelljen a legalacsonyabb szinten megvalósítani külön-külön minden programozónak ezeket (és/vagy az egymás mellett futó programok ne zavarják egymást). Ilyen szempontból a BIOS egy része is API ugyanúgy, ahogy az OpenGL is az, de más-más szinten és célra.
- az utasításkészleteket közvetlenül megértik a CPU-k, GPU-k, vezérlők (pl. egy-egy SmartCard-szabványnak is eltérő utasításkészlete van, amit megért); ritkábban a nekik megfelelő gépi kóddal, gyakrabban az azt leképező assembly nyelvvel közvetlenül használhatóak (ez például az R600-ra épülő Radeon GPU utasításkészletének leírása). Így bármi megírható rájuk, de az csak azon az architektúrán fut egyáltalán vagy hatékonyan.
A HSA, a PTX és a többi virtuális ISA a kettő között van: a hardware nem érti meg közvetlenül, ezért fordítani kell külön ARM-ra, x64-re, nVidia-ra, bármire, ami támogatja, de assembly nyelven leírható elemi utasításokból épül fel (mint pl. a PTX), magasabb szintű programozási struktúrák nélkül (nincs for ciklus vagy while se). Egy-egy ilyen vitruális utasítás gépi megvalósítása lehet direkten leképezhető egy-egy gépi utasításra (erre törekszenek a HSA-nál a belépő támogatók, a PTX-nél az nV), vagy sokra (ez a teljesítmény rovására megy, de korábbi hardware-ken is futnak az újabb verzióra épülő programok; gyenge példaként mintha egy AVX-re fordított program is futna egy P3-mon, csak lassan - ezért jó hasonlat a Java).
Kb. ilyen a viszony a tradicionális API-k és a virtuális ISA-k között, amit ez a dokumentáció mutat , címe "Using inline PTX assembly in CUDA". A PTX-re lefordított bytekódot az nVidia semelyik GPU-ja nem érti meg közvetlenül (a CUDA-programozási környezetek erre fordítanak), a driver-ben van a végső fordító. Viszont egyrészt egyszer, a program az indításakor fordul le PTX-ből arra a gépben levő GPU által megértett gépi kódra, futás közben nem lassít a fordítás ˇ(lásd Java), másrészt erre a szintre lehet más komolyen optimalizálni (mivel a legtöbb vISA utasításnak közvetlenül egy-egy gépi utasítás felel meg; amelynek most nem, annak a következő generációs hardware-ben már meg fog).
-
Abu85
HÁZIGAZDA
Igen. De a Llano nem tudja a HSA MMU kiterjesztést. Persze ettől még működni fog.
(#41) DRB: Nem API, hanem vISA.
Mondjuk rá, hogy ez a két mód létezik, bár szerintem több is. A HSA a Java-hoz hasonlítható, de inkább a két mód közé raknám, ha most mindenképpen erre akarod helyezni a gondolatmeneted.
A HSAIL és a Java bytecode hasonló vISA csak más szempontok szerint fejlesztették, így a teljesítmény is eltérő lesz.
Az API egy alkalmazásprogramozási interfész. Ilyen mondjuk az OpenCL, ami eléggé low-level, de API. A HSA az OpenCL alatti szinten helyezkedik el.(#43) DRB: A cikkben a Java az Aparapi miatt került elő. Erre az AMD nagyon gyúr, és egyelőre az Aparapi OpenCL-en keresztül valósul meg, de hosszútávon az a terv, hogy a HSA része legyen a JVM-nek. Ez lehetséges, és a fejlődés irányát tekintve az Oracle is értékesnek találhatja.
-
#47
Jim Tonic
nagyúr
MCBASSTION
#45
válasz
MCBASSTION
#45
üzenetére
ha nem a teljesítmény a cél, akkor hagyjad a GPU-t békén. Ez elég vicces mondat az APU-k korában.
-
#44
MCBASSTION
aktív tag
MongolZ
#11
MCBASSTION
aktív tag
azért mert nem tanulják meg rendesen. Az egésznek az a lényege h megértsd a videokártyák felépítésének előnyeit és azt ki tudd használni. Enélkül nem fognak sokat gyorsulni a programok.
itt ha megnézted a grafikont nem arról van szó h az aloritmus lenne rövidebb, hanem h az előkészítést (context létrehozás stb.) leveszi a válladról. Ezt egyszer kell megírni, utána működik mindig.
-
#43
DRB
senior tag
huskydog17
#42
DRB
senior tag
válasz
huskydog17
#42
üzenetére
Azt írta, de a cikkben meg az van, hogy ez a Java-ba épül be(mikor teljesen elkészül a projekt), mint valami új feature, többet fog ezáltal tudni a Java és nem egy újabb réteg lesz, ha meg mégis külön réteg lesz, akkor is API-ként funkcionál, szerintem. Mindegy, előbb-utóbb majd csak körvonalazódik minek is híjuk ezt az "izét".
Egyébként meg nem annyira lényeges ez, csak én be akartam illeszteni egy kategóriába, de szemmel láthatóan nem nagyon sikerült, egyelőre. -
#42
huskydog17
addikt
DRB
#41
huskydog17
addikt
Nekem is hasonló a gondolkodásmódom, bár Abu azt írta, hogy ez a HSA cucc a hardver és API közé ékelődik be. Tehát így lesz egy plusz lépcsőfok, ami nekem csak egy újabb lassítást jelent, hiszen még egy réteget beiktatnak.
Amúgy nekem HSA BOLT függvénytárról rögtön az azonos nevű film jutott az eszembe.
-
DRB
senior tag
(#35) Abu85, (#36) Löncsi:
Egyikőtök azt írja API, a másik meg azt, hogy nem API. Ennek ellenére kezd körvonalazódni bennem a dolog, ez jó jel, nem fogok már annyit kérdezni.Lehet, hogy nem látszik a hozzászólásaimból, de tanultam a programozás alapjait
, persze nem mostanában volt az és tényleg csak nagy általánosságban.
Megpróbálom a lehető legegyszerűbben, hétköznapi, de a témában azért kicsit jártas, ember számára is érthető módon, leírni mi a gondom. Én azt tanultam(legalább is ez sejlik fel a nagy ködből), hogy alapvetően két módon írhatunk meg egy programot, az egyik módja, hogy tudom a különféle CPU-k(vagy akár GPU-k is) milyen utasításokat tudnak végrehajtani, ennek tükrében írom meg a programot, külön kell leprogramozni Intel-re, AMD-re, stb.(természetesen vannak közös utasítások, utasítás készletek, ez megkönnyíti a dolgom), de ez növeli a programom méret, összetettségét, minél több eltérő képességű CPU-n szeretném futtatni, annál jobban, ráadásul a hibalehetőség is egyre nagyobb ezáltal. A másik módja, hogy van egy "keretprogram", amire írom, és az a "keretprogram"(mitom' én, mondjuk java) majd lefordítja nekem az épp gépben lévő hardver(CPU) felé. Ez a "keretprogram" az API, szerintem. Na most ennek tükrében ez is egy API(de mégis bizonytalan vagyok benne a hiányos tudásom következtében, ezért kérdeztem/kérdezem), egy olyan API amelyik nem csak az épp a gépben lévő CPU utasításkészleteire fordítja le a kódomat, hanem akár azt is megteheti, hogy ne a CPU-n fusson, hanem a GPU-n, ha ott, " ő szerinte", esetleg gyorsabb, illetve el is osztja több szálra, az egyik akár mehet a GPU-n is.Valami ilyesmit(értsd az utolsó mondat), sikerült kihámozni a cikkből, meg az eddigi válaszaitokból, de nekem túl szakmai, így nem világos minden. Ha meg sok hülyeséget írtam, akkor bocsi még egyszer, csak próbálok megérteni valamit, de minden kezdet nehéz.
-
#38
Jim Tonic
nagyúr
Kotomicuki
#26
válasz
Kotomicuki
#26
üzenetére
Egy fix vagy lebegőpontos számítás átadása a GPU-nak teljesen logikus programozói szempontból. A CPU-hoz mérten brutális számítási képességek miatt akkor is nagymértékű lehet a gyorsulás, ha nem optimalizálod tökéletesre a kódot.
Mondom egyszerűbben: eddig szinte csak a játékprogramot írók használták ki az előnyöket, mivel egy egyéb programot készítő programozó vagy azt gondolta, hogy nem öl bele időt, vagy azt, hogy nincs jelentősége, melyik mag végzi el a számítást. Most ez megszűnik, és természetes lesz minden olyan esetben a GPU-t használni, mikor az a logikusabb.
-
Abu85
HÁZIGAZDA
Az API-t azt tényleg hagyjuk most mert ez nem az. Ez az API és a hardver között lehet. De elsősorban a GPU compute a cél. A DX-szel nem akar mit kezdeni, egyelőre.
A működés le van írva a cikkben. Megírsz egy programot OpenCL-ben mondjuk, de úgy, hogy csak az algoritmussal és a futtatással törődsz. A HSA Runtime lesz az a köztes réteg, mely helyetted elvégzi a párhuzamosítást. Ezután jönnek a gyártóspecifikus dolgok, amik a HSAIL kódot a fizikai hardverre fordítják.(#34) DRB: A konzoloknak van low-level API-juk, de mivel a hardver adott, így érdemes kézzel optimalizálni a kritikus részeket. Ezzel még így is sokat lehet nyerni. Persze nem kötelező, de az exkluzív címek azért néznek baromira jól ki, mert a fejlesztők megteszik.
(#33) juzer78: Leegyszerűsítve ez lenne a lényeg, de nem API a HSA, hanem vISA. Illetve a finalizer felel a HSAIL hardverre való fordításáért. Külön optimalizáció pedig itt is kelleni fog. A HSA ad egy nagyon jó alapot, de a legjobb teljesítményhez szükséges a specifikus optimalizálás. A funkcionalitás persze nem szenved csorbát optimalizálás nélkül.
-
DRB
senior tag
Azt hiszem értem, köszi.
Mondjuk most meg ez a konzolos dolog nem egészen világos.
Eddig folyamatosan azt hallottam a hozzáértőktől(elsősorban itt a PH!-n!), hogy konzolon nincs API, ott a játék úgy van megírva, hogy egy adott hardveren menjen(gyakorlatilag közvetlen fér a hardverhez, értsd úgy, hogy bele van írva az "API" a játékba vagy valami hasonló) és ez az a nagy előny a PC-vel szemben, ami miatt itt tartunk "PC-ügyileg". De szerintem hagyjuk, majd máskor kiokítotok, "kissé" fáradt vagyok ma, hosszú és durva volt az éjszaka. -
juzer78
tag
Ha jól értelmezem a dolgokat, akkor ez végülis egyfajta virtuális API-nak tekinthető, ami JIT fordító segítségével fut különféle megoldásokon legyen ARM vagy x86 vagy GPU és használja annak képességeit, annak megfelelően, hogy a hardvergyártó milyen meghajtót készített azokhoz. És ha egy termék (pl telefon vagy tablegép) HSA képes, akkor a HSA képes alkalmazás függetlenül attól, hogy az ARM vagy x86 alapú a termék, egyformán képes lesz futni, ráadásul úgy, hogy nem kell külön optimalizációt végrehajtani. Ha jól értem. Kicsit leegyszerűsítve.
-
Löncsi
őstag
HSA is egy API lesz, gyors és könnyű fejlesztést előtérbe rakva, teljesítmény viszont biztos csorbát szenved.
Konzolon is van API, csak low-level, hatékonyabb kódot lehet írni, csak több idő és pénzbe kerül, illetve az Xbox-os kód csak Xbox-on tud futni és slussz, hardvert nem cserélheted ki alatta. Itt esetleg az Unreal motor ami kivétel, ott gyorsan lehet portolni a megírt cuccot más platformra.
-
DRB
senior tag
"Program sose fér közvetlenül a hardverhez, API mindig kell"
Pont ez a probléma, nem? Ezen gondon akkor ez sem segít, tehát ha jól értem, ez mégis úgy működik mint egy API(bár Abu azt írta hogy nem, viszont a Java-hoz hasonlította mégis
), csak egyszerűbb? A maximális tisztánlátás végett kérdezem harmadszor is, sorry. A konzolok előnye(talán az egyetlen, de nagyon sokat dob rajtuk), hogy ott nincs API, nem ezt kéne valahogy elérni PC-n is? -
-
DRB
senior tag
Azt hogy API csak úgy általánosságban értettem(vagy valami ilyesmi
), pl, mint hogy egy program nem fér közvetlenül a hardverhez(GPU-hoz, CPU-hoz, stb) hanem "valamin" keresztül(nem a driver), pl dx, vagy .net, vagy mitom' én még mi. Ilyen értelemben ez is így működik? Ha jól veszem ki a válaszod igen, de mondom nem vagyok programozó, így ha kérhetnék kicsit még hétköznapibb megfogalmazást, csak az fog megvilágosítani. 
-
lenox
veterán
Amugy akkor szerintem az lehet a megfejtes, hogy ha egyseges cimter van, akkor ahhoz kepest jobb a teljesitmeny, mintha nem hasznalnak a gpu gyorsitast, mivel akkor tobb projektnel eri meg gpu gyorsitast alkalmazni.
Olyan szempontbol nem lenyegtelen, hogy ez az aktualis technika, ami gyorsan valtozik, szoval azert, mert 2 evvel ezelott valaki mondott valamit, aminek alatamasztasara csinalt egy merest, az ma mar egy masik allitas, vagy hasonlo, de mas kornyezetben megfogalmazodo allitas alatamasztasara nem biztos, hogy alkalmas. Egyebkent azt a reszt azert gondolom vetted, hogy rakhatsz a pcie buszra dugott gpu memoriajara is egyseges cimteret, attol gyorsabb nem lesz, igy ez a ket dolog, nevezetesen az egyseges cimter es hogy pcie buszra kell-e dugni az accelerator kartyat teljesen fuggetlen dolog, tehat az egyikre hivatkozni, hogy a masikra vonatkozo allitast tamasszunk ala, ez teljesen ertelmetlen.
Amugy visszaterve az elozo peldara, 2 evvel ezelott opencl-lel olyan 1.5-2 GB/sec koruli effektiv mem-gpu mem bandwidth-t lehetett elerni, es egy dual proc workstation-ben olyan 9-10 GB/sec effektiv memory bandwidth-t, kb ilyen arany latszik a linkelt grafikonon. Jelenleg egy Z800 workstationben kb. 5.5-6 GB/sec mem-gpu mem bandwidth-t lehet elerni, meg mindig 9-10 GB/sec memory bandwidth mellett, szoval a bottleneck joval kisebb, mint amit a grafikon mutat. A PCIE3-at meg nem mertem ki, de elvileg kb. duplazodik a sebesseg. A mem bandwidth pedig olvasasra 15 GB/sec, irasra 6 GB/sec dual proc SB-nel, szoval amig ez a problema meg nem javul, addig bizonyos esetekben egal, mas esetekben pedig 30% a performance hit a PCIE busznal, ha megjavul, akkor gondolom allando 30% lesz. De ez mar regen nem az, mint a kezdeti 2 vs 10. Persze latency meg mindig van, ami alkalmazastol fuggoen vagy erdekes, vagy nem, amiket en csinalok, azoknal foleg nem, az Adobe-nal is foleg nem.
Az egyseges cimter, meg koherens memoria meg killer feature, de nem teljesitmeny szempontjabol, illetve csak ugy teljesitmeny szempontjabol, hogy olyanok is hasznalnak altala gpu gyorsitast, akik amugy nem tennek.
Kivancsi leszek a stacked memory-ra, de nekem valahogy nagyon nehezen elkepzelhetonek tunik, hogy 64 MB cache-t csinaljon valaki, pedig az mar nagyon-nagyon minimum.dezz: Kivancsi leszek, ha igy lesz, akkor szuper lesz, de nekem hirtelen nem jut eszembe jobb otlet, minthogy cache-sel lehet ezt ertelmesen megcsinalni, akkor meg a cache mennyisege hatarolja be a jol megoldhato feladatokat.
-
Abu85
HÁZIGAZDA
Többségüknek közvetlenül nem, de a HSAIL teszi lehetővé nekik, hogy ne kelljen hardverre optimalizálni. Közvetve tehát az előnyiből profitálnak. De hogy egyértelműbb legyen átírtam.
(#25) DRB: A legegyszerűbb felfogása ennek a Java. A Java bytecode is egy vISA. Ez is hasonlóan működik, csak más szempontok szerint fejlesztették.
API-nak semmiképp sem nevezhető. -
#26
Kotomicuki
senior tag
MCBASSTION
#8
Kotomicuki
senior tag
válasz
MCBASSTION
#8
üzenetére
+1
...
(#11) MongolZ:
Nézzük kicsit távolabbról a dolgot:
Lehet, hogy 5-10x annyi idő és költség a jó program(kód) létrehozása, de mivel jól működik (a plusz idő nagy része a tesztre/hibajavításra (esetleg optimalizálásra) megy el - tapasztalt programozónál), ezért nem éri 100-1000x akkora kár a felhasználóját (/db; ha többen vannak, akkor ez tovább halmozódik; bár csak elméletben írható ez a nyereség oldalra, ellenben a veszteség gyakorlati, "kézzel fogható" lesz...), mintha a gyorsan elkészült selejt miatt áll az arra épülő, sokkal nagyobb értéket képviselő projekt.
A jól működő dolgoknak ára van, ez a legtöbb esetben a rászánt idő lesz az: a megtérülést mindig bele kell kalkulálni a képletbe.
(Ahol az 5x szoftverköltség - filléres tétel a kiadási listán - már veszélyezteti a nyereséget, ott nem ezzel a szoftverrel/hozzáállással/egyéb kellékekkel kell nekifogni az adott dologhoz...)(#16) Jim Tonic:
Aki fizet vmilyen programért, az valószínűleg az az által elérhető teljesítménytöbbletért teszi azt. Az árú-kapcsolt piacgazdaságnál - és a tudatlan vásárlók (itt: a tudatos ellentéte) magas aránya miatt - , persze, ez nem feltétlenül igaz, de legyünk jóhiszeműek a fennálló rendszerrel szemben...
...
Remélem, a "közkézbe" való kiadása nem fogja zátonyra futtatni ezt, az alapjába véve hasznos "találmányt".
-
DRB
senior tag
Lehet, hogy hülyeséget kérdezek, nem a szakterületem ez, de azért felteszem, hátha nem az. Szóval az lenne a kérdésem, hogy ezt valamiféle API ként kéne felfogni? Nem épp az API-kat akarják nélkülözni, mert lassítja az egész rendszer működését? Nincs több kérdésem, ha hülyeség volt elnézést.
-
dezz
nagyúr
"Az előnyök kézzelfoghatóak, ugyanis a HSAIL egy nagyon leegyszerűsített virtuális ISA, amire a fejlesztőknek egyszerű lesz dolgozni."
Szerintem a hétköznapi fejlesztőknek semmi közük nem lesz a HSAIL-hez! Azok a Bolttal, Open-CL-lel, C++ AMP-pal dolgoznak!
A HSAIL-lel a rendszer-/driver-programozók dolgoznak és azt oldja meg, hogy a hétköznapi programozóknak ne kelljen egyedi HW-ekre optimalizálni a magas szintű kódokat!
(#2) lenox: Az egységes címtér nyilván a portolhatóságot és magas szintű programozást egyszerűsíti, de a rendszer gondoskodik az adatok megfelelő kezeléséről (mit milyen memóriába, ill. ezt talán jelezni is lehet neki), így a teljesítmény sem szenved csorbát.
-
-
Abu85
HÁZIGAZDA
Hardver szempontjából az AMD Vision APU-k támogatják a HSA-t. A Trinity a HSA MMU kiterjesztést is. Az ImgTec esetében a PowerVR 5 család SGX 545 IP-je támogatja, illetve a készülő Rogue, az majd támogathat extrákat is. Az ARM esetében az új generációs Mali T család támogatja a HSA-t, egyelőre nem tudom, hogy milyen kiterjesztésekkel.
-
Abu85
HÁZIGAZDA
Nem tudom, hogy más mit írt, én megnéztem az előadást. Egyértelműen a teljesítmény portolhatósága volt a téma, és Tom Malloy szerint ezen javíthat az egységes címtér.
Az előadás ilyen ömlesztett volt, jöttek az emberek, és mondták a magukét. A data transfer problémája jelentős. Azt mondták, hogy nagyon függ a feladattól, de a helyzet az, hogy van ahol ez elkerülhetetlen. Lényegtelen, hogy a HD 5870 mikor volt. Ettől még a teljesítményt a data transfer fogja vissza. Rakhatsz akármilyen erős gyorsítót oda, ha az adatokat másolgatni kell. Pont ezért mondja az NV is egy ideje, hogy a tradicionális accelerator kártyáknak nincs jövőjük.
Az AFDS programozóknak szóló rendezvény. A problémákat vázolták a vezető szoftvermérnökök. Nekik nem céljuk a marketing. Azért lettek meghívva, hogy tanítsák a fiatal generációt.
Nem. Ahogy látom az AMD/Intel/AMD/ARM ... hosszútávú roadmapját mindenhol a teljesen koherens megosztott memória szerepel, mint killer fícsőr. Persze elképzelhető, hogy tévednek, de annyira egységesen látják a jövőt, hogy kicsi a valószínűsége.
A stacked memory pedig sokféle lehet, de inkább cache szempontból van értelme ilyen jövőképek mellett. -
#16
Jim Tonic
nagyúr
MCBASSTION
#8
válasz
MCBASSTION
#8
üzenetére
Nem értelek. Ha egy olyan programot készítesz, ami néhány számítást inkább a GPU-val végeztet, és nem az a cél, hogy maximálisan kihasználd a képességeit, akkor miért ne lenne ez a járható út?
-
lenox
veterán
Ok, en ezt mashol mas mondatokkal latom, meg ahol ez a mondat van, ott vesszo van a performance es a portability kozott, szoval szerintem 'performance portability' egyutt nincs.
Amugy akkor ez egy tevedes. A memcached key lookup nyilvan akkor mukodne jol diszkret gpu-n, ha nem kell odatranszferalni, nem tudom ki csinalta a grafikont, de ennek igy semmi ertelme sincs, meg 5870, az mikor volt mar?
A kovetkezo lepes nem a chipre integralt gyors memoria lesz? Ahhoz gondolod, hogy pcie buszon fog menni az adat a main memorybol? Szerintem erdemes tul latni a marketinganyagon. A pcie busz okozta bottlenecknek nem az egyseges cimter a megoldasa, azt pcie busszal is meg lehet oldani, es majd csodalkoznal, hogy hol gyors, hol meg lassu a programod, annak megfeleloen, hogy hova tudtad foglalni a buffered. Ujra el lehet vitatkozni ezen, de az teny marad, hogy gyors memoriat csak megfelelo meretu cache-sel lehet valamennyire kivaltani, ami draga, ugyhogy nem valoszinu, hogy elterjed. Ha pedig van gyors memoria, akkor azt megkulonboztetve kell kezelni a lassutol, legalabbis ha performance-t akar az ember. Ha portability fontosabb, akkor persze lehet egyseges.
-
#14
Löncsi
őstag
MCBASSTION
#8
Löncsi
őstag
válasz
MCBASSTION
#8
üzenetére
+1.
Párhuzamos programozás is kemény dió, nemhogy a GPU.
-
vanhalen
senior tag
"Szuperszámítógépes területen nem is kicsit elterjedt a linux.
Egyre terjed a hardveres gyorsítás támogatása itt is, grafikai programok terén Blender, Gimp (nem tudom milyen szinten)"Ezekre, főleg a szuperszámítógépes részhez biztos lesz támogajtás (meglepne, ha nem lenne..)
"Vagy csak nem volt pénzük megvenni a többieket" Ha az OpenCL-re gondolsz, az eredetileg Apple kezdeményezés volt, szóval..
Ők be is építették rendszer szinten Snow Leo-ba oszt jónapot. Többiek, meg csináljanak amit akarnak. Nekem legalábbis így tűnt/tűnik.(#12) Abu85: "Amit a HSA eliminál az a "pöcsölés" Nagyon helyes. Hálistennek ezt nem tudja lenyúlni valami nagy cég, mint anno a transitive-nél
A java hasonlat mennyire helytálló? -
Abu85
HÁZIGAZDA
-
#11
MongolZ
addikt
MCBASSTION
#8
MongolZ
addikt
válasz
MCBASSTION
#8
üzenetére
Az miért is baj, hogy ha kevésbé képzett programozók is elkezdik az APU-k erejét kihasználni?
Ezenkívül, hogy ha programozó vagy, nem hiszem, hogy a főnököd/megrendelőd nyugodt szívvel mondaná azt, hogy na, MCBASSTION, nyugodtan írd csak meg 5x annyi idő alatt azt az 5x olyan hosszú kódot (5x annyi hibalehetőséggel), hiszen ráérünk.
-
Abu85
HÁZIGAZDA
A HSA nem függ az OS-től, szóval nem lehet gond a Linux disztribúciók támogatása sem. Persze önmagában nem akkora fókusz, mint az elterjedt OS-ek. Erről a HSA alapítvány gondoskodik. Ennek résztvevői lényegében azok a vállalatok, amelyek beléptek. Mindegyik cégnek van egy képviselője. [link]
Önmagában az AMD hatalma a draft specifikációk megalkotásával véget ért. Az alapítvány azt a célt szolgálja, hogy minden cég egyenrangú legyen a HSA támogatása szempontjából. Ennek megfelelően a további fejlesztéseket nem csak az AMD, hanem résztvevők végzik egységesen.Nem, a közösség kezébe nem adják a HSA fejlesztését. Ez az alapítvány feladata. A gyártók feladata, hogy a saját finalizert és a kernel drivert megírják. Mivel ezek a fizikai hardverhez kötődnek, így erről mindenkinek gondoskodni kell.
A fejlesztésbe viszont be lehet lépni, de csak úgy kívülállóként a közösség ezt nem fejlesztheti.
Nyílt forrású sosem lesz. Az alapítványon belül a tagok ingyenes jogot kapnak a használatára, de minden fejlesztést meg kell osztani mindenkivel az alapítványon belül. -
wetomi
aktív tag
Nem a "fosavindóz linuxfanok" miatt kérdezem, mert az nem érdekel. Bizonyos területeken nem csak ez a szabadszoftveres hippilét a legfontosabb.
Szuperszámítógépes területen nem is kicsit elterjedt a linux.
Egyre terjed a hardveres gyorsítás támogatása itt is, grafikai programok terén Blender, Gimp (nem tudom milyen szinten).
A Canonical is nagyon tolja az Ubuntu szekerét.
És fejlődnek az arm portok is, ezért is vagyok kíváncsi, mi várható.(#7) vanhalen: OK így már értem mire gondoltál, tényleg nem nagyon kardoskodtak mellette. Vagy csak nem volt pénzük megvenni a többieket.
-
#8
MCBASSTION
aktív tag
MCBASSTION
aktív tag
nem értem mire jó ez... hogy kevesebb kódot írjunk? vagy hogy kevésbé hozzáértő programozók is nekilássanak opencl-ben programozni?
az első esetben még jól is jöhet HA ua a teljesítményt nyújtja mint ha simán OCL-ben írtam vna. Ellenkező esetben nem érdekel h 5x annyi kódot írok.
A kevésbé hozzáértő meg ne ezzel próbálkozzon, hanem tanulja meg az egészet rendesen mert másképp nincs értelme ezzel foglalkozni.
-
vanhalen
senior tag
Nem értek hozzá de hasonlatként írták a cikkben a java-tm hogy ahhoz hasonlít majd kissé. Meg azt, hogy várják szeretettel a programozókat is HSA kebelére: gondolom mehetnek a linuxosok is, tehát hajráf. Azt nem érdemes várni, hogy majd a linux kedvéért, ami nem képvisel túl nagy profitot, vagy elterjedtséget, külön támogatást írnak. Ha igen, akkor talán a droid miatt, bár a megrögzött linux fanoktól rendszeresen fanyalgó véleményezéseket olvasok, hogy "az nem is igazi linux"
Ott a lehetőség, csatlakozzanak az önkéntes-nyíltforráskódú vagyok-fosawindóz emberkék a HSA alapítványhoz és lehet alkotni (#5) wetomi: Úgy értettem az agresszivitást, hogy nem elég, ha csak leteszik egy alapítványba, oszt jónapot. Kapmányolhatnának, marketing 1000-el, előadások, demózások stb. (ha akarnak valamit) OpenCL is mióta van már kész formában? 2008 óta talán? Ott is ezt csinálták, aztán máig hány program van forgalomban, ami rá épít, annak ellenére, hogy a legnagyobb nevek felsorakoztak mögé? Pár fecske és puszi.. 4 év alatt.. Tudom, hogy írták, ennek egyszerűbb a programozása, de akkor sem elég, ha ülnek a babérjaikon.
-
Abu85
HÁZIGAZDA
Tom Malloy összegzése:
Ott van, hogy a teljesítmény portolhatóságán segít.A tradicionális accelerator kártyák esetében nagyon függ a sebesség a feladattól. Nem felelnek meg minden igénynek. Az igaz, hogy baromi gyorsan végeznek a végrehajtással, de a data transfer sok időt elvehet.
Például az offload memcached technikánál a szervereknél. Látható, hogy az accelerator szerepét betöltő Radeon HD 5870 baromira gyorsan végez a feldolgozással, de a data transfer megöli a sebességet.
Hasonló következtetést vont le az NVIDIA is a jövővel az Ecehlon projekt tanulmányában. [link]
... CPUs and GPUs will be integrated on the same die with a unified memory architecture. Such a system eliminates some of accelerator architectures historical challenges, including requiring the programmer to manage multiple memory spaces, suffering from bandwidth limitations from an interface such as PCI Express for transfers between CPUs and GPUs, and the system-level energy overheads for both chip crossings and replicated chip infrastructure.
Van ahol nem számít annyira a data transfer büntetése, de jellemzően jelentős probléma, így Tom Malloy nyugodtan beszélhet erről általánosan. -
wetomi
aktív tag
"Most az egyszer lehetne AMD is olyan agresszíven nyomulós, mint Intel, vagy nV.. Ez, hogy "itt van gyerekek, alkottunk valamit, naggyoncéép, naggyonjóó nesztek beleb@sztam egy alapítványba, aki akar gyühet, oszt jóvan" manapság már nem elég (szerintem)"
Kb ez olyan, mint amikor valami nyíltforrású projektet átadnak a közösség kezébe. Nincs rá/sajnálják a pénzt a fejlesztésre, csinálja tovább más. Így viszont kevésbé lesz egységes fejlesztési koncepció.
-
wetomi
aktív tag
"A támogató cégek számára a rendszer szintén nagyon egyszerű, gyakorlatilag csak a saját hardverekre szabott finalizerről, illetve a kernel driverről kell gondoskodni, a HSA többi eleme univerzálisnak mondható."
Ezek szerint milyen linuxos támogatásra lehet számítani, lehet egyáltalán bármire?
A SoC gyártók remélhetőleg megcsinálják androidra is a saját változatukat, nem csak windowsra, de mi a helyzet linux téren?
Arról van valami információ, hogy ezt a részét mennyire veszi komolyan mondjuk az AMD?
Még ha játszani ugyan nem is a leggondtalanabb, de számolgatni nagyon jó lehet ez linuxra is, hiszen erre vannak az apu-k, általános számításra is."Ennek megfelelően megjelenik a QoS (Quality of Service) is, mely biztosítja a párhuzamosan futó alkalmazások, illetve a párhuzamosan beérkezett felhasználói igények számára a grafikus vezérlő erőforrásaihoz való zavartalan hozzáférést."
A közösség kezébe adják ennek a fejlesztését és így lesz egy nyílt és lesz egy zárt gyári "meghajtó/kernel driver" különböző tudással, mint a grafikánál?
Vagy "teljes funkcionalitású" verzió várható gyári támogatással, amit megkap a linux kernel?
Vagy először még pénzt csinálnak belőle és csak utána jöhet a nyílt forrású változat? -
lenox
veterán
Tom Malloy szerint a legfontosabb képesség a programozók szemszögéből az egységes címtér lenne, mely jelentősen megkönnyítené a teljesítmény portolhatóságát, illetve a fejlesztők munkáját.
Nem tudom, nekem ez nem hangzik igaznak. Szoval egy megfelelo nagy cache-sel gyorsitott egyseges cimter az persze jo lenne, de a mai allapot szerint, amikor a legtobb esetben van egy gyors es egy lassu memoriaterulet, akkor a kettot egyseges cimterbe vonni az a teljesitmenyt inkabb gatolna, mint segitene. Persze azt ertem, hogy egy APU-nal, ahol egyfajta memoriaterulet van, ott ez mindegy, de pont a kovetkezo lepes az, hogy megint ketfajta memoriaterulet lesz, nem?
Amugy en Tom Malloytol csak azt latom, hogy a portolhatosagot segitene az egyseges cimter, ebben a mondatban teljesitmenyrol nincs szo. -
vanhalen
senior tag
Érdekes elképzelés. Az AMD nagyvonalúan közkinccsé tette, de vajon a többi gyártó kész ebbe beolvadni? nV-t még talán nem zavarná egy ilyen, ha Intel dobta volna ki, Intelékből viszont már nehéz kinézni, hogy beállnának a sorba
Viszont ugye ott a mobil oldal, az ARM-os jövő. Ezzel, ha jól értem simán növelhető az ARM SOC-ok teljesítménye, mármint programok futása szempontjából, a felhasználóknak meg úgyis a végeredmény számít, nem az, hogy mi dohog a háttérben. Tetszik a koncepció, kíváncsi vagyok életben marad e. Most az egyszer lehetne AMD is olyan agresszíven nyomulós, mint Intel, vagy nV.. Ez, hogy "itt van gyerekek, alkottunk valamit, naggyoncéép, naggyonjóó nesztek beleb@sztam egy alapítványba, aki akar gyühet, oszt jóvan" manapság már nem elég (szerintem)
) programkódnál - , akkor a (d)GPU-t a PCI-E-n keresztül használó, heterogén programkód kevéssé hatékony. Az APU-ban ezt próbálják meg helyrerakni, a CPU-GPU egyetlen lakán való elhelyezésével: ekkor már a RAM elérés/sávszélesség válik a legfőbb teljesítményromboló tényezővé - a több számítás, több/gyorsabb tárhelyigénnyel is él (itt ehhez is kell optimalizálni a kódot) és a 240-pin-s DDR3 modul (sebessége nagyjából fix, csak a csatornák számának növelésével javulna a teljesítménye, de az már messze nem pénztárcabarát megoldás) jelentős hátrányban van a 256-512 bites, 1500-1750 MHz-s(effektív 6-7GHz) DDR5 vRAM-l szemben (a GPU mellett, a VGA-n, viszonylag szabadon variálható elrendezésben és mennyiségben).
Tök8 mekkora vas kell alá. 
). Bocsi az offért, de egyre jobban kezdek csalódni az egészben.![;]](http://cdn.rios.hu/dl/s/v1.gif)
tulajdonképpen ez is az, csak egybeépítve a cpuval
, persze nem mostanában volt az és tényleg csak nagy általánosságban.
), csak egyszerűbb? A maximális tisztánlátás végett kérdezem harmadszor is, sorry. 
Új hozzászólás Aktív témák
ph Az 1.0 draft specifikációk elkészültek, így létrejött a HSA alapítvány is, amelybe több cég is belépett.
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- LEGO klub
- Mesterséges intelligencia topik
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- Asztrofotózás
- Projektor topic
- Formula-1
- Samsung Galaxy A55 - új év, régi stratégia
- Luck Dragon: Asszociációs játék. :)
- Samsung Galaxy S22 és S22+ - a kis vagány meg a bátyja
- További aktív témák...
- Bomba ár! Dell Latitude 5410 - i5-10GEN I 16GB I 256SSD I HDMI I 14" FHD I Cam I W11 I Garancia!
- LG 55G4 - 55" OLED evo - 4K 144Hz & 0.1ms - MLA Plus - 3000 Nits - NVIDIA G-Sync - FreeSync Premium
- Honor 90 Lite 256GB, Kártyafüggetlen, 1 Év Garanciával
- AKCIÓ! HP ZBook Firefly 14 G9 üzleti notebook- i7 1255U 32GB RAM 512GB SSD nVidia T550 4GB Win11
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5800X 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest