[Cin] cingg vaapi on i3-3227U cpu

[Andrew Randrianasulu]

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-device-uses-the-i915-driver

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 at gmail.com>
wrote:

>
>
> 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
>> 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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20220414/cb194cb3/attachment.htm>