https://github.com/intel/media-driver/issues/195 run into weird issue lately - for some reason VA-API stopped working! turned out udev loaded modules in wrong order (for dual gpu - integrated intel + discrete radeon in laptop!) so radeon was sitting on /dev/dri/randerD128 and i915 on 129.... this lead to spectacular driver failure when I set acceleration to vaapi and set LIBVA_DRIVER_NAME=i965 libva driver from mesa/radeon worked but was slow.. so, if you have dual-gpu (intel/something) setup you might want to check names: === from bug == $ sudo cat /sys/kernel/debug/dri/128/name i915 dev=0000:00:02.0 master=pci:0000:00:02.0 unique=0000:00:02.0 $ sudo cat /sys/kernel/debug/dri/129/name nvidia-drm dev=0000:02:00.0 unique=0000:02:00.0 I think there might be way to force udev to hold on loading radeon until i915 was loaded... but my udev-fu not really good enough for finding this on my own failure message was DRM_IOCTL_I915_GEM_APERTURE failed: Invalid argument followed by crash/assert in intel buffer manager. may be setting vaapi_driver in h264_vaapi profile will fix it - until next reboot I have vaapi working.... beignet (Intel's opencl driver) had patch for dealing with this situation.... https://beignet.freedesktop.narkive.com/9BYGmazy/patch-1-2-ensure-that-drm-d... new result with intel driver 1.8.3 was nearly 22 fps! And much better seeking behavior... On Tuesday, January 18, 2022, Andrew Randrianasulu <[email protected]> wrote:
On Tuesday, January 18, 2022, Andrew Randrianasulu < [email protected]> wrote:
Well, I compiled new Cingg git (gcc 5.5.0, ~ Slackware 14.2, 32 bit (!))
file 1920x1080 24 fps h264 mkv from youtube
no plugins/effects/transitions
default project format - rgba-8bit
and va-api works for me on both decoding (most visible cpu usage reduction if i set output to x11-direct - 60% g> 30%), on opengl output it really close to same 60-70% cpu utilization (one core, dynamic freq.) and encoding
you need to restart Cin after changing hw accel method
But biggest thing was va-api h264 encoding - 130% cpu and 18 fps vs nearly 400% cpu and 2 fps (while file size more like 5 mb for software vs 13 mb for vaapi). And memory usage with sw encoding much higher = 800/900 mb vs 300 mb in va-api case. I nearly deadlocked this 4gb ram laptop while trying ram-only (tmpfs) build and encoding tests... zram + zswap helped surely...
2 fps was due to x264 not picking up old nasm - it seems 2.13+ needed for libjpeg-turbo too (according to its own building instruction)
With normally-compiled x264 I got 9.66 fps - much better!
So, this is another hazard (speed-wise) - old nasm may work for some components and do not work for others (with significant encoding speed loss)