Csak én nem látom a konzorcium tagjai között az intel-t?

Meg az nVIDIA-t, Apple-t, Google-t, Qualcommot sem. Kicsit hasonlit a HSA konzorcium osszetetelere. Veletlen?

[ Szerkesztve ]

Na ez az. Hol az intel?

[ Szerkesztve ]

Az Intel es az nVIDIA sem szivesen csatlakozik masokhoz, amikor szabvany kidolgozasrol van szo. Ok maguk, a sajat igenyeik, elkepzeleseik menten szeretik kidolgozni a szabvanyokat, amit aztan nem is nagyon osztanak meg senkivel, hacsak nem nagyon muszaj -- vagy valami miatt megeri nekik megis megosztani. Ezek ilyen cegek, es egyelore ugy tunik, sok esetben nekik van igazuk. Vagy mondjuk ugy, hogy sok esetben pont az ilyen proprietary technologiak ill. zart szabvanyok sikeresebbek tudnak lenni, mint a nyilt szabvanyok. Pl. CUDA vs. OpenCL, vagy x86 vs. ARM a szerver piacon.

[ Szerkesztve ]

Nem azért sikeresek inkább, mert előbb jöttek? Ha már van egy jól bevált rendszert, akkor miért mennél át egy másikra? Főleg, hogy nem egyszerű, s kockázatos.

A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

(#2) Fiery
(#3) ThePoweR

Mivel az Intel a Micron Technologies -vel ál közeli (romantikus) viszonyban, ezért ebből az következik, hogy közvetlenül ugyan nem, de közvetetten ők is tagjai a konzorciumnak.

[ Szerkesztve ]

plus ça change, plus c'est la même chose

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.

[ Szerkesztve ]

Bocs, de Intel =/= Micron. Az, hogy a flash memoria gyartasban egyuttmukodnek, egy dolog. Az Intel es a Micron sem csak a flash memoriakrol szol, az csak a biznisz egy szelete.

Nem írtam le, de azt természetesnek vettem, hogy használható, úgymond egyenrangú alternatíva legyen. Tehát ha előbb jön egy prop, s utána egy open alternatíva, ami hasonló vagy kevésbé versenyképes, akkor persze, hogy nem állnak át, hisz minek.

A Cudát így egyértelmű, hogy miért nem váltja le az OpenCL, s az AMD miért próbálkozik a saját "CUDA-fordítójával". Az ARM meg jelenleg csak az ultramobil részlegen tud versenyezni, hisz ott többet kínál az x86-nál (az ottani Atom mára ki is halt), de feljebb már bonyolódik a helyzet. A linux (kernel) sikeressége meg abban van, hogy jóval rugalmasabb, mint a windows.

[ Szerkesztve ]

A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.

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

Azt elfelejtitek, hogy e cégek többségének is van saját megoldása a problémára. Például a CCIX-re az AMD-nek ott a GMI, az IBM-nek a CAPI, stb. Erre a Gen-Z-re az AMD-nek például ott a Freedom.
A probléma igazából nem az, hogy nem tudják maguknak megoldani, hanem az, hogy a zárt megoldás nem érdekli a Facebookot és a Google-t, meg egy rakás nagy céget, mert ők a következő generációnál nyitni akarnak, hogy saját maguk tudjanak szervereket, vagy akár lapkákat tervezni, amit mondjuk egy gyártói technológia nagyon megakadályoz. Emiatt alakulnak most hirtelen ezek a konzorciumok, nem pedig amiatt, mert nem tudják megoldani a cégek maguk.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Tőlem nem kell bocsánatot kérnem.
Az Intel honlapján fennt vannak a részletek.
(Még az is, hogy kisfiút, vagy kislányt várnak)

plus ça change, plus c'est la même chose