Hirdetés
- Azonnali notebookos kérdések órája
- Nvidia GPU-k jövője - amit tudni vélünk
- AMD Ryzen 9 / 7 / 5 / 3 3***(X) "Zen 2" (AM4)
- Hogy is néznek ki a gépeink?
- RAM topik
- Azonnali processzoros kérdések órája
- TCL LCD és LED TV-k
- Friss adatok érkeztek a Lunar Lake-MX-ről
- Gaming notebook topik
- ASRock lapok általában
Hirdetés
Új hozzászólás Aktív témák
-
con_di_B
tag
Na jo, azer a hiszem ha latom faktor meg mindig eleg eros, ha az NVIDIA-rol van szo.
Meg aztan valami azt sugja, hogy nem egy modern OpenCL 2.0, SPIR-kompatibilis implementacio lesz amit latni fogunk. Egyebkent ha nyitnak, abbol remelem abbol nem lesz valamifele hintapolitika, hogy "oke, vegre a Maxwell mar nem ego, most nyissuk kicsit a piacot, majd visszazarjuk ha megint benak elszunk".
-
LordX
veterán
Már az is nagy előrelépés lesz, ha OpenCL 1.2 támogatott lesz - ki lehet vágni a hülye 1.1-es workaroundokat a kódbázisból, de az 1.2 meg egy jó ideig velünk marad. Az utolsó előtti, a Qualcomm is már váltott 1.2-re (Mondjuk a Galaxy S5-ön nem segít, abban csak az 1.1-es maradt.)
-
vinibali
őstag
akármennyire is vagyok AMD párti és felhasználó, de szvsz ha tényleg ráfekszenek az OpenCL-re, jobb lesz a zöld driver ismét
BIOS/UEFI írás, helyreállítás, törlés, mentés! https://www.bvinarz.org/bios-iras/
-
vicze
félisten
Hm, kezd befagyni a pokol vagy mifene?
[ Szerkesztve ]
-
bandika0626
senior tag
Az Jó lesz ha opencl terén összekapják magukat mert pl sony vegast opencl-én keresztül sokkal jobban gyorsít az AMD mint az Nvidia cuda-n keresztül. Legalábbis én így tapasztaltam mikor 7790em volt most pedig 750TI.
AMD RYZEN R7 1700, Cooler Master MasterLiquid 240, MSI X370 SLI PLUS, Corsair 2x4GB DDR4 3600MHz,Asus dual 1060 3G , Gigabyte GTX 1060 3G , Coolermasters GX 450, WD Caviar black sata3 500GB, SSD samsung 830 64GB.
-
Abu85
HÁZIGAZDA
válasz bandika0626 #5 üzenetére
Ez inkább azért van, mert a Sony a CUDA-ra már nem csinál teljesítmény optimalizálást. Megelégednek azzal, ha képes futni a program CUDA portja.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
bandika0626
senior tag
Hát remélem ezen a driverek segíteni fognak.
Tetszik az aláírásod. Pontosan ezt a szöveget állapíttam meg egyik cimborámmal kb 15évvel ezelőtt.
De szó szerint.[ Szerkesztve ]
AMD RYZEN R7 1700, Cooler Master MasterLiquid 240, MSI X370 SLI PLUS, Corsair 2x4GB DDR4 3600MHz,Asus dual 1060 3G , Gigabyte GTX 1060 3G , Coolermasters GX 450, WD Caviar black sata3 500GB, SSD samsung 830 64GB.
-
LordX
veterán
-
arn
félisten
Vannak olyan teruletek, ahol lenyegtelen, hogy cuda vagy opencl, mert az adott vasra optimalizalnak.
Amugy meg mindig nem ertem, hogy cuda fujfuj, miert akar sajat apit, mantle meg mekkora dobas, es kovetni kene. Ez nem tul kovetkezetes. Amugy pcn maradjanak csak az altalanos apik.
facebook.com/mylittleretrocomputerworld | youtube.com/mylittleretrocomputerworld | instagram.com/mylittleretrocomputerworld
-
Abu85
HÁZIGAZDA
A Mantle egy nyílt specifikációjú API lesz két hónapon belül. Most véglegesítik az egészet úgy, hogy az Intel és az NV tudjon hozzá drivert írni.
Arra is reagálnak, hogy az Intel és az NV fél belépni, mert a fejlesztés az AMD-nél marad és arra viszik tovább, amerre akarják. Ennek érdekében a Mantle 1.0 core specifikáció fixálva lesz, vagyis soha többet nem nyúlhat hozzá senki, és ezzel az aktuális API fejlesztése be is fejeződik. Tehát nem kell attól félni, hogy az AMD gonosz lesz, és bántani fogja a gyártókat. Lényegében OpenGL szintű nyíltságúvá válik az egész 1.0-s specifikáció.
Készül egyébként egy másik Mantle verzió, amely nem lesz kompatibilis a Mantle 1.0-val, vagyis lesz még egy új low-level API-ja az AMD-nek, amit majd fejleszt tovább. Ennek is Mantle lesz a neve egy kis extrával.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
-
HalasKYO
aktív tag
Ennek én csak örülnék, mert akkor VGA-ból végre tudnék AMD-t is venni.
Eddig CUDA-ra volt/van szükségem autodesk szoftverek miatt (főleg V-ray RT), mivel az Open-CL alatt egy GTX 470 el egy kaki.
Remélem így több szoftvergyártó is mozdul a közös platform felé, és nekünk felhasználóknak nagyobb lesz a választás.
De nVidiától azért ez kicsit idegen a gamework-ös húzásai után.
Majd ha letette az asztalra és fél évre rá mindenki kipróbálta és működik akkor elhiszem. De akkor se teljesen[ Szerkesztve ]
Halas - http://www.flickr.com/photos/halaskyo
-
Abu85
HÁZIGAZDA
API-ból származó előnye az AMD-nek nincs és nem is lesz soha. Technikailag nem is lehetséges, mert az API egy specifikáció. Abból származhat előny, hogy megmondják a fejlesztőknek, hogyan kell a GCN-re optimalizálni, míg az NVIDIA ezt eltitkolja a saját architektúráinál. De ez csak egy döntés, és az API semmilyen formában nem befolyásolja ezt. Ugyanez az előny a DX12-nél is fennáll.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Pekkk
aktív tag
Ezek szerint PhysX, Cuda kuka?
-
lenox
veterán
válasz Meteorhead #11 üzenetére
Mar kb. egy eve kerdezgeti az nv a szoftver partnereitol, hogy mit csinalnak opencl-ben, hogyan ertekelik a cudahoz kepest, mit kellene megoldaniuk, hogy jobb nv support legyen. Szoval ez nem egy ujkeletu dolog. Iden mar segitenek is opencl-ben, korabban csak cudaban.
-
con_di_B
tag
Nem az a baj a CUDA-val, hogy letezik, hanem, hogy az NVIDIA nagyon eroteljesen hasznalja vendor lock-in-re, ezen kivul pedig annak van kulturalt szabvanyos alternativaja, az OpenCL (ami kenyelmi funkciokat ugyan nem tamogat azonos mertekben, mint a CUDA, de egyebkent mindent meg lehet vele csinalni).
A Mantle-nek viszont egyelore nincsen szabvanyos alternativaja, majd az DX12, illetve esetleg, talan ha ... az uj OpenGL lesznek azok. Nyilvan azt is hasznalhatna vendor lock-in-re az AMD, az ezzel kapcsolatos mesekben en kevesbe hiszek (mar abban, hogy nem probalja meg, ha megteheti).
A szabadsag, egyenloseg, testveriseg es a nyilt ipari szabvanyok vedelmezese pedig a romantikan kivul nyilvan egyebkent is eleg praktikus, en peldaul eleg boldog lennek egy olyan vilagban, ahol OpenCL mellett lenne egy epkezlab OpenGL valtozat, es ezek mindenhol remekul mukodnenek, valoban jo minosegu implementaciok lennenek mindenhol, mivel masra nem is kene fejleszteni, ezekre lenne kiterjesztve mindenki platformszinu supportja (tehat nem lenne Metal, DX, RenderScript stb.) es osszessegeben az egesz iparag, szoftveres es hardveres oldalon is drasztikus koltsegcsokkenest latna. Ha pedig ezt meg a konzolok is tudnak sajat API-k helyett, az lenne a kanaan. De persze bilibe log a kezem.
[ Szerkesztve ]
-
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.
-
lenox
veterán
válasz Meteorhead #25 üzenetére
En ebben csak azt nem ertem, hogy ha openclezni akarnak, akkor miert nem hasznalnak amdt, ha az nv-vel problemajuk van? Tudomanyos proggynak nem kell minden hardveren futni... Persze ugyanennyi erovel futhatnanak csak nv-n is cudaban. Mi miatt kell mindent tamogatni?
-
Abu85
HÁZIGAZDA
[link] - Itt van. Ez ma az egyetlen gyorsító, ami tud 2 TFLOPS-ot DGEMM-ben. Viszont rohadt drága. Majdnem 5000 dollár darabja, és nem mindenkinek van ekkora igénye, tehát sokan a rég megvásárolt gyorsítót szeretnék csak használni OpenCL-ben. Amúgy persze, ha van 5000 dollár/kártya, akkor nem gond AMD-re váltani, de sok helyen nincs ekkora luxus.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
vicze
félisten
A K80 meg 3TF-t, persze 2 mag, de akkor is no.
Amúgy az AMD most lépett vissza erre a piacra, a FireStream volt előtte, de az is eléggé hanyagolt volt 2010-es az utcsó.
Az utóbbi 4 évben ezen a piacon az nV elég egyeduralkodó lett.AMD inkább a Remote GPU/vGPU-s dolgokban van elöl, a tudományos kutatásokat eddig amennyire látom hanyagolták.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Nem, a K80 még két GPU-val is 1,7 TFLOPS-ot tud DGEMM-ben. Ne a boost órajellel számolj, mert az alapórajellel fog úgyis működni ilyen terhelés mellett. Alapórajellel még az elméleti DP tempó is kisebb az S9150-nél.
Mindig kínáltak ide megoldásokat, nem most léptek be vagy vissza.Itt arról van szó, hogy a felhasználók a hardvert úgy akarják használni, ahogy nekik hasznos. Hidd el, ha be tudnák vállalni, hogy kártyánként 5000 dollárért frissítenek, akkor már rég megtették volna, de ez irtózatos pénz mondjuk úgy 50 kártyával dolgozó szerverben.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
vicze
félisten
-
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.
-
lenox
veterán
válasz Meteorhead #33 üzenetére
Ezt tovabbra sem ertem. Oke, nv-be belockolni nem akarjatok magatokat. Van meg amd es intel. Mondjuk mar ezek is elegge kulonbozoen viselkednek, szoval vagy minden platformon ki kell optimalizalni, vagy vallalni kell, hogy az elsodleges platformon jo gyors lesz, a tobbin meg futni fog. Ha az nv meg gyengebb tamogatast nyujt, szerintem hagyni kell a picsbe egyelore. Majd ha mar normalisat nyujt, ujra fel lehet venni a tamogatottak listajara. Masik lehetoseg (mi ezt csinaljuk), hogy olyan opencl kodot irni, ami mindenhol fut, nv-n es amd-n is. Ekkor persze nem tudsz minden feature-t hasznalni, de valamilyen kompromisszumra szukseg van.
#28: Milyen ertelemben Tesla szintut? Teljesitmenyben, megbizhatosagban, vagy valami mas feature-ben? Nalunk amd-bol van 290x, w8100, w9100, mindegyiken szepen lehet fejleszteni. Szoval ahhoz kb. mindegy szerintem. Futtatni meg gondolom mindenki a sajat hardveren akarja, azert nincs lelockolva. Nem volt meg sok bajom az amd kartyakkal, a mac proban levo d500-d700-ak es szepen muzsikalnak. Az opencl-lel volt, az egy szar szerintem, de ez egy masik tortenet, szerencsere valami megoldast sikerult meg mindig talalni, max kell valami kompromisszum.
-
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.
-
félisten
Amikor csak meglátok ilyen OpenCL-hez hasonló elnevezést, már szinte rosszul leszek a libopencl-es Ubuntu Linuxos szívások miatt (az utóbbi időkben kiadott Wine program telepítésekor).
nvidia-libopencl1-331 has to be removed before installing WINE
-
félisten
-
bandika0626
senior tag
Új driver írásából akkor Elméletileg megoldható az olyan programok futtatása nv kártyákon ami csak opencl-t támogatnak?
AMD RYZEN R7 1700, Cooler Master MasterLiquid 240, MSI X370 SLI PLUS, Corsair 2x4GB DDR4 3600MHz,Asus dual 1060 3G , Gigabyte GTX 1060 3G , Coolermasters GX 450, WD Caviar black sata3 500GB, SSD samsung 830 64GB.
-
LordX
veterán
válasz bandika0626 #43 üzenetére
Ez már ma is megoldható, ha valaki nagyon akarja.. A probléma az, hogy sok kompromisszummal jár.
-
bandika0626
senior tag
De az lehet hogy ugyanaz a progi jobban futna opencl-lel mint cuda-val ugyanazon a hardveren.
AMD RYZEN R7 1700, Cooler Master MasterLiquid 240, MSI X370 SLI PLUS, Corsair 2x4GB DDR4 3600MHz,Asus dual 1060 3G , Gigabyte GTX 1060 3G , Coolermasters GX 450, WD Caviar black sata3 500GB, SSD samsung 830 64GB.
-
LordX
veterán
válasz bandika0626 #45 üzenetére
Ezt nem tartom valószínűnek. A CUDA többet tud, és a kettő ugyanazt a backendet használja, szóval nem sok esélye van az OpenCL-nek a nyerésre (azonos szinten optimalizált programmal).
-
bandika0626
senior tag
Értem. Pl a Sony vegasnál lehet cudaval vagy opencl gyorsítani de a cuda nem gyorsít semmit. Ha viszont openclt is tudna akkor lehet hogy jobban menne.
AMD RYZEN R7 1700, Cooler Master MasterLiquid 240, MSI X370 SLI PLUS, Corsair 2x4GB DDR4 3600MHz,Asus dual 1060 3G , Gigabyte GTX 1060 3G , Coolermasters GX 450, WD Caviar black sata3 500GB, SSD samsung 830 64GB.
-
lenox
veterán
válasz bandika0626 #47 üzenetére
Értem.
Vs
Ha viszont openclt is tudna akkor lehet hogy jobban menne.
Vagy egyik vagy masik...
Új hozzászólás Aktív témák
- Redmi Note 13 Pro 5G - nem százas, kétszázas!
- Samsung Galaxy Z Fold3 5G - foldi evolúció
- Counter-Strike: Global Offensive (CS:GO) / Counter-Strike 2 (CS2)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Rubik kocka
- Autóvásárlás Németországban
- Politika
- Nothing Phone 2a - semmi nem drága
- Dragon's Dogma 2
- Mégsem a Samsung gyártja az iPhone SE paneleket?
- További aktív témák...