- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
- Gaming notebook topik
- Házimozi haladó szinten
- Házimozi belépő szinten
- A régi node-okra koncentrál a szankciók miatt Kína
- NVIDIA GeForce RTX 3080 / 3090 / Ti (GA102)
- Fujifilm X
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Milyen TV-t vegyek?
- AMD GPU-k jövője - amit tudni vélünk
- RAM topik
Hirdetés
-
Az Apple iPadOS-t is megrendszabályozza az EU
it Az EB közölte: az Apple iPad táblagépekre írt iPadOS rendszere is kapuőrnek számít, az üzleti felhasználókra gyakorolt fontossága miatt.
-
Xbox Game Pass [2024] - A májusi lista
gp Az elkövetkező időszakban többek között megkapjuk a Kona II Brume című játékot.
-
Spyra: akkus, nagynyomású, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
És az adatok vándoroltak a hatványozottan lassabb PCI Express felületen keresztül. Nem véletlen, hogy a valós időben számított feladatoknál a fejlesztők nem engedtek meg maguknak két adatcserénél többet. Sőt még az egy is sok, mert irtózatos késleltetéssel jár. Egy ilyen APU-ban a késleltetés sokkal kisebb, vagyis több adatcsere is megengedhető. Például egy játékban a GPU-s fizika számításánál szigorúan CPU->PPU(ez számolja a fizikát)->GPU az út. És ez mind azért ilyen megkötött, mert az adatok lassan vándorolnak az alaplapi buszokon. A rendszerszintű integrálás mellett megcsinálható egy olyan út is, amiben az IGP visszaadja az adatokat a CPU-nak további feldolgozásra és ez lapkán belüli kommunikációval legalább háromszor eljátszható. Ha ugyanezt az alaplapi buszokkal csinálnád, akkor olyan késleltetéssel jelenne meg a képkocka a képernyőn, hogy nem tudnál megfelelően reagálni a világra, mert az az információ, amit te látsz, már rég nem valós. Itt kis időegységekről beszélünk, de érezhető lagról lenne szó. Kb. az ilyenek miatt gondolkodik mindenki fúzióban.
Az előny kézzel fogható. Persze a késleltetést tovább kell csökkenteni, hogy minél több adatcsere valósulhasson meg.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Oliverda
félisten
Ezek nem egyik napról a másikra fognak népszerűvé válni, de akinek egy kis rálátása van a dolgokra az tudja, hogy most ennek van jövője és erre kell fejleszteni a hardvereket is. Nem értem, hogy miért kell ennyit feleslegesen értetlenkedni ezen...
"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."
-
Abu85
HÁZIGAZDA
A lelkesedés eddig is megvolt. Készülnek is az OpenCL-es programok. Egy DVD felkonvertáló már van is, az nagyon cool. Tesztelgetek egy arcfelismerőt is. Egyelőre kevés sikerrel, sajna még béta szegény, az Intel-Radeon páros nem tetszik neki. Full AMD-s platformon persze szó nélkül megy a rohadék. Mindegy, majd a végleges.
A saját memória nem olyan jó dolog. A hatékony heterogén feldolgozás egyik alapja, hogy közös memória kell, persze ettől ritkán jelent jelenleg hátrányt.Az nem kérdés, hogy a diszkrét GPU-ra mindig lesz igény, de az már nagyon lényeges szempont, hogy mekkora. Az asztali VGA-k piaca, már most nem jövedelmező, mi lesz itt jövőre. Nézd meg a VGA-gyártókat. Szinte mindenki ugrik máshova. Sokan alaplapot fognak gyártani, de van aki az SSD piac felé megy.
(#48) Zanik: A te gépednek a felhős modellnék csak az a dolga, hogy a kapott, kész képkockát kirakja a képernyőre.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
CPT.Pirk
Jómunkásember
Nem bólogatunk hozzá vadul, pl. mikor a többmagos procik kezdtek bejönni, akkor John Carmack beszélt róla, hogy sokkal jobb lenne, 1 gyors proci mag, mint több, de lassabb. Úgy igazából nem hatott meg senkit, főleg h. nem is igen kivitelezhető. Szélsőséges példa erre a Win Vista, amit kevesebb, de gyorsabb procimagra készítettek fel, aztán a felhasználók meg alátettek több, de lassabb magot.
Eddig is volt pár alkalmazás, ami ki tudta használni a gpu erejét pl. videó kódolásra, tényleg ott van rajta egy rakás ram, ami nyilván gyors és alkalmas is nem csak a 3D-s játékok adatainak tárolására, viszont hogy közben a proci is dolgozzon azon, vagy valami hozzá kapcsolódó feladaton, azt nem fogod tudni összehozni, a köztük lévő nagy késleltetésű adatbusz miatt.
Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)
-
con_di_B
tag
Ne csodálkozz, hogy nem lelkesek.
A HD3000-es szériánál még csak a Stream volt (Close To Metal?), a HD4000-esek tudnak OpenCL 1.0-át, atomi műveletek és osztott memória támogatás nélkül (= félkarú óriás), és csak a HD5000 után beszélhetünk elfogadható OpenCL támogatásról, ami egyébként továbbra is bugos, GPU-n.
Az AMD-nek van ezen kívül CPU-s OpenCL megvalósítása is, ami stabil, de kegyetlenül lassú értelemszerűen.
Az NV-nek ott van a CUDA, ami elvisz a hátán egy egész korrekt OpenCL implementációt, ráadásul nekik a régebbi hardvereiken is jó az implementáció.
Az Intel meg még most szerencsétlenkedik a sajátjával, alpha verzió, vehetjük úgy, hogy nincs is.
Ezek után senki ne lepődjön meg, hogy nem hemzsegnek az OpenCL-re fejleszteni kívánó lelkes fejlesztők. Simán lehet olyan HELYES programot írni, ami éppen per-pillanat egyik GPU-s implementáción sem fut le.
Hogy a témához is szóljak, viszont abban a távoli jövőben amikor már sikerül drivert írniuk OpenCL-hez, nagyon jó lesz ez a FUSION még akár diszkrét VGA mellett is, mert az OpenCL-ben egyszerre több computing device-ot is vezérelhetsz, szóval én el tudok képzelni olyan programot, ami mondjuk kirak egy lassú de relatíve önállóan elvégezhető feladatot a diszkrét böhömnagy GPU-ra, mellé egy szinkronizáció igényesebbet a Fusion GPU-ra (mert azt alacsony késleltetéssel éri el), és akkor még ott van az 1-4 mag hagyományos, folyamatalapú többszálúságra. De ezt meg a feladat határozza meg, ha a feladatot nem lehet szétosztani így, akkor hiába minden, de azért a néhány wattért amennyi az integrált GPU TDP-je lehet, nagyon-nagyon megéri már a lehetőség is.
[ Szerkesztve ]
-
opr
veterán
Ha jók az információim, akkor elvileg asztali vonalon -egyelőre- úgy lesz, hogy a low-end, meg max a middle szegmensben lesz APU, a többiben sima, nyilván baromira erős CPU.
Így viszont szerintem a kétségek megintcsak el vannak oszlatva, a megfelelő gpu-val mint azt fentebb tanult kollegánk is említette bőven elegendő akár egy x2 250-es athlon is mindenre, amire egy potenciális vásárló használni fogja a gépet. Pl. internet, HD filmezés. Ezekre dosztelég két, viszonylag magas órajelű processzormag, meg egy mindentvagyészbőlvagyizombólgyorsítok GPU
A felsőházban pedig természetes, hogy a halálnak nincs rá (APU) szüksége, de ott egyelőre nem is lesz. Aztán, hogy mit hoz a jövő, azt majd meglátjuk.[ Szerkesztve ]
"Programozó vagyok. Ez azt jelenti, hogy amit leírok, megtörténik." :D “The only valid measurement of code quality is What-The-F**ks/Minute.” - Robert Martin
-
opr
veterán
Ja, persze, abban teljesen igazad van. Programot többszálúra megírni sokkalta nehezebb, mint egyszálúra, már ha lehet egyáltalán, ez természetes (és ugye a GPU még erre tesz egy péklapáttal). Szerintem ide tartozik még, hogy a senior/junior arány nem valami jó a programozók között, ami mégjobban nehezíti a dolgokat ilyentéren.
Szerintem a probléma gyökere ott van, hogy a mai programozók -köztük én is- amikor programozni tanultak, akkor még jó gépnek számított egy 386dx. Teljesen más paradigmába "nőttünk bele". Evvan, előbb-vagy utóbb, de átszokik mindenki."Programozó vagyok. Ez azt jelenti, hogy amit leírok, megtörténik." :D “The only valid measurement of code quality is What-The-F**ks/Minute.” - Robert Martin
-
Abu85
HÁZIGAZDA
A felépítés szempontjából kétféle processzormagot különböztetünk meg. A hagyományos értelemben vett CPU késleltetésre érzékeny, míg a GPU rengeteg szállal dolgozik, és főleg az adatpárhuzamos feldolgozási modellt követi. A kettő koncepció teljesen eltérő, és másfajta feladatokban jók. Nyilván erre van példa is. Egy CPU ugyanúgy képes a 3D-s grafikát kiszámolni, csak pokolian lassan. A heterogén feldolgozás lényegében arról szól, hogy az adott feladatott az a mag végezze, amin a feldolgozás a leghatékonyabb.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Igen az APU heterogén programozása az lényegében CPU+GPU, de nincs közte lassú busz, vagyis az eddigiekhez képest az adatcserével sokkal bátrabban lehet bánni. Ez adja az egész előnyét. Ez csak az első lépés az úton. Mint írtam a hírben is, még ennél is lehet jobb kommunikációs lehetőségeket biztosítani, így még többször lehet az adatokat a magok között vándoroltatni, ami még gyorsabb feldolgozáshoz vezet.
(#104) lenox: Arra gondolj, hogy egy feladatot átadsz a GPU-nak, akkor az időbe telik. Például a flashgyorsítás jelenleg úgy működik, hogy a CPU átadja a dekódolásra váró streamet a GPU-nak, majd a feldolgozás megtörténik, és a GPU visszaadja az eredményt a CPU-nak, majd az utómunka után mehet ki a végső eredmény. Ezért hal meg az Ion 2 a Hulu weblejátszón már 720p-ben. A PCI Express x1 egyszerűen akkora késleltetéssel jár, hogy ez az út járhatatlan. Ilyen helyzetekben előny az integráció.
Ez láthatóan minden cég számára világos, nem véletlenül van/lesz a hátuk mögött platform. Attól nem kell félni, hogy az izmos GPU-kat kiváltják ezek a rendszerek, de az egész IT ipar erre megy, és ennyi cég nem tévedhet. Nyilván dönthetnek a még több CPU mag mellett is, de az ábrából látható, hogy elértük a korszak végét. Ugyanezt az ábrát mutatta be az NVIDIA az SC10-en, ahol magyarázták, hogy miért raknak latency optimized CPU magokat a következő generációs lapkáikba. Persze ők más szempontból közelítették meg a kérdést, hiszen nekik GPU-ik voltak, de a konklúzió dettó ugyanez volt, vagyis az egyetlen út a hibrid rendszer. Azt nem tudni, hogy a latency optimized CPU az NV-nél mit jelent, de gyaníthatóan ARM architektúrát. Az lenne a leglogikusabb, mert az ARM-ra elkészül a Windows 8, vagyis az NV onnantól kezdve nem függ az AMD és az Intel processzoraitól, mert egy cGPU-val képes futtatni a rendszert.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
con_di_B
tag
Ez egyszerű válasz lesz. Vagy van egy összetákolt programfelületed, amiben minden hardverre külön írsz kódot (CUDA, CTM), procikra külön írsz assemblyben kódot a kritikus részekre, vagy van egy egységes, általános felületed, amiben a különböző dolgokban jeleskedő hardvereket egyszerre érheted el (OpenCL). Ez egyszerűsít a képleten. De ehhez tényleg nem kell Fusion.
Fusion ahhoz kell, hogy ne a gépek 1%-ában legyen elég gyors OpenCL implementáció, hanem minden újonnan vásárolt gépben legyen, akár desktop, akár notebook, akár netbook vonalon => onnantól fogva máris megérni elkezdeni (ki)használni.
(Szerk: meg az, amit Abu írt
)[ Szerkesztve ]
-
opr
veterán
Na, mire hazaértem melóból már látom meg is válaszolták
röviden, amiért könnyebb programozni:
a kisebb késleltetés miatt nem kell annyira kínosan ügyelni az optimalizációra, kisebb adatcsomagokat is megéri küldözgetni, adott kód sokkal kisebb darabokra bontható, így amellett, hogy esetenként könnyebb, akár gyorsabb eredményt is dobhat, mint egy brutl különálló vga
amiért ugyanolyan nehéz:
Szintén "szét kell szedni" a programokat a megfelelő módon, mint eddig.Szal, tömören: ugyanolyan nehéz rá kódolni, mint eddig, csak mégsem(tudod, a veréb között semmi a különbség, mert mindkét szrnya ugyanolyan, főleg a bal
), és potenciálisan gyorsabb az eredmény.Nagyjából ennyi. Plusz ehhez jön még, hogy a programozók is kezdenek hozzászokni a többszálban gondolkodáshoz, plusz egyre kiforrottabbak a nyelvek/fejlesztői környezetek.
[ Szerkesztve ]
"Programozó vagyok. Ez azt jelenti, hogy amit leírok, megtörténik." :D “The only valid measurement of code quality is What-The-F**ks/Minute.” - Robert Martin
-
freeapro
senior tag
DRB kicsit fárasztó vagy!
Eddig volt egy jó elméleti lehetőség. Azt ígérte az OpenCL, hogy tudsz CPU-n meg GPU-n is feladatokat végrehajtatni. Írtál rá egy programot ahogy elképzelted, hogy működnie kellene. Kipróbáltad: nem ment. Akkor elkezdted az elképzelést közelíteni a valósághoz, meg optimalizálni, meg guglizni, hogy hol a hiba, mások mit találtak ami működik, mik a soha nem publikált best practice eljárások stb. Nagyon sok vesződés árán csináltál valamit ami alig lett jobb mint a sima egyszálú program. Jó esetben. Rossz esetben kiderült, hogy ezt még nem lehet megcsinálni. És itt elment a kedved az egésztől.
A heterogén felépítés pedig végre azt nyújtja mait ígért. Fut a cucc az APU-n amihez ha CPU kell akkor ahhoz nyúl, ha GPU akkor ahhoz, kicsit még mindíg rosszabb mint vártad, de lényegesen jobb mint az egyszálú program. És ekkor megszereted.
-
P.H.
senior tag
APU-n azért könnyebb programozni, mert az ember jópár dolgot, ami diszktét GPU-n lassabban megvalósítható volt, már előzetes számítások (adatcsere időigénye pl. - alapján) is eleve elvetett, megoldható.
Igaz, nem könnyebb programozni, de kifizetődőbb. Az FPU-t sem volt anno könnyebb, aztán egyre többen használták, be is épült a CPU-ba.
Pedig ahhoz egyetlen dolog kellett, a CPU felismerte a nem neki szánt utasításokat, és továbbította megfelelő lábain az FPU-nak. Erre pl. az Intel-nek manapság is vannak már megoldásai pl., csak ugye minek, amikor már vannak a piacon kész, platformfüggetlen megoldások.A heterogén megoldások jobban kiterjesztik a párhuzamosítás lehetőségeit, mint a többszálúsítás, ez a grafikai eredetükből is látszik: klasszikus példám az, hogy egy nagyméretű színes képet akarsz fekete-fehérré tenni. Ha CPU-programozó vagy, akkor egy processzoron írsz egy (minőségigénytől föggően) 5-10-15 utasításból álló ciklust, ami lefut minden pixelre, egymás után - némi átfedéssel, OoO miatt. Majd beleizzadsz, hogy jó teljesítményt nyújtva 2-4-8 magon jobban, gyorsabban fusson le ugyanez (az adminisztáció, elosztás, szinkronizáció időigénye miatt). Ugyanezt megírod egy GPU-like architektúrára, hogy fusson le minden pixelre ugyanaz az 5-10-15 utasítás, a hardware + driver pedig kezeli neked, hogy hogyan, mi módon párhuzamosítva, te csak azt látod, hogy gyorsabb, mint CPU-n (pl. OpenCL).
Hozzátéve, hogy egy GT9500-ból vagy egy GT220-ból ily módon kihozható számítási teljesítmény kb. egy 4/6 magos CPU-éval egyezik, a CPU-többszálúsításánál könnyebben elsajátítható programozási modell mellett, akkor szerintem billen a mérleg asztalon is.
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
freeapro
senior tag
Dehogynem: single core > multi core > hetrogen
Hogy értsd, hogy miről beszélek: próbáltam DX játékot csinálni, a doc és a példák alapján vertex buffereket csináltam az objektumokra, kiszámoltam a mátrixokat és szépen egyesével kipakoltam a képernyőre. Állati lassú lett. Ekkor elkezdtem mégegyszer átnyálazni az SDK docot és többszázoldalas nyomtatásban tényleg ott volt az egysoros megjegyzés, hogy a graf kártyák azt szeretik, ha nem csak úgy összevisza küldjük az adatokat, hanem az azonos objektumokat egyszerre batchben szeretik kiiratni.
Hiába pár sor a kódodban egy API hívás ha mögötte több száz soros driver kódot kell végrehajtani és rendszerek között kell kommunikálni aminek nagy overheadje van, akkor azt másképp kell csinálni.
De ha egy chipeben lesz az egész, lehet, hogy újra elővehetem a programomat és most jól fog futni...Ennél jobban már tényleg nem tudom elmagyarázni..
-
dezz
nagyúr
"Pont ugyan úgy kell programozni ezt is, mint ahogy eddig is kellett egy CPU(akár több magos)+ diszkrét GPU párost."
Most miért is ismételgeted ezt, dacára annak, hogy már többször is leírták, személy szerint neked, hogy nem így van?
(Főleg, hogy ezt már a HD3xxx-től méred.) Esetleg elkerülte a figyelmedet con_di_B #82-es hsz-e? Idézem:"A HD3000-es szériánál még csak a Stream volt (Close To Metal?), a HD4000-esek tudnak OpenCL 1.0-át, atomi műveletek és osztott memória támogatás nélkül (= félkarú óriás), és csak a HD5000 után beszélhetünk elfogadható OpenCL támogatásról"
Tudod, mi volt a Close To Metal? Egyfajta ASM kódolás... A OpenCL már nem ilyen, de az 1.0 meglehetősen kezdetleges volt. Oké, hogy HD5000-től már volt 1.1, no de arra alapuló IGP még nem létezett.
Továbbá, az OpenCL (vagy akár a DirectCompute) alkalmazása is teljesen más, mint a CPU-s többszálúsítás.
Ha mindezt továbbra sem érted, hát tényleg maradj a kaptafánál, akarom mondani a multimédiánál...
lenox: Világos, hogy sok feladatnál sokkal többet számít a nagy memóriasávszél, mint a késleltetések (bár általában nem árt, ha az utóbbi elfedhető). Ezek főleg olyan műveletek, ahol nagyon sok adattal, de nem túl bonyolult műveleteket kell végezni. Végülis a játék-grafika is ilyen. De vannak olyanok is, ahol kevesebb adattal, de jóval bonyolultabbakat. Ilyen lehet adott esetben pl. a ray-tracing (meg ugyebár itt fontos a véletlenszerű memóriahozzáférés hatékonysága is, tekintve pl. a VRAM és a main ram eltérő időzítéseit). Ezeknél elég lehet az a 27 GB/s (feltételezem, ez a Llanora vonatkozik), illetve később "jelentősen több". (Meg ha most nincs, később biztos lesz hozzáférés a L3-hoz is.)
A Zacate-t (és az Ontariot) meg nyilván az IGP-k és low-end kártyák szintjén kell megítélni ilyen szempontból, nyilván nem egy súlycsoport egy komolyabb GPU-val, akármennyire is egy APU.
Elég baj, ha ilyen sokáig tart 1-1 számítási feladat indítása a GPU-n, ezen később bizonyára jelentősen javítanak majd, pl. az OpenCL1.2-ben.
[ Szerkesztve ]
Az előny kézzel fogható. Persze a késleltetést tovább kell csökkenteni, hogy minél több adatcsere valósulhasson meg.
)
(Főleg, hogy ezt már a HD3xxx-től méred.) Esetleg elkerülte a figyelmedet con_di_B #82-es hsz-e? Idézem:
Új hozzászólás Aktív témák
ph A Brazos platform keretén belül megszületett az első heterogén módon programozható PC-s lapka.
