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

• #10 Fiery veterán lezso6 #9

  Új Válasz 2016-10-14 10:59:05 #10

  Ú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

  

  Fiery

  veterán

  válasz lezso6 #9 üzenetére

  "A Cudát így egyértelmű, hogy miért nem váltja le az OpenCL"

  Miert lenne egyertelmu? Akkor lenne legfeljebb egyertelmu, ha a CUDA hasznalhato lenne minimum 1 masik GPU gyarto termekein is, pl. AMD vagy Intel (vagy me'g jobb ha mindketto). Ha azt vesszuk, hogy a CUDA szigoruan zart technologia, es csak az nVIDIA termekein hasznalhato, akkor vegul is abszolut lenne letjogosultsaga egy AMD-fele CUDA-nak vagy Intel-fele CUDA-nak. Megsem szuletett meg egyik sem. Pontosabban az ATI-nak me'g anno volt sajat megoldasa erre Stream neven, de nem volt sikeres. Az OpenCL meg sajnos nem egyenrangu a CUDA-val, hiszen pont azokon a pontokon gyenge, amiken a CUDA eros; es pont olyan pontokon kinal pluszt, amik viszont a gyartok f*szsagai es a fragmentacio miatt lenyeguket vesztik. Pl. a CUDA eseteben tipikusan elore leforditod a kodot, es a binarist mellekeled a szoftveredhez, ami aztan kozvetlenul fut a GPU-n, koztes 2 lepcsos forditas nelkul. Ezzel persze kinyirod az elore kompatibilitast (forward compatibility), azaz ha jon egy jovobeni GPU, azon jo esellyel nem fog futni a szoftvered, hanem frissiteni kell, mellekelve az ujgeneracios GPU-hoz egy plusz binarist. Viszont a masik oldalrol meg nem kell a szoftveredet kitenni az epp az adott szoftveres kornyezetben hasznalatos GPGPU fordito bugjainak, azaz nem fog a szoftvered fejreallni egy Catalyst/ForceWare/Intel GPU driver compiler bugja miatt (nem urban legend, honapokig szivtunk mi is ezzel, es azota is kisert a dolog, tobbszor kapunk megkeresest, hogy egy uj video driverben hogyhogynem az eddig jol futo OpenCL kodunkkal mar megint valami problema van -- egy ujabb OpenCL compiler bug, koszi AMD, Intel vagy epp nVIDIA). Amit veszitesz a kompatibilitason, azt megnyered a stabilitassal, kiszamithatosaggal. Az x86 se jutott volna el idaig, ha on-the-fly forditana a CPU, es az epp aktualis CPU firmware-en vagy CPU driveren mulna az, hogy az x86-os szoftver helyesen fut vagy szetszall a francba. Az nVIDIA lehet hogy az egyszeri juzer szempontjabol genyonak tunik, mert mindig a sajat technologiait probalja tolni -- ahelyett, hogy beallna a nyilt szabvanyok moge --, bezarkozik, nem osztja meg a fejleszteseit masokkal; de az utobbi par ev tortenesei alapjan jol lathato, hogy nekik (es me'g nehany cegnek is) ez a modszer mukodik, ok igy tudnak biztositani egy "teljes csomagot". Azaz igy tudnak kesziteni egy stabil hardvert, egy ahhoz tartozo stabil szoftver stacket (driver, compiler, fejlesztokornyezet, stb), es a 3rd party-k ahhoz tudnak stabil szoftvereket szallitani. Amint ebbol a csomagbol kiveszel valamit, vagy csak kicsit meggyengited egyetlen ponton, maris borul minden, es oda juthat az egesz kezdemenyezes, ahol most az OpenCL vagy epp a HSA tart.

• #7 Fiery veterán lezso6 #5

  Új Válasz 2016-10-14 07:43:13 #7

  Ú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

  

  Fiery

  veterán

  válasz lezso6 #5 üzenetére

  Ha az torvenyszeru lenne, hogy mindig az a sikeresebb, aki elobb erkezik, akkor most az Apple helyett a Nokia lenne a legnagyobb okostelefon gyarto; x86 es nem ARM SoC lenne a legtobb telefonban es tabletban; es nem Android lenne a legsikeresebb mobil oprendszer, hanem a Windows. Sot, tovabbmegyek: a Linux is kesobb jott, mint a Windows, manapsag pedig a Linux (kernel) alapu oprendszerek sokkal sikeresebbek, mint a Windows. Az ARM-ban is megvan a potencial, hogy sikeres legyen a szerverekben is, csak ahhoz kicsivel tobb minden kell (korites/platform szinten), mint ami egy okostelefonhoz. Egy Apple-szeru szereplo kellene, akinek megvan a penze es a fokuszaltsaga is ahhoz, hogy osszerakja a puzzle darabjait, es nem mellesleg, hogy maga mellé allitsa a Microsoftot is, es akkor menni fog az. Tippem szerint nem az AMD lesz az, aki ezt vegig tudja vinni (plane mivel ok a Zen alapu szervereket toljak most ezerrel, nagyon helyesen), hanem a Qualcomm. Vagy ha vegkepp megall az okostelefonos piac bovulese, me'g az Apple is beszallhat erre a piacra.

  Az OpenCL vs. CUDA pedig vegkepp nem arrol szol, hogy ki volt elobb. Az OpenCL eleve egy hibas elkepzeles, rosszul mukodik, szivas hasznalni, rettento fragmentalt, rettento sok darabja van a puzzle-nek ahhoz, hogy egy-egy reteg felhasznalason kivul barmi komolyra hasznalni lehessen. Hiaba nyilt egy szabvany, ha pont ezzel (ettol) lesz gyenge. A zart, szorosan kezben tartott, sajat hardverhez optimalizalt szabvanyok/technologiak nem veletlenul tudnak jobban mukodni, sikeresebbek lenni. Van egy csomo olyan helyzet, amikor ezerszer konnyebb mind a hardver fejleszto, mind az API fejleszto, mind az API felhasznaloja (azaz a szoftver fejlesztok) szamara, ha zart egy szabvany, ha adott esetben egyetlen ceg egyetlen (vagy nehany) hardveret kell vele megcelozni, es nem egy csomo ceg csomo API implementaciojahoz kell igazitani a szoftvert. Nyilvan a piac szamara ez rossz, de a nyilt szabvanyokkal ill. az elozoleg zart szabvanyok megnyitasaval sem sikerult sok teruleten elorelepest tenni. Hiaba harsogja a media, hogy milyen szuper dolog, amikor jon egy uj, nyilt szabvany, azoknak jo resze vagy pont ugyanolyan reteg igenyt fog vegul kiszolgalni, mint amit egy zart szabvany is meg tudott volna tenni; vagy egyszeruen eljelentektelenedik.

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