<a href="https://github.com/intel/media-driver/issues/195">https://github.com/intel/media-driver/issues/195</a><div><br></div><div>run into weird issue lately - for some reason VA-API stopped working! </div><div><br></div><div>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.... </div><div><br></div><div>this lead to spectacular driver failure when I set acceleration to vaapi and set</div><div>LIBVA_DRIVER_NAME=i965</div><div><br></div><div>libva driver from mesa/radeon worked but was slow.. </div><div><br></div><div>so, if you have dual-gpu (intel/something) setup you might want to check names:</div><div><br></div><div>=== from bug ==</div><div>$ sudo cat /sys/kernel/debug/dri/128/name</div><div>i915 dev=0000:00:02.0 master=pci:0000:00:02.0 unique=0000:00:02.0</div><div>$ sudo cat /sys/kernel/debug/dri/129/name</div><div>nvidia-drm dev=0000:02:00.0 unique=0000:02:00.0</div><div><br></div><div>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</div><div><br></div><div>failure message was</div><div>DRM_IOCTL_I915_GEM_APERTURE failed: Invalid argument </div><div><br></div><div>followed by crash/assert in intel buffer manager. </div><div><br></div><div>may be setting vaapi_driver in h264_vaapi profile will fix it - until next reboot I have vaapi working.... </div><div><br></div><div>beignet (Intel's opencl driver) had patch for dealing with this situation.... </div><div><br></div><div><a href="https://beignet.freedesktop.narkive.com/9BYGmazy/patch-1-2-ensure-that-drm-device-uses-the-i915-driver">https://beignet.freedesktop.narkive.com/9BYGmazy/patch-1-2-ensure-that-drm-device-uses-the-i915-driver</a></div><div><br></div><div>new result with intel driver 1.8.3 was nearly 22 fps! And much better seeking behavior... </div><div><br></div><div><br><br>On Tuesday, January 18, 2022, Andrew Randrianasulu <<a href="mailto:randrianasulu@gmail.com">randrianasulu@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br>On Tuesday, January 18, 2022, Andrew Randrianasulu <<a href="mailto:randrianasulu@gmail.com" target="_blank">randrianasulu@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Well, I compiled new Cingg git (gcc 5.5.0,  ~ Slackware 14.2,  32 bit (!)) <div><br></div><div>file 1920x1080 24 fps h264 mkv from youtube</div><div><br></div><div>no plugins/effects/transitions</div><div><br></div><div>default project format - rgba-8bit<br><div><br></div><div>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</div><div><br></div><div>you need to restart Cin after changing hw accel method</div><div><br></div><div>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... </div></div></blockquote><div><br></div><div>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) </div><div><br></div><div>With normally-compiled x264 I got 9.66 fps - much better! </div><div><br></div><div>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) </div>
</blockquote></div>