Hi’m exploring game/desktop capturing via ffmpeg.
Unfortunately i noticed that when the gpu use is high and i capture the desktop via x11grab, the whole thing starts to stutter a lot, so i wanted to try kmsgrab instead.
Unfortunately, it is not working, see:
i modified my system configuration to disable nvidia modeset:
koko@slimer# sudo cat /sys/module/nvidia_drm/parameters/modeset
N
Now ffmpeg is failing in another way:
[kmsgrab @ 0x5580a46c64c0] Failed to set universal planes capability: primary planes will not be usable.
[kmsgrab @ 0x5580a46c64c0] Failed to get plane resources: Operation not supported.
Doing some poking at the device files, I get the impression that as soon as X starts with the Nvidia DDX, the drm device /dev/dri/cardX becomes an inacessible dummy and everything gets re-routed to the /dev/nvidia* device files.
from console, the drm node is accessible but due to the lack of a drm console, not much to do there.
Likely working, to be tested, though probably not useful:
using the modesetting DDX
running Wayland
Edit: tested with the modesetting DDX, kmsfbshot works. Though performance wasn’t actually usable, took ~2sec. So in general, it’s supported but the nvidia DDX disables it.
I get the impression that as soon as X starts with the Nvidia DDX, the drm device /dev/dri/cardX becomes an inacessible dummy and everything gets re-routed to the /dev/nvidia* device files.
Yup, that’s my impression as well. This might be the reason why Wayland is not supported yet. The nvidia driver seems to be pretty borked. The server side solutions for Visual computing aren’t really better. This is frustrating especially from the industry leader. :-(
@tuxrampage
Before ditching nvidia, i started to use it as a mere graphic accelerator via prime render offload.
Yes, you loose 5% of performance (the same of running a compositor), but i’ve got lower power consumption and a snappier desktop (and kmsgrab working , of course).
Unfortunately, other things like the horrible memory managment made me switch to amd.
It is not that other hardware is not capable of, it is just that the driver explicitely denies to use other hardware to do the task.
Indees, binary patching the driver makes nv capture api work on all other nvidia gpus too (or bypass the maximum number of concurrent encodes), but i don’t know if it is legal.
It is honestly weird, since nv capture api is deprecated on windows in favour of windows system api.
(!)
No other GPUs are not permitted by the EULA. This is because nVidia is earning from licensing technologies for Datacenters and this would bypass it. Not a strategy that I endorse, but it seems to be the way atm.
Edit:
I’ll check out the capture SDK anyways, as well. The readme states “An NVIDIA GPU board with a Kepler or later GPU.” as requirement. Before releasing or using a software that is using the SDK, you have to contact nVidia anyways with specific information.
Intel+kmsgrab+nvidia (with prime render offload) does work indeed and the grabbing itself does not impact the discrete graphic performance.
(prime itself “steals” about 5% of performance on my previous 1060 card)