- Milyen videókártyát?
- Vezetékes FÜLhallgatók
- OLED TV topic
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Kompakt vízhűtés
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Vezeték nélküli fejhallgatók
- Milyen házat vegyek?
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- Amlogic S905, S912 processzoros készülékek
Hirdetés
-
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...
-
Olcsó 5G-s ajánlatot nyújt a Realme Indiának
ma Megérkezett a Realme C65 5G, az első készülék a MediaTek Dimensity 6300-zal.
-
Ülésezik a hardveregylet
ph Az irodai készülékek és monitorok társaságát egy ház, egy egér és egy DAC egészíti ki.
Új hozzászólás Aktív témák
-
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.
-
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.
-
vicze
félisten
Legfőképp telejsítmény+support nem csak nV részéről, hanem hogy valaki meg is építi azt az adott méretben. Tehát nem egy 1db "mezei" W9000 hanem 20db egybekötve egy kész rackben. Ilyen volt a FireStream és most ilyen a Fire S, de közte 4 évig semmi. Közben a nV meg elég csúnyán betolta a Teslát ebbe a szektorba. A váltás meg sok zöldhasúba kerül. Ráadásul a Fire S mocsok drága a Teslához képest teljesítmény arányosan.
Amire ti használjátok, ha jól sejtem az az nV-nél a Quadro és nem a Tesla.
-
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.