2. Fórumok
  3. Videokártyák
  4. Nyílt lesz az NVIDIA CUDA fordítójának forráskódja
Keresés

Új hozzászólás Aktív témák

  • #46 Abu85 HÁZIGAZDA szabi80sz #45
    Új Válasz #46
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Abu85

    HÁZIGAZDA

    válasz szabi80sz #45 üzenetére

    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.

  • #43 Abu85 HÁZIGAZDA szabi80sz #41
    Új Válasz #43
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Abu85

    HÁZIGAZDA

    válasz szabi80sz #41 üzenetére

    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.

  • #40 Abu85 HÁZIGAZDA szabi80sz #38
    Új Válasz #40
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Abu85

    HÁZIGAZDA

    válasz szabi80sz #38 üzenetére

    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.

  • #36 Abu85 HÁZIGAZDA Hiftu #34
    Új Válasz #36
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Abu85

    HÁZIGAZDA

    válasz Hiftu #34 üzenetére

    Az asztali Linuxokkal nem is érdemes törődni. A gyártók ezt üzleti szinten kezelik. Látják, hogy van egy rendszer, ami ingyé sem kell az emberek nagyon-nagyon-nagyon-nagy többségének. Az rendben van, hogy a driverekben az elmúlt hónapokban óriási volt a fejlődés, de még így sem fektetnek bele túlzott erőforrást. Egyszerűen nem jön vissza a pénz. Szimpatikus a Linux, de a mai világ az kőkemény üzlet. Ha valahol van pénz, akkor az kap támogatást, ha nincs benne pénz, akkor ott komoly befektetésre sem lehet számítani. A Linux tulajdonképpen egy gyártónál sem számít asztali szinten. Profi szinten már más a helyzet, oda komoly erőforrások mennek minden oldalról. A másik az Android, ami egy sokkal jobban fejlődő OS. Oda is jóval több erőforrást fektetnek a gyártók. Itt a jövő egyértelműen az egyéni Android verziók, mert minden cég ki szeretné használni azokat az extrákat, amiket a chipbe építenek. Itt elsősorban az AMD van ilyen helyzetben, hiszen a Brazos képességei két évvel előzik meg a konkurenciát (számolva azzal, hogy a Tegra 4 megjelenik 2012 végén), de a Google úgy építette fel az Androidot, hogy egyszerű legyen a userek szempontjából, vagyis saját API-kat használ, így amikor programot töltesz le, akkor csak a verziószámot kell nézni. Ez jelenleg megfelelő a gyártóknak, de az AMD más most többet akar, és ezért fejlesztik az x86 Androidot nem hivatalos forrásból, mert a hivatalos Android nem felel meg nekik. A jövőben egyre több cég dönt majd így. Az NV számára például ott a CUDA. A Google nem fogja hivatalosan implementálni, így alternatív utat kell keresni. Nyilván az Android a jelenlegi formájában pár gyártónak nem felel meg. A Google maximum az OpenCL beépítésével fog törődni, mert az kezd tömeges igény lenni a gyártók oldaláról, de a CUDA, a C++ AMP, a OpenVideo Decode, stb. egyelőre egyéni, vagy csak pár gyártó igénye. Mindenesetre ez egy olyan kérdés, amit valahogy meg kell oldani. A Windows 8 megjelenésével a gyártók kapnak az Android mellé egy alternatívát. Ráadásul olyat, ahol az egyéni igények könnyen beépíthetők. Nyilván a Google-nek kell valami megoldás arra, hogy az Androidon is ki lehessen elégíteni az egyéni igényeket.

  • #31 Abu85 HÁZIGAZDA FireGL #29
    Új Válasz #31
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Abu85

    HÁZIGAZDA

    válasz FireGL #29 üzenetére

    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.

  • #24 Abu85 HÁZIGAZDA Sanya #21
    Új Válasz #24
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Abu85

    HÁZIGAZDA

    válasz Sanya #21 üzenetére

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

  • #22 Abu85 HÁZIGAZDA MaUser #18
    Új Válasz #22
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Abu85

    HÁZIGAZDA

    válasz MaUser #18 üzenetére

    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.

  • #16 Abu85 HÁZIGAZDA Jack@l #15
    Új Válasz #16
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Abu85

    HÁZIGAZDA

    válasz Jack@l #15 üzenetére

    Ezt nevezik szelektív látásmódnak. Úgy alakítod a top500 adatait, hogy az jó legyen annak a szempontnak, amit ki akarsz hozni belőle. Felőlem ezt megteheted, de ebben az esetben sértő számomra, hogy pont te nevezel elvakultnak. :)
    Én szeretnék ebből kimaradni, mert az egyértelműen nem tényszerű információcseréhez vezet, ha a vizsgált lista 95+%-át szándékosan kizárjuk a statisztikából.

  • #14 Abu85 HÁZIGAZDA Jack@l #13
    Új Válasz #14
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Abu85

    HÁZIGAZDA

    válasz Jack@l #13 üzenetére

    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.

  • #12 Abu85 HÁZIGAZDA smkb #5
    Új Válasz #12
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Abu85

    HÁZIGAZDA

    válasz smkb #5 üzenetére

    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.

Új hozzászólás Aktív témák

Hirdetés