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 clise 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...
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 clise 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)
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)
Interesting that you put this here. In a completely different life I am seeing other weird things with this interface as well. For example /dev/dri/card0 sometimes becomes /dev/dri/card1. Maybe a more stable identified something like 'by path' would help software in general, so the choice can be actually set to 'a card' rather than 'a number'. -- Stefan
yeah, someone just need to implement this. Also found this discussion, it seems va-api a bit.. shortsightened: https://github.com/intel/libva/issues/540 "libva (v2.12) does not find /dev/dri/renderD129 (stops scanning for GPUs if "renderD128" is not present) #540 Closed eero-t opened this issue on 6 Sep 2021 · 3 comments" this probably affects flatpack and other modern isolation techniques... also, freebsd setup has its own problems back in 2020 or so (again, due to gpu device name), but at least it proves gpu media acceleration sometimes possible on FreeBSD https://emby.media/community/index.php?/topic/70699-enable-hardware-accelera... On Friday, April 15, 2022, Stefan de Konink via Cin < [email protected]> wrote:
Interesting that you put this here. In a completely different life I am seeing other weird things with this interface as well. For example /dev/dri/card0 sometimes becomes /dev/dri/card1. Maybe a more stable identified something like 'by path' would help software in general, so the choice can be actually set to 'a card' rather than 'a number'.
-- Stefan -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
On Fri, 15 Apr 2022, Stefan de Konink via Cin wrote:
/dev/dri/card0 sometimes becomes /dev/dri/card1. Maybe a more stable identified something like 'by path' would help software in general, so the choice can be actually set to 'a card' rather than 'a number'.
I personally never had a system with several videocards enabled simultaneously, but perhaps the uncertainty in the order they are enumerated by the kernel could be solved in a similar manner as for other types of devices. Here are several recipes I used elsewhere. 1) /etc/modprobe.d/usb-controller.conf This ensures loading the ehci USB driver before uhci and ohci: softdep uhci-hcd pre: ehci-hcd softdep ohci-hcd pre: ehci-hcd 2) a rule in /etc/udev/rules.d which defines the enumeration order of two different audio devices (one was RTL HDAudio chip on the motherboard, the other HDMI output on the ATI graphic card): SUBSYSTEM!="sound", GOTO="my_usb_audio_end" ACTION!="add", GOTO="my_usb_audio_end" DEVPATH=="/devices/pci0000:00/0000:00:03.0/sound/card?", ATTR{index}=1 DEVPATH=="/devices/pci0000:00/0000:00:1b.0/sound/card?", ATTR{index}=0 LABEL="my_usb_audio_end" 3) another method in /etc/modprobe.d which corrects enumeration of two audio devices, both controlled by the same snd_hda_intel driver (one is HDAudio on motherboard, the other HDMI output of the on-chip Intel graphics): # Reverse HDA Intel cards ordering: options snd_hda_intel index="1,0" _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3307864 Email [email protected] _______________________________________________________________________________
I have problems with vaapi too, so much so that lately I never enable it. The following is an outdated page, I don't know if it will help: https://trac.ffmpeg.org/wiki/Hardware/VAAPI
participants (4)
-
Andrea paz -
Andrew Randrianasulu -
Georgy Salnikov -
Stefan de Konink