Avagy mi a különbség a DXVA és a CUDA dekódolási folyamata között

Bevezetés

Mint azt már egy ideje sokan tapasztalhattátok, bizonyos nVidia modelleknél lehetőség van olyan nagyfelbontású filmek lejátszására is a videokártya segítségével, amelyek egyébként már nem férnek bele a GPU-n keresztüli dekódolás keretébe. Az AMD felhasználók ugyanakkor ezt egyelőre nem mondhatják el kártyáikról és náluk bizony ezek a filmek vagy akadást, vagy lényegesen magasabb processzorkihasználtságot eredményeznek.

Az ok egyszerű: a filmek dekódolására több olyan útvonal is lehetséges, ami a grafikus kártyát veszi igénybe. Jelen írásban megpróbálom szemléletesen, nem túl technikai módon bemutatni a lehetőségeket, ezek hasonlóságait, eltéréseit. Nem szeretnék háborút indítani, hogy melyik gyártó termékei a jobbak, csupán metódusokat fogok leírni.

A HD filmek manapság fókuszban állnak, így hardvergyártók, szoftverfejlesztők egymás után állnak ki újabb és újabb megoldásokkal, amelyek ezeknek a filmeknek a lejátszását vagy transzkódolását segítik elő a kényelem és a gyorsaság jegyében. Természetesen azt látnunk kell, hogy egy számítógép nem célhardver, így nem összehasonlítható egy asztali lejátszóval, hiába nagyobb teljesítményű és bonyolultabb.

Néhány fogalom röviden

API (Application Programming Interface, alkalmazásprogramozási felület): Az API egy olyan leírás (dokumentáció) egy rendszeren belül, amely segítségével külső rendszerek kapcsolódhatnak az adott alkalmazáshoz anélkül, hogy annak belső működését ismernék. Az API jól definiált eljárásokat, paramétereket ad meg programnyelvtől függetlenül, amelyeket használva bizonyos szolgáltatások érhetőek el a külső rendszer számára. Egy operációs rendszernek több API-ja lehet feladattól függően.

DDI (Device Driver Interface): Az API-hoz haszonló interfész, ám a DDI közvetlenül egy-egy hardver meghajtó programjával illeszthető össze az operációs rendszerrel.

DXVA és történelem

Még a HD megjelenése előtt, amikor a DVD volt az uralkodó, a Microsoft kitalált egy API-t és DDI-t, amellyel videó folyamok dekódolását gyorsíthatják hardveresen a videokártya bevonásával. Az igény érthető volt, hiszen a filmek lejátszásakor minden esetben a processzor dolgozott és a VGA maximum a lejátszó megjelenítésében játszott szerepet. A grafikus chip specifikusabb felépítése és gyors számítási egységei kecsegtető lehetőségnek tűntek bizonyos dekódolás közbeni számítások elvégzéséhez, amelyek a központi egységeket nagyon megdolgoztatták.

A szoftveres dekóderek (codec) bonyolult műveleteket végeznek a bitfolyamon, amíg az megjeleníthető képek formájában a monitorra kerül és ezeknek a végrehajtása megfelelő sebességgel igencsak erőforrás igényes, főleg az amúgy általános műveletek elvégzésére megalkotott processzorok irányában, ezért lejátszás közben a kép akadozhat, elcsúszhat a hang és magas kihasználtság léphetett és lépett is fel.

A hardveres támogatást végül a Microsoft® DirectX® VA API nevet kapta – rövidebb nevén DXVA – és az 1.01-es verzióval indult el 2001 elején. Először alapvetően a következő szabványokhoz készült:
• ITU-T Rec. H.261
• ITU-T Rec. H.263
• MPEG-1 video
• MPEG-2 Main Profile video

Később több kiterjesztést adtak ki hozzá (Windows Media Video (WMV) 8, WMV 9, és SMPTE VC-1), amíg eljutott a 2.0 verzióig, ami már H.264/AVC kiterjesztést is tartalmaz. A két verzió között lehetséges az átjárás, él a visszafelé kompatibilitás elve.

A DXVA 1 a Windows 2000-ben jelent meg először és rendererként az Overlay Mixer, VMR-7, VMR-9 (DirectShow) támogatott benne.

A DXVA 2 a Vista bevezetésével lépett színre és EVR (DirectShow vagy Media Foundation) renderer-t használ.

Dekódolás DXVA-n keresztül

Általánosságban

A DXVA-ban az utasítások egy része a grafikus driver-ben van implementálva és - természetesen – a grafikus processzoron hajtódik végre. Ezt nevezik gyorsítónak (accelerator) és azokat a folyamatokat, amelyek maradtak a CPU, illetve a codec (szoftver) oldalán, host decoder-nek nevezik. Azokat a folyamatokat, amelyeket a GPU végez, off-host folyamatoknak nevezzük (a host decode oldali műveletek a host-based műveletek). Amennyiben egy ilyen művelet kerül sorra, a szoftver a gyorsító pufferébe fogja tölteni a szükséges adatokat, amikkel a művelet elvégezhető.

A gyorsító egységeket a két legnagyobb gyártó kártyái már jó ideje tartalmazzák. Ezek az UVD (AMD) és a Purevideo HD (nVidia). Persze ezeket is fejlesztik, optimalizálják és a DXVA mai implementációja szerint el lehet érni, hogy a teljes bitfolyam minden számításigényes feladata már off-host műveletként kerüljön végrehajtásra. Ennek legnagyobb előnye, hogy a processzor és a GPU is viszonylag alacsony kihasználtságon fusson a dekódolás alatt.

Kicsit mélyebben

A GPU-ban lévő szoftverkomponens, ami a dekódolásban segít, általánosan Video Processing Device (VPD) néven említik. Feladata a dekódolás alatt a következő alapműveletek elvégzése:
• Deinterlacing és inverse telecine
• A video substream-ekre osztható, ezeket mixeli egybe (kép a képben funkció = két stream)
• Színbeállítások (ProcAmp), képszűrés
• Skálázás (kép)
• Színtér konverzió
• Alpha blending

Arra most nem térek ki, melyik mire szolgál. A "köznapi" használatban négy blokkra oszthatóak az elvégzendő műveletek:
• Bitstream továbbítás (CAVLC, CABAC)
• Inverz transzformáció (iDCT)
• Mozgáskompenzáció
• Deblocking

Ezzel a négy fő művelettel jellemezhetőek legjobban a dekódolás lépései. A videokártyák az első időkben persze nem tudták biztosítani mind a négy „egység” GPU-n keresztüli végrehajtását, ám mára a teljes folyamat átkerült a grafikus processzorra.

Egy grafikus driver megvalósíthat több VPD-t is, attól függően, mely feladatra szánták. Például van a bob deinterlace-re egy ilyen VPD (DXVA2_VideoProcBobDevice) és van egy azokra a filmekre, amelyek csak progresszív kereteket tartalmaznak (DXVA2_VideoProcProgressiveDevice). Ez a két VPD minden DXVA-t implementáló grafikus driver-ben jelen van.

A dekódolás menete

A DXVA 1.0 verziójában a hívások az IAMVideoAccelerator interfész részei, míg a 2.0 verzióban ezt már az IDirectXVideoDecoder interfész valósítja meg. Működésük hasonló, céljuk azonos.

A dekódolás kezdete az BeginFrame parancs, ami jelzi az accelerator-nak, hogy dekódolási folyamat kezdődik, aminek folyamán adatokat fog írni a gyorsító egy tömörítetlen felület pufferbe.

Ezt követi az Execute parancs, amivel a gyorsítónak átadásra kerülnek a tömörített adat pufferek és a rajtuk elvégzendő műveletek specifikálásra kerülnek. Erre a gyorsító egy státuszinformációval válaszol.
Ha minden adatot átküldött a host decoder, akkor egy EndFrame paranccsal jelzi, hogy az adott keret teljes egészében átment és a BeginFrame lezárható.

H.264 dekódolásnál egy BeginFrame lockol egy felület puffert és az Execute parancs tartalmazza ennek az indexét is. Amíg nem érkezik egy EndFrame parancs, addig a puffer lock alatt marad és csak a gyorsító írhatja. Execute többször is érkezhet, ám a decoder nem szakíthatja meg a folyamatot EndFrame nélkül.

Természetesen a dekódoláshoz szükséges adatokat a gyorsítónak kell tárolnia. Ilyenek például az intra és inter képadatok, B szeletek, macroblock adatok, stb.

Ennél sokkal mélyebben nem mennék bele, mert ez nem egy programozás technikai cikk, csupán szemléltetni akartam, hogy milyen lépéseken keresztül történik a dekódolás a DXVA interfészein keresztül. Látható tehát, hogy nem az operatív memóriában tárolódnak az egyes dekódolásra váró és dekódolt keretek, hanem minden közvetlenül a gyorsítónak lesz átküldve és a saját puffereit használja a VGA.

Az új ATI HD5000 család bevezetésével az AMD megtartotta az UVD egységeket, de már shader szinten is lehet többféle képjavító eljárást alkalmazni, amiket a lejátszókban, driver-ben lehet szabályozni. Ezzel együtt is megmarad egyelőre tehát a dekódoló egység és az AMD egyelőre az ATI Stream-et nem fogja be dekódolásra, ha az UVD-n keresztül esetleg ez meghiúsulna, mert a lejátszandó média nem fér bele a DXVA kereteibe.

Ezzel szemben az nVidia abba az irányba ment, hogy ha a PureVideo HD nem képes dekódolni a filmet, akkor se adja vissza a dekódolást a processzornak, hanem tereljen bizonyos műveleteket a saját, általános számításokra használható egységei felé, a CUDA irányába.

nVidia CUDA

A CUDA (Compute Unified Device Architecture) egy nagyszerű fejlesztés az nVidia grafikus kártyáira, ami számítások elvégzésére hivatott szinte bármilyen adaton, bármilyen műveletet futtatva (GPGPU). Párhuzamosan tud kódokat futtatni a GPU-n, így nagyobb sebességet és hatékonyságot lehet elérni vele, mint a processzorral.

Programozására a C nyelv egy kiterjesztése, a „C for CUDA” használható alapvetően, de több más nyelvet is támogat. Sokan sajnos összekeverik a CUDA és az UVD/PureVideo HD általi HD dekódolást, pedig a kettő mondhatni: ég és föld.

A CUDA működési elve alapvetően más, mint a DXVA API-n keresztüli műveletek. A CUDA alapvetően az operatív memóriából kap adatokat és a processzortól kap utasításokat, amiket az adatokon el kell végeznie. Ha végzett, az eredményt visszamásolja a rendszermemóriába.

Tehát például a CoreAVC codec olyan kiterjesztést tartalmaz, amely képes a CUDA interfészeivel kommunikálni és ha a PureVideo HD nem képes dekódolni a filmet (vagy nincs is jelen), akkor a dekódolási folyamat átterelődik a szoftveres útra. Ilyenkor a keret adatai a rendszermemóriába kerülnek és onnan a VGA memóriájába másolódnak, ahol a GPU elvégzi a számításokat a processzortól kapott utasítások alapján. Ha végzett egy kerettel, visszamásolja azt a memóriába és a codec-nek már nincs más dolga, mint megjeleníteni azt.

A CUDA tehát végső soron a GPU-ban végzi a dekódolás egyes lépéseit, de a teljes mértékben hardveres DXVA API-n keresztüli dekódolást nevezhető inkább hardveresnek, ha már ilyen módon kell kategorizálni.

Végszó

Nagyjából tehát látható, hogy mi a különbség az UVD/Purevideo HD és a CUDA HD dekódolási folyamatában. A gyakorlatban a felhasználó lejátszás közben nem fog nagy különbséget tapasztalni a két mód között. A CPU kihasználtsága kicsit magasabb lesz, de ez nem zavaró mértékű.

Azt azért érdemes szem előtt tartani, hogy a DXVA-hoz igazodó videók mindig jobbak, mert azok a szabványt követik a paraméterek beállításában, míg a sokszor elborult beállításokat alkalmazó filmek képe sem szebb, sem pedig jobb nem lesz, csak annyit érnek el velük, hogy a DXVA API-n nem lehet áttuszkolni őket.

Még ma is felesleges az L5.1 alkalmazása és a ref_frames értékét is felesleges megtörni, hogy a DPB értéke véletlenül se legyen valós. Persze most sokan kérdezhetik, hogy ha egyszer nincs megkötés, miért ne lehetne, de erre csak azt tudom válaszolni, hogy teljesen felesleges, mert ez nem a kreativitás, hanem a következetlenség jele és sokat romolhat is a minőség az eredetihez képest és a durva mértékű túllövés a lejátszás minőségében okozhat igen nagy károkat, ezzel téve igénytelenné a munkát. Azért a teljesség kedvéért hozzáteszem, hogy az anime rajongók közül sokan úgy vélik, hogy a minél magasabb ref_frames hozzájárul a jobb minőséghez és mivel sokan közülük post processing filtereket is használnak, náluk a DXVA nem nagyon jön szóba.

A másik kérdés, ami felmerülhet, hogy miért erőltessük a DXVA-t, ha egyszer van CUDA. Nos, erre az a válaszom, hogy a CUDA nem tudja, mit csinál és a codec sem, csak végzik a dolgukat, ha tudják, míg az UVD és a PureVideo HD célzottan az ilyem folyamatokra szánt megoldásokat alkalmaznak, így abban legalább biztosak lehetünk, hogy egy DXVA-hoz igazodó filmnél mire számíthatunk.
Természetesen a CUDA nagy előny, mert azért a processzor általi dekódolásnál lényegesen gyorsabb és kevesebb erőforrást is használ. Reméljük, hamarosan az AMD is elszánja magát egy hasonló lépésre.