- Háromféle processzor is része lesz a Core 200 sorozatnak
- Milyen billentyűzetet vegyek?
- Gaming notebook topik
- Milyen processzort vegyek?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- BIOS topic
- HiFi műszaki szemmel - sztereó hangrendszerek
- Hobby elektronika
- Azonnali alaplapos kérdések órája
- Vezetékes FÜLhallgatók
Hirdetés
-
iPaden is vége az App Store monopóliumának
ma Ősztől lehet alternatív alkalmazásboltból telepíteni az EU tagállamaiban.
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
-
Megbírságolták a Razert a Zephyr maszkok miatt
ph A cég elég olcsón megússza az ügyfelei félrevezetését, de az üdvözlendő, hogy az Egyesült Államok hatóságai nem siklottak el az ügy felett.
Új hozzászólás Aktív témák
-
Sinesol
veterán
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. -
LordX
veterán
Már a 2014 R1 is támogatta a SPIR 1.2-t, igaz csak béta státuszban.
-
-
stratova
veterán
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 ]
-
Sinesol
veterán
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 ]
-
Sinesol
veterán
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 ]
-
-
Abu85
HÁZIGAZDA
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.
-
Sinesol
veterán
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 ]
-
LordX
veterán
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.
-
Sinesol
veterán
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 ]
-
Goblin12
őstag
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.
-
Cathulhu
addikt
É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
-
Sinesol
veterán
Amit leirtál az lesz a jövő, az igp-t eddig is csak azért használták grafikára mert egyrészt nem volt meg a szoftveres környezet, másrészt hardveresen is csak most jutottak el odáig hogy valóban működőképes legyen a dolog /megosztott memóriakezelés/
Az apu mint koncepció is azért született meg, mert a sima x86 architektúra lassan eléri a határait, már nem lehet hatékonyan növelni a számítási teljesítményt, ezért bevonják a buliba a gpu-t is.
Az apu a cpu-t váltja le, erre született, így is kell kezelni egy komplex központi egységként. Grafikára meg ott lesz a dedikalt vga.Ha az intel broadwell kijön akkor mind2 nagy gyártónak lesz teljesértékű apu-ja a piacon, így már csak a fejlesztőkre kell várni, tehát lassan elhárul minden akadály.
Letiltott igp csak eddig volt, mert független részegység volt a Cpu mellett. A közös memóriakezeléssel viszont már nem lesz se IGP se CPU, csak egy közös egész ami az APU.
-
Sinesol
veterán
Hát, végülis a megosztott memóriakezelést, amire leginkább szükség van, azt a Broadwell is tudja majd.
A platformszintű atomi utasítások támogatását valóban a Skylake hozza el, végülis szigorú értelemben véve az tekinthető teljes értékűnek, igazad van.
Viszont egyelőre az kevésbé fontos dolog, azok a dolgok amelyekre ma szükség van, benne lesznek a Broadwellben. Mire a platformszintű atomi utasításokat rendesen kihasználják el telik még pár év, szoval nem jelent hatranyt egyelőre.[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
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.
-
Jack@l
veterán
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ó.
-
Abu85
HÁZIGAZDA
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.
-
Jack@l
veterán
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ó.
-
lenox
veterán
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....
-
LordX
veterán
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.
-
LordX
veterán
Egyébként ez a "nem fog skálázódni" is.. hát, hogy mondjam.. túlzás.
Igen, nem fogod megkapni az elméleti teljesítmény 100%-át. Egy nem-hülyére, de megfelelően optimizált kódon, minden OpenCL hardveren könnyen, gyorsan el lehet érni az elméleti teljesítmény 2/3-3/4 részét. Nem (csak) én állítom ezt, Bristoli egyetemen erre jutottak: link. (szlájdok jobb fent).
És ha csak 75%-ot kapsz, akkor mi van? Ez még mindig egy nagyságrenddel több, mint amit a processzorral kapsz.. Egy Python és JavaScript és társai vajon mennyit hoz át? 10%? Használják az emberek? Igen. Csak az optimalizálás mértékétől lesz gyors egy program? Nem, egy buta algoritmus sokkal, de sokkal többet tud rontani.
-
Diocles
aktív tag
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.
-
Abu85
HÁZIGAZDA
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.
-
Abu85
HÁZIGAZDA
Elméletben elfogadható, hogy az egyik hardverre optimalizálva van, míg a másikon 20%-kal csökken az elméleti optimalizáláshoz viszonyított teljesítmény. A gyakorlatban viszont ez mindig vitát eredményezett. Főleg az Intelnél, amely cég mindent megtesz azért, hogy az OpenCL fejlesztők kedvébe járjon, abszolút dokumentálja a hardvereit, vannak jó leírások, és a programozók az AMD-t célozzák az optimalizálással.
Lehet mondani, hogy 20% nem sok, de y cég meg fogja kérdezni, hogy miért x-nek adtátok az előnyt, és miért nem kapták meg ők is. Mert amúgy nem olyan nehéz x-re is optimalizálni. Főleg, ha vannak doksik és eszközök hozzá.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
LordX
veterán
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..
-
Diocles
aktív tag
Az én 4 fizikai magos i7-esemen gyorsult 5-szörösen a legegyszerűbb átírással. A magok számát illetően erőfeszítés nélkül skálázódik az OpenCL, legfeljebb ahhoz kell gondolkodni, hogy a vektoros műveleteket is jól tudja használni, de ez GPU-val sincs másként.
Ha már van egy többszálas programod, nincs értelme foglalkozni vele, de ha nincs, OpenCL-lel a legegyszerűbb írni egyet.
-
Abu85
HÁZIGAZDA
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.
-
Abu85
HÁZIGAZDA
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.
-
oraihunter
aktív tag
"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!
-
LordX
veterán
Végre: AMD OpenCL 2.0 driver
-
Jack@l
veterán
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ó.
-
Jack@l
veterán
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ó.
-
Jack@l
veterán
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ó.
Új hozzászólás Aktív témák
- Háromféle processzor is része lesz a Core 200 sorozatnak
- Path of Exile (ARPG)
- Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
- Barimel károsultjai
- A fociról könnyedén, egy baráti társaságban
- Milyen billentyűzetet vegyek?
- Politika
- WLAN, WiFi, vezeték nélküli hálózat
- Gaming notebook topik
- Milyen processzort vegyek?
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest