Ez az inteles fejlesztőkörnyezet főleg a saját architekturájuk mellett érzi majd jól magát?
Mert ez igy érdekes lesz, a Hsa igazabol kb sehogy se halad, nemsok hajlandoságot mutatnak a fejlesztők, Az intel viszont most sem a levegőbe beszélt, a progik is jönnek majd, mivel itt ugye az intel kéréséről van szó...tehát kb parancs.

Már a 2014 R1 is támogatta a SPIR 1.2-t, igaz csak béta státuszban.

GPU oldalon csak saját hardvert támogat.

CPU oldalon meg nem sok értelmét látom az OpenCL-nek; arra jó, hogy már most el lehet kezdeni OpenCL 2.0-ra fejleszteni, amíg várod, hogy az AMD / nVidia / ARM / Qualcomm / stb. kiadja a saját OpenCL 2.0 drivert.

Gondolom mivel a piac CPU >80%-át urajla a cég [és így az ő lapkájával kel el a legtöbb GPU is], komolyabb OpenCL fejlesztés tán most fog beindulni. Hogy hogyan muzsikál AMD vason az engem is érdekelne.GCN főleg GPGPU-ban gurított nagyot a korábbi megoldásokhoz képest.
Core M 24 EU-t kapott, de legutóbbi hírek szerint Broadwellben 48 Skylake-ben 72-re van kilátás.

Techreportnál LuxMarkban Haswell i7-4950HQ (40 EU) sem volt gyenge, cserébe eddig nagyon ritka és drága.

A lényegesen olcsóbb (bár összességében nem túl olcsó) A10-7800 náluk így muzsikált

Ők még régebbi verzióval vagy más beállítással mérnek? PH-n A10-7800/7850K és i7-4770K is jobban muzsikál GPU-ban.

[ Szerkesztve ]

Ez az egész a nextgen APU-kat érinti, ne keverjük ide az nvidiat, meg a többi armos cuccot, azoknak sok közük nincs ezekhez a dolgokhoz.

Már ugy értem hogy csak saját gpu-t támogat az nem tul jó hír. Hiába ad ki más is OpenCl drivert, nagyon jol tudjuk kinek a fejlesztőkörnyezetét fogják használni a fejlesztők és mire fognak optimalizálni.
A Hsa például bőven jobb is, az Amd oda is rakta a hardvert mellé, mégse érdekel senkit, mert az Intel más irányt akar.

Van egy olyan érzésem az APU korszakban se az Amd fog jól járni, hiába járnak/jártak élen technikailag

.

[ Szerkesztve ]

Ezt mégis hogy gondoltad? Egy darab olyan gyártót nem fogsz találni, aki más gyártó hardverét támogatja a fejlesztőkörnyezetben. Maga a kód ettől még futni fog, ha nem használsz olyat, amit a másik nem tud.

Ez egyértelmű, de ha az intel megoldásaira van optimalizalva egy adott program akkor azon az architekturan fog a legjobb sebességgel menni. Gondolom olyan sok erőforrást nem fognak abba ölni, hogy a kisebbség hardvereire optimalizaljanak. Na meg kérdés hogy ki fog a Hsa-ra nagyobb munkát forditani, amikor az opencl ugyanugy jo az amd-n is...

[ Szerkesztve ]

Ha valami Intelen fog futni az elméleti teljesítmény 90%-ával, és az AMD-n fog futni az elméleti max 75%-ával, akkor még mindig 3x lesz gyorsabb az utóbbi. Amíg tényleges teljesítményben nem kerül az AMD közelébe az Intel, addig nem aggódom értük.

Senkinek sem mondja az Intel, hogy ne optimalizáljanak a többi OpenCL-re. Mindenki adjon ki hozzá SDK-t és kész.

A HSA nem ide tartozik. Az csak lehetővé teszi a magas szintű GPGPU kódot, vagyis azt, hogy a kódod teljesítménye portolható legyen az architektúrák között. Nagyon sok OpenCL alkalmazás azért fut sokkal jobban Radeonon, mert arra van írva a low-level kód, és a többi architektúrára a futtatás portolható, de a teljesítmény már nem. A HSA ezt a gondot oldja meg.

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Ha egy cég ilyen közel monopol szinten lefedi az x86 piacot, akkor mennyi az esélye hogy jelentős erőforrást fordítanak a fejlesztők arra hogy más cégek Sdk-it is kellően megismerjék, kellően optimalizalt programokat irjanak?
Nem áll fenn a veszély, hogy a nagy kékre megirják alaposan, a kisebbekre meg összedobnak valamit?

[ Szerkesztve ]

Nem azért, de vedd már észre, hogy hülyeséget szeretnél.

Intel hardveren Intel SDK-t kell használni, mert másikkal nem megy. AMD hardveren AMD SDK-t kell használni, mert másikkal nem megy. Úgy hogyan optimalizálsz valamire, ha nincs meg neked?

Nem azért fogják Intelre dolgozni a népek, mert nem ismerik az AMD megoldását, hanem mert nem használ a célközönség AMD-t. Egyébként az AMD SDK a diszkrét grafkártyákat is támogatja, szóval Intel processzor mellett is használják.

Hát mind1 lehet tényleg tul sok mindent magyarázok bele

De amugy az volt a hírben, hogy a cpu-nak altalanos szamitasokban segitsen be, ezért gondoltam en inkabb az Apu-k szempontjabol végig. Oké hogy diszkrét vga-k is támogatják, de ott azert mégsem lehet teljes az összhang , elég nagy a pci-ex késleltetés és közös memoriakezelés sincs.

[ Szerkesztve ]

Szerintem ti már nagyon belebolondultatok ebbe, ebben a topikban is meg a másikban is. Szerintem fussatok egy kört vagy ússzatok vagy valami.

Én mondjuk nem látom akadályát annak, hogy legyen egy opencl kód a programban az APU számára (legyen az intel vagy AMD) plusz a számításigényes grafikát meg dedikált kártya végezné nem opencl alapon. Így legalább a mostanság letiltott igpk is munkára foghatók lennének. Megakadályozza ezt valami?

Ashy Slashy, hatchet and saw, Takes your head and skins you raw, Ashy Slashy, heaven and hell, Cuts out your tongue so you can't yell

Javítsatok ki, ha tévednék, de az Intel első "teljesértékű" APU-ja nem a Skylake lesz?

Jelenleg pont az a helyzet, hogy az AMD APP SDK-ját használják főleg. De ettől még az Intelét is elő kell venni, ahogy a többi gyártóét is.
Az OpenCL esetében csak olyan veszély áll fent, amit ma is látsz. Megírják az AMD APP SDK-re, és a szállított bináris csak az AMD-n fut. Ez ma nem egy programban így van. Jelenleg azon van az Intel, hogy a fejlesztők olyan binárist is szállítsanak, ami náluk is elindul. De egyszerűbb most már a SPIR-re ráterelni a programozókat. Ez a legjobb mód szerintem az OpenCL programok szállítására.

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Felmerül a kérdés, hogy ez a támogat nem támogat dolog nem e hülyeség. Ha én megírok egy opencl kódot, az nagyjából ugyanúgy fog futni procin, gpu-n, vagy bármi egyeben ami opencl-t támogat. Max nem fogom tudni úgy debugolni, totál ráoptimalizálni arra az egyfajta device-ra, stb...

[ 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ó.

Ha ügyelsz arra, hogy betartsd a szabvány előírásait, akkor kompatibilitás szempontjából a kód lefut bármilyen olyan implementáción/platformon, amely támogatja a kódod követelményeit. De a kód teljesítménye már nem fog skálázódni, tehát mindenképp érdemes portolni a kódod teljesítményét direkten a célzott architektúrákra.
Erre a problémára kínál megoldást a HSA az OpenCL kiegészítéseként, ami nem csak a kompatibilitást, hanem a teljesítmény portolhatóságát is biztosítja ugyanazzal a szabványos kóddal.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Ha teszem azt perverz módon van egy intel cpu-m, egy amd és egy nv kártyám, akkor mire fordítsak, ha mindhármat(illetve 4-et) szeretném egyszerre használni egy feladat kiszámolására? Mi - hova nem fog skálkázódni?

[ 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ó.

Nekem amd es nv kozott windowson egesz jol szokott menni, mac-en amd-n ennek ellenere dobja a hibakat meg a warningokat, intel cpun ritkan probalom, de az menni szokott, intel igp-n viszont generaciotol fuggoen ez vagy az nem mukodik, vagy mashogy. Szoval meg kell nezni minden platformon, aztan oda valo kodot fejlesztenu.

Amugy az uj 18 magos xeonok eleg jok opencl-re kozos memoriaval....

A kérdés ugyanaz, mint: "van egy x86-os, egy ARM és egy MIPS processzorom, mire fordítsak".

Semmire. Az OpenCL bináris nem hordozható. Vagy belerakod a programba a forrást, és on-the-fly / programindításkor fordítasz, vagy azt csinálod, mint a Java: Fordítasz bájtkódot (ez a SPIR az OpenCL esetében), amit az adott hardver saját runtime-ja majd szépen lefordítja a kártya saját utasításkészletére.

Bravo. Jól sejtem, hogy az Intel végül csak megelőzte az AMD-t az OpenCL 2.0 kiadásában? Nem az SDK itt a lényeg, hanem a 2.0 kompatibilis driver meg hardver.

Az SDK-kon meg a mások hardvereinek támogatásán való fennakadást nem értem. Az OpenCL-nek az a lényege, hogy nyílt szabvány, és a megírt programok bármilyen platformon működhetnek. Az OpenCL kódot nem a fejlesztő fordítja, hanem a felhasználó, a fordító az eszközmeghajtóban van benne.

A fejlesztéshez egyáltalán semmilyen SDK-ra nincs is szükség. Khronos oldaláról leszeded a header fájlokat, meg linkeled a .lib-et vagy .dll-t, amit mindenkinek a saját CPU vagy videokártya drivere fog felpakolni a rendszerre.

Megjegyezném, nekem eddig is a Intel SDK-ja tetszett a legjobban, az volt legkönnyebb elkezdeni a fejlesztést, és a kész program mint említettem mindenen futott ami az adott szabványszintet támogatta.

(3) LordX: Van értelme. 4, 8 meg 16 magosak már a konzumer processzorok is. OpenCL-lel a legegyszerűbb kihasználni őket. A naivan megírt OpenCl kód 4-5-ször gyorsabb a naiv egyszálas C kódnál egy i7-esen és nem nehezebb megírni. El lehet felejteni az Boost-ot, OpenMPI-t, AVX intrinsiceket.

A Kaveri APU-hez és a Hawaii GPU-hoz április óta van tesztplatform, ami támogatja az OpenCL 2.0-t.

Ez az OpenCL elmélete. A gyakorlat pedig az, hogy írsz egy kódot, és vagy fut vagy nem. A kódot szállíthatod úgy, hogy a driver fordítsa, de ilyenkor ki van téve a működés a fordító fejlesztéseinek. Tehát előfordulhat, hogy az egyik driverrel jó a kód, míg a másikkal nem. Ezért vált szokássá manapság binárist fordítani, mert így kicsi az esélye, hogy a program ne fusson, viszont célozni kell a megjelent hardvereket és frissítésekkel hozni a támogatást az újakra. Az ultimate megoldás a SPIR, amivel a fenti két probléma megoldható. A fejlesztők szempontjai szerint is a legjobb szállítási forma az OpenCL-re.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Publikusan nincs se a Kaverihez se a Hawaiihoz OpenCL 2.0. A Kaverihez egy OpenCL 1.2 + néhány (!) OpenCL 2.0 feature van, és az is csak az egyik chippel, és egy adott Asus alaplappal, custom BIOS-al (!) működik. Ja, és ma 404-et ad az összes link rá (ezért nem tudom megnézni melyik OCL2 feature és melyik chip).

A Hawaii chiphez való runtime témájában meg akkor állnak veled szóba, ha vettél egy FirePro-t, R9 290-el nem. 10x annyi pénzt keveseknek éri meg, hogy tesztelhessenek egy béta drivert..

Publikusan nem tudnád használni, az OpenCL 2.0-s meghajtója az AMD-nek a HSA-ra épül, tehát nem AMDIL-t, hanem HSAIL-t használ, illetve ehhez olyan BIOS-ok kellenek, amelyek még nem érhetők el. Ha letölthetővé teszik, akkor is kell az a tesztplatform, amit szállítanak igény esetén.

Tesztre az az ASUS HSA-platform a legolcsóbb. Átlag embernek azt érdemes rendelni FirePro helyett. Abban működik a C11 atomi operáció gyorsítása is.

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

A teszthardveren béta driver vs. kereskedelmi hardveren release driver - még mindig pár utcahosszal nyerte az Intel ezt a kört.

Nekik nagyon muszáj ezt megnyomni, mert ma senki sem optimalizál rájuk. Nem egy olyan OpenCL program jelent meg az elmúlt három hónapban, amely csak AMD-n fut. Holott akadálya nem lenne annak, hogy Intelen is elinduljon, csak a bináris amit szállítanak nem támogat mást az AMD hardverein kívül. Ha ezen változtatni akarnak, akkor muszáj a fejlesztők kívánságait lesni.
Ki kell építeni azt a bizalmat, amit az AMD kiépített magának a fejlesztők körében. Ennek az egyik legjobb módja a fejlesztőkörnyezet agresszív fejlesztése.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

"Az Intel szerint" óvatos megfogalmazás!

oraihunter felhasználónak 381 pozitív és 0 negatív értékelése van a fórumon! Ha sürgős, akkor az adatlapon a telószám (06-30-293-42-53), de számkijelzés nélküli hívást már 21-éve nem fogadunk!

Végre: AMD OpenCL 2.0 driver

Azza baj, hogy ez még mindig a 14.4-es driverre alapoz, ha jól látom a verziószámból.

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

Az a legutolsó nem-béta release..

14.7 is rc3-nál jár.

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

UI: felraktam, de valamiért csak ilyen c++ runtime-ot, meg install managert meg ilyeneket akar felrakolni a 7970-emhez, magát a vga drivert meg control centert nem nagyon...

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

Még nem próbáltam, épp használja munkatárs az AMD-s devel gépet (otthonra meg nem fogom feltenni, mert minek).