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:

$ 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

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....

new result with intel driver 1.8.3 was nearly 22 fps! And much better seeking behavior...

On Tuesday, January 18, 2022, Andrew Randrianasulu <randrianasulu@gmail.com> wrote:

On Tuesday, January 18, 2022, Andrew Randrianasulu <randrianasulu@gmail.com> 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)