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

• #16 Fiery veterán dezz #15

  Új Válasz 2014-06-20 11:23:36 #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

  

  Fiery

  veterán

  válasz dezz #15 üzenetére

  En abban ketelkedek, hogy ez a mostani modell mas esetekben is mukodokepes lehet. A dolgok normalis menete ugy nezne ki (egy idealis vilagban), hogy maga a szoftvergyarto irja meg a GPGPU kodot, altalanosan (ha mar van OpenCL, ami mindharom gyarto GPU-in hasznalhato), leteszteli, es szepen kiadja, hogy ez jo CPU-ra, es jo mindharom GPU-gyarto termekeire. Ezzel is biztositva azt, hogy nem reszrehajlo a ceg, nem egyik iranyba billenti a merleget.

  A konkret esetben pedig -- megint csak egy idealis vilagban -- ugy nezne ki a dolog, hogy ha mar az AMD sutba dobta a sajat, properietary GPGPU interfeszet (Stream), es atallt a nyilt OpenCL-re, azt hangoztatva, hogy az mennyivel frankobb, es hogy milyen nyilt ceg ok maguk is, akkor egy ilyen esetben irjak meg az OpenCL kernelt, adjak oda a szoftvergyartonak, hogy "innentol a Te feladatod tovabbvinni", es majd a szoftvergyarto eldonti, hogy mit csinal vele. Ha lusta, nem ert hozza, nem akar molyolni vele, akkor kiadja ugy ahogy van, akkor is, ha nem fut vagy nem jol fut mas (Intel, nVIDIA) GPU-kon. Ha kicsit fogekony a szoftverfejleszto az OpenCL-re, akkor pedig kicsit megpatkolja az AMD GPU-khoz keszult OpenCL kernelt, hogy fusson Intelen es nVIDIA-n is szepen, es kiadja a cuccot. Nem kell kiadnia a kernel forrast, erre nincs szukseg, de ha nem is kapja azt meg az AMD-tol, akkor esely sincs arra, hogy mas GPU-gyarto termekein is fusson ugyanaz (vagy nemileg modositott formaban ugyanaz) a GPGPU kod.

  Ebben a konkret esetben azonban nyilvanvaloan egyfajta egyezseg szuletett a szoftvergyarto es az egyik GPU-gyarto kozott: a GPU-gyarto megirja, zart modon a sajat termekeire a dekodert, csereben viszont mas GPU-gyartok termekeire nem adja ki -- legalabbis kezdetben -- a Strongene a GPGPU gyorsitott dekodert. En szemely szerint egyebkent ketlem, hogy a masik 2 gyarto ilyen szinten foglalkozna a kerdessel, a Strongene-nek pedig -- ugy tunik -- nincs kompetenciaja a GPGPU fejleszteshez, ugyhogy nem szamitanek arra, hogy mas GPU-kra is elkeszuljon a dekoder.

  Az AMD reszerol azert is furcsa ez a fajta hozzaallas, mert me'g ha modositja is valaki az eredeti OpenCL kernelt, hogy fusson Intel es nVIDIA GPU-kon (mar ha egyaltalan modositani kellene oket, nem tudhatjuk, hiszen a kernelek nem elerhetoek), akkor is lenyegeben a teljes piaci szegmensben, APU-tol a high-end dGPU-kig az AMD-nek all a zaszlo. GPGPU-ban a GCN-ek jelen allas szerint verhetetlenek, tehat semmi szukseg nem lenne az ilyen exkluziv megoldasokra. Sot, me'g jot is tenne adott esetben az AMD-nek, ha le lehetne benchmarkolni, hogy pl. egy mobil Kaverin mennyivel durvabb teljesitmenyre kepes a dekoder, mint mondjuk egy Haswellen vagy akár Broadwellen.

  "Benne van a cikkben, hogy később Intelre és Nvidiára is valószínűleg el fog készülni."

  Akarcsak a WinZip eseteben. Gyanusan hasonlit a 2 eset egymasra... SZVSZ ezt a forgatokonyvet me'g latni fogjuk nehany esetben, plane mivel -- ha jol latom -- a HEVC dekoderben alkalmazott AMD GPGPU megoldas egy olyan motort hasznal, amit mas szoftverekben, mas algoritmusoknal is be lehet vetni. Vannak ehhez kapcsolodoan konkret informacioim is, de nem publikusak, sz'al maradjunk annyiban, hogy majd lehet figyelni a hireket, Abu be fog szamolni minden, ehhez az esethez kisertetiesen hasonlito fejlemenyrol, mas szoftverekkel kapcsolatosan.

  ---

  Me'g annyit, hogy ha a HEVC dekoder CPU verzioja mondjuk AVX gyorsitast használna, es a Strongene olyan kodot adna ki, ami csak Intel processzorokon hasznalja ki az AVX-et, Te es me'g sokan masok is fel lennenek haborodva. Ez ugyanaz a tortenet lenne: egy szabvanyos, kvazi gyarto fuggetlen optimalizacios eljaras kihasznalasra az egyik gyarto termekein, mig ugyanannak a kodnak a szandekos nem hasznalata a tobbi gyarto termekein, ahol egyebkent ugyanugy meg lenne a lehetoseg az optimalizacio hasznalatara.

  [ Szerkesztve ]

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