2. Fórumok
  3. Videokártyák
  4. Az AMD elérhetővé tette az OpenVideo Decode API-t
Keresés

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

  • #50 Meteorhead aktív tag leviske #49
    Új Válasz #50
    Ú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

    Meteorhead

    aktív tag

    válasz leviske #49 üzenetére

    NV nincs olyan helyzetben, hogy diktáljon?!?! :D Ez nagyon tetszik! Bár igazad lenne... NV még mindig a CUDA-val nyert előnyét lovagolja meg és szándékosan hanyagolja el OCL 1.1 driver kiadását. Olyannyira diktál, hogy a többség OCL 1.0-val foglalkozik, mert NV még csak azt támogatja. 6 hónapja nem képesek egy új drivert kiadni ami vinné. Gusztustalan és szánalmas. (Én ezért utálom NV-t, mert rengeteg ilyen húzásuk van) Persze mindenki védi a piaci pozícióját, de amikor valaki ennyire látványosan lehetetleníti el a gyártó-független szabvány terjedését, akkor azért felforr a vérem. Senkinek sem fájna, ha tényleg OCL-en keresztül mérlegre lehetne tenni a kártyákat. NV kártyák nagyon jók és a GPGPU szegmensben bármikor megállják a helyüket, bármilyen API-n keresztül is éri el őket az ember.

    Én személy szerint AMD párti vagyok, de ez hosszú és kitartó (ön)lejáratókampányába került Intelnek és NV-nek is. AMD azért nyomatja OCL-t annyira, mert neki nincs más. Intel is azért kapaszkodik mert neki sincs más, de neki is van miért csinálni. OCL-en keresztül lehet majd Knights Corner kártyákat értelmesen programozni. Nekem nem fáj, hogy csak a HPC szegmensben fognak játszani, mert én HPC programokat írok. :) És léteznek olyan alkalmazások, ahol a shaderek túl fájdalmasak és lenne létjogosultsága Intelnek is.

  • #47 Meteorhead aktív tag Pikari #34
    Új Válasz #47
    Ú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

    Meteorhead

    aktív tag

    válasz Pikari #34 üzenetére

    Igazad van Pikari, ez nem egy rossz elrendezés, és az Intel Larrabee chipje (amiből volt alaplapra gyógyított variáns) az pontosan ezt csinálta. A koncepció (annak aki nem tudná) az volt, hogy sokkal egyszerűbb x86 magokat csinálni, de sokkal többet (16 azt hiszem). A magok pedig teljesen szabadon számolhattak x86 binárist vagy DX9 API-n keresztül grafikát. A probléma csak ott volt, amikor grafikát kellett számolni. Ugyanis xar volt. Kicsi, kevés, keskeny, sovány, vékony.

    A probléma a bonyolultságában rejlik, és nem az elrendezésnek, hanem az x86-nak. Itt nem architektúrális bonyolultságról van szó, ez ARM-mal és semmi mással sem lehetne kivitelezhető ilyen formában, mégpedig a végrehajtóegység bonyolultsága miatt. Egy x86 mag ha meglát egy sinust, kiszámolja, ha meglát egy if()-et, talán át is tudja ugorni anélkül hogy kiértékelné a belsejét (kód előre olvasás). Egy shader ha sinust lát, egy szorzás 137-szeres műveletigényével ki is számolja (dupla pontosságról már nem is beszélek), ha if()-et lát... akkor megáll a világ.

    Amire szerintem Pikari gondol az mostanság van készülőben, csak nem verik nagydobra. AMD-nek vannak népbutító marketing videói, mennyivel jobb Llano játékban mint Sandy Bridge ha közben excel számol háttérben és filmet nézel. (Fixed funkciós egységek fitogtatása) Mindez azért van, mert Sandy Bridge IGP-je osztozik a CPU cache-ével (amit az excel rendszeresen kipurgál, ezért megy xarul a játék). MERTHOGY Intel arra utazik, hogy olyan C compilert írjon, ami magától felismeri a vektorosítható műveleteket és azokat minden programozói kijelentés nélkül az IGP-n hajtsa végre. Ez már egy igazi összeolvadása a két egységnek.

    Látható, hogy minden csak stratégia kérdése, nem biztos, hogy az erős integráció járható út (Larrabee), lehet hogy a picit herélt mód (Sandy Bridge) lesz a járható, vagy a jó API-kon keresztüli megoldások (Fusion). Én személy szerint az utolsó mellett tenném le a voksomat, de ez ízlés kérdése.

    A fixed function videodekódoló egységek pedig igenis jó dolgok, bármit is mond bárki. Nem cserélődnek olyan gyorsan a közkedvelt codec-ek, hogy ne működne a dolog.

  • #21 Meteorhead aktív tag Pikari #8
    Új Válasz #21
    Ú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

    Meteorhead

    aktív tag

    válasz Pikari #8 üzenetére

    Nem kifejezetten szeretem, amikor a fórumozó népek összefognak és szétszedik az egyetlen más állásponton lévőt, úgyhogy maradok a kultúr véleménynyilvánításnál.

    Pikari, ugyan még nem írtam videotömörítést OpenCL-ben, de a legeslegelső OCL béta SDK óta nyúzom az APIt (szinte főállásban) és határozott véleményem, hogy ez nem bonbonos doboz. Ha megnézed 1.1.7-es VLC GPU gyorsított codecjét, akkor látni fogod, hogy egy vicc. (1.1.8-ra csináltak valamit, de még mindig nem az igazi)

    Adat GPU-ra >> decode >> adat vissza CPU-ra >> post-process >> vissza GPU-ra >> display

    Ugyan GPU accel, de szaggat mint atom, rosszabb mint a sima CPU-s ami tökéletesen működik a 8GB-ba tömörített HD-knál, csak a 25GB+ videok fekszik meg a gyomrát mezei masinákon.

    Az értelme ennek az egésznek, hogy egy egységes felület adódik az ilyen problémák nagyon szép és frappáns kiküszöbölésére. Az ember streameli adatot GPU-ra, UVD egyszerű preprocess formában dekódolja az adatot, OCL kernel postprocess javításokat használ rajta és küldi OGL-nek megjeleníteni. Nagyon szép moduláriás és robusztus rendszer.

    Hogy mire jó a frappáns elrendezés? Ezzel lehet igazi varázslatot csinálni. Gondolom mindenki látott már 100+Hz TV-n frame beillesztő eljárást, és hogy mennyivel simább lesz tőle a videó. Az ilyen szép strukturált programokkal lehet ilyet csinálni gépen is tv nélkül. UVD dekódol képet küldi OCL-nek, OCL vár még egy frame-re, amikor másodikat kapja interpolál egy kockát a kettő közé (ami számításigényes buli ha szépen akarod megcsinálni), postprocess az első és az interpolált képre és mehet OGL-nek megjelenítésre, már nem 29.7 hanem 59.7 fps streamként.

    Ettől a felhasználó már hanyatt esne. Hadd ne folytassam, hogy az encode és transcode variációkkal miket lehet még csinálni, de hidd el hogy az ilyen dolgokért nagyon sokan ölni tudnának (köztük én is). És szeretném kihangsúlyozni, hogy AMD nem olyan mint buzi Intel vagy NV, hogy ahol tudják kiszorítják a konkurenseket, hanem nyílt szabványba invitálja a népeket.

    Remélem sikerült megvilágítani Pikari és a kétkedők számára hogy miért jó ez.

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