Érdekes... Ezt a lépést nem vártam volna... Ha már lúd, legyen kövér alapon nyitottá tehették volna teljesen. Ennek sztem kb. ugyanannyi értelme van, mintha nem csináltak volna semmit. Max némi marketing, hogy azért tudják a fejlesztők, ők is itt vannak még...

Alamuszi Nyuszi nagyot ugrik... :)

igen, kb ennyiről lehet szó

UpTheBruce!

Kiáltás a pusztába ...

||| Wayteq xTAB 70i |||

Kíváncsi vagyok, mi lesz a CUDA-val, az eddigiek alapján a távoli jövőképe nem túl rózsás...

"Éppen ezért a gyártók szemében a CUDA továbbra is mostohagyermek lesz, és a gyártóktól valóban független platformok továbbra is jobb alternatívát jelenthetnek."

Mely független platform van jelenleg jobban támogatva alkalmazásokkal, mint a cuda, pl hpc szegmensben? Mert, ha ugye eddig is mostoha gyerek volt, akkor nyilván tobzódnak az alkalmazásk a független apikra és többszörösük van, mint cudára...

Jah, adobék is ezt az elavult zárt rendszert használják

Ezért kellett kártyát cserélnem

Kíváncsi leszek, hogy fog kihalni és a nyíltak mikor fognak elterjedni...

A kicsire nem adunk... a nagyot meg leszarjuk!

majd akkor fog kihalni mikor kifogy a csúszópénz az "nvidia The Way It's Meant To Be Worked" alapból.

Egy példa, eredetileg a vray rt csak nvidia gpu-kon futott a cuda miatt de elég hamar rájöttek hogy ők elég kicsit ahhoz hogy letegyék a voksukat egy gyártó mellett, mert nagyon hamar megjelentek az ingyenes jó minőségű renderelők opencl re akiket nem igazán érdekelt a cuda
és már ez is elérhető openclre. És itt a cudába ölt pénz, fejlesztés, támogatás, cégeknek ajándék, hamar (1-2 év alatt) semmis lett. Ma már csak annyi hogy az ajánlott cimkét kapták meg.

Johnny Mnemonic 2021:320gb-t töltött az agyába és majdnem meghalt, inkább pendrive a s?ggébe!

Tudtommal a vray rt azért lett először CUDA-s, mert amikor elkezdték fejleszteni, akkor a többi nem létezett, legfeljebb hallani lehetett róla, hogy majd jön.

Ugyanez a helyzet az Adobe-nél is, ahol még el is gondolkodtak az openCL-en, amikor az megjelent, de aztán rájöttek, hogy hiába írnák át egyből OpenCL-re, nem lenne semmivel sem jobb a helyzet, mert a konkurens OpenCL kompatibilis hardverek amúgy is lassúak, tehát ha nem érdemes hardvert váltani, akkor jó a CUDA is, pláne, hogy az nV karikon az OpenCL kód lassabban fut, mint CUDA kód, így csak rontottak volna a helyzeten.
Pár év múlva amúgy is szükséges lesz a GPGPU kód refaktorálása, ahogy szinte minden olyan kódnál, ami nagyon új terület a fejlesztők számára, így meglesz a lehetőség az openCL-re váltásra később is, ha a konkurens hardverek teljesítménye labdába fog rúgni.

[ Szerkesztve ]

Ez így igaz hogy akkor még csak az volt, de gyorsan áthajóztak a nyíltforrásra ahhoz képest hogy az nvidia gáncsolja a nyílt dolgokat ahol csak tudja (phisx, cuda), erre akartam mutatni.

Johnny Mnemonic 2021:320gb-t töltött az agyába és majdnem meghalt, inkább pendrive a s?ggébe!

Igen, ez igaz, én meg ezt akartam alátámasztani azzal, hogy a vray esetén csak az openCL későbbi érkezése miatt kezdték CUDA-ban. Persze, nekik lehetőségük is volt OpenCL-re váltani, mert pl. az AMD karikon meglepően tűrhető eredményt produkál a Vray RT, ahogy hallottam. Tehát érdemes volt engedni az nV karikon tapasztalható teljesítményből a konkurencia támogatásáért.

Az Adobe GPGPU kódja ezzel szemben feltehetően halott lenne AMD karikon így az OpenCL támogatás csak rosszabb lenne, mert az nV karik lassabb működésével fizetnének az amúgy is lassú konkurens kártyák támogatásáért - ami nem éri meg.

[ Szerkesztve ]

"A CUDA Toolkit nyílt fordítót támogató verziója egyelőre nem publikus, de az alábbi weboldalon kérvényezni lehet a hozzáférést." - Isten malmai lassan őrölnek..

RISC86 Power

Ha a top500-at nézzük, akkor a gépek nagyon csekély része tartalmaz GPU-t. Nagyon az elején vagyunk még az aratásnak. A HPC szegmensben az egész innováció akkor veszi, majd kezdetét, amikor megkezdődik az integráció. A CPU-magok számos dologra jók, és a GPU-magok is. Egymástól függetlenül, vagy távol azonban a lehetőségek korlátozottak. Együtt egy lapkán belül viszont igazán ultimate megoldások lesznek. Amire viszont figyelni kell az a piac igényei. Nagyon sokan nem akarnak elszakadni a magas szintű programozási nyelvektől. A CUDA-nak és az OpenCL-nek is lesz létjogosultsága, de nem egyszerű platformokról van szó. A C++ AMP, az OpenACC, és a natív C++ támogatás sokkal kedvezőbb lesz.

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.

Kicsit elvakult/elfogult...
Régebb óta kint van a piacon, könnyebb cuda-ra fejleszteni és sokkal gyorsabban is fut pl egy raytracing-es renderelő, mint opencl-ben megírva. (akár hasonló kaliberű AMD kártyával összehasonlítva is)
Egyetlen hátránya, hogy only NV, de lehet a GK100 megjelenése után 1024 maggal ez már nem is számít annyira

Ja nyilván. Én döntöttem arról is, hogy az Intel, az AMD, az IBM, az ARM, és a többiek nemet eddig mondtak a CUDA támogatására. Én vagyok akitől a CUDA sorsa függ, mert a sakkban tartom a gyártókat, és kényszerítem őket, hogy mellőzzék a CUDA-t. A CUDA mellé oda lehetett eddig is állni, csak senki sem tette. Az NV most nem nézi tétlenül, hogy a gyártófüggetlen megoldások elkaszálják (ahogy a történelemben ez mindig megtörtént a zárt rendszerekkel), így az OpenACC általánosan érdektelensége után az egyetlen út a CUDA LLVM fordító forrásának megnyitása. Ezzel időt adott magának az NV. Valószínű, hogy gyártói támogatást nem látunk, mert már az AMD és az Intel is a C++ natív támogatásában bízik. A fejlesztőknek ez egyszerűbb alternatíva.

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

Én is ezen gondolkodom. Mi a tapasztalatod egyébként?

Abból a szempontból viszont indokolható, hogy értelemszerűen a lista elején vannak az újabb gépek, nyilván egy öt éves gépben (2006-os gépek is bőven beférnek a top500-ba!) nem lesz GPU. Egyébként a top20-on kívül is bőven van nV GPU-s gép még a konkurencia szinte nem is képviselteti magát: Top500

''A file-cserélés öli meg a filmipart? Inkább a filmipar öli meg a file-cserélést. 2 hónapja nincsen semmi értelmes film, amit érdemes lenne letölteni...''

a cudanak mar vege van , ez mar csak az utolso lehelete

Ezek a gyártók a programozók lennének?

Ez olyan dolog, hogy ha megjön egy új Windows, akkor kizárod a régieket, és 100%-os a részesedés. Mondom fel lehet állítani ilyen direktívákat, hogy az eredmény kozmetikázott legyen, de ettől még nem lesz elterjedtebb a rendszer a teljes piacot tekintve.

Az AMD más utat választ a HPC-hez. Az új GPU-ról nem beszélhetek, mert volt már konf. ... de korábban már kiderült, hogy a C++-ban bíznak, mert sok rendszeren fontos, hogy ne kelljen újraírni a programot. Az NV ezért vetette be az OpenACC-t, mert a CUDA és persze az OpenCL nem mindenhol előny. Persze abban azért továbbra sem hiszek, hogy szimpla újrafordítással, illetve direktívákkal jó lesz a sebesség.

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

NV

Nem. A gyártók, a gyártók, lásd Intel, AMD, IBM ... stb.

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

A direktívával semmi gond nincs, az AMD jelenleg tényleg észrevehetetlen a top500-ban GPU szinten... Én kemény két gépet számoltam össze, de nézd át a listát te is. Kb. 10:1-hez az arány az nV javára.

''A file-cserélés öli meg a filmipart? Inkább a filmipar öli meg a file-cserélést. 2 hónapja nincsen semmi értelmes film, amit érdemes lenne letölteni...''

amd, intel miért támogassa a cuda-t? ez eddig is köztudott volt, hogy soha nem is fogják támogatni azt.

Na ez az! Miért támogatnák a konkurenciát?!

[ Szerkesztve ]

Szerintem meg már örülhetünk, hogy legalább valami haladás megmutatkozott a témában. Ki tudja, előbb-utóbb hátha nyílt lesz az egész.

Skype-on lány az informatikusnak: Milyen színű a szemed? Informatikus: #0034ff

amíg teljesen zárt rendszer volt

Az embert a gondolkodás tette állattá...

az opencl-t is használja az összes konkurencia nem csak az nv

Az embert a gondolkodás tette állattá...

A gyártóknak már az nem tetszik a C++ AMP-nél, hogy az AMD írja az SDK-t a nem Windows rendszerekhez. Miért tetszene innentől a CUDA, amit minden rendszerre az NV fejleszt, saját igényei szerint. Ez vállalhatatlan. A C++ AMP még épphogy vállalható. Kétségeim vannak, hogy az AMD nem optimalizál haza a nem Windows rendszereken, de legalább a platform fejlesztését független cég delegálja, és a Win alatt az AMD egyenlő a többiekkel.

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

a windows 8 -ban alap az AMP, innentol kezdve a cudanak nagyon nincs szerepe, az opencl hasonloan az opengl-hez multiplatformos fejleszteskoor johet szoba
az nvida rajott hogy az o megoldasuk halalra van itelve, ez a lepes maximum a szinpatiat noveli iranyukban, bar ez az egesz alsagos lepes, a semmit sem ero vackot konnyu kozze tenni

hosszu tavon sajnos az nvidianak nem terem baber, az intel be fogja daralni, az armos win8 is egy butitott verzio lesz

[ Szerkesztve ]

Jujj!!! Te jó ég, hogy itt mennyi hozánemértő osztja az észt! A C++ AMP és a Cuda teljesen más területre valók! Van amire a Cudát lehet használni, de a C++AMP-ot nem (fordítva ez nem igaz, legfeljebb annyi, hogy ahol az AMP használható, ott hatékonyabban lehet programozni, mint a Cudát vagy az OpenCl-t, pont ezért van létjogosultsága). Ugyanígy az OpenCl-nek sem ellenfele az AMP.
Ilyen szöveg, meg hogy "a Cuda halálra van ítélve"... No comment...
Más: az OpenCl-es cikk nem lenne rossz, csak átveszi a marketinget és a valóságról nem sok szó esik benne (csak olyan tervekről, mit az OpenCl-ben érdekelt hardvergyártók nagyon szeretnének elérni, de ez még jó ideig álom marad, mert jelenleg sajnos az OpenCl több területen nem igazán szóbajöhető alternatívája a Cudának).

Az OpenCl-t pedig pont nem az Nvidia vágja "tönkre", hanem az Amd fejlesztői a pancserkodásukkal (meg az 1/4-es adathosszkorlát, sem tesz mindig jót az OpenCl-nek, amit a Khronos Group vezetett be).

na végre.

esetleg kijavíthatjuk a ptxas-t, mert valami borzasztó, néha miket csinál.

Az OpenCL fejlesztéséért nem felel az AMD, sem pedig az NV, vagy más gyártó. A Khronos Group a platform felügyeleti szerve. A gyártók beleszólást kapnak, de csak SDK-t és persze támogatást készítenek az aktuális verzióhoz. Az persze igaz, hogy a rendszer élharcosai közé az Apple, az AMD, az ARM, és most már az Intel tartozik, míg az NV inkább később támogatja az aktuális verziókat, hogy egyszerűbb legyen a CUDA élete. Ez az a probléma, ami a konkurens gyártók által nem támogatott rendszereknek nehézséget okoz. Az Intelnek lenne valamennyire hatalma a saját akaratát rákényszeríteni a piacra, de az NV kicsi ehhez. A PC-s piacon rendelkeznek jelenleg ~16-18%-os részesedéssel. Ez nem elég. Ezért áll át egyre több szoftverfejlesztő az OpenCL-re, mert egyszerűen nagyon kevés felhasználó tudja kihasználni a CUDA-t. Jóval egyszerűbb egy szoftvert eladni, ha a PC-s piacon eladott gépek 100%-a támogatja a felületet. A kontraszt láthatóan jelentős. A C++ AMP is jelentős változás lesz, bár technikai értelemben nem olyan, mint a CUDA, vagy az OpenCL, de a célja nyilván azonos.
Az NV-nek meg kellett nyitnia a CUDA fordító forrását, mert a CUDA elveszne a független felületek között. Így sincs túl sok esély rá, hogy a gyártók beállnak a támogatók sorába, hiszen a felügyelet az NV-nél maradt, de adnak még egy kis időt a CUDA-nak. Az valószínű, hogy a konzumer szinten a CUDA-nak vége. Nem látom reális esélyét annak, hogy egy cég 16-18%-os és folyamatosan csökkenő részesedéssel el tudna terjeszteni bármit is. De a professzionális és a HPC-piacon van még lehetőség a CUDA előtt, legalábbis azzal, hogy nyílt a fordító mindenképpen nyert egy kis időt az NV.

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

Részben egyetértek. Amivel nem (illetve lehet, hogy inkább csak félreértettél) : pontosan az OpenCl "támogatással" van a probléma Amd környékén (nem a funkcionális támogatással, hanem az optimalizálás teljes hiányával -ezt felejtik ki a marketingből-, ami főleg az indulási időket jellemzi, ami bizonyos programoknál nem olyan fontos, mert elrejthető, de más programokban pedig nagyonis számítanak). Tehát bizonyos programokat Amd videókártyán futtatni felesleges, mert a cpu-n gyorsabban fut le a kód, pedig pont az Amd miatt használnak (jelenleg még) OpenCl-t, de ha egy Geforce-on van értelme lefuttatni, Amd-n nem, akkor már inkább Cudát használ az ember. (Persze ettől még egyre inkább igaz lesz az, hogy a konzumer szinten csökkenni fog a Cudás kódok száma, hála az Nvidia butaságának, hogy nem tette és nem teszi nyílttá a Cudát).
Egyébként a Cuda már régen eltűnt volna, ha annyira rossz lenne. Igaz, hogy ez volt az első megjelent kiterjesztés, amivel általános célú programokat lehetett készíteni GPU-ra (emiatt elég sok olyan kod készült, amik ma is futtathatók), ráadásul a rendszer tervezői nagyon jó munkát végeztek, amit az OpenCl-re már nem lehet elmondani. Elég csak arra gondolni, hogy szemléletmódjában az OpenGl-es vonalat követi (nyilván emiatt elvileg jobban integrálható az OpenGl-el), de az OpenGl-t nem általános programozásra tervezték és ezért hiába másoltak le sok mindent a Cudából: sokkal kényelmetlenebb a programozása, mint a Cudának (elsősorban ez okozza a programok Cudához képesti lassabb futását, az OpenCl-es implementációjuk alatt).
A CL_DEVICE_MAX_MEM_ALLOC_SIZE pedig az OpenCl egyik legdurvább korlátja, ami amellett, hogy kényelmetlen is, lassít és felesleges többletmemóriát kell felhasználni miatta.
Nyilván sok esetben ezek nem tántorítanak el embereket az OpenCl-re történő fejlesztés melletti döntéskor, de ha én játszani akarok: konzolt veszek és nem számítógépet, így ha komolyan gondolom a GPU-ra történő fejlesztést (jelenleg) hiába OpenCl programokat fejlesztek, akkor is Nvidia kártyát veszek.
Ezzel még nem értek egyet: "A C++ AMP ... bár technikai értelemben nem olyan, mint a CUDA, vagy az OpenCL, de a célja nyilván azonos." Amennyiben a cél alatt azt érted, hogy egy program a gpu-n is futhasson akkor ez igaz, de ez annyira absztrakt megközelítése a dolgoknak, mintha azt mondanám, hogy egy harci helikopter, bár technikai értelemben nem olyan, mint egy utasszállító repülőgép, de nyilván a célja azonos (repülnek és emberek is lehetnek bennük ). Azért le kell szögeznem, hogy a jövőbeni változásait a C++ AMP-nak nem ismerem, de akkor is igaz, hogyha olyan funkcionalitást akarnak, mint amilyen a Cudáé vagy az OpenClé, akkor annyira meg kellene változtatni, hogy pont a jelenlegi előnyeit veszítené el, emiatt nem hiszem hogy ezeket a változásokat elvégzik.

[ Szerkesztve ]

Az Amd környékén OpenCl szinten megjelenő problémáról itt találsz infót:
http://forums.amd.com/forum/messageview.cfm?catid=390&threadid=157563&enterthread=y
(Bár én németet és franciát tanultam, angolt nem, így az angol nyelvtudásom nem éppen a legjobb..)

Az AMD nem is a VGA-kra gondol az OpenCL-nél. Nekik a Fusion a lényeg. Nagyjából 50 programot készítettek már az APP SDK-val. És tegnap voltam konferencián, ahol szintén bejelentettek pár programot, melynek az OpenCL részét átírják az APP SDK-val és ezzel gyorsabb lesz Fusionön. A tendencia látszik. Korábban olyan programok, amelyek only CUDA besorolásúak voltak már APP SDK-val készülnek (ArcSoft progik többsége pl., de a Corel is egyre jobban áll át). Ebből a szempontból a fejlesztők számára nagyon is megfelel az AMD fejlesztőkörnyezete. Ha nem felelne meg nem használnák. Az OpenCL egyik legnagyobb problémája debug, már amin ugye lehet korrigálni. Ezért vette meg az AMD a gDEBuggert, hogy ezen javítsanak. Ez nagy szerepet játszik abban, hogy az APP SDK-t egyre egyszerűbb használni. Nem sokat beszélhetek a készülő programokról, de fájltömörítőt is írnak APP SDK-ban jelenleg. 2012-ben meg is jelenik. Valszeg a Trinity APU startjához időzítik.

A CUDA nem rossz. technikailag semmi baj nincs vele, csak az NV 16-18%-os részesedésével a konzumer piacon nem lehet alternatíva. Saját maga hasznát vágja el a fejlesztő, ha CUDA-ra ír egy konzumer vásárlóknak szánt programot.

Úgy értem. A GPU-k kihasználása a cél az általános számításoknál. Az MS megközelítése egy picit más. Valszeg sikeres lesz, mert pont ott előnyös a C++ AMP, ahol a CUDA és az OpenCL nem. Sokan szeretik a magas szintű megközelítést. Nem a leghatékonyabb, de könnyű benne dolgozni.

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

A hozzászólásod kapcsán nem ismételném magam. Nem írtam semmit -szerintem -, ami ennek a hozzászólásodnak ellentmondana.
A fusion-t nem tudtam tesztelni, de szerintem az indulási idők ott is okozhatnak "fennakadásokat", szóval az Amd-nek érdeke lenne minél hamarabb kijavítani ezeket, mert nem igaz, hogy az Nvidia fejlesztői 600* gyorsabb kódokat tudnak írni (vagyis úgy tűnik, hogy sajnos igaz, de most hogy tudnak a problémáról: talán javítanak is majd, remélem: minél hamarabb).

Azért még ezt a korábbi mondatomat kiegészíteném a hozzászólásod kapcsán: "Nyilván sok esetben ezek nem tántorítanak el embereket az OpenCl-re történő fejlesztés melletti döntéskor.."
Főleg, ha még fizetnek is érte, akkor meg pláne nem okozhatnak ilyen gondot a fejlesztőknek. (Meg persze az is igaz, hogy a jövőre is gondolni kell és inkább egy univerzálisabb platformra érdemesebb fejleszteni, a hátrányok jelentkezésekor pedig inkább becsukjuk a szemünket és összeszorított foggal megpróbálunk nem tudomást venni róluk, de ezzel kapcsolatban is volt már szó, hogy az Nv nagyon elszúrta, a Cuda zártságát stb.)

A zártság ellen mindig lehet tenni. Az AMD-nek van egy OpenVideo Decode API-ja. A fejlesztésnél úgy tervezték, hogy zárt lesz, de később ez megváltozott. Jelenleg készítettek egy olyan alaprendszert, aminek sok hardver megfelel, és kérvény van beadva, hogy a Khronos Group felvegye szabványba. Jövőre erről döntenek, de sok fejlesztő szeretné, így valószínűleg nem lesz akadály a szabványosítás. Utána lehet fejleszteni a rendszert új verziókkal.
Az NV még most is odaadhatja a CUDA-t a Khronos Groupnak. Ha egy független szervezet felel a fejlesztés koordinálásért, akkor a gyártók biztos nem lennének ellene.

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.

az arm platform megjelenesevel , mar nem csak amd es nvidia jatszik windowsos kornyezetben, es egyseges gpu tamogatast csak a windows biztosit az AMP vagy compute shader altal
a jelenlegi fejlesztorendszer ugy nez ki hogy meg opengl-es programot sem tudsz irni win8-ra nemhogy opencl-eset m a microsoft korulbastyazta magat a sajat technologiajaval