[Cin] cingg vaapi on i3-3227U cpu
randrianasulu at gmail.com
Thu Apr 14 21:43:40 CEST 2022
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
libva driver from mesa/radeon worked but was slow..
so, if you have dual-gpu (intel/something) setup you might want to check
=== 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
new result with intel driver 1.8.3 was nearly 22 fps! And much better
On Tuesday, January 18, 2022, Andrew Randrianasulu <randrianasulu at gmail.com>
> On Tuesday, January 18, 2022, Andrew Randrianasulu <
> randrianasulu at 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
>> 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cin