2. Fórumok
  3. Multimédia, életmód, 3D nyomtatás
  4. Publikusan tesztelhető a Strongene HEVC dekódere
Keresés

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

  • #23 Fiery veterán dezz #22
    Új Válasz #23
    Ú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 #22 üzenetére

    "Nem vágnak el semmit, hiszen az újabb verziókban szállíthatnak binárisokat újabb/egyéb GPU generációkhoz/architektúrákhoz is."

    Annak a lehetoseget azonban elvagjak, hogy a jelenlegi verzio futhasson egy most me'g nem tamogatott GPU-architekturan. Persze nem olyan nagy gond ez, ha folyamatosan frissitgeted a dekodert, csak mondjuk CPU vonalon ez nem megszokott. CPU-knal, ha mondjuk egy szoftver SSE-t tamogat, akkor nem szokas az, hogy jon egy uj, SSE-kepes CPU-generacio, es azon hirtelen nem fut egy meglevo, SSE-re optimalizalt szoftver.

    "Ti sem OpenCL forráskódot adtok, hanem binárist. Akkor higgyem azt, hogy nektek is a cégek készítik el a GPGPU-s részeket? Egyébként ti külön binárist adtok a különféle GPU-khoz?"

    Nem bantani akarlak, de ebbol a 3 mondatodbol tokeletesen latszodik, hogy nem ertesz az OpenCL temahoz, csak hozzaszolsz. Ez nem lenne gond, ha nem irnal olyan meggyozo(nek latszo) dolgokat :) No offense. Sz'al a dolog ugy nez ki normalis esetben, hogy megirod az OpenCL kernelt (forraskodot), azt mellekeled a szoftverhez. Ha okos vagy, akkor nem sima TXT fajlkent (.CL kiterjesztessel szokas, de ez mindegy) mellekeled a szoftveredhez, mint az OpenCL sample-k eseteben (ld. pl. AMD APP SDK sample kollekcio), hanem letitkositod es eltarolod mondjuk resource-kent. Tehat a forraskodot mellekeled, de nem olvashato formatumban. Aztan, a szoftver futasa kozben a kernel forrast betoltod, dekriptalod, es atadod az OpenCL forditonak (clCreateProgramWithSource). Ennek a megoldasnak az a nagy elonye, hogy gyarto fuggetlen kodot tudsz mellekelni a szoftveredben, a hatranya pedig az, hogy a valosideju OpenCL forditas miatt ki van teve a kodod az OpenCL forditok esetleges benasagainak, bugjainak. En szemely szerint ugy gondolom, hogy ennek a megoldasnak tobb elonye van mint hatranya, ezert ez a preferalt pl. az AIDA64-ben is. De a Sandra is igy mukodik, meg me'g egy csomo mas szoftver is.

    A valos ideju forditas elonyei:
    + gyartofuggetlen
    + platformfuggetlen
    + future-proof (jovobeni GPU architekturakhoz is jo a kod)
    + jovobeni OpenCL compiler optimalizaciokkal a teljesitmeny a kod ill. a teljes szoftver modositasa nelkul is novelheto

    A valos ideju forditas hatranyai:
    - ki van teve az OpenCL forditok benasaganak
    - ha valaki feltori a szoftvert, akkor viszonylag konnyen megszerezheti a kernel forrast es felhasznalhatja a sajat celjaira. De a binaris kodokat is vissza lehet fejteni, csak az kicsivel nagyobb melo. HSAIL-nel konnyebb lesz a binaris kodok visszafejtese, mert az egy nyilt specifikacio.

    "BTW, éppen erre a problémára nyújt megoldást a HSA: a HSAIL bytecode nem forráskód, miközben többféle GPU-ra továbbfordítható."

    Igy van, a HSAIL egy jo megoldas lesz erre a dilemmara, felteve persze hogy a HSAIL-t Intel es nVIDIA GPU-n is tudod majd futtatni. Ha nem, akkor alig lesz jobb, mint most az AMDIL :( Tudom-tudom, a HSA Foundation-nek tagja a Qualcomm es a Samsung is, es a HSAIL-t majd jol tudod futtatni a mobiltelefonodon is, nem csak az AMD APU-s PC-den, de maradjunk most az x86-os PC-knel, ez a jelen rogvalosag.

    A HSA tamogatas azonban onmagaban is egy dilemma az AMD reszerol. Egyreszt ugye nincs kesz a HSA implementacio, nincsenek HSA compilerek, masreszrol pedig a HSA-t tamogato hardverek nagyon szuk kort kepviselnek (Kaveri, oszt annyi). Ha pedig csinalsz mondjuk egy HSA-s HEVC dekodert, es valahogy belehakkolod a Catalystba (mint a JPEG dekodert), akkor jon a sok dGPU-tulaj, ill. regebbi APU tulaj, hogy ok miert nem kapnak ebbol a josagbol :) Ha viszont megcsinalnad HSA-ra is es OpenCL-re is, akkor meg az lenne a gond, hogy jo esellyel eltunne a HSA elonye, es az lenne az igazi PR-katasztrofa :) Mert arrol nem szolnak a hiradasok, Abu se gyakran emlegeti, hogy ha egy adott problemat meg tudsz oldani OpenCL-lel is, es HSA-val is, es egy adott vason mindketto hasznalhato, akkor nagyon keves olyan eset van, amikor a HSA nagyobb teljesitmenyt tud nyujtani. Mas teszta persze, ha OpenCL-lel keptelenseg megoldani normalisan a problemat, de a HEVC dekodolas ugy tunik, siman megy OpenCL-lel is...

    "Nincsenek leejtve az Nvidia és Intel felhasználók sem, csak ha egyszer az AMD finanszírozza a GPGPU-s változatot, akkor joggal kér cserébe némi előnyt a támogatásban."

    Mar megbocsass, de en mint nVIDIA GPU tulaj (Intel procival) nem kaptam semmit az AMD-tol, se a Strongene-tol. En nagy ivben teszek arra, hogy a Strongene es az AMD mikent fekudtek ossze az OpenCL tamogatas kapcsan. Az en szempontombol csak annyit erzek, hogy le vagyok ejtve. Kaptam GPU-gyorsitott HEVC dekodert? Nem. Kapni fogok? Majd egyszer, talan. Na itt a baj. Egy felhasznalo szamara teljesen mindegy, hogy mi az oka annak, hogy kimaradt a "tutibol", a lenyeg az, hogy kihagytak. Szoftver fejlesztokent nekem nem lenne pofam ilyet csinalni, de teny, hogy en nagyon kis hal es egy abszolut amator, koca programozo vagyok az AMD-hez vagy a Strongene-hez kepest :U

    "Azért érv, mert ha lassabban futna pl. Nvidián, mint elvárható lenne, azzal kitették volna magukat az Nvidia és/vagy Nvidia fanok támadásának, hogy ez biztos szándékos húzás, ami etikátlanabb, mint későbbre halasztani a támogatást"

    Marpedig lassabban fut, mint elvarhato lenne. Az elvarhato az lenne, hogy ha OpenCL-t tamogat a szoftver, akkor GPU-n is futnia kene. nVIDIA-n is, Intelen is. Ergo, ha direkt nem hasznalhato az OpenCL optimalizacio a GPU-n, akkor ott az elvarhato teljesitmeny nincs meg. Es igen, szerintem szandekos volt ez az egesz, csak az nem vilagos, hogy pontosan mi van a szinfalak mogott.

    "Korábban kérdezted, miért terjed olyan lassan az OpenCL alkalmazása? Nos, talán mert az Intel egyelőre inkább az SSE/AVX-es fejlesztést támogatja. Ezzel is valamilyen módon versenyeznie kell az AMD-nek."

    Mi koze a kettonek egymashoz? Az nVIDIA-nal ott a CUDA, regebb ota nyomja, mint hogy egyaltalan OpenCL letezett volna. Megsem tolonganak a CUDA fejlesztok sem, es az OpenCL fejlesztok sem. Pedig az nVIDIA az OpenCL-t is tamogatja. Nem feltetlenul azt nyomjak, de nem is allnak az ember utjaba, ha az OpenCL-t valasztja es nem a CUDA-t. Plusz, a CUDA es az OpenCL kozott eleg durva atfedes van, ergo ha az egyikhez ertesz, a masik is menni fog siman. Tehat van AMD+OpenCL, Intel+OpenCL (lightosan), nVIDIA+CUDA, nVIDIA+OpenCL, es megsem terjed a dolog igazan szepen. Ennek azert kell hogy legyen oka, de persze ezt csak azok latjak igazan, akik konkretan fejlesztenek is GPGPU-ra valamilyen szinten, vagy legalabbis megprobaltak beletanulni. Meggyozodesem egyebkent, hogy rengeteg C/Delphi/Java/VB/.NET fejleszto megprobalkozott a GPGPU temaval, csak feladtak, meg tul neheznek, tul korulmenyesnek, tul elrugaszkodottnak talaltak azt a megszokott fejlesztoi kornyezetekhez, a megszokott nyelvekhez kepest legalabbis.

    [ Szerkesztve ]

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