Keresés

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

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

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

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

  • szabi80sz

    tag

    válasz szabi80sz #37 üzenetére

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

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

Hirdetés