Include intel i915 SR IOV driver

Feature Requests
21

Understandable; thanks for your assistance in this. I don’t have any 12th-gen Intel hardware to test with myself.

22

I’m kinda struggling to see the broader use case here. I thought this was about running TrueNAS as the hypervisor with SR-IOV, but you seem to want to keep your hypervisor?

Hypervisor → TrueNAS VM → Container that uses iGPU is possible without SR-IOV if you passthrough your entire iGPU to the TrueNAS VM

But I’m assuming you can’t do that because you also have a different VM that also needs the iGPU, so you installed the experimental DKMS on both the hypervisor and this VM.

Wouldn’t it be wiser to just spin up yet another VM with the DKMS to run your container instead of doing it in TrueNAS? Is this all just to bypass the virtual network and have raw access to the data in TrueNAS from the container? I think you’ll find that NFS, SMB and iSCSI are plenty fast for any such need.

It’d be safer to wait for/contribute for the support to be provided by the mainline xe driver, in my opinion.

23

By the same logic, truenas scale is not needed. After all, truenas core exists. Anything you want that can’t be achieved by truenas core, can be achieved by spinning up a Linux VM.

I believe the intention has been clearly communicated, and I don’t intend to start an argument about all the details.

24

How it ended ?
I have exactly the same problem | scenario
Proxmox → TrueNAS Scale VM → App Immich

Kernel module for Intel 13th Iris Xe GPU were loaded but no drivers for i915 or xe.

does nowaday a fix exist ?

25

This is the Feature Requests category. If it wasn’t marked [Accepted] or marked [Not Accepted], it is still just a request to have the feature added in the future.

Rejected or Accepted are locked threads

26

They’ve touched the topic in today’s podcast. As far as I inderstood it, it won’t get implemented as long as the upstream project is marked as experimental.

2 Likes
27

Thanks for the info. I went and checked the podcast. They actually discussed it in good detail. The position is fairly clear and pretty reasonable, they don’t want to introduce instability to other users. Given that fact that there is very little resources poured into it, it is unlikely this will ever get out of experimental status. I think I will just have to continue “experimenting” this on my own.

28

Preamble: I care about this feature a lot on Proxmox because I need GPU acceleration in VMs where I’m doing VDI/remote desktop work that either (1) needs audio; or (2) involves GPU-accelerated compute (Plex/SDR). So, I’ve gotten a good bit of experience making this work on Proxmox. :slight_smile:

I have a 12th gen Intel-based NAS running TrueNAS, so I’ve got an iGPU that supports the DKMS driver.

I very much understand iX’s position avoiding blacklisting the Xe driver and a wariness regarding the “highly experimental” language, but I wanted to provide some anecdotal context from my use of the StrongTZ DKMS repo with Proxmox.

I’ve been using it for at least 2 years at this point. Maybe longer. It’s always had that “experimental” label on it, even though it’s much more stable now than it used to be. It’s also got more maintainers now and bugs and kernel compatibility features are patched much more quickly than they used to be.

At least once, the entire DKMS module has been rebased on the latest Intel LTS and otherwise patched to incorporate upstream Intel LTS changes.

I’ve never had it crash the host OS (Proxmox); stability in this context is more a question of whether it’s actually going to work inside a VM–and at this point that’s very solid for supported kernels.

OTOH, it’s an unofficial DKMS module, so the “experimental” tag is meant to set the expectation that it might burst into flames at any moment and take your system down with it, and they can’t really promise stability (but do fix bugs as they appear and keep an easy to use deb package up to date).

But it does work very well with kernels 6.8 to 6.14 right now, so if it was added, it would need to be Fangtooth or newer only. Electric Eel is on 6.6, and there’s a forked, older version of the DKMS driver for that kernel. I’m not sure it’s actually maintained as actively.

Since it’s a hacked version of the i915 driver that has to be continuously updated to work with new kernels, it also spits a ton of scary warnings and errors onto the console/dmesg because it’s just hacked enough to work, but the i915 driver was never meant to be used this way long term. If it’s working, that flood of warnings can be ignored, but it’s still a flood of warnings that can distract from real issues. :stuck_out_tongue:

So, anecdotally, it works great in Proxmox, but it’s very much not a novice-level feature. You need to understand editing the kernel command line, deploying a DKMS driver, and basic kernel log-based debugging to make it work.

But it’s too wonky and requires way too much customization to be part of the base TrueNAS install, IMO. Especially when it has to be recompiled/can break for every single Linux kernel update.

This feature request actually came up in this week’s T3 Podcast, here, as part of the discussion of building systemd-sysext modules: https://youtu.be/F0frVAjuoj4?si=hnE7wPNoEJh0EC7v&t=1152

Is that even feasible for something like this? At minimum, the i915 DKMS driver requires:

  1. Modifying the kernel command line and updating grub;
  2. Blacklisting the xe driver (either via a config file or the kernel command line–using the kernel command line is much more reliable, in my experience); and
  3. Installing a .deb package containing the i915 DKMS (which compiles the module for the active kernel and will automatically compile the module again every time a system update installs a new kernel).

I’m not familiar with how systemd-sysext works at all. Can it do all those things? Without breaking the base TrueNAS install?

The xe driver won’t ever support anything before the Xe generation, and i915 doesn’t support anything after ARC A-series. Running the vanilla modules side-by-side is fine but it appears that something in the SR-IOV DKMS module conflicts with xe that necessitates blacklisting it as a required kernel parameter.

I’ve run into this with Proxmox (which now defaults to the Xe driver for 12th-gen iGPUs) and any VM that defaults to Xe. The current version of the Xe driver takes over the iGPU on the host (it’s the driver in use according to lspci), but has no actual SR-IOV support right now, so there’s no SR-IOV iGPU VFs to pass to VMs. Blacklisting the Xe module allows the i915 DKMS driver to load and expose the VFs.

I think there should be a way to tell the system to load the i915 driver without having to blacklist the Xe driver, but I could never get that to work.

29

Separately, I wanted to bring up the idea of this SR-IOV appearing in the Xe driver. That whole situation is a bit of a mess, from what I’ve observed while using the i915 SR-IOV DKMS and waiting for Intel to do … something.

  1. Intel 12th-gen CPUs were marketed as having iGPUs with SR-IOV support, and have always confirmed that support in hardware when you probe them with something like cpuinfo. I (and anecdotally from various forums), a lot of home server buyers chose this CPU generation because they wanted SR-IOV for iGPUs for VDI/remote desktop. (There are dozens of us. Dozens!)
  2. According to a (now old) video from Wendell at Level1Techs, the SR-IOV functionality for 12th gen and up CPUs has always been a skunkworks project inside Intel. Management doesn’t like it because they want to sell you datacenter-grade GPUs. Originally, SR-IOV support was supposed to get put into the official i915 driver, but that never happened.
  3. Work to get SR-IOV into the mainline kernel has been going on inside Intel since at least kernel 6.8 (Phoronix has several articles that mention this, with SR-IOV expected to be mainlined Any Time Now® since kernel 6.9.) The GitHub issue on their end for SR-IOV mainlining was opened in 2022. See: SR-IOV: mainlining? · Issue #33 · intel/linux-intel-lts · GitHub So … that’s been a minute.
  4. Based on that (long, ongoing) thread, the current drm-xe-next package only supports the upcoming PantherLake iGPUs; no one can confirm support for 12th-14th gen, which is supported by the i915 DKMS.
  5. Development on the i915 DKMS module actually slowed down at one point because the devs assumed Intel was going to upstream the feature into the kernel, an then picked back up and intensified and added more maintainers around 6.12 when it became clear that was not happening.
  6. As far as I know, there’s still no formal roadmap or statement from Intel on where this feature is in their LTS kernel or when it might be upstreamed to mainline.
  7. Currently in Intel’s fork of the LTS kernel, a number of newer iGPUs are tagged as having SR-IOV support, but it’s not enabled in the kernel and enabling it causes instability. So it’s not yet clear that, even when they actually get SR-IOV into Xe, it’ll work with 12th-14th-gen iGPUs.