#Has anyone had success using vaapi on an
1 messages ยท Page 1 of 1 (latest)
Internal graphics is Enabled in the BIOS (one thing I found through search), and vainfo gives me this:
error: can't connect to X server!
libva info: VA-API version 1.17.0
libva info: User environment variable requested driver 'iHD'
libva info: Trying to open /lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_15
libva error: /lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed
libva info: va_openDriver() returns 1
vaInitialize failed with error code 1 (operation failed),exit
I can run frigate by commenting out hwaccel_args: preset-vaapi under ffmpeg:, but it obviously increases CPU usage
seems like most folks are running Ubuntu and have success installing the HWE kernel, but I think that's a hack for Debian
I think some people are, you may want to try installing some of the other packages along with that one https://github.com/blakeblackshear/frigate/blob/d7ae0eedf89e14f297093ac5c8042862034cbaeb/docker/main/install_deps.sh#L61-L63 to see if it makes a difference since frigate needs others as well.
Is that vainfo output from inside the frigate container or the host?
from the host
maybe also see what lspci -k says
I think I've installed all of those
oh, it's an i915?
00:02.0 VGA compatible controller: Intel Corporation Alder Lake-N [UHD Graphics]
DeviceName: Onboard - Video
Subsystem: Intel Corporation Alder Lake-N [UHD Graphics]
Kernel driver in use: i915
Kernel modules: i915
no kidding
I get the same if I don't choose a driver and run vainfo from the container
I saw some mention of secure boot, which is disabled
installing those dependencies didn't help, unfortunately.
root@rcoleman-linux:/opt/frigate# vainfo
error: XDG_RUNTIME_DIR is invalid or not set in the environment.
error: can't connect to X server!
libva info: VA-API version 1.17.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_17
libva error: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed
libva info: va_openDriver() returns 1
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_8
libva error: /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so init failed
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit
same thing inside and out of the container
I guess I can try the 6.5 kernel tonight
The 6.6 kernel seems to lock up the Beelink box hard somehow, in that it's hard to even get into the BIOS afterward. I don't know what the heck it's doing
man, that's very odd
I was freaking out a bit last night, but I was able to get into the boot menu with F7 to re-choose my SSD. Before that, simply repeatedly pressing escape was enough to get into the full BIOS, but that just stopped working ๐คท
network was flashing, but no video output, couldn't SSH, no idea what was going on
I was just transplanting the exact same SSD from my old Lenovo Thinkcenter to the Beelink and I figured it would just be a drop-in replacement, but there's always that one thing....
5 hours later, having nearly broken it so nothing works, I went back to the older kernel and just left it ๐
which beelink is this? I just bought one like a week ago and not having any issues using vaapi
I have bookworm but also using casaos so stuff like frigate are ran in containers
heh thats the exact one i have
Hmmm
I'm using all containers, too, but I get the same on the host. Maybe I'll try a live bookworm thumb drive
wait.. mines the pro.. it looks and has those sam specs but the listing on amazon is diffrent from the beelink store. same price too
I think I did a dist upgrade to bookworm on this, so maybe something to do with that
You're running the 6.1 kernel?
maybe. I just installed bookwork then immediatly slapped casaos on it and away I went
uname -a
6.1.0-18
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 23.1.1```
If it doesn't fail, then yeah
tough little machine
I like it. It's even smaller than the think center, and easier to get to the bits
I think I need to poke around in the bios some more
yea using mine for my moms frigate with her 7 cameras. access it remotely which is why I just slapped casaos on it
Feels a bit like a plastic toy, but high performance at low power
yea
Way cheaper than similar NUCs
mines sitting in towel closet with just gaps around the door for ventilation and it remains cool
Mine is going to consolidate 3 servers when I'm done, saving a bunch of power at higher performance
I started moving to faster machines with ESPHome and voice/wakeword. Building that takes forever on my old HA machine
Frigate is okay even without vaapi for now
what you gonna run for docker management?
casaos is great for a ui aspect especially remotely but i cannot for the life of me figure out how to mount a tmp for frigate to cut back on ssd
ah
I'm okay with a giant docker-compose file and profiles
If I can't get those commands to work on the host, I don't expect it from the container, though
I didn't have to use the i965 driver or anything. just using the vaapi preset in frigate and it all worked
The container installs the drivers
Just doesn't work for me
That's why I'm suspicious of a bios setting
Some security thing
One of the other commands gave an MMIO access failure, and one dude tracked that down to secure boot. Bit that's disabled on mine. Might be related, though
I peeked in the bios but changed nothing
I wanted to make sure the machine was going to auto restart in the evnt of a power outage
prob just some glitch in the matrix..start over lol
unless you got a lemon.. fingers cross for that not to be the case
With so much stuff in containers, that's probably not such a big deal. Bit I would hate to waste the time and have it not help
That's why I'm think that a live boot stick might be interesting
yeah I'd be curious on that
did you have a chance to try it?
No, didn't have time last night.
It's kind of a pain to keep bringing the server up and down, since it's running a ton of stuff and my house doesn't really work when it's down ๐
yeah I can imagine :/
works fine from the latest bookworm live boot, so ๐คท
truly weird and confusing. I tried the -18 kernel with the same failure
something might have borked when you did the dist upgrade
no idea. I haven't figured out how to get more info about why the driver init failed
I also made an executive decision to allow images/embeds in this channel
hmmm:
ioctl(3, DRM_IOCTL_I915_GETPARAM, 0x7ffe6445eff0) = -1 ENOEXEC (Exec format error)
that sounds like a bork during an update/change to me
luckily, everything else is working, including Frigate without vaapi support. But that also makes me less interested in reimaging
I'll figure it out, it's just a challenge ๐
you did pass the driver into the container correctly?
i still passed the d128 into mine
this is what's failing in teh container and the host, so until I get this working on the host, I don't think the container is the issue:
rcoleman@rcoleman-linux ~/docker % sudo intel_gpu_top
intel_gpu_top: ../tools/intel_gpu_top.c:1932: init_engine_classes: Assertion `max >= 0' failed.
[1] 19951 IOT instruction sudo intel_gpu_top
rcoleman@rcoleman-linux ~/docker % sudo intel_gpu_top -L
card0 Intel Alderlake_n (Gen12) pci:vendor=8086,device=46D1,card=0
โโrenderD128
it clearly sees it
have you tried reinstalling the driver?
1000000 times
yea you got way more patience than me.. i would have wipd and redone it all over by now
that will spawn more hours of figuring out what I don't have and need to install when literally everything else works
base Debian 12 has pretty much nothing
I dunno what casaos installed extra but i usd th same debian image
e key
I did a quick search what you postd abov. this poppd up https://github.com/intel/media-driver/issues/1371
I didn't have to install anything on the live USB image, it just worked out of the box
ya same
i literally installed debian via usb, slapped casaos and then away I went.. no additional drivers or anything
looked through that issue and the error is the same (but pretty generic), but the strace is different. I'm getting that "exec error", which seems interesting
they also had suggested to reinstall the libva-drm2 as well. I don't have vainfo installed on host on my machine
that didn't help. I'm rebuilding the intel_media_driver now ๐
my device ID has been in the driver foreverr, so it isn't the same issue as in the one above
just checked my downloads folder to make sure which debian i did grab and yea it was this image debian-12.5.0-amd64-netinst
I wonder if Debian has a "fix this installation" mode, like MacOS does. Non-destructive, fix the stuff that users won't normally touch
I'm rebuilding the driver now for fun, so let's see
no idea. aside from this time I only ever installed it once before cause they kept a 32 bit image around longer
Finally figured it out. Some web searching pointed out that the ENOEXEC error that I saw in the strace was related to missing or invalid firmware, and I noticed that I didn't have the i915 firmware in /lib/firmware. When I tried to install the firmware-misc-nonfree package, I realized that it moved from the non-free component to non-free-firmware component in bookworm. After fixing that in /etc/apt/sources.list, installing the firwmare, and rebooting, everything works as expected
I went as far as building the whole intel graphics driver packages from source with debug enabled and started to add my own debug before I decided that I was going down a rabbithole that I was unlikely to escape
this was the key: https://lore.kernel.org/all/7e166f02-db00-9b18-dad0-7e04c348a920@intel.com/
>>>>> -ENOEXEC if HuC firmware is invalid or mismatched,
I still essentially spent the hours that I would have spent reimaging and restoring what I had, but at least I learned some stuff ๐
and now that I built my own driver stack, I'm on the latest. so there's that