Új hozzászólás Aktív témák
-
Még nem sok minden, de azért kell ilyen progikat kihozni, hogy amikor majd jönnek az ilyen videók, akkor ne félkész szoftverekkel kelljen szívni, hanem addigra legyen kiforrott szoftverpark.
Addig kell a szoftvert és a drivereket csiszolni, amíg nincs nagy tétje.
[ Szerkesztve ]
Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html
-
#7
Meteorhead
aktív tag
Meteorhead
aktív tag
Milyen kiterjesztés kell hozzá, amit csak az AMD támogat? Intel is mindent visz 1.2-ből amit lehet még az IGP-n is. Ha a cl_amd_media_akármi miatt megy csak AMD-n, akkor tökön bököm magam. Az aztán tényleg nem feature.
-
Peter13
senior tag
-
Cathulhu
addikt
Ha windows only, akkor sokra nem jo. Desktopon/notebookban szerintem sokkal kesobb lesz 4K attores mint akar a mobil piacon, de akar beszelhetunk dedikalt medialejatszokrol, okostevekrol. Oda kellene keveset fogyaszto, lehetoleg cross-platform, de minimum linuxon mukodo, hatekony dekoder.
Ashy Slashy, hatchet and saw, Takes your head and skins you raw, Ashy Slashy, heaven and hell, Cuts out your tongue so you can't yell
-
#11
Fiery
veterán
Meteorhead
#7
Fiery
veterán
válasz
Meteorhead
#7
üzenetére
Erre en is kivancsi lennék...
-
Fiery
veterán
Nekem ugy tunik -- de majd Abu megmondja a frankot --, hogy ebben az OpenCL dekoderben kb. annyi a nyilt es fuggetlen OpenCL, mint a mackosajtban... En ugy latom, mint ha ez a cucc eloreforditott AMD-IL binarisokat hasznalna (clCreateProgramWithBinary), AMD GPU architekturankent kulonallo binarisokat (pl. Lent_idct_Hawaii.dll), ergo eselye sincs mas (Intel, nVIDIA) architekturanak labdaba rugni. Alapos munkanak tunik, de az egesznek pont az a celja (vagy epp side-effect-je, ki hogyan ertekeli), hogy ha letezik is mogotte egy OpenCL forras, az me'g veletlenul se fordulhasson le vagy futhasson Intel vagy nVIDIA GPU-n. Ennyit arrol, hogy az AMD nyilt, jofej es mindenkivel megosztja a sajat technologiajat... Ennyi erovel CUDA-rol is beszelhetnenk, az legalabb kimondva is zart az nVIDIA szemszogebol.
Persze a kernel forrasok ismerete nelkul nehez megmondani, hogy valojaban mennyi es milyen kritikus OpenCL kiterjesztest igenyel a kod, es hogy valojaban meg lehetett volna-e csinalni ezt az egesz dekodert minimalis modositassal mas architekturara is.
Az is erdekes, hogy cca. 74%-kal nagyobb az AMD-IL kod merete a VLIW-es GPU-kon, mint a GCN-eken. Meg persze az egesz dekoder 17 MB-tal kisebb meretu lenne, ha nem eloreforditott AMD-IL binarisokat hasznalna, hanem rendesen forraskodbol dolgozna. Persze a mai vilagban mi a 17 mega...
[ Szerkesztve ]
-
Fiery
veterán
Tudtommal nem. A dolog szerintem nagyjabol ugy nezett ki, hogy a Strongene-nek nem volt eroforrasa/tudasa/embere arra, hogy a CPU-ra megirt dekodert (GP)GPU-ra portolja, ezert felkereste az AMD-t (es -- talan -- a masik 2 GPU gyartot is), hogy ok fejlesszek ki a portot. Az AMD ezt elvallalta, es -- amennyire en meg tudom itelni -- teljes egeszeben a sajat fejlesztoi altal keszitett egy AMD GPU portot a dekoderhez, ami sajnos nem kompatibilis mas GPU architekturakkal. Kerdes, hogy a (GP)GPU piac ilyen iranyu alakulasa kinek jo valojaban, es vajon mennyi jovoje van ennek az egesznek igy. A szoftver fejlesztok hagyomanyosan megallnak az SSE optimalizacional, de a (GP)GPU tema mar tul magas a legtobbnek. Kerdes, hogy mennyire van ertelme es letjogosultsaga annak a trukknek, amit az AMD csinal, azaz hogy a szoftverfejleszto cegek helyett megirjak az OpenCL kerneleket. En amondo vagyok, egy-egy kiemelt esetnel ez mukodhet, de nagy tomegben az AMD-nek sincs kapacitasa arra, hogy a szoftvercegek munkajat a sajat fejlesztoivel oldja meg. PR fogasnak jok ezek a kiemelt esetek, precedens erteku lehet sokak szamara, meg persze mi mint felhasznalok csak nyerhetunk ezzel, de jovoje ennek, ilyen formaban szerintem nincs. A HSA ezen valtoztathat, bar a jelenlegi helyzet alapjan nem vilagos, hogy mikeppen tudna megvaltozni a szoftvercegek hozzallasa a (GP)GPU temahoz.
-
dezz
nagyúr
Most te tényleg az AMD-t szídod, amiért egy tőle független fejlesztő nem teszi közszemlére a kommersz szoftvere tesztváltozatának forráskódját?
(#14): Itt meg tényleg olyasmitől "félted" őket, ami a te feltételezésed (hogy az eredeti fejlesztő helyett dolgoztak)?
Benne van a cikkben, hogy később Intelre és Nvidiára is valószínűleg el fog készülni.
-
Fiery
veterán
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 ]
-
dezz
nagyúr
Értsd meg, hogy a Strongene HEVC dekódere egy zárt forrású, kommersz program. Attól, hogy OpenCL maga nyílt szabvány, még nincs előírva, hogy minden OpenCL kódnak nyílt forrásúnak kell lennie.
És légy szíves, ne állítsd be úgy, mintha az OpenCL valami olyan mágia lenne, amit csak az AMD szakemberei művelnek, más fejlesztők meg hozzá sem szagolnak. Itt a Ph!-n is többen vannak, akik ebben (is) programoznak.
A WinZIP programozói amatőrök, ez látszik a WinZIP-en is (kevésbé hatékony és jóval lassabb, mint a versenytársai és még bumfordibb is az egész program). Nem csoda, hogy az AMD csinálta meg helyettük az OpenCL kódot. Ebből nem lehet túl messzemenő következtetéseket levonni.
Tudsz mondani rá példát (az olyan tesztprogramokon kívül, mint az Everest és az AIDA), hogy más binárist adnak inteles AVX-hez, mint AMD-shez? Én nem tudok ilyenről. Azt viszont el tudom képzelni, hogy a különféle gyártók GPU-n némileg eltérő OpenCL kód fut a legjobban.
Az is benne van a pakliban, sőt talán ez a legvalószínűbb, hogy az AMD támogatta a fejlesztést, ezért cserébe átmenetileg csak AMD vason fut a GPGPU-s változat.
[ Szerkesztve ]
-
Fiery
veterán
"Értsd meg, hogy a Strongene HEVC dekódere egy zárt forrású, kommersz program. Attól, hogy OpenCL maga nyílt szabvány, még nincs előírva, hogy minden OpenCL kódnak nyílt forrásúnak kell lennie."
En megertem, termeszetesen, Te viszont azt nem erted, hogy ha az AMD nem binarisokat szallitott volna a Strongene reszere, es a Strongene fejlesztoi kozott lenne valaki, aki GPGPU/OpenCL temaban kicsit is jartas, akkor nem kellett volna kizarolag AMD-re limitalni az OpenCL tamogatast, hanem minden bizonnyal siman meg lehetett volna oldani mindharom GPU-gyarto termekehez is. Ez a baj a binaris megoldassal. Attol, hogy az AMD es a Strongene kozott nyilt forras lett volna az OpenCL kernel kapcsan, attol me'g nem lett volna kotelezo a Strongene-nek nyilvanossagra hozni a kernel forrast. Pl. a Sandra is kernel forrasbol dolgozik (pont azert, hogy minden GPU-gyarto termeken fusson a GPGPU kod), megsem latod magat a kernel forrast a szoftverben sehol, kulonosen nem a dokumentacioban.
"És légy szíves, ne állítsd be úgy, mintha az OpenCL valami olyan mágia lenne, amit csak az AMD szakemberei művelnek, más fejlesztők meg hozzá sem szagolnak. Itt a Ph!-n is többen vannak, akik ebben (is) programoznak."
Kar, hogy a gyakorlat mast mutat. Nyilvan van jo nehany fejleszto, aki OpenCL-ben es CUDA-ban is jol dolgozik, csak epp ha a "big picture"-t nezed, azaz a vilag osszes x86 PC-re dolgozo fejlesztojet, akkor azok kozt elenyeszo szamban vannak azok, akik kepesek lennenek egy x264 vagy HEVC dekodert, vagy epp egy WinZip-et portolni GPGPU-ra. Mas kerdes irni egy hello world appot OpenCL-ben (ertsd: egyszeru matrix szorzas vagy FFT), egy kicsivel nagyobb lepcso mondjuk fraktalokat szamolni OpenCL-ben, megint kicsivel nagyobb ugras mondjuk ray-trace engine-t irni, es ahogy megyunk egyre feljebb a komplexitas lepcsojen, ugy kopnak ki a magukat jo OpenCL fejlesztonek mondo programozok. Pedig mar indulasnak sincsenek sokan, az osszes lepcsot egybeveve
Vagy ha szerinted olyan baromi sok gyakorlott, tapasztalt, penge OpenCL/CUDA fejleszto van a vilagon, akkor miert nem terjed jobban/gyorsabban a GPGPU? Miert nem mindenki OpenCL/CUDA-val gyorsitott web bongeszot hasznal, miert nem a GPU szamit mindent, amit csak lehet? Ja, tudom, a HSA hianya, persze... A vegso, mindent megmagyarazo erv
"A WinZIP programozói amatőrök, ez látszik a WinZIP-en is (kevésbé hatékony és jóval lassabb, mint a versenytársai és még bumfordibb is az egész program). Nem csoda, hogy az AMD csinálta meg helyettük az OpenCL kódot. Ebből nem lehet túl messzemenő következtetéseket levonni."
En vonnék le mashonnan is kovetkeztetest, csak mit csinaljak, ha se a WinRAR, se a 7zip, se egyik masik fajl tomorito szoftver sem kerult OpenCL-re vagy CUDA-ra portolasra. Ez megint veletlen? Vagy csak az a gond, hogy mindenutt ugyanolyan fakezu programozok dolgoznak, akik csak a nyamvadek es ezerszer eltemetett x86-hoz ertenek?
"Tudsz mondani rá példát (az olyan tesztprogramokon kívül, mint az Everest és az AIDA), hogy más binárist adnak inteles AVX-hez, mint AMD-shez"
Felteteles modot hasznaltam, szerintem el kene olvasnod alaposabban, amit irtam...
"Azt viszont el tudom képzelni, hogy a különféle gyártók GPU-n némileg eltérő OpenCL kód fut a legjobban."
Ez abszolut igy van, csak epp kezdesnek kellene egy OpenCL kernel, amit aztan lehet tesztelgetni, profilozni a tobbi GPU architekturan. A Strongene-nel ez a lehetoseg nem adott.
"Az is benne van a pakliban, sőt talán ez a legvalószínűbb, hogy az AMD támogatta a fejlesztést, ezért cserébe átmenetileg csak AMD vason fut a GPGPU-s változat."
Es ez igy rendben van? Mert szerintem nem igy kellene ennek mukodnie. Az AMD GPU-val rendelkezo felhasznalok szempontjabol mindenkepp jo ez igy, csak ahogy fentebb is irtam, nem gondolom, hogy ez egy mukodokepes modell lehet. Az AMD-nek sincs annyi eroforrasa, hogy minden szoftverceg hozza outsource-olja a GPGPU fejleszteseket...
[ Szerkesztve ]
-
dezz
nagyúr
Egyelőre nem tudhatjuk biztosan, hogy (szintén egyelőre) miért csak AMD-n fut a GPGPU-s változat. Te azt feltételezed, hogy azért, mert az AMD szállította az OpenCL-ből fordított binárisokat. Ez következetlenség a részedről, hiszen korábban sokat írtál arról, hogy sokszor ugyanaz a kód itt vagy ott hibásan fut. Azt sem zárnám ki, hogy némileg eltérő OpenCL kód kedvez az egyik vagy a másik GPU architektúrának. És itt van még az a lehetőség is, hogy az AMD anyagilag támogatta a céget a GPGPU-s változat elkészítése érdekében, amiért cserébe átmenetileg az csak az AMD-n fut.
Az összes programozó közül ugyanúgy nagyon kevesen vannak, akik SSEx/AVX kódot készítenek és az összes program közül is nagyon kevés használja. Mégsem mondható, hogy lényegében bukás az SSEx/AVX, mert akadnak, akik használják és van egy sor jelentős program, ami használja. Az OpenCL-lel hasonló a helyzet, vannak, akik használják és már van egy sor program, ami ennek segítségével bírja munkára a GPU-t.
Nem számít, hogy feltételes módot használtál, mert általánosságban kérdeztem.
"A Strongene-nel ez a lehetoseg nem adott."
Megint feltételezésekre alapulóan teszel tényállításokat. Simán lehet, hogy nem vagy nem jól (lassan vagy hibásan) futott más gyártók GPU-in, ezért azokat egyelőre hanyagolták. Főleg, ha AMD finanszírozással készült.
A végén anyagi támogatásról beszéltem, de sikerült teljesen máshogy értelmezned.
-
Fiery
veterán
"Te azt feltételezed, hogy azért, mert az AMD szállította az OpenCL-ből fordított binárisokat."
Azert feltelezem ezt, mert a HEVC dekoder felepitese egyertelmuen erre enged kovetkeztetni.
"Ez következetlenség a részedről, hiszen korábban sokat írtál arról, hogy sokszor ugyanaz a kód itt vagy ott hibásan fut."
Nem ertem, mi az osszefugges. En azt irtam mar sokszor, hogy az OpenCL-lel az az egyik gond, hogy az aktualis videodriverben levo aktualis OpenCL compiler bugjainak ki van teve az a fejleszto, aki OpenCL kernelt valosideju forditas utan futtat. Ezt a problemat -- legalabbis reszben -- nyilvan ki lehet kerulni azzal, hogy OpenCL binarist szallitasz a szoftvereddel, azonban ezzel egy adott architekturahoz lancolod a szoftvert. Ha pl. csak az AMD-nel maradunk, akkor is elvagod magad a jovobeni architekturak tamogatasatol a binaris modszerrel. A HEVC dekoder az Iceland, Hainan es Tonga architekturakhoz is tartalmaz binarisokat, ez egyreszrol valamennyire jovobemutato, hiszen ezek jovobeni architekturak; viszont az ezeken felul megjeleno architekturakat mar nem fogja ez a HEVC dekoder tamogatni. Mig, ha OpenCL kernelt hasznalnanak, akkor (az Intel es nVIDIA GPU-k tamogatasan felul) nyitva hagyhatnak a lehetoseget annak is, hogy egy jovobeni AMD architekturan is modositas nelkul fusson a dekoder jelenlegi verzioja. Persze kozben ott van a compiler problema is, nyilvan, de ezt meg at lehetne hidalni pl. egy hibrid megoldassal: az AMD binarisokon felul lehetne hasznalni kernelt is, es akkor a kecske is jollakna es a kaposzta is megmaradna. Vajon miert nem ezt az utat valasztotta a Strongene? Mert az AMD-nek nem allt volna erdekeben, ilyen egyszeru. Az Intel es nVIDIA GPU-val rendelkezo felhasznalok -- akik mellesleg a PC-felhasznalok tobbseget teszik ki -- meg le vannak ejtve...
"Azt sem zárnám ki, hogy némileg eltérő OpenCL kód kedvez az egyik vagy a másik GPU architektúrának."
Ez nyilvan igy van, csak nem ertem, mit akarsz ezzel mondani. De me'g ha nem is aldozna idot a Strongene arra, hogy kulon Intel, kulon nVIDIA optimalizalt OpenCL kernelt keszitsen, egy unified kernel is sokkal jobb megoldas lenne, mint CPU-val dekodolni a videokat...
"És itt van még az a lehetőség is, hogy az AMD anyagilag támogatta a céget a GPGPU-s változat elkészítése érdekében, amiért cserébe átmenetileg az csak az AMD-n fut."
Termeszetesen elkepzelheto, bar en nem latom ennek tul nagy eselyet. Az AMD-IL binarisok, plane ugy, hogy minden AMD GPU csaladra kulon binarist keszitettek, nagyon alapos, nagyon profi munkara utal. Olyan munkara, amit leginkabb csak az AMD maga akar es kepes megcsinalni. Ezzel nem lebecsulom a Strongene fejlesztoinek kepessegeit, sot. Csak epp egy akarmilyen szoftverceg nem allna neki ilyen szinten berhelni az AMD GPU-ival, hiszen -- normalis esetben -- az ebbe belefeccelt idot inkabb arra forditaná, hogy a masik 2 GPU gyarto termekein is fusson a cucc. Par %-kal alacsonyabb teljesitmeny egy regi VLIW-es AMD GPU-n szerintem megerne annyit, hogy Intel es nVIDIA GPU-n is szepen szaladjon a dekoder -- kiveve persze ugye ha eleve nem cel az, hogy barmin fusson, ami nem AMD.
Ez az egesz egyebkent a felig tele - felig ures pohar tipikus esete. Te mint AMD-vel szimpatizalo emberke azt latod, hogy a HEVC dekoder nagyon alapos, nagyon franko OpenCL optimalizaciot kapott AMD GPU-kra, es ennek orulsz, hiszen felig tele van a poharad. En meg abbol az iranybol kozelitem meg, hogy miert nem kapott Intel es nVIDIA GPU-ra is OpenCL optimalizaciot a dekoder, plane ugy, hogy a PC felhasznalok tobbsege pont e ket gyarto GPU-jat hasznalja? Nekem ez egy hianyos termek igy, egy rossz koncepcio eredmenye, egy felig ures pohar.
"Simán lehet, hogy nem vagy nem jól (lassan vagy hibásan) futott más gyártók GPU-in, ezért azokat egyelőre hanyagolták. Főleg, ha AMD finanszírozással készült."
Elkepzelheto, csak epp nem valoszinu. Ha az AMD keszitette az OpenCL binarisokat, es az OpenCL kernelt odaadta volna a Strongene-nek (miert tette volna, ha eleve nem volt cel, hogy nem-AMD GPU-n is fusson a dekoder?), akkor minden tisztesseges ceg legalabb megprobalta volna mukodesre birni azt mas architekturakon is. Az nVIDIA OpenCL compilere pedig az en szemelyes tapasztalatom szerint van annyira jo, hogy minden bizonnyal be lehetett volna roffenteni a cuccot minimalis modositassal. Az Intel mas teszta, az o compileruk sz*r, azon siman lehet, hogy nem megoldhato a dekoder portolasa, me'g kisebb compiler modositasokkal/patkolasokkal sem
A lassan futas pedig nem jo erv, hiszen me'g egy lassu GPU is gyorsabban dekodolja a HEVC-t, mint egy mainstream x86 CPU.
[ Szerkesztve ]
-
Fiery
veterán
"Tudsz mondani rá példát (az olyan tesztprogramokon kívül, mint az Everest és az AIDA), hogy más binárist adnak inteles AVX-hez, mint AMD-shez?"
Ahhoz, hogy erre egyertelmu valaszt lehessen adni egy adott szoftver eseteben, ismerni kellene a konkret kodot, ami fut a CPU-n. Mert a PR-anyagban maximum a benchmarkoknal (AIDA64, Sandra) reklamozzak a CPU generacio specifikus AVX optimalizaciokat, real-world applikacioknal erre nem szoktak kiterni. A reverse-engineering pedig nem olyasmi, amit etikus vagy legalis lenne hasznalni, ha ilyesmire vagy kivancsi
-
dezz
nagyúr
Akkor máris két okát is láthatjuk, miért nem az OpenCL kódot adják, hanem a binárisokat:
1. Nem open-source fejlesztés.
2. Az OpenCL fordítók hibáinak kikerülése.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.
OpenCL kernel = OpenCL forráskód, nem? Mert akkor lásd fenti 1. pont!
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?
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ó.
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.
"A lassan futas pedig nem jo erv, hiszen me'g egy lassu GPU is gyorsabban dekodolja a HEVC-t, mint egy mainstream x86 CPU."
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.
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.
-
Fiery
veterán
"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 novelhetoA 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
"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 ]
-
dezz
nagyúr
Az Intel korábbi ténykedésének (fordítós trükközés) következményeként volt olyan, hogy egyes szoftverek csak Intelen használták ki az SSEx-t, miközben ott volt már az AMD procikban is. Nem vettem észre, hogy annak idején regényeket írtál volna az ezen való felháborodásodban.
Olyan is volt, hogy az Intel fontos distributed computing projektet pénzelt azzal a feltétellel, hogy még akkor is kizárólag CPU-n fusson, amikor már több hasonló jó ideje GPGPU-ban utazott. És máig van olyan, tesztelésre is használt jelentős szoftver (Maxon Cinema/CineBench), ami kimondottan Intelre optimalizált.A hozzáértésnek több szintje van. Sosem állítottam be úgy, mintha OpenCL-ben programoznék. (Ez később még változhat.) De azt hiszem, az átlag fórumozónál azért többet tudok róla. Szerintem erről a forráskód-titkosítási lehetőségről sokan nem hallottak még, akik napi szinten beszélnek az OpenCL-ről.
Az általad korábban elmondottak alapján ez a futás idejű fordítás eléggé nyögvenyelős dolog, minden OpenCL driver verzióval tesztelni kell minden GPU típust, stb. Nem minden fejlesztőnek van erre ideje.
"De a binaris kodokat is vissza lehet fejteni, csak az kicsivel nagyobb melo."
Sokkal nagyobb meló.
"nem csak az AMD APU-s PC-den, de maradjunk most az x86-os PC-knel, ez a jelen rogvalosag."
Nem egészen, mert ott van pl. a PS4 is. Sok megoldás ott fog először megjelenni és utána hozzák át PC-re. Pl. fizikai szimulációs megoldások és egyéb olyan számítások, amit nem csak játékprogramokban lehet felhasználni.
Nem tudom, miért állítod szembe egymással a HSA-t és az OpenCL-t. A HSA nem egy programnyelv, hanem egy architektúra, amire többféle nyelven lehet majd programozni, ezek közül az egyik az OpenCL.
Intel+Nvidia tulajként miért várod el, hogy kiszolgáljon az AMD? Az AMD GPU-k támogatása (a standard CPU-s támogatáson felül) egy plusz, amiért az AMD fizetett. Inkább az Nvidiánál és az Inelnél kellene reklamálni, hogy ők miért nem támogatják az ilyen irányú fejlesztéseket...
"Mi koze a kettonek egymashoz?"
Az, hogy ha az Intel az SSE/AVX támogatást támogatja (
), netalántán a kimondottan Intel CPU-ra való optimalizálást, akkor nem fog egy cég ingyen nekiállni az OpenCL-es támogatásnak.Elég sok CUDA-s program van, csak ezek nagy része nem hétköznapi felhasználóknak szánt PC-s szoftverekbe kerül. OpenCL támogatású programból is van már egy sor.
"rengeteg C/Delphi/Java/VB/.NET fejleszto megprobalkozott a GPGPU temaval, csak feladtak, meg tul neheznek, tul korulmenyesnek, tul elrugaszkodottnak talaltak"
Nem baj, ők majd megvárják, amíg ezekben is lehet programozni HSA-ra. Lásd pl. Java 9, Project Sumatra.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Igen. A Strongene előre fordított binárisokat használ. De az aktuális kód amúgy sem működne az összes hardveren. Azokra másik kód készül. Egyébként azok is binárisok lesznek.
Tudtommal OpenCL-re még az Ittiam és a Telestream is így szállít programot. Azt nem tudom, hogy ők mennyire vannak készen a munkával. Az Ittiam már bemutatta az ARM-os megoldását, míg a Telestream még csak zárt környezetben mutatta be a Switch lejátszót, de az első körben biztosan csak Kaveri APU-n fog futni.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Strongene nem marad ennél a modellnél. Ők már a pekingi APU konferencián elmondták, hogy a jelenlegi megoldásukat leváltja majd egy szabványos HSA alternatíva, ami mindenkinek a hardverén képes futni. Az Ittiam és a Telestream is mondta korábban, hogy hosszútávon a HSA-ban gondolkodnak, így az OpenCL, előre fordított binárisokkal csak egy átmeneti megoldás.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Átolvasva a vitát ... szerintem a Fusion Fund a fő oka annak, hogy az AMD-re hamarabb jelenik meg OpenCL támogatás egy-egy alkalmazásban, vagy exkluzív OpenCL alkalmazás jön. Bár a Fusion Fund nem tartozik szorosan az OpenCL-hez, de lényegében arról szól, hogy ha valami gond van, akkor meg lehet keresni az AMD-t, és adnak anyagi támogatást, vagy csupán szakértelmet, illetve más támogatási formákba is be lehet lépni. Ez attól függ, hogy ki mit akar, vagy ki mit kér.
Az is fontos tényező lehet, hogy az Intel és az NV, illetve az AMD fejlesztési stratégiája eltér. Az előbbi két cég fejleszti az újításokat és idővel azok megjelennek, majd megkapják a fejlesztők. Viszont senki sem kérdezte meg őket, hogy akarjátok-e, vagy jó ötletnek tartjátok-e. Szimplán itt van, ez a jövő, és ezt kell használni. Az AMD még 2010 közepén vezette be hivatalosan azt a modellt (de már Dirk kinevezésével is élt, csak fű alatt), amelyben a fejlesztők partnerei lehetnek a cégnek, és leadhatják a rendeléseiket, hogy mit is akarnak látni a jövő hardvereiben. Na most az AMD manapság teljesíti ezeket az igényeket. Ezzel azt érzik a partnerek, hogy számít a szavuk, és nem valami marhaságot akarnak lenyomni a piac torkán. Például kevesen tudják, hogy a SAD4 opcionális szabványosítása mellett a QSAD és az MQSAD az AMD hardvereiben az Adobe, Cyberlink, Microsoft, stb. szoftvercégek kérése volt. Az AMD boldog volt a SAD4-gyel, de kérték, hát belerakták.
Nyilván valahol egyet lehet érteni az AMD-vel, mert a hardverekre a szoftvercégek írják a szoftvert, és ha ők akarnak valamit, akkor azt talán érdemes teljesíteni. Ugyanakkor a másik álláspont az, hogy ez a modell ugyan a szoftvercégek számára jó, de lojálisak lehetnek az AMD iránt, és az árt az Intelnek, vagyis bizonyos programfunkciók kihasználásához AMD hardverre kényszerül a piac. Ez önmagában nem lenne baj, de esélyes, hogy az Intel technológiáikat (akár elterjedt/szabványosakat is) már nem is veszik számításba (lásd AVX/AVX2), mert nem feltétlenül értenek már egyet azzal a gyakorlattal, hogy mindenképpen egy hardvercégnek kell megmondani merre menjenek a szoftverfejlesztések.
Ez egy meglehetősen furcsa lavina, amit az AMD elindított pár éve. Pont ott hatnak a fejlesztőkre, ahol a legjobban meggyőzhetők, ezzel elnyerik a támogatásukat, még úgy is, hogy a program esetleg nem fut a konkurens hardvereken. Persze elő lehet jönni azzal, hogy szégyellhetik magukat a fejlesztők, de ők annyira mámorban vannak attól, hogy meghallgatták őket, hogy eszükbe sem jut az, hogy csak az egyik gyártót támogatják.
Bár a témához nem kapcsolódik, de csak nézzétek meg Johan Andersson, Dan Baker, Joshua Barczak, John Kloetzli Jr, Chris Kingsley, stb. PC-s kutatási kedvét a Mantle után. Újra elkezdtek radikálisan technológiákkal dolgozni, amiket évek óta nem tettek meg, mert nem működtek az API-k és tudták, hogy úgyis kukában végezte volna a projekt. De most úgy tekintenek a Mantle-re, mint egy gyerek egy új Legóra. Végre újra tudnak szórakozni. Visszakapták azt az időszakot, amit a 2000-es évek közepétől fokozatosan elvettek tőlük. Dan Baker például a Nitrous terrain erosion rendszerét átírta Mantle-re AVX2-ről. Százszorosára gyorsult R9 290X-szel a Haswellhez képest. Más API-ban ehhez hozzá sem fogott volna.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Vagy csak valami "egzotikum" hogy ilyen is legyen?
Olyan is volt, hogy az Intel fontos distributed computing projektet pénzelt azzal a feltétellel, hogy még akkor is kizárólag CPU-n fusson, amikor már több hasonló jó ideje GPGPU-ban utazott. És máig van olyan, tesztelésre is használt jelentős szoftver (Maxon Cinema/CineBench), ami kimondottan Intelre optimalizált.
Új hozzászólás Aktív témák
ph A 2.0-s fejlesztés az alapcsomagot, illetve egy OpenCL-es opciót is kínál.
- Megjelent a Moondrop audio-fókuszú telefonja Kínában, lesz globális verzió is
- eBay-es kütyük kis pénzért
- Opel topik
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen okostelefont vegyek?
- Motorola Moto G24 Power - hol van az erő?
- Kínai, és egyéb olcsó órák topikja
- Olcsó sportkamerák (GoPro alternatívák)
- Politika
- Anglia - élmények, tapasztalatok
- További aktív témák...
