- Xiaomi 13 - felnőni nehéz
- Milyen okostelefont vegyek?
- Samsung Galaxy A35 5G - fordulópont
- iPhone topik
- Vékonyabb lett, jobb kamerát kapott, de az akku maradt a régi: itt a Fold7
- Poco F6 5G - Turbó Rudi
- Samsung Galaxy Watch7 - kötelező kör
- Apple Watch Sport - ez is csak egy okosóra
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Változó design, tekerhető lünetta: megjött a Galaxy Watch8 és a Classic
Új hozzászólás Aktív témák
-
julius666
addikt
Már leírták előttem, de kb. lövésed sincs a videó dekódoláshoz (meg úgy ámblokk kicsit underage megmondóember szaga van a kommentednek).
Mondjuk annyiban egyetértek, ez az új API átlagos végfelhasználói szempontból különösebb megváltást nem fog hozni. Windowson hardveres gyorsítás eddig is megvolt DXVA-val, az értelmesebb post-process effektek nagy részét shaderekkel meg tudták oldani (a Linuxos oldalt annyira nem ismerem ott pontosan mit és mivel lehet, de ezekre ott is van mód).
Illetve a videó tömörítést magát én sem forszíroznám a GPU-n, a jelenlegi megoldások rettentően ratyik és a jelenlegi hardverfelépítés mellett jelentősen jobbra nem is nagyon van kilátás. Esetleg egy megfelelő minőségű, az egyes lépésekhez fix funkciókkal rendelkező dedikált egység (lásd dekódolás) lehetne előrelépés (az Intel ugye ezzel próbálkozott is a Sandyban, bár az is elég ratyi lett minőségben, illetve túl "merev", nem lehet belepiszkálni eléggé a működésébe).
Ellenben mégiscsak nagy szó hogy végre valaki végre egy komolyabb platformfüggetlen API-t akar csinálni egy ilyen széttöredezett piacon (ahány platform kb. annyiféle API).
-
hát... ne haragudj, de ennek nagy részét nem tudom értelmezni...
"A probléma szerintem nem ezeknek a technológiáknak, inkább az egész GPU alapú filmgyorsításnak a létjogosultságát kérdőjelezi meg. Tényleg szűkség van rá, és tényleg működik a gyakorlatban?"
A VGA alapú dekódolásnak nem az a lényege, hogy kikerüljük vagy csökkentsük a memóriaírást (azt végképp nem értem, a te elképzelésedben hol szerepel a memória, ha már az első mondatban azon akadtál meg, hogy oda kerül a megjelenítendő anyag), hanem az, hogy az iDCT és a MoComp, deblock vagyis az alapvető műveletek ne egy általános egység kezében legyenek (CPU), hanem egy erre dedikált eszköznél, ami ezáltal hatékonyabban végzi el ezeket a számításokat. Az off-host folyamatoknak nem a megváltás a célja, hanem például a fogyasztás vagy gyengébb hardver esetében optimálisabb hardverkihasználás.
"A probléma ezzel az, hogy minden egyes videótömörítésre külön meg kell ezt csinálni. 2 hét múlva kijött egy új verzió? Hát szar ügy, mehet vissza a 100ezres videókártya a dobozba, meg a tervezőasztalra, hogy kicseréljenek benne 100 tranyót. Tényleg szűkséges ezeket a GPU-ba integrálni? Vagy a CPU-ba? Nem az."
Itt most akkor mi a konkrét javaslatod, ha nem az, hogy hardveres dekódolás legyen megvalósítva? Tudom, szoftveres, ezt már kifejtetted, de amióta van UVD, azon inkrementális fejlesztéseket végeznek (és nem azért, mert a H.264 gyökeresen megváltozott). Nem tartom életszerűnek, amit leírtál. Jól működő rendszerekről van szó. (bár ha a VPD-t vesszük alapul, akkor a szoftveres igényeid is ki vannak elégítve
)""Egy számítógép esetében ennek nincs létjogosultsága. Hisz ilyen technológiák léteznek már 10 éve. Azóta se használja őket senki. Meg ezután sem fogja. Persze az ipar nem először gondolkodik, aztán cselekszik.""
"Hát gyorsítsunk vele videódekódolást. Azt már most mondom, hogy nem fogsz. Ugyanis vagy tranyó szinten beteszik az adott videóformátum dekódolását, és akkor fogsz. Azt az egyet. Vagy egy grafikus kártyára épített streaming műveletekre kihegyezett egységre épített általános célú végrehajtó egységekre épített általános célú interfészemuláción keresztül leprogramozótt dekóderrel fogsz egy papíron x000 gigaflops teljesítményű valamivel dekódolni egy framet - a gyakorlatban, mint láthatjuk, max olyan sebességgel, mint egy Pentium2-n alulról, vagy olyan kinézettel mint egy 15 éves mpeg dekódoló kártyán."
Innen átmentem read-only mdba, mert meggyőződést érzek csak, de szakmai érveket nem a kommentben. Plusz tárgyi tévedésekkel is tele van tűzdelve. Nekem valamiféle rizsának tűnik az egész minden konkrétumot nélkülözve. Ne haragudj, vagy nem tudod elmondani, amit akarsz vagy nem tudom.
-
dezz
nagyúr
Huh, ember! Itt nagyon-nagyon türelmesek veled, de én nem kertelek: ebből a postból tökéletesen lejött, hogy bár alapvetően nem vagy teljesen hülye a számtechhez, de a GPU-s videodekódolás témakérében totálisan járatlan vagy! Úgy is mondhatnám, nagyon le vagy maradva ebben.
Az alábbi videotömörítési formátumok dekódolása már vagy 5 éve hw-esen támogatott az összes ATI/AMD, Nvidia (és többé-kevésbé Intel) GPU-ban:
- Mpeg-2
- Mpeg-4/Part 10 (H.264/AVC)
- VC-1
- Újabban: DivX/Xvid, MVC (Blu-ray 3D)Már vagy 3 éve a dekódolás összes lépése hw-esen megy (VLC/CAVLC/CABAC, frequency transform, pixel prediction and inloop deblocking) és csak az opcionális post-processing (denoising, de-interlacing, scaling/resizing) megy shaderekkel.
Bőszen tanulmányozd: UVD, PureVideo
Minimális fogyasztással megy a dolog akár többtíz Mbps-es HD-s anyagokkal, minimális prociterheléssel. Nem lehetetlen persze "kicselezni" a hw-t, azaz úgy enkódolni, hogy ne tudja rendesen dekódolni, de ma már eléggé odafigyelnek az enkódolók erre, főleg a HD-s anyagoknál. Nem csak a GPU-k miatt, hanem a teljesítményigényesebb eljárások esetén ugyancsak hw-es dekóderekkel dolgozó asztali lejátszók miatt is.
A cikket sem olvastad igazán figyelmesen, mert az új API-ban sem a dekódolást akarják a shaderekre bízni, hanem ugyanúgy a post-processinget.
És, hogy mi az egésznek az értelme?
- Nem csak 3-4 GPU-s gyorsítású dekóder lesz.
- Több nem-DXVA alapú lejátszóban jelenik meg a GPU-s gyorsítás támogatása, dekód és post-processing szinten is.
- A meglévő és újfajta post-process eljárások OpenCL-re ültetése, a CPU felszabadításával, kisebb fogyasztás mellett nagyobb teljesítmény igénybevételének lehetőségével.
- Mindezt nyílt szabvány alapon. -
GerykO
aktív tag
Én igazából arra gondoltam, hogy bizonyos feladatokra idővel kiválik egy célhardver az általános célú végrehajtókból, majd ha teljesítményt tekintve már nincs rá szükség, akkor ismét visszaköltözik az általános végrehajtóba, és ez periodikusan ismétlődik.
Igazából szebben is meg lehetne fogalmazni, de szerintem a lényeg így is érthető.
De példának ott az FPU, a memóriavezérlő... -
#47
Meteorhead
aktív tag
Pikari
#34
Meteorhead
aktív tag
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.
-
Abu85
HÁZIGAZDA
Ha gyorsabb memóriát akarsz, akkor azt jelenleg a csatornák növelésével érheted el. Ezt meg kell fizetni a lábak számában. Nyilván a több lábat pedig mi fizetjük majd a kasszánál.
Mindenki elkezdte a GPU-t és a CPU-t egybepakolni. Lassan minden versenyző vállalat realizálja, hogy a heterogén éra elkerülhetetlen, ugyanis a CPU-magok számát nem tudod növelni a végtelenségig. Meg lesz az a határ, ami az egymagos rendszerek karrierjének véget vetett. Nagyon közel járunk a kritikus fogyasztási határ, vagyis olyan útra kell lépni, amivel a vég elnapolható. Ezért pakolják a cégek a CPU-t és a GPU-t össze. A késleltetésre érzékeny szálak a CPU-n lesznek futtatva, míg a párhuzamos végrehajtás esetében ki lehet használni a GPU masszív számítási teljesítményét.
Nyilván a következő lépcsőfok a még szorosabb integráció, de egyelőre erre nincs lehetőség. Majd 2013 környékén. Akkor lehet gondolkodni a memória-sávszélesség problémáján is.
A jelenlegi technikák mellett egy Cellhez hasonló megoldást tudsz kihozni. Ez persze nem olyan rossz, de vannak gyengéi, ami a PC-n alkalmatlanná tenné a rendszert. -
eziskamu
addikt
Esetleg elő kéne venni a Transmeta Crueso-t, csinálni belőle egy százmagosat spéci memvezérlővel, és alapból x86-os morph progit feltölteni, de esetleg szoftveresen lehessen változtatni "magonlént", hogy adott mag x86-os vagy valami más üzemmódban működjön? Vagy ez is hülye ötlet?
-
Abu85
HÁZIGAZDA
Ha a jövőben megjelenő Atom nem gyúr rá a multimédiára, akkor az óriási fail az Intelnek, mert a Brazos fényévekkel az aktuális platformjuk előtt jár. Nem azt mondom, hogy verjék meg az AMD-t itt, de illene egy minimális szintet hozni.
Jó. Azt úgy lehet kivitelezni, hogy négycsatornás memóriavezérlőt építesz a CPU-ba. Ez kb. 1500+ láb. Belevéve a routing bonyolultságát cirka hatszorosára nőne a belépőszintű, és háromszorosára a középkategóriás termékek előállítási költsége.
Amit mondasz az mind kivitelezhető, ha a termékek fogyasztói árát megtöbbszörözik. Ja és el lehet felejteni a mobil forradalmat is. -
Abu85
HÁZIGAZDA
Érdemes megnézni a gyakorlati példákért a Brazos tesztet. [link] Ott a videólejátszás táblázata, ahol le van vezetve, hogy négy videó lejátszása milyen minőségű. A két legmegterhelőbb videó akad az Atomon, míg a Brazos mindkettőt zsírul viszi. Az Atom + Ion páros gyomrát egyedül a Killa sample fogja meg.
Na most a gyakorlat világosan mutatja, hogy GPU-s gyorsítás nélkül egy Atom mellett meg vagy lőve. Alapvetően a Brazos processzormagjai mellett is meg lennél, ha nem lenne mellette egy UVD 3.0-s motorral szerelt IGP. Ez önmagában megalapozza a GPU-s gyorsítás létjogosultságát. Az AMD csak annyit szeretne, ha ez az élmény egy korszerű API mellett még jobb lenne. A többiek ehhez csatlakozhatnak.Amúgy a shaderekkel nem videokódolást gyorsítasz, hanem post process szűrést. A dekódolásra ott az UVD motor.
A post process szűrést ellenőriztük a TMT5 szoftverrel, ahol OpenCL-ből alkalmaztunk HD felskálázást. Az OVD-vel ezt a fejlesztő a lejátszóba integrálhatja magába a futószalagba. Ez egyértelműen win számodra, mert javul a videó minősége. Ráadásul Open az egész, vagyis bárki támogathatja. -
Abu85
HÁZIGAZDA
Nem éppen. Például a DirectCompute alatt eleve a shader modell 5 az ami értékelhető teljesítményt tesz lehetővé. A DXVA viszont nem támogatja a DirectCompute felületet. A legjobb shader modellből ezzel helyből kizártad magad. Persze a DXVA-t tovább lehet fejleszteni, hiszen az MS bármikor megteheti, csak addig amíg ez nem történik meg lenyeled a korlátokat, vagy váltasz egy másik API-ra, ami rugalmasabb. Pl.: a hírben szereplő.
-
#21
Meteorhead
aktív tag
Pikari
#8
Meteorhead
aktív tag
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.
-
O_L_I
őstag
Na tisztázzunk valamit mert új vagy itt.
A Troll és a pesszimista szakértő között annyi a különbség hogy a szakértő megmagyarázza hogy miért szar a bizonyos dolog a troll meg csak leírja hogy szar és ezt az álláspontját bármiféle érvelés nélkül a végletekig védi.
A bonbonos hasonlatból nem jön ám le hogy te melyik kategóriába tartozol.
Tehát nem besértődni kell hanem akkor mond el hogy ez szerinted miért nem ér semmit.
)
Új hozzászólás Aktív témák
Hirdetés
- Bomba ár! HP ProBook 450 G5 - i5-8GEN I 8GB I 256GB SSD I 15,6" FHD I HDMI I Cam I W10 I Garancia!
- AKCIÓ! Lenovo IS8XM LGA 1150 DDR3 alaplap garanciával hibátlan működéssel
- Quadro FX 570 eladó
- AKCIÓ! Gigabyte B450M R7 2700X 16GB DDR4 512GB SSD RX VEGA64 8GB CM 690 III FSP 600W
- Samsung Galaxy S22 Ultra 512GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest