Dotaz: D1800M a Debian 10 - video akcelerace

[driver]

Zdravím, dostala se ke mě deska D1800M a osadil jsem to tedy asi 4TB disků, 16GB ram (max) a provozuji na tom Debian 10.

Má to 2 účely. MiniPC občas pro děcka na promítání pohádek a nějaké předpočty pro jiný server, které to může dělat v iddletime, což mám svými scripty pořešené, aby to neházelo server load > 1.

Řekl bych ale, že video například z VLC renderuje CPU. Ne že by to děckám nějak vadilo, zas jako extra to neškube, ale přeci jen při švencích, zoomech atd je vidět, že tam je menší framerate a minimálně jedno CPU ze dvoujádrového CPU na desce má co dělat s přesuny dat po dekódování do grafiky, nebo co se to tam přesně děje - něco asi na ten způsob. Když vypnu své předpočty pro externí server, tak žádná změna. Tam je limit fakt asi HW a mé scripty na to mají vliv naprosto nulový.

Nakopnul by mě někdo na instalaci driverů pro akceleraci videa pro Debian 10 s touto pasivně chlazenou SOC deskou, aby to bylo plynulejší a CPU si oddechl, pokud to tedy nějakou akceleraci vůbec má a pokud na to pro linux někdo něco napsal?

Co jsem hledal tak drivery jen pro Widle.

Je tam

/0/100/2 display Atom Processor Z36xxx/Z37xxx Series Graphics & Display

neboli

00:02.0 VGA compatible controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display (rev 0e)

dle vseho by na to mel byt i915, ale ten tam je defaultne od instalace asi

i915 1736704 40

Jako všechno jede, jen to fullscreen video prostě je vidět, že akcelerované není a že to honí softwarové CPU seč mu síly stačí a nedělá to úplně blbě, jen se u toho hodně zapotí.

Moc se v driverech pro linux neorientuju. Proto jakákoliv nápověda vítána. Blbej urcitě nejsem, bude možná stačit malinkatý nákop (link), za který budu vdečen.

Mnohokrát díky za případný dobrovolně věnovaný čas mému dotazu.

Odpovědi

[X]

Co by jsi chtel za zazracny ovladac? Je to presne i915 8086:0f31, ovladac mas spravne, ale molh by te zajimat napriklad vystup prikazu vainfo.. pripadne RTFM.

[Bherzet]

Obávám se, že z toho procesoru víc nevyždímeš. Z mojí zkušenosti je navíc na Intelu grafický výkon pod Linuxem o něco slabší než na Windows (ale nevím, jestli to platí obecně).

[MadCatX]

Od doby vzniku téhle wiki stránky se to, myslím, trochu změnilo ale jakž takž by pořád mělo platit toto: VLC GPU Decoding.

[driver]

Experimentuji prave s odkazem na https://wiki.debian.org/HardwareVideoAcceleration od prvniho dobrodince ktery odpovedel, zatim se stejnymi vysledky.

Hele jako ono to neni nedivatelne, to v zadnym pripade, trpi to jen drobky ...

Objevil jsem napriklad:

user@server:~$ mpv -fs /mnt/sdc2/Videos/Asterix\ a\ Překvapení\ pro\ Caesara-xEwhuHZK1bU.mp4 
Playing: /mnt/sdc2/Videos/Asterix a Překvapení pro Caesara-xEwhuHZK1bU.mp4
 (+) Video --vid=1 (*) (h264 472x360 25.000fps)
 (+) Audio --aid=1 (*) (aac 2ch 44100Hz)
AO: [pulse] 44100Hz stereo 2ch float
VO: [gpu] 472x360 yuv420p
AV: 00:21:01 / 01:13:18 (28%) A-V:  0.000 Dropped: 12
[input] No key binding found for key '`'.
AV: 00:21:06 / 01:13:18 (28%) A-V:  0.000 Dropped: 12


Exiting... (Quit)

kdezto

user@server:~$ mpv -hwdec -fs /mnt/sdc2/Videos/Asterix\ a\ Překvapení\ pro\ Caesara-xEwhuHZK1bU.mp4 
Playing: /mnt/sdc2/Videos/Asterix a Překvapení pro Caesara-xEwhuHZK1bU.mp4
 (+) Video --vid=1 (*) (h264 472x360 25.000fps)
 (+) Audio --aid=1 (*) (aac 2ch 44100Hz)
[vo/gpu/vaapi-egl] vaAcquireSurfaceHandle() failed (invalid VASurfaceID)
Using hardware decoding (vaapi).
VO: [gpu] 472x360 vaapi[nv12]
AO: [pulse] 44100Hz stereo 2ch float
AV: 00:03:31 / 01:13:18 (4%) A-V:  0.000
[ffmpeg/video] h264: mmco: unref short failure
[ffmpeg/video] h264: mmco: unref short failure
AV: 00:11:32 / 01:13:18 (15%) A-V:  0.000

Zdrojem je verejne dostupne youtube video stahle pres youtube-dl a poustene lokalne.

Hlaska [vo/gpu/vaapi-egl] vaAcquireSurfaceHandle() failed (invalid VASurfaceID) ... nevim jestli ma vliv a co to presne znamena.

vainfo po jeho instalaci hlasi

user@server:~$ vainfo 
libva info: VA-API version 1.4.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_4
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.4 (libva 2.4.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Bay Trail - 2.3.0
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Simple            :	VAEntrypointEncSlice
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointEncSlice
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointEncSlice
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointEncSlice
      VAProfileH264StereoHigh         :	VAEntrypointVLD
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD
      VAProfileNone                   :	VAEntrypointVideoProc
      VAProfileJPEGBaseline           :	VAEntrypointVLD

Lepsi to neni ani pokud experimentuju s nastavenim VLC...

Hardware acceleration in VLC is controlled in the GUI via “Tools → Preferences → Input / Codecs → Hardware-accelerated decoding”, or via the CLI option –avcodec-hw value [‘value’ is mandatory].

Treba se z toho fakt neda vic vyzdimat, coz nerozporuju :) Jen experimentuju. Zadny extra zazrak to neni :), to bez debat, ale pracant to je schopny i tak na ruzny ucely.

Zajimavy je ze pres VNC vidim VNC zpusobem typicky sekany samplovany video a ne napriklad jednobarevnou plochu na kterou by se na fyzickem monitoru skutecne hardwarove renderovalo (klicovalo) video resamplovany navic hardwrarove. Ja se na to nedivam pres VNC samozrejme primarne, fyzicky monitor je hned vedle na stole, jen VNC mam jako ovladatko z meho NTB at nemusim prepojovat mys a klavesnici. Odpojeni se od VNC nema na zobrazeni na fyzickem monitoru vliv. Napriklad RPi a omxplayer tohle bezne dela. Pri pohledu na VNC clovek video logicky nevidi, pac video je renderovano HW casti primo do HDMI o cemz VNC nema v tu chvili poneti a prenasi jen barevnou plochu nebo proste desktop. Tohle chovani jsem kdysi zjistil u prehistoricke Matrox Marvel G200, kde jsem tyhle finty objevil, ale to neni podstatny.

Mozna se toho uz moc vyladit neda a ja vlastne jedu na maximalni HW podpore co z toho vyzdimat jde a jen resim detaily jako napriklad nejaky divny sync viditelny i normalne okem na monitoru pri urcitych scenach. Kdyz jsem tak u toho asterixe, prikladam jedno z asi 190 fotek pri pokusu sejmout jednu vec, viditelnou i okem pri švencich, pohybech obrazu, zmenach obrazu kde si toho lze vsimnout. Zajimave ze se vyskytuje stale na stejnem miste obrazu.

Snimek monitoru mobilem: https://imgur.com/a/dVnUE0D

Neni to jen vlastnost mezi cipem mobilu pri foceni monitoru a frekvenci monitoru, protoze tohle jde fakt videt i okem. Monitor na kterem to zobrazuju je tento VGA uz skoro dedek https://iiyama.com/gb_en/products/prolite-e2407hds-1/

Tohle jsem kdysi stejne tak sledoval na jednom pracovnim HP notebooku s Fedorou uz jen pri presouvani okna na beznem Xfce desktopu, a mam pocit ze to byla nejaka globalni vec na urovni HW a driveru nebo neceho kdo vi ceho, pac desktopove rozhrani at uz treba mate nebo gnome se chovalo stejne se stejnymi artefakty. Lomeny "45" stupnu zlom do pulky obrazu a pak rovny zlom v pulce obrazu. Zvlastni. Da se to nejak poladit nebo je to brutal alychymie?

[PetebLazar]

Intel GPU typicky poskytují akceleraci (dekódování) přes VA API. Takže bych vyzkoušel utilitu vainfo, která informuje o jejím dostupném rozsahu. https://wiki.archlinux.org/index.php/Hardware_video_acceleration#Verifying_VA-API

Vypadá to, že v Pentiu J1800 (GPU Intel HD Gen7) by měla být podle DXVAcheckeru (zdroj Pctuning) dostupná minimálně plné (VLD) dekódvání Mpeg-2/VC-1/H.264 (BD formáty). https://pctuning.tyden.cz/ilustrace3/flanker/baytrail/dxva_akcelerace.jpg

[PetebLazar]

Přehlédl jsem výpis vainfo v předchozím příspěvku. Ta chybová hláška je údajně snaha o volání funkce, která v VA API 2.0 neexistuje.

[driver]

Hoj. Jak se na to zpětně dívám na svůj post ...

VO: [gpu] 472x360 vaapi[nv12]

Takže jak se píše, ono to dekóduje GPU, takže tady už asi už nic nevymyslím víc. Pokud to správně chápu. Nebo i renderuje GPU? Možná i renderuje... Kdo ví. Dekódování z mpeg do raw RGB dat frame po frejmu a synchronizovaný přenos těchto raw dat do požadovaného obdélníku v pixelech na ploše monitoru ve videoram grafiky jsou 2 různé věci samozřejmě, pokud je tedy obě nedělá jeden HW.

Takže já vlastně řeším možná jen tenhle divný vizuální sync možná a tím se mi to zdá neplynulé.

Napadá někoho čím by se do dalo poladit nebo čím tenhle efekt vzniká? Samotného by mě to zajímalo co si kdo o tom myslí principielně na úrovni HW (sem tam se v takových vécech rýpu :) ). Jakoby půl frejmu bylo přesunováno do video ram nějak pomaleji nebo rychleji, nebo mimo sync, než spodní zbytek frejmu. Nevím, sám nad tím špekuluju. 2 jádra toho CPU že by se dělily o půl frejmu každé a tím by vznikala ta rozdílnost v půlce frejmu?

Jestli někdo už řešil a povedlo se (nějaký konfig jádra, ovladače, biosu, kdo ví čeho), tak budu vděčen. Tohle ale jak jsem psal vídávám poslední dobou na vícero PC i noteboocích. Zřejmě stejný nebo podobný model GPU nebo kdo ví čeho.

Kritické to není, peníze mě to nestojí, vyladit by to bylo zajímavé možná i pro ostatní, kteří podobné projevy vidí a rádi by řešili :)

[driver]

Vracím se zpět k tomuto tématu. Výše jsem v diskuzi zmiňoval zlom v obraze. Po hledání jsem našel, že se to jmenuje video tearing a nedávno při restartu tohoto stroje jsem zjistil, že problém vymizel.

Pomohlo toto

Tak jsem si vzpoměl, že to sem loupnu a třeba se někomu bude hodit. Je to fakt jiná liga, když se to nezalamuje. Takže i z takto levné desky lze vymáčknout ještě více. A toš tak.