Hirdetés
-
Igencsak szerény méretekkel rendelkezik az Aetina Xe HPG architektúrás VGA-ja
ph Az 50 wattos modellt beágyazott rendszerekbe, MI-vel kapcsolatos munkafolyamatokhoz és edge applikációkhoz szánták.
-
A személyre szabott reklám lehet a streaming következő slágere
it A jobb célzott hirdetések érdekében adatplatformot indít a Warner Bros Discovery.
-
SMITE 2 - Napokon belül indul a zárt alfa teszt
gp Több mint egy tucat karaktert próbálhatnak ki a szerencsésebbek, a teljes listát a május első napján esedékes streamben árulják el.
Új hozzászólás Aktív témák
-
#11
Meteorhead
aktív tag
arn
#9
Meteorhead
aktív tag
Amikor megláttam a címet, azt hittem rosszul látok. Mondjuk én is hiszem ha látom, de valamilyen szinten sokan jósoltuk már, hogy be kell adniuk a derekukat.
Egyébként én sosem mondtam, hogy CUDA pfujpfuj. A CUDA az NV Mantle-je GPGPU fronton. (És felejtsük el egy pillanatra, hogy CUDA már akkor is volt, amikor Mantle még kósza gondola sem volt.) AMD sem kukázza OpenGL-t, csak azért mert van Mantle. És NV se kukázza OpenCL-t, csak azért mert van CUDA. Mindenki írja meg a drivert a közös, szabványos API-kra, és fejlesszen egy sajátot azoknak a tőkeerős cégeknek, akik megengedhetik maguknak, hogy 2-3-4 API-ra is megírják a compute-render back-endet. De az akadémiai szféra (lásd GROMACS) jellemzően nem ilyen.
-
#25
Meteorhead
aktív tag
lenox
#22
Meteorhead
aktív tag
Akkor elmondom, hogy én mivel találkozom. Kb másfél éve (amióta triviális, hogy nV úgy ott hagyta OpenCL-t, mint eb a Szaharát) minden létező konferencián, fórumon, kutatóintézeti kapcsolatokon keresztül kérdezgetem, hogy mégis mi a fészkes fenét csinál nV OpenCL fronton.
Egy éve kaptam továbbítva egy belsős, nem hivatalos e-mailt egy német kutatóintézettől, amiben azt írták nekik, hogy nincs tervben akármilyen OpenCL update a közép-távoli tervekben.
Másfél hónapja egy pisai konferencián egy nV alkalmazott előadást tartani GPU optimalizációkról, természetesen CUDA-only. Kávészünetben beszélgettünk, és ecseteltem neki, hogy az emberi erőforrásoktól szegényes tudományos computingnak miért olyan végtelenül káros ez a buzeráns CUDA-only stratégia. Hivatalos állásfoglalást nem tudott tenni, de azt azért elmondta:
...as for NVIDIA making progress in terms of OpenCL any time soon... don't count on it.
Lehet mondani, hogy a partnereik már egy ideje tudják, hogy lesz valami fejlődés, de a díjnyertes CUDA Professor Partnership programban résztvevő kollégáim, akik szintén ki vannak éhezve OpenCL hírekre, mert 2 év dobták már CUDA-t OpenCL-ért cserébe, ők sem tudnak semmit. Vagy nagyon rossz a PR gépezet (amit kétlek, mert egyedül erről híres talán NV), vagy ez maximum az elmúlt 2-3 hónap fejleménye lehet, és most úgy lengetik a tudományos szoftverek OpenCL portjait a zászlójukon, mintha ők találták volna fel a spanyol viaszt, pedig nagy fa**t. Miattuk olyan tetű nehéz hordozható számolásokat csinálni.
-
#33
Meteorhead
aktív tag
lenox
#27
Meteorhead
aktív tag
Azért akarjuk annyira, hogy OpenCL és nV is menjen, mert minden valamire adó fejlesztő bagázs igyekszik elkerülni a vendor lock-int.
Senki nem tudja megmondani, hogy milyen architektúrák lesznek itt 3 év múlva, de egy szoftvert szeretnénk úgy megírni, hogy az 3 év múlva is használható, vagy legalábbis részeiben használható legyen, és ne kelljen 2 évente egy teljes kódbázist portolni egyik API-ról a másikra. Erre nincs erőforrásunk. Ugyanakkor előfordult már, hogy egyik arc írt egy nV-re optimalizált kódot, kicserélte a Tesla K20-at egy Radeon HD7970-re, és közel kétszer olyan gyors lett a progija. És lehet, hogy jövőre Intel Phi-vel lesz ugyanez pepitában.
Szeretnénk mindig a feladathoz a legjobb hardveren futtatni, ezt viszont csak úgy lehet, ha mindegyik gyártó megcsinálja a házifeladatát.
-
#36
Meteorhead
aktív tag
lenox
#34
Meteorhead
aktív tag
Mi is körülbelül azt csináljuk, amit ti. Úgy fejlesztünk, hogy mindenhol elfusson. Vannak azért generikus adatpárhuzamos optimalizációk, amik a diverz architektúrák ellenére gyorsítanak mindenütt:
+ __local terhelése GPU-n LDS-t használ, CPU-MIC-en pedig cache optimizationnek felel meg.
+ coalesced NV-nek nagyon kell, többiek vagy profitálnak vagy mindegy nekik (AMD-n channel conflict többet számít)
+ az ember annyi built-in intrinsic függvényt használ, amennyit csak lehet
+ ha van hordozható extension valamihez (cl_khr_extended_atomic_int32) akkor használja az ember, mert nagyságrendeket tud gyorsítani __global atomicon AMD-n például.
Sima OpenCL valóban egy fos, ebben igazad van. Mi ezért utazunk SYCL-ben, de miután SYCL is, és linuxon C++AMP is OpenCL-re dependál, ezért amíg nV-nek nincs SPIR fordítója, addig kiesett a játékból. Egyébként osztom a véleményed, ami OpenCL-re van megírva, azt hordozhatónak tekintem. Amíg nincs zöld implementáció, addig egyszerűen unsupported-nek van titulálva. Csak bosszant, hogy saját magukat szabotálják el, mert ezzel az én piacom is csökken. Nem tudok zöld gépeken futtatni.
Nálunk többnyire mindenki a saját notebookján fejleszt, tesztelni a klaszterünkben lévő mindenféle vason szoktunk, és ha stabil a számolás, több gyártó implementációjával is ugyanaz az eredmény, akkor 100 iteráció helyett 10.000.000 iterációval rátoljuk a nagy klaszterre, ami Radeonokkal van kitömve.
Most egyébként egy olyan libet fejlesztünk, ahol lesz minden feature-nek egy generikus implementációja, ami ezeket az ökölszabályokat veszi figyelembe, és ha marad kapacitás, akkor a program egyes részeihez meg lehet írni az architektúrákra optimalizált változatot is. Az egyikkel az elméleti kapacitás ~60%-át lehet elérni, a másikkal ~75%-ot. De ezért a 25%-os sebesség növekedésért első körben nem éri meg izzadni.
Új hozzászólás Aktív témák
ph A konkrétumok még nem nyilvánosak, de a már lezajlott SC14 rendezvényen több érkező fejlesztésre is utalt a cég.
