Intel GPU support Matrix

fahrenheit

fahrenheit

As the support for Intel GPUs (integrated or discreete) in FreeBSD is confusing (well, in general), here is an handy table for theoretical support as constructed from Linux Kernel LTS release code.

Please remember that:
  1. Only FreeBSD 15.1/16 support DRM 6.12 (more specifically FreeBSD 15 after 1500509 and FreeBSD 16 after 1600018)
  2. FreeBSD 14.x and 15.0 support DRM 6.1 and 6.6 (plus 5.x versions)
  3. The currently available firmware package is 20250109
  4. You have to have the DRM package and the Firmware package to support your GPU
  5. Even if you have the right DRM and Firmware packages you may have issues due to board issues (most of the time they will also happen on Linux for the same DRM/Kernel version + Firmware package)
  6. For recent hardware (Arrow Lake for example) DRM 6.12 may or may not work even with the most recent firmware package (depends on whether or not the right modules are coded to be loaded)
  7. Xe2/Xe3 (Bxxx/Cxxx) cards require a new DRM driver that has not been ported yet (see: https://github.com/FreeBSDFoundation/proj-laptop/issues/111)
I hope that this table helps.

1780305002924.png


Notes:
  1. In the DRM column if you see i915* that means the driver supports the device but it needs to be forced
  2. In the DRM column if you xe that means only the xe driver supports that architecture (so, Linux DRM 6.12 supports Xe2 and X3 but FreeBSD does not)
  3. In the DRM column if you see i915 (b) that means that the architecture is reportedly broken on FreeBSD
  4. In the DRM column if you see i915 (w) that means that the architecture is reportedly working on FreeBSD
  5. In the firmware column if you see Yes* that means that there were updates vs the 20250109 release
  6. In the firmware column if you see Yes** that means that those architectures were probably also affected as they are derivatives
  7. In the firmware column N/A means that that generation does not require firmware
 

Attachments

As you may remember , Im building a ArrowLake-S Desktop that kernel Paniced using DRM 6.6 but
doesnt die using DRM 6.12 . However im only using my discrete Nvida RTXPRO 4000.
 
drsnx60 said:
As you may remember , Im building a ArrowLake-S Desktop that kernel Paniced using DRM 6.6 but
doesnt die using DRM 6.12 . However im only using my discrete Nvida RTXPRO 4000.
Click to expand...
From the source I looked at arrowlake is meteorlake (it just lacks the pci ids and some extra defines), so it wouldn't take much to get 6.12 to fully support it. But the latest firmware packages have changes to meteorlake so it's a bit of both.
But yeah, not panicking is good.
 
Some of those earlier chipsets on that list are doubtful to me. PINEVIEW Atoms especially. I thought support for those was gone.

Is anybody running i915drm on old Atoms like N410/N425/450/455 or D510 ect...
I tried on an old N270 touchscreen it did not work but it was 32bit so I was not surprised.
GEN2-Pinetrail-N circa 2010
 
Phishfry said:
VALLEYVIEW and CHERRYVIEW support on FreeBSD i915 is broken with drivers past drm510.
Click to expand...

Could it be that I have one of those in this old ASUS R517S? After drm-510 I can get it to work using scfb or the xf86-video-intel driver but there's no hardware acceleration in either case. On FreeBSD13 it was working fine.

If kind souls are working on fixing things I can use this ASUS to test things?

sysctl -a | egrep -i 'hw.machine|hw.model|hw.ncpu'
hw.machine: amd64
hw.model: Intel(R) Pentium(R) CPU N3700 @ 1.60GHz
hw.ncpu: 4
hw.machine_arch: amd64


pciconf -lv | grep -B4 VGA
vgapci0@pci0:0:2:0: class=0x030000 rev=0x21 hdr=0x00 vendor=0x8086 device=0x22b1 subvendor=0x1043 subdevice=0x1d5d
vendor = 'Intel Corporation'
device = 'Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Integrated Graphics Controller'
class = display
subclass = VGA


/grandpa
 
fahrenheit said:
In the DRM column if you see i915* that means the driver supports the device but it needs to be forced
Click to expand...
Can you elaborate on this statement? I have an A310 that I was (wrongly?) informed wouldn't work in 14.4-RELEASE so I've been trying to pass it thru to a VM. Your table shows driver support is there, which means maybe I don't need the VM and can just use a jail. I'd prefer this, but don't understand what you mean when you say the device needs to be forced.
 
epower53 said:
Can you elaborate on this statement? I have an A310 that I was (wrongly?) informed wouldn't work in 14.4-RELEASE so I've been trying to pass it thru to a VM. Your table shows driver support is there, which means maybe I don't need the VM and can just use a jail. I'd prefer this, but don't understand what you mean when you say the device needs to be forced.
Click to expand...
The intel driver, for hardware that they don't support very well, requires that the linux kernel be started with the i915.force_probe=<pciid|*> module parameter.

But like ArgentoSoma said, dg1 and dg2 are broken (i think due to fimrware loading).

In any case, the ArchLinux wiki page on i915 is sobering to understand the depth of issues with intel hardware even on linux.
 
Phishfry said:
Yup this is affected. N3700
I believe I steered you to the last remaining support with drm510. Still buildable on the 14.x branch.
https://forums.freebsd.org/threads/...2-stable-and-14-3-release.101732/#post-747189

I wonder if anybody has filed a bug report to see if this is fixable?
Click to expand...

Oh you have excellent memory!

I can post that PR now! I've also noticed that it's really beneficial to join a mailing list and voice the PR there as well so I'll try the -drivers list.

I just need to find a way to describe the bug. The symptom I have is that hardware acceleration isn't working and that is very vague.

Yesterday I found this on Github - about porting drm drivers from Linux to FreeBSD - and I'm thinking I would need to try that process to see where it breaks and then post that as a PR?

I am guessing a bit since I haven't fully understood the porting drm upgrading process but I suppose I need to start with kernel and drm build for 14.1 since Makefile for 5.10 says:

Makefile: 
.if ${OPSYS} == FreeBSD && ${OSVERSION} >= 1401501

Once that it built I could try the process for Linux drm v5.11 and start logging the output for when it breaks and create a PR?

/grandpa
 
fahrenheit said:
The intel driver, for hardware that they don't support very well, requires that the linux kernel be started with the i915.force_probe=<pciid|*> module parameter.

But like ArgentoSoma said, dg1 and dg2 are broken (i think due to fimrware loading).

In any case, the ArchLinux wiki page on i915 is sobering to understand the depth of issues with intel hardware even on linux.
Click to expand...

i915 on Linux support DG1 (since 6.1) and DG2 (since 6.8) without i915.force_probe.

The problem with these cards is that many functions necessary for their proper initialization are missing from LinuxKPI, and the initialization paths differ from those used in the iGPU versions.

In fact, while certain Xe-LP iGPUs do work on FreeBSD, the dGPUs (Xe-HP) do not. The issue regarding the initialization paths is, in any case, the most critical problem, as it affects both FreeBSD and OpenBSD and is precisely what triggers the kernel panic in both systems.

On Reddit, a user created a port of the Xe driver (distinct from the i915 driver), but declined to submit a Pull Request for a review of the changes a step that could have assisted dumbell with the porting process and the proper enablement of these GPUs.
 
fahrenheit said:
ArgentoSoma just checked both the linux and drm-kmod code for 6.1, 6.6 and 6.12 and DG1 requires force_probe (whether or not that is enforced on the FreeBSD side I don't know).

I've updated the table with the reports for the rest of the architectures.
Click to expand...
Anyway, it should've been hard works, as (as far as I know) Intel does NOT provide good and readable info.

NVIDIA keeps on maintaining lists of currently supported and at which legacy branch specific GPU was last supported in their README. I think this is the best approach.

For AMD GPUs, I found something like following.

But not for Intel GPUs. So works should've been hardest!
 
You must log in or register to reply here.
Back
Top