Keresés: - [Re:] Végre érkeznek az OpenCL-es programok

Legfrissebb anyagok

Mobilarena témák

PROHARDVER! témák

IT café témák

GAMEPOD témák

LOGOUT témák

Keresés

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

#131 dezz nagyúr lenox #130

Új Válasz 2011-06-20 15:21:10 #131
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

dezz

nagyúr

válasz lenox #130 üzenetére

Én nem beléd kötöttem, hanem egy szakmai kérdést próbáltam megvitatni, és éppen, hogy tőled nem telt többre, mint kötekedésre, állandó félrebeszélésre, korrekt válaszok helyett.
Egy esetben volt olyan, hogy egy szócska elnézése miatt félreértettelek, amiért elnézést is kértem.
Csak olyankor "szídtalak", amikor korrekt válasz helyett süketelést kaptam. Tudod, arra nehéz észérvekkel reagálni.
#129 dezz nagyúr lenox #127

Új Válasz 2011-06-19 21:24:09 #129
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

dezz

nagyúr

válasz lenox #127 üzenetére

Mi azon az inkorrekt, hogy egyenes válaszokat próbálok kicsikarni belőled?
Rég rossz, ha valaki ennyire nem tudja elismerni a tévedését... Vitaképtelen.
Baglyozz csak, de hiába nem nézel bele a tükörbe, attól mások még látnak.
#124 dezz nagyúr lenox #122

Új Válasz 2011-06-19 16:46:52 #124
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

dezz

nagyúr

válasz lenox #122 üzenetére

Csak azt szerettem volna elérni, hogy korrekt válaszokat adjál, de úgy látszik, képtelen vagy erre.
Tényként csak annyit állítottam, hogy pl. a ray-tracingben vannak olyan feladatok, amik jobban fekszenek egy CPU-nak és olyan is, amik megfelelőek egy GPU-nak is. Nyilván egy high-end GPU belassulás fennforgása esetén is nagy eséllyel lenyom bármilyen CPU-t -- csak pl. nem mindegy, mennyi áramot fogyaszt el közben.
Ha belenéznél abba a bizonyos tükörbe, meglátnád a gerendát a saját szemedben...
#107 dezz nagyúr lenox #105

Új Válasz 2011-06-17 19:51:57 #107
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

dezz

nagyúr

válasz lenox #105 üzenetére

Erm, bocs, ebben a sok félrebeszélésben valahogy elsiklottam a #99 aposztrofos részében az arra szócskán. Akkor nézzük így:
- Tagadod-e, hogy a CPU optimálisabb a komplikált, sok feltételes ugrást és random memóriaműveletet tartalmazó algoritmusok végrehajtására?
- Tagadod-e, hogy a GPU ezzel ellentétben kevésbé tolerálja az ugrásokat és a random memóriaműveleteket (könnyen elveszítheti ilyen körülmények között a számítási teljesítmény fölényét), így inkább a stream-feldolgozás jellegű feladatokra igazán alkalmas?
- Tagadod-e, hogy mindkét féle feladatot tartalmazó alkalmazásoknál előnyös lehet mind a CPU-t, mind a GPU-t igénybe venni?
- Tagadod-e, hogy lehet olyan eset, amikor ezek gyors egymásutánban követik egymást vagy akár teljesen összekeverednek, ami kulcsfontosságúvá teszi a kettő közötti gyors (kis késleltetésű és kellően sávszélességű) kommunikációt?
- Tagadod-e, hogy GPGPU-s alkalmazásnál jóval kisebb lehet a memóriasávszéligény, mint a megszokott grafikai műveleteknél és hogy ez általában így is van?
"Nezzuk majd meg."
Nézzük! (Csak ne állítsd be úgy, mintha ez egy kőbe vésettnek vélt szabály lenne -- ez egy vélemény és fenntartom a tévedés jogát.)
"(lopod a szovegemet, nincs sajat? )."
Nem, b@szod, ez nem lopás, ezt úgy hívják: tükör...
"abban legalabb egyetertunk, hogy a lassu memoriarendszer bottleneck"
Már megint csak kiforgatod a szavakat a korrekt válasz helyett, mert éppen, hogy azt írtam, bizonyos esetekben az lehet, más esetekben meg NEM!
#100 dezz nagyúr LordX #98

Új Válasz 2011-06-17 01:31:16 #100
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

dezz

nagyúr

válasz LordX #98 üzenetére

Abu szerint egy program egyszerre csak egyfélét használhat. [link] Bár ez nekem elég furcsa, szerintem megoldhatónak kell lennie, csak talán komplikáltabb.
(#99) lenox: Észrevetted már, hogy nagyon szereted kiforgatni a szavakat? (Uhh, 1000 bocs, ez most megint "az ellenfel fikazasa", csak hát, ez a helyzet.) Én mindösszesen arra kérdeztem rá, hogy elismered-e, hogy az említett esetben az APU a gyorsabb. Nyilvánvalóan ettől nem lesz automatikusan mindenben gyorsabb. Nem is értem, ez hogy jött ki neked. Vagy itt most a lenox-féle érveléstechnika csillant meg?
A #94-ben sem arra válaszoltál, hanem tereltél és kötözködtél.
"Ha jol ertem akkor nem tudsz peldat mondani, tehat akkor azt az allitast, hogy de te mar mondtal, azt minek nevezik?"
Ehh, újabb kiforgatás... (Pedig egyértelműen különbséget tettem az általános, a leszűkített és a programnév szinten konkrét példa között, direkt a kedvedért...) Nos, én az első kettőt teljesítettem: pontosan leírtam, milyen esetben jön ki az APU előnye, és példát is mondtam rá a ray-tracing képében. Csak hát te itt már programnevet követelsz, amivel valóban nem szolgálhatok, mint már írtam.
"nem az a lenyeg, hogy ossze van-e integralva a gpu a cpu-val, hanem hogy egy kozos lassu memoriarendszeren osztoznak-e."
Aham, csak kár, hogy ez hozzátartozik az összeintegráltsághoz, főleg ha még egy címterületen is dolgoznak majd... És mivel ez így van, amit te is jól tudsz, csak kibúvókat keresel, ezért tehát szerinted itt bukik az egész dolog. Én meg erre ugye azt mondom, már nem tudom, hányadszorra, hogy bizonyos feladatok esetén ez valóban bottlenecket képez, más feladatoknál meg nem.
#97 dezz nagyúr lenox #80

Új Válasz 2011-06-16 19:17:59 #97
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

dezz

nagyúr

válasz lenox #80 üzenetére

Ja, ezt elfelejtettem betenni:
Év eleje táján írták, hogy visszamenőleg 2-3 Catalyst verzióval nem működik két GPU-val.
(#96) LordX: Csak az a kérdés, működik-e OpenCL környezetben az, hogy más drivere van a CPU-nak és a GPU-(k)nak...
#95 dezz nagyúr Dr. Akula #93

Új Válasz 2011-06-16 18:37:27 #95
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

dezz

nagyúr

válasz Dr. Akula #93 üzenetére

Szerintem tesztelik, csak az nem várható, hogy kimondottan rá is optimalizálják a CPU-s részt Intel procikra.
(#94) lenox: Ez nagyon gerinces, hogy folyamatosan a konkrét (mint program-cím) példán pattogsz, de messziről elkerülöd a válaszadást az idézett mondatrész folytatására... (Mellesleg 1-1 tévedésedet sem igyekszel elismerni.)
"Az integraltsag elonyet akarod bizonyitani meg mindig. Nyilvan akkor olyan rendszerhez kell hasonlitani, ami hasonlo tulajdonsagu, csak nem integralt."
Természetesen!
"Amugy a cpu magaban 21.6 MPix/s-et tudott, de ebbol csak 7.6 maradt meg... Nekem ugy tunik gatoltak egymast, de akkor magyarazd meg, ha nem."
Sajnos nem szerepel ott CPU + diszkrét GPU eredmény, hogy legyen mihez hasonlítani. De nyilván csökkenti a CPU teljesítményét, ha a GPU dolgoztatásával is foglalkoznia kell. Nem mintha ez itt megint egetrengető lassulást okozna...
"Nem gondolom ezt"
Akkor miért vonsz le ilyen irányú következtetést?
"ez a kozos memoria bottleneck tema, ami az integraltsag hatranya."
Hogyan bizonyítanád, hogy itt erről van szó?
Az utolsó bekezdésben önmagadnak mondasz ellent, mert pl. a Trinitynél is közös lesz a memóriavezérelő, így szerinted mindenképpen rosszabb választás, mint a különálló CPU és GPU, ami a teljesítményt (akár grafikus, akár GPGPU) illeti.
#92 dezz nagyúr lenox #91

Új Válasz 2011-06-16 15:56:39 #92
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

dezz

nagyúr

válasz lenox #91 üzenetére

Olyan feladatoknál, ahol a CPU és a GPU gyors interakciója és a kellő számítási teljesítmény ugyanolyan fontos, előnyösebb egy APU, mint egy diszkrét GPU vagy a proci önmagában, AVX-es kóddal. Ezt csak nem tagadod...!? Az már más kérdés, hogy milyen alkalmazásban fordul elő ilyen feladat.
"Hat igen, ha ket gpu van a rendszerben, az gyorsabb lehet, mint ha egy."
Nyilván nem ez volt a lényeg...
"Teljesen lenyegtelen, hogy abbol az egyik a cpu-val egy lapra van integralva"
A fenti esetben nem -- ha kellően gyors (kis késleltetésű és elegendő sávszélességű) a CPU és a GPU közötti kommunikáció.
"Legyszi ird le a peldakat, amikor vgaval nem megy, ellenben apuval igen."
Már többször is meghatároztam, milyen esetekben tud döntő tényező lenni és példát is írtam.
"Melyik is volt az?"
#56?
"Amikor a llano csak gpu-val kb. ugyananolyan eredmenyt ert el, mint cpu+gpu-val"
Már ha a 348,4 és 356 közötti 7,5 GFLOPS neked semmi...
"de mindketto alatta volt az ugyanannyi sp-t tartalmazo, ugyanolyan sebesseggel jaro diszkret vga-s eredmenynek?"
Milyen érdekes, hogy az előzővel ellentétben a 356 és 359,9 közötti 3,9 GFLOPS itt mekkora jelentőségűvé válik... Hát tudod, itt most számszerűen kijött, hogy nem ugyanazzal a mérleggel méred a neked tetsző és nem tetsző dolgokat...
BTW, a 348,4 és 359,9 közötti, ~3%-os különbség sem nevezhető éppen egetrengetőnek...
"Ezt nem inkabb neked kene tudomasul venni, hogy hoppa, semmilyen elonnyel nem jar, ha osszeintegralod oket?"
1. Szerintem mosd ki a szemed, mert belement valami...
2. Miből gondolod, hogy ebben a tesztben olyan feladat van, aminél kulcsfontosságú a kettő közötti kommunikáció?
3. A Llano csak az első lépés ebben az irányban, de te az egész APU koncepció létjogosultságát kérdőjelezted meg.
#90 dezz nagyúr Dr. Akula #89

Új Válasz 2011-06-16 13:46:23 #90
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

dezz

nagyúr

válasz Dr. Akula #89 üzenetére

Az Intel OpenCL drivere egyelőre CPU-n fut.
Nem ismerem az OpenCL-t töviről-hegyire, de csodálkoznék, ha nem lehetne minden cuccnak saját OpenCL drivere. Tehát, ha pl. csak akkor működhetne együtt Nvidia és AMD GPU (vagy épp Intel CPU + AMD GPU), ha mindkettőnek ugyanazt a drivert használja (amilyen nyilván nem lesz, ami az első esetet illeti)...
Szerintem az APU-knál arról van szó, hogy adott esetben előnyösebb az összegyúrt driver (ami a GPU-t és a CPU-t egyben kezeli), mint a különállók.
#88 dezz nagyúr lenox #84

Új Válasz 2011-06-16 12:48:23 #88
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

dezz

nagyúr

válasz lenox #84 üzenetére

Nézd, a SandyB esetén én fejeztem ki kételyemet a számítási teljesítményhez képesti fele olvasási és negyede írási L1D sávszélességgel kapcsolatban, akkor ti gyorsan megmagyaráztátok és végülis bizonyítottátok (legalábbis az olvasást illetően), hogy ez nem gond.
Most viszont úgy próbálod beállítani, hogy mintha a Llanonál egész más lenne a helyzet (GPGPU-s felhasználást illetően is), pedig teszteredmény bizonyítja, hogy egálban lehet a neki megfelelő diszkrét változattal. (Figyelmedbe ajánlanám, hogy az IGP-ben lévő cache ugyanolyan sávszélekkel rendelkezik, mint a diszkrét változat esetén.)
Az lehetséges, hogy egy jóval több SP-s GPU-val nem tud versenyre kelni, azonban adott esetben igen sokat dobhat a teljesítményen, ha egy sok-SP-s GPU mellé tesznek egy ilyen APU-t, ami bizonyos feladatokon a CPU-val közelebbi együttműködésben dolgozik.
Mindez desktopon -- mobil volalon nagyon sok esetben nem lesz diszkrét GPU.
"azt allitottam, hogy a kommunikacio esetleges gyorsasagat nemigen fogja tudni semmi kihasznalni (mivel a cpu - pcie - gpu rendszerben is mindig probalja az ember elfedni)"
Csak nem mindig sikerül...
"tehat csak az a hatrany fog kijonni, hogy a cpu es gpu kozos lassu memorian osztozik. Es lam a tesztek is pont ezt mutatjak, milyen meglepo."
Egyelőre itt én hoztam fel teszteredményt, ami éppen hogy az ellenkezőjét mutatta. A meglepő az, hogy nem veszed tudomásul...
#82 dezz nagyúr lenox #80

Új Válasz 2011-06-16 03:32:15 #82
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

dezz

nagyúr

válasz lenox #80 üzenetére

Ejj, ejj, mintha nem tudnád, hogy a GPU-k (maiak sem) nem igazán szeretik az ugrásokat, amik a CPU-knak viszont meg sem kottyannak... Ennek kihasználásához mindössze olyan feladatok kellenek, amiknek egyes lépései komplikáltabb algoritmusok, más lépései pedig egyszerűbb, de számításigényesebbek. Ne mondd már, hogy ez annyira egzotikus dolog lenne!
Nem is kell messzire menni, vegyük pl. a a ray-tracinget: van benne rengeteg adaton, de egyszerűbb és jóval kisebb adathalmon, de jóval bonyolultabb számítási feladat is. (De szerintem ezt nem kell neked magyarázni. Vagy ha mégis, később majd meglátod, ha továbbfejleszted esetleg azt a kis OpenCL-es ray-tracert...)
Az AVX-ből, mint megbeszéltük, ilyen 200 GFLOPS körüli (vagy alatti) értékeket lehet kihozni SandyB-n és az IvyB sem lesz sokkal előrrébb. Ehhez képest a Llano IGP-je 4-500 GFLOPS-os, ami azért mégis csak 2-2,5x annyi. Bár még nem derült ki, milyen gyors lehet a kommunikáció a CPU és a GPU között.
"ugyhogy pontosan akkor lehet majd ebbol igazi elonyt kovacsolni, amikor az integralt cpu es gpu kozos cache-sel fog rendelkezni. Az meg nem most van."
Nocsak, nocsak! Eddig az egész APU koncepciót értelmetlennek mondtad (és még a mondat első fele alapján sem ilyen befejezésre számítana az ember ), ehhez képest előrelépés, hogy bizonyos feltétekkel már tulajdonítasz neki némi létjogosultságot.
Mindegy, ezek csak az első lépések, a jövő a sokkal komolyabb integrálás, összegyúrás, közös regiszterkészlettel, stb.
#79 dezz nagyúr lenox #63

Új Válasz 2011-06-15 23:17:55 #79
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

dezz

nagyúr

válasz lenox #63 üzenetére

+Raymond:
1. Az A8-3500M egy mobil chip, 1,5 GHz CPU és 444 MHz GPU órajellel. Így talán nem csoda, hogy az ugyanannyi s.p.-vel rendelkező HD5570 444 MHz-en van egálban vele... Később majd lesznek tesztek desktop A8-3800/3850-nel is, szerintem igen közel lesz az 5570-hez OpenCL-ben.
2. Tisztázni kellene, mi a gyenge közepes. Szerintem nem kapásból HD5xxx-en belül kellene nézni, mert a piacon van még rengeteg korábbi generációs kártya is, ahol is a középosztály alja lejjebb volt még.
"Erre mondj mar legyszi egy valos peldat, mert mindig felhozzatok, de a gyakorlatban valahogy en meg nem lattam ilyet, csak a fusion marketing szovegben."
Nem hiszem, hogy ne tudnál elképzelni olyan helyzetet, amikor nem optimális a nagyobb csomagok cseréje a CPU és a GPU között, hanem kisebb csomagok jóval gyorsabb cseréjére van szükség.
(#64): Előtte is, utána is láttam több-GPU-s eredményeket, szal szerintem átmeneti bug lehetett.
#58 dezz nagyúr Dr. Akula #57

Új Válasz 2011-06-15 05:37:34 #58
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

dezz

nagyúr

válasz Dr. Akula #57 üzenetére

Azt a részt én egy kicsit erősnek tartom. Nyilván nem fogják a végletekig optimizálni Intel CPU-kra, de szerintem abban nem érdekeltek, hogy egyátalán ne fusson, mert az az OpenCL-nek is keresztbe tenne és az ő nimbuszukat sem növelné. Azt sem árt szem előtt tartaniuk, hogy egyelőre mégis csak az Intel a domináns CPU fronton, és még mindig jobb, ha AMD VGA-t tesznek mellé.
De amúgy is botorság, hogy csak annyit érne, hiszen az OpenCL nyílt szabvány, nincs az AMD-hez kötve, előbb-utóbb az Nvidia és az Intel is előáll a hivatalos, nem beta 1.1-es drivereivel. (Már ami az x86(-64) platformot illeti, mert máshol is van OpenCL.)
"Ismerve a jelenlegi AMD procik "csodálatos" teljesítményét az Intelhez képest"
Ne zavarjon, hogy ezzel az előző gen. Intelt is lesimfölted. Fölösleges állandóan ilyen bicskanyitogatóan fogalmaznod. Már ha nem ebben leled minden örömödet -- akkor csak rajta, nem akarom ez is elvenni tőled...
#56 dezz nagyúr Abu85 #15

Új Válasz 2011-06-15 05:10:02 #56
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
Privát üzenet küldése

dezz

nagyúr

válasz Abu85 #15 üzenetére

Ha egy program fel van rá készítve, hogy több GPU device-t használjon, akkor több GPU-t fog egyszerre kihasználni. Bár remélem, valahogy meg lehet különböztetni az APU-t a diszkrét GPU-tól, mert ugye komoly előnye tud lenni a shared memóriának.
(#31) lenox: "Szoval opencl-ben megveri a llano az sb-t, de egy gyenge kozepes grafkartyatol mar kikap."
Gondolod?
Nyilván a 400 s.p.-jével nehezen lenne erősebb egy 800 s.p.-snél. Ez persze feladatfüggő is, valahova a max. throughput kell (kevés számolás -- sok memóriaművelet), máshol meg a számítási teljesítmény dominál. És vannak olyan feladatok is, ahol a CPU és a GPU közötti gyors kapcsolat is kiemelten fontos.
Eléggé nem mellékes, hogy eddig a legtöbb átlagos gépben ez a teljesítmény és feltételrendszer sem volt adott. A Llano remélhetőleg jelentősen hozzá fog járulni ezen arány javulásához, ami elősegíti az erre épülő szoftverek mind nagyobb számban való megjelenését, ill. a meglévők "feltorbózását".