RFE: Xe driver support

[DemiMarie]

Lunar Lake, Battlemage, and newer Intel graphics cards are Xe2 and require the Xe driver from Linux.

[thesunexpress]

...aaand also requires Linux 6.6+ at least. We are still at Linux 6.1-lts at best.

[DemiMarie]

Time to update to Linux 6.12?

An alternative might be to run an actual Linux kernel in a Bhyve or Xen VM, pass through the GPU to it, and use a paravirtualized interface to allow the FreeBSD host to access it. Bhyve is the FreeBSD-native solution, but Xen would have the advantage of being able to share code with other projects that have similar needs, such as @QubesOS. (Disclaimer: I work on Qubes OS, but my opinions are my own.)

[mtlll]

Now that drm-kmod master is at 6.8, I guess it's at least imaginable to try to bring the Xe driver over. Is anyone working or planning to work on this? I'm interested in trying, since I have an A770 I'm not able to use at the moment. And although I'm a decent C programmer, I have no FreeBSD kernel experience, or any other kernel experience really. Does anyone know if there is anything currently missing in LinuxKPI and/or drm-kmod that's required by Xe(the one from 6.8)?

[Defenso-EBO]

Any updates on this? I'd like to try out the Xe driver support, but I don't know where to find the relevant branches or code.

[emaste]

We will relatively soon be at parity with Linux 6.12 and will then carry on to 6.18 and beyond, but porting Xe is not yet started. There's also an issue with the license on some of the Xe files (some are GPL-only) that needs to be resolved.

[Defenso-EBO]

We will relatively soon be at parity with Linux 6.12 and will then carry on to 6.18 and beyond, but porting Xe is not yet started. There's also an issue with the license on some of the Xe files (some are GPL-only) that needs to be resolved.

Thank you for your answer. Do you know if it is possible to use Lunar lake with the i915 driver ?

[SimoneFelici]

We will relatively soon be at parity with Linux 6.12 and will then carry on to 6.18 and beyond, but porting Xe is not yet started.

Hi,
I noticed that drm-kmod is now based on Linux 6.12.85. Do you know whether the porting work for the Intel Xe driver has started yet?

Thanks!

[DemiMarie]

Linux does not provide LTS support for the DRM subsystem. Only the latest stable kernel is supported, if that.

[grahamperrin]

#316 (comment)

… an issue with the license on some of the Xe files (some are GPL-only) …

Is that an issue only in the context of what might (in future) be in FreeBSD base i.e. the src tree?

I recall some discussion a year or so ago, but can't find it. Sorry. Maybe in or around the Laptop and Desktop Workgroup (LDWG).

[Matinthereal]

We've been measuring what an xe port to drm-kmod actually requires, using a Lunar Lake laptop (Core Ultra 5 226V / Arc 130V, 8086:64a0) as the reference target. Method: vendor drivers/gpu/drm/xe from Linux 6.12 unmodified into a drm-kmod fork, then drive per-file clang -fsyntax-only sweeps against FreeBSD 15 (main) kernel headers + linuxkpi + drm-kmod headers, adding small additive compat headers until the errors speak.

Result so far: 97 of 99 core .c files (SR-IOV PF group and hwmon excluded, as a minimal config would) are syntax-clean with ~25 small additive headers (~30 distinct missing symbols), 5 trivial __linux__/__FreeBSD__ call-site adaptations, and stubs that gate userptr (-ENODEV) and the MEI/GSC path (no-HuC) off for a first-light configuration. Display: 10/11 (xe reuses the i915 display core drm-kmod already carries at 6.12).

Findings that may be useful independently of xe:

• linux/args.h (COUNT_ARGS/CONCATENATE) is absent from linuxkpi; its absence breaks xe's RTP macro machinery with misleading cascade errors.
• pci_release_resource() in Linux collides with the native FreeBSD PCI KPI of the same name (different arity) — any driver using the Linux one will need a considered resolution in linuxkpi.
• FreeBSD defines CLOCK_BOOTTIME as an alias of CLOCK_MONOTONIC, which turns Linux clock-id switch statements into duplicate-case compile errors.
• drm-kmod's linuxkpi/bsd moduleparam.h shadows the base linuxkpi copy but lacks LINUXKPI_PARAM_charp.

This is a syntax-level result only — it does not yet prove link-time or runtime viability. Next layers we're measuring: link-time symbol gaps and a kbuild→bmake Makefile. We have a classified gap list we're happy to share, and we can offer the LNL laptop as a standing test platform.