Hirdetés

2019. augusztus 19., hétfő

Hozzászólások

(#1) con_di_B


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

(#2) LordX


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

(#3) vinibali


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 :F

BIOS írás, helyreállítás, törlés, mentés! http://vinibali.x3.hu/bios.html

(#4) vicze1


vicze1
(nagyúr)

Hm, kezd befagyni a pokol vagy mifene? ;]

[ Szerkesztve ]

(#5) bandika0626


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.

(#6) Abu85 válasza bandika0626 (#5) üzenetére


Abu85
(HÁZIGAZDA)

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.

A semmi az nem nincs, hanem van. Ha a semmi van, akkor nincs semmi, de ha nincs semmi, akkor valami van, de az nem semmi.

(#7) bandika0626 válasza Abu85 (#6) üzenetére


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.

(#8) LordX válasza bandika0626 (#7) üzenetére


LordX
(veterán)

Besenyő Pista bácsi.

[ Szerkesztve ]

(#9) arn


arn
(nagyúr)

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.

RETRO HW-t veszek (VLB, Pentium, Tseng, GUS, Roland, etc)

(#10) Abu85 válasza arn (#9) üzenetére


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 ]

A semmi az nem nincs, hanem van. Ha a semmi van, akkor nincs semmi, de ha nincs semmi, akkor valami van, de az nem semmi.

(#11) Meteorhead válasza arn (#9) üzenetére


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.

(#12) HalasKYO


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 :D

[ Szerkesztve ]

Halas - http://www.flickr.com/photos/halaskyo

(#13) arn válasza Abu85 (#10) üzenetére


arn
(nagyúr)

Tolongani fog a tobbi gyarto... Nyilvan nincsen semmi elonye amds hwen :)

RETRO HW-t veszek (VLB, Pentium, Tseng, GUS, Roland, etc)

(#14) Abu85 válasza arn (#13) üzenetére


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.

A semmi az nem nincs, hanem van. Ha a semmi van, akkor nincs semmi, de ha nincs semmi, akkor valami van, de az nem semmi.

(#15) arn válasza Abu85 (#14) üzenetére


arn
(nagyúr)

Ne haragudj, de abban nem igazan hiszek, hogy az amd olyanba fektesse a nem tul sok penzet, hogy a konkurencianak jo legyen.

RETRO HW-t veszek (VLB, Pentium, Tseng, GUS, Roland, etc)

(#16) Abu85 válasza arn (#15) üzenetére


Abu85
(HÁZIGAZDA)

Nem is kell hinned benne, ugyanis egyáltalán nem értük csinálják. Ez a szoftverpartnereik kívánsága.

[ Szerkesztve ]

A semmi az nem nincs, hanem van. Ha a semmi van, akkor nincs semmi, de ha nincs semmi, akkor valami van, de az nem semmi.

(#17) Pekkk


Pekkk
(aktív tag)

Ezek szerint PhysX, Cuda kuka?

(#18) Meteorhead válasza Pekkk (#17) üzenetére


Meteorhead
(aktív tag)

...igen. Mennek a cudába.

(#19) LordX válasza Pekkk (#17) üzenetére


LordX
(veterán)

Miért lenne kuka?

(#20) Milgram1 válasza LordX (#19) üzenetére


Milgram1
(aktív tag)

Nvidia physx helyett most nem ez a hihetetlenül minőségi gameworks csomag van? Most nekem nem tűnt fel vagy tényleg nem nagyon vannak mostanában PhysX-es játékok?

"with a great processing power, comes a great responsibility" - Hackerman

(#21) LordX válasza Milgram1 (#20) üzenetére


LordX
(veterán)

Az inkább azért van, mert egy zárt szar, nem azért mert az nV dobná.

(#22) lenox válasza Meteorhead (#11) üzenetére


lenox
(addikt)

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.

(#23) con_di_B válasza arn (#9) üzenetére


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 ]

(#24) Sir Ny válasza con_di_B (#23) üzenetére


Sir Ny
(senior tag)

inkabb pokol lenne, mint Kanaan

-

(#25) Meteorhead válasza lenox (#22) üzenetére


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.

(#26) Meteorhead válasza Sir Ny (#24) üzenetére


Meteorhead
(aktív tag)

Ezt fejtse ki kérem!

(#27) lenox válasza Meteorhead (#25) üzenetére


lenox
(addikt)

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?

(#28) vicze1 válasza lenox (#27) üzenetére


vicze1
(nagyúr)

Mutass egy Tesla szintű cuccot az AMD-től, és akkor innentől megértheted, miért szettnének nV-t de OpenCL-t azon a szinten.

(#29) Abu85 válasza vicze1 (#28) üzenetére


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 ]

A semmi az nem nincs, hanem van. Ha a semmi van, akkor nincs semmi, de ha nincs semmi, akkor valami van, de az nem semmi.

(#30) vicze1 válasza Abu85 (#29) üzenetére


vicze1
(nagyúr)

A K80 meg 3TF-t, persze 2 mag, de akkor is no. :P
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 ]

(#31) Abu85 válasza vicze1 (#30) üzenetére


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 ]

A semmi az nem nincs, hanem van. Ha a semmi van, akkor nincs semmi, de ha nincs semmi, akkor valami van, de az nem semmi.

(#32) vicze1 válasza Abu85 (#31) üzenetére


vicze1
(nagyúr)

Akkor inkább arról van szó, hogy a meglévőt szeretnék úgy használni, mivel eddig nem volt AMD alternatíva. A régit meg nem dobálják ki nyilván. Így 4év alatt bebetonozta magát szépen az nV, innen persze hogy enhéz váltani.
Főleg erre vonatkozott az első megjegyzésem.

(#33) Meteorhead válasza lenox (#27) üzenetére


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.

(#34) lenox válasza Meteorhead (#33) üzenetére


lenox
(addikt)

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.

(#35) vicze1 válasza lenox (#34) üzenetére


vicze1
(nagyúr)

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.

(#36) Meteorhead válasza lenox (#34) üzenetére


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.

(#37) Dhampir


Dhampir
(nagyúr)

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

:D

(#38) vinibali válasza Dhampir (#37) üzenetére


vinibali
(őstag)

csak nvidiás opencl libbel van tapasztalatod? a mesa opencl package miatt kérdezem...

BIOS írás, helyreállítás, törlés, mentés! http://vinibali.x3.hu/bios.html

(#39) Dhampir válasza vinibali (#38) üzenetére


Dhampir
(nagyúr)

Csak erre emlékszem. Még márciusban simán futottak a játékok 12.04 alatt, aztán a 14.04 használata során befejeződött. Lehet, hogy régebbi Wine telepítésével, cserélgetésével egyszerűen is megoldható, virtuális meghajtóra téve POL-ban.

(#40) Dhampir


Dhampir
(nagyúr)

PlayOnLinux telepítésénél is ez a helyzet:

(#41) Dhampir válasza Dhampir (#40) üzenetére


Dhampir
(nagyúr)

Maradt ez a megoldás:

sudo apt-get install nvidia-cuda-toolkit
sudo apt-get install ocl-icd-opencl-dev
sudo apt-get install wine (illetve playonlinux)

(#42) vinibali válasza Dhampir (#41) üzenetére


vinibali
(őstag)

köszi.
múltkor láttam egy mesa-opencl csomagot, amiatt kérdeztem. azt hittem van tapasztalatod a minőségével :)

BIOS írás, helyreállítás, törlés, mentés! http://vinibali.x3.hu/bios.html

(#43) bandika0626


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.

(#44) LordX válasza bandika0626 (#43) üzenetére


LordX
(veterán)

Ez már ma is megoldható, ha valaki nagyon akarja.. A probléma az, hogy sok kompromisszummal jár.

(#45) bandika0626 válasza LordX (#44) üzenetére


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.

(#46) LordX válasza bandika0626 (#45) üzenetére


LordX
(veterán)

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

(#47) bandika0626 válasza LordX (#46) üzenetére


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.

(#48) lenox válasza bandika0626 (#47) üzenetére


lenox
(addikt)

Értem.

Vs

Ha viszont openclt is tudna akkor lehet hogy jobban menne.

Vagy egyik vagy masik...

(#49) LordX válasza lenox (#48) üzenetére


LordX
(veterán)

Nincs itt semmi ellentmondás, lásd #6. A CUDA kód abban a programban nem olyan jó minőségű, mint az OpenCL.

Copyright © 2000-2019 PROHARDVER Informatikai Kft.