Csodás, már csak 300 év, és az Nvidia ad hozzá drivert. Egyébként egy float atomic_add jöhetett volna...

lesz*rom az nvidiát, csak csináljanak már az OpenCL-hez egy rendes, aktualizált, dokumentált .NET wrappert... iszonyat mennyiségű kódom áhítozik OpenCL-esítésre...

SC2: KillerJohn#634, D3: KillerJohn#2359

Ez jó hír, remélem majd ír valaki OCL-re egy remek fizikai motort

...az ár/érték arány a vesztesek mentsvára :D

Lehet hülye kérdés de ebből a - ha jól értem, heterogén programozási modellből mikor lesz a gyakorlatban is használható alkalmazás,program?

Mondjuk a mostani rendszermeghajtómon ami egy ssd, mikor lesz olyan vírusirtó ami mondjuk a szokásos 10-50-100 fájl/sec scannelési időt "felturbózza" olyan 500-1000-5000 fájl/sec-re a vga számítási kapacitásának a segítségével? (a számokat csak hasraütés szerűen írtam)

Thx!

Semmi sem állandó, csak a változás.

Nem tudom milyen jellegű kódokról van szó, de sajnos egy wrapper nem sokat segít a legnagyobb problémán, ami a SIMD programszervezés. Az optimalizálást meg is nehezítheti.

Úgy érted, hogy a gyakorlatban általad használható?

Már kismillió alkalmazásban használják, de várhatóan mindig több olyan feladat lesz, amit nem érdemes GPU-n futtatni, mint amit igen. Ami a vírusírtót illeti, egyrészt kérdés, hogy a számítási teljesítmény-e a szűk hatáskeresztmetszet, vagy az SIMD olvasási sebessége, netalán a memóriasávszél. Processzorhasználatból lehet erre következtetni.

Másik kérdés a párhuzamosíthatóság: nem ismerem a vírusírtók algoritmusait, úgyhogy nem tudom megtippelni, hogy tartható-e a szál koherencia, lehet-e latency hidingot csinálni, stb. Nem annyira egyszerű kérdés.

talan a harmadik GPU Gems-ben volt egy iras, amiben a ClamAV mintailleszto algojat atultettek shaderekre (ha jol emlekszem, Cg-ben irtak), erdemes elolvasni..

in asm we trust

Mikor lesz hozzá nv driver?

Üdv:kte0

Nagyjabol soha. OpenCL-t nem erre talaltak ki.

Ez kb. olyan kérdés, hogy jó, jó de mikor lesz a C++-ból, Javából, PHP-ból (stb.) gyakorlatban is használható program.

Az OpenCL egy programnyelv. Ebből program soha nem lesz. Max olyan program(részlet), amit ebben írtak.

Mondjuk vírusirtónál adná magát különböző fájlokat párhuzamosan szkennelni. Kérdés az IO.

Igen. Kérdés hogy mikor fognak az SDD-k a PCI-E sávszélességén dolgozni (~6GB), ami egyébként jóval lassabb, mint device memory (~140GB).

De ha már itt tartunk a Word-öt kéne GPU-ra átírni...

...mert CSAK!

Úgy látom, hogy vagy félreérthetően fogalmaztam vagy egyesek nem olvasták el alaposan a hsz-emet. Arra gondoltam,h. ezt a programozási nyelvet, modellt stb-stb mikor lehet majd mondjuk általam is használható hétköznapi programok készítésére felhasználni vagy ezt felhasználva mikor fognak hétköznapi felhasználóknak szánt programok készülni, amik ezt a heterogén megvalósítást kihasználják.

A vírusirtó csak egy spontán példa volt ami eszembe jutott. Viszont mi van az olyan hétköznapi átlagfelhasználókkal, akik nem renderelnek, nem konvertálnak videókat, nem futtatnak adatbázisokat a gépükön, nem vesznek részt tudományos programokban stb-stb. Nekik ez a programnyelv mikor és milyen előnyt fog hozni a "hagyományosakhoz" képest?

Vagy ez is csak egy "marketing bla-bla"? Akkor viszont nem értem,h. miért erőltetik annyira ezt a "Future is Fusion" és hasonló dolgokat, ha az átlagfelhasználó ebből semmit sem fog tudni használni, észrevenni? Ez a heterogén programozási mód milyen hasznot fog hozni a hétköznapi felhasználóknak, akik nem valami speciális területen tevékenykednek a pc-jükkel?

Egyébként tudom,h. a php-t a dinamikus weblapok készítésére használják, a C++ pedig az egyik legelterjedtebb programozási nyelv ám még amiket utóbbiban is írnak, azok közül is ritkaságszámba megy ami 1-2 magnál többet használ. (talán ami pozitív kivételt láttam erre az-az Unreal Engine legújabb változata (vagy nem tudom melyiket használták fel pl. a Bioshock-hoz, ebben láttam 4 magot kihasználni vmennyire), ha már mondjuk játékokból keresek példát és nem egyéb "spéci alkalmazásokból"...

Semmi sem állandó, csak a változás.

http://sourceforge.net/projects/opentk/

"As an online discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches 1."

tudom, tudom, de ez még messze nem az "ideális"

SC2: KillerJohn#634, D3: KillerJohn#2359

"Sőt az utóbbi vállalat elmondta, hogy a Fusion APU-k, illetve az ATI Streammel kompatibilis hardverek támogatni fogják a megújult felületet."

streamet támogatnak a hd3xxx-ek is. Akkor ezek szerint végre meg óhajtják csinálni az opencl-t ezekre a gpukra is? Vagy kitalálják hogy ja az nem olyan stream hanem az más?

[ Szerkesztve ]

szövegértelmezés, az ÉRTELMEZÉS a fontos, mert az olvasás mindenkinek megy, de az ÉRTELMEZÉS már komoly probléma a magyaroknál. Gondold ezt át mielőtt marhaságot írsz...

nem hinnem, Stream-kompatibilitas alatt valoszinuleg Stream 2.0 kompatibilitast ertettek..

in asm we trust

Csak az Integrált HD 3000-ek támogatják a Streamet. Az asztali verziók a CAL-t és a Brook-ot kezelik.

Egyébként technikai akadálya nincs a támogatásnak. Inkább az üzleti szempontok miatt nincs engedélyezve a Stream.

[ Szerkesztve ]

A semmi az nem nincs, hanem van. Ha a semmi van, akkor nincs semmi, de ha nincs semmi, akkor valami van, de az nem semmi.

ja a stream mostmár egy nyelv? Eddig még sdk volt, ami támogatta a 3000-ek nyelvét is. Jól átvariálják a dolgokat hogy legyen ürügy miért kell újabb gpu

szövegértelmezés, az ÉRTELMEZÉS a fontos, mert az olvasás mindenkinek megy, de az ÉRTELMEZÉS már komoly probléma a magyaroknál. Gondold ezt át mielőtt marhaságot írsz...

Nem a Stream sosem volt nyelv, csak egy SDK és felület. A CAL volt az alapréteg és arra épül a Brook. Mivel az utóbbit senki sem támogatta, így a CAL megmaradt alaprétegnek, de minden más Open lett, vagyis szabványos platformra váltott az AMD. Ez volt a Stream 2.0 bemutatása. A régi kártyák a Brookot és annak verzióit támogatják. Meg lehetne oldani az OpenCL támogatását is, csak üzletileg hibás döntés lenne.

A semmi az nem nincs, hanem van. Ha a semmi van, akkor nincs semmi, de ha nincs semmi, akkor valami van, de az nem semmi.

Egy Fusion chipben nincs is PCI mögött a GPU

Egyébként ha már Office, egy Excel pl. tudná használni táblázat képleteinek számolásánál a GPUt, ha elég nagy a táblázat, akkor már megérné. Sőt, ha a GPU csak egy L3 cache távolságra van - megintcsak Fusion - , akkor már kis táblázatra is használni tudná. Persze az tök mindegy, hogy 5ms vagy 0.5ms alatt számolja ki a táblát, de ha közben tizedannyi áramot fogyaszt, akkor laptop/netbookba máris jogosultságot nyert a OpenCL-es Excel...

Persze ez most még csak vad fantáziálás.

SIMD jellegű feladat nem csak videokódolásban van, nagyon sok helyen lehet találni, csak kicsit kell keresni: Például játékoknak a grafika mellett a fizika és AI számítások is ilyenek. Fizikára nem véletlen létezik a Physx..

Másik lehetséges példa az előző hozzászólásomban.

Az a baj, hogy a "nem spéci alkalmazások" alatt általában Office-t meg webböngészést értenek. Ha leszámítom a webböngészés során a videónézést és flashjátékot, akkor ezek az alkalmazások már 5 éve sem tudtak egyetlen processzort leterhelni, mivel ezeknél a sebességet a felhasználó inputja határozza meg. Szóval nem szükséges egy párhuzamos számításra kihegyezett programnyelv használata ezekre a feladatokra.

Ez nem fantáziálgatás, már most is van, ahol használják Excelben a GPU-t. Semmi nem akadályoz meg, hogy a plugined GPU-n fusson.

Plugin != Excel. Ilyen alapon a Total Commander meg az MSN Messenger meg a Windows asztal is fut GPU-n (csak tedd fel a plugint, ami minden alapműködést kicserél GPU-s kódra)..

Én inkább a standard beírom a képletet a cellába és a GPU kiszámolja esetre gondoltam.

"(csak tedd fel a plugint, ami minden alapműködést kicserél GPU-s kódra).."
Ez miféle plugin?

Na, lehet, hogy nemsokára letelik a 300 év?