Intel HD Graphics (Braswell (Valleyview Cherryview)) no hardware acceleration after drm-510-kmod

G

grandpa

Hello,

Hardware acceleration for Intel HD Graphics Valleyview and Cherryview works up to 14.1-RELEASE with drm-510-kmod.

Drm-510-kmod is in the ports tree for 2026Q2 - it will most likely be gone in Q3.

Compiling from source or installing xf86-video-intel, libva, libvdpau does not enable hardware acceleration.

A PR has been posted - 295788 - but the bug description is very vague.

The process to port a new version of drm drivers for FreeBSD is to grab the Linux drm, change as little as possible until it runs on FreeBSD.

Looking at the source code for all drm-kmod versions the code for Valleyview and Cherryview is still there (515, 61, 66, latest).

Let's assume that this bug comes from FreeBSD going from 14.1 to 14.2 or from the drm going from 510 to 515.

In the Makefile for drm-510-kmod it says "Not supported on FreeBSD 14.2 and higher" but it does not say why.

Does anyone know why drm-510-kmod not is supported on >14.2?

/grandpa
 
Hacking around with code shows that it is possible to squeeze drm-510-kmod through the compiler on 15-RELEASE-p9.

This is of course futile since the leap is too big from 14.1 to 15.0-p9 (or drm-51 to 66). With some changes to drm_os_freebsd.c, drm_pci.c, drm_sysctl_freebsd.c, i915_gem_mman.c and a reboot an upside down green plasma login screen can be seen before the GPU_HANG comes.

Probably better to compare drm-510 to drm-515 and try to understand what has changed?

/grandpa
 
I tried enabling guc/huc with sysctl hw.i915kms.enable_guc only to find out that Braswell does not support guc/huc ;^D

Also tried setenv LIBVA_DRIVER_NAME i965 which gave me:
# vainfo
Trying display: wayland
Trying display: x11
libva info: VA-API version 1.23.0
libva error: vaGetDriverNames() failed with unknown libva error
libva info: User environment variable requested driver 'i965'
libva info: Trying to open /usr/local/lib/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_23
DRM_IOCTL_I915_GEM_APERTURE failed: Bad file descriptor
Assuming 131072kB available aperture size.
May lead to reduced performance or incorrect rendering.
get chip id failed: -1 [9]
param: 4, val: 0
i915 does not support EXECBUFER2
libva error: /usr/local/lib/dri/i965_drv_video.so init failed
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exi


Bugs leading to bugs.

/grandpa
 
Phishfry said:
Yes the worst I saw was a dmesg warning message about ABI not right version or mismatch. It still works.
Click to expand...
I had to do changes in drm_os_freebsd.c, drm_pci.c, drm_sysctl_freebsd.c, i915_gem_mman.c to make it compile - does it compile without changes for you?

/grandpa
 
Collecting related threads here:

Phishfry

Thread 'Intel DRM trouble on N3160'

I seem to be having troubles on FreeBSD 14.3-RELEASE with N3160 and Intel DRM. Both drm-515-kmod and drm-61-kmod.

It seems to act like Baytrail Graphics which also bomb out on newer versions of FreeBSD.
Installed gpu-firmware-kmod.

Xorg.0.log snip:
Code: 
[   162.270] (II) modeset(0): Modeline "640x480"x75.0   31.50  640 656 720 840  480 481 484 500 -hsync -vsync (37.5 kHz e)
[   162.270] (II) modeset(0): Modeline "640x480"x60.0   25.20  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz e)
[   162.270] (II) modeset(0): Modeline "640x480"x59.9   25.18  640 656 752 800  480 490 492 525...
  • Like
fahrenheit

Thread 'Intel GPU support Matrix'

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...
  • Thanks
D

Thread 'Intel Pentium n3540 integrated graphics problem'

I decided to install FreeBSD with the KDE Plasma 6 environment on my Asus x553ma laptop. I was able to install it, but I struggled with the integrated graphics of my Intel Pentium N3540 (Intel HD Graphics Bay Trail-M) for a long time, in the end, installing the drm-515-kmod package helped, but there was one but...

My KDE Plasma session with Wayland doesn't work, I decided to use the session on X11, but in the end I noticed one but. Here my video adapter is displayed as llvmpipe, which, as I found out, means that x11 couldn't find my video adapter. And in KDE itself, compositing didn't...
G

Solved Thread 'modesetting difference between 13.2-STABLE and 14.3-RELEASE?'

Hello,

Q1. Is there a drop in hardware support specifically for Intel HD Graphics for the xorg driver modesetting between 13.2-STABLE and 14.3-RELEASE?

Q2. As an alternative option - is there any chance of getting hardware acceleration to work with xorg+xf86-video-intel for old hardware?


I dual boot a 10 year old Intel Pentium N3700 Braswell laptop with Intel HD gfx with one 13.2-STABLE and one 14.3-RELEASE.

For the 13.2-STABLE i run xorg+modesetting and here the modesetting enables glamorgl so I have hardware acceleration and all is fine.

For the 14.3-RELEASE it's a...
the3ajm

Solved Thread 'How to migrate to amber branch for mesa'

I recently updated pkg on Freebsd 12.4 and the i915 driver seems to be missing from mesa loader message. I looked at some documentation that says version after Mesa 21.3 has removed the driver and need to migrate to the amber branch: https://docs.mesa3d.org/amber.html

I dont seem to find any documentation on how to do that and on the bug reporting site shows a link to using meson: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269006

I'll do more digging to see if I can figure this one out but if anyone have done this before please share your knowledge.

Thanks.
 
A quick question, if you know, does Linux (6.12+) have support for these platforms (other than the code apparent support)? Or is it broken also?
 
grandpa said:
does it compile without changes for you?
Click to expand...
No I was probably wrong and never compiled it for FreeBSD 15. I am not savvy enough to make those sort of changes.

I am glad we are getting eyeballs on the problem. Did support drop off or it is a bug? I have hesitated to file a bug report.
 
Oh no one has had time to look at the PR yet - patience is a virtue. I did update it from affects only me to affects some people though.

I threw in the Xorg.0.logs for 510 vs 515 as description but that's really vague.

I can compile 510 and it works on 14.1 and when I compile 515 on 14.1 it breaks. I'm not sure but this points to that it's not the base system/kernel nor the xorg server since these are same for both compilations. If this bug appears in the transition between 510 and 515 then those Xorg.0.logs are probably worthless. I saw you had the same breakage in the trouble on n3160 thread.

This is a snippet from Xorg.0.log from 14.1 + drm510 that is working:

[ 28.783] (II) UnloadModule: "vesa"
[ 28.783] (II) Unloading vesa
[ 28.978] (==) modeset(0): Backing store enabled
[ 28.978] (==) modeset(0): Silken mouse enabled


And this is the same snippet from 14.1 + drm515 that breaks.

[ 28.080] (II) UnloadModule: "vesa"
[ 28.080] (II) Unloading vesa
[ 28.087] (EE)
Fatal server error:
[ 28.087] (EE) Caught signal 6 (Abort trap). Server aborti


The "backing store" is probably a red herring since it's a log from xorg and not drm itself. Some googling says that the modesetting driver does not support hardware level backing store. If the source is same for 510 as for 515 this herring can be eliminated.

Doing egrep -R "backing" . | grep i915 for 510 and 515 source code gives me something to read.

/grandpa
 
fahrenheit said:
A quick question, if you know, does Linux (6.12+) have support for these platforms (other than the code apparent support)? Or is it broken also?
Click to expand...

That is a really good question and by logic it should be broken from 5.10 as well. Some googling says that it should work though but might require mesa version 24.3.

This is the 14.1 mesa-driver:

pkg info | grep mesa-dri
mesa-dri-24.1.7_11 OpenGL hardware acceleration drivers for DRI2+


But since drm-510 works with these mesa-drivers ...

Also - the source code for all drm versions including latest has the Cherryview/Valleyview code in it.

/grandpa
 
fahrenheit said:
Okay, so for clarity, assuming the loading the kernel driver doesn't panic, and the issues are only on X the issue may be related with mesa vs mesa-amber. I.e. drm-5.10 has the necessary code paths mesa uses but they may have changed stuff in drm 5.15+.

If that's the case, maybe this post helps: https://forums.freebsd.org/threads/how-to-migrate-to-amber-branch-for-mesa.89668/
Click to expand...

Well, the i915kms loads fine for 14.1 + drm515, the resolution switch is there on boot. Xorg bails out.

The mesa track is interesting. I did make showconfig for mesa-dri and this is the output:
# make showconfig
===> The following configuration options are available for mesa-dri-24.1.7_11:
ZSTD=on: Use ZSTD for shader cache
====> Unified OpenGL drivers
crocus=on: Intel GPU Gen4 (Broadwater) to Gen7 (Haswell)
i915=on: Intel GPU Gen3 (Grantsdale to Pineview)
iris=on: Intel GPU Gen8 (Broadwell) and newer
r300=on: AMD/ATI R300, R400 and R500
r600=on: AMD/ATI R600, R700, Evergreen, Northern Islands
radeonsi=on: AMD/ATI Southern Islands and newer
svga=on: VMWare Virtual GPU
swrast=on: Software Rasterizer
zink=on: OpenGL on top of Khronos’ Vulkan API
====> Options available for the group PLATFORM
X11=on: Enable X11 support for GBM/EGL
WAYLAND=on: Enable Wayland support for GBM/EGL and Vulkan
====> Vulkan drivers
anv=on: Intel GPU Gen9 and newer Vulkan support
radv=on: AMD/ATI Southern Islands and newer Vulkan support
swrast_vk=on: Software Rasterizer Vulkan support
===> Use 'make config' to modify these settings


This would imply that default mesa-dri does have the i915 drivers (on 14.1).

It's not really clear to me how drm-515 (or drm-61) would require another mesa-dri derived from amber to support i915? Wouldn't that be a dependency from drm-515 to mesa-dri-xxx?

Edit: Anyway I'll grab the mesa-amber and see if it compiles. It looks as if it's well supported with many releases in 2026.

/grandpa
 
fahrenheit said:
does Linux (6.12+) have support for these platforms (other than the code apparent support)? Or is it broken also?
Click to expand...
I wonder that too in your above post with Linux GPU Matrix.
Is that actual or theoretical...
G45 accelerated support still available would blow my mind.
 
fahrenheit said:
Okay, so for clarity, assuming the loading the kernel driver doesn't panic, and the issues are only on X the issue may be related with mesa vs mesa-amber. I.e. drm-5.10 has the necessary code paths mesa uses but they may have changed stuff in drm 5.15+.

If that's the case, maybe this post helps: https://forums.freebsd.org/threads/how-to-migrate-to-amber-branch-for-mesa.89668/
Click to expand...

I looked - briefly - at the mesa-amber source code specifically in the src/gallium/drivers and compared it to the mesa 24.1 source code and the drivers listed appear to be the same with ambers being older. Since mesa 24.1 has working hardware acceleration on 14.1 with drm-510 I'll go back to comparing drm-510 with drm-515.

/grandpa
 
Adding another tidbit. This is not exactly the same scenario as the Xorg.0.log. It's a feeble attempt to catch what happens with /usr/local/libexec/Xorg when it runs.

This is the output from 14.1-RELEASE with drm-515-kmod. After unsuccesful boot in console logged in as root running "lldb /usr/local/libexec/Xorg" says:

(==) Log file: "/var/log/Xorg.0.log". Time: Sun Jun 7 23:34:41 2026
(==) Using system config directory "/usr/local/share/X11/xorg.conf.d"
scfb trace: probe start
scfb trace: probe done
Process 1583 stopped
* thread #1, name = 'Xorg', stop reason = signal SIGABRT
frame #0: 0x000000082ae3c10a libc.so.7 __sys_thr_kill +10
-> 0x82ae3c10a <+10>: jb
0x82ae3c110 <+16>: retq
0x82ae3c111 int3
0x82ae3c112 int3
(lldb) Stopping sddm.

/grandpa
 
T-Aoki said:
Maybe this commit upstream?
Click to expand...
This commit is present in the drm-510 from ports 2026Q2, ie latest.

I reverted the commit and put this line back in drivers/gpu/drm/i915/gt/intel_ring_submission.c‎ after copying intel_ring_submission.c‎ to intel_ring_submission.c.orig.‎

C: 
if (IS_GEN(engine->i915, 7) && engine->class == RENDER_CLASS) {

Then I did:

cd /usr/ports/graphics/drm-510-kmod
make makepatch
make clean
make ALLOW_UNSUPPORTED_SYSTEM=yes reinstall
reboot
freebsd-update fetch
freebsd-update -r 14.2-RELEASE upgrade
freebsd-update install
reboot
freebsd-update install
reboot


And by thus cheating the Makefile restriction for only supporting 14.1 I have a 14.2 with drm-510-kmod that has hardware acceleration running. Small victory - yay :)

I now have the following:
uname -a
FreeBSD asus-r517sa 14.2-RELEASE-p1 FreeBSD 14.2-RELEASE-p1 GENERIC amd64
pkg info | grep drm
drm-510-kmod-5.10.163.1401000_13 Direct Rendering Manager GPU drivers


I wonder if the reverted commit actually had an impact or if this would have worked with the default drm-510? I'll make a note to go back to 14.1 to check.

But now I'm eager to go -> 14.3 -> 14.4 -> 14.5 etc up to 15.

/grandpa
 
After upgrade to 14.3 the i915kms didn't load on boot so I rebuilt drm-510-kmod on 14.3 by commenting out below lines in the Makefile and did
make clean
make reinstall

Makefile: 
#.if ${OPSYS} == FreeBSD && ${OSVERSION} >= 1401501
#IGNORE=                not supported on FreeBSD 14.2 and higher
#.endif

I now have the following:
uname -a
FreeBSD asus-r517sa 14.3-RELEASE-p14 FreeBSD 14.3-RELEASE-p14 GENERIC amd64
pkg info | grep drm
drm-510-kmod-5.10.163.1403000_13 Direct Rendering Manager GPU drivers


Moving on to 14.4.

/grandpa
 
We have 14.4. No need to rebuild drm-510 for this step.
uname -a
FreeBSD asus-r517sa 14.4-RELEASE-p5 FreeBSD 14.4-RELEASE-p5 GENERIC amd64
pkg info | grep drm
drm-510-kmod-5.10.163.1403000_13 Direct Rendering Manager GPU drivers
glxinfo | grep render
direct rendering: Yes
GLX_MESA_copy_sub_buffer, GLX_MESA_gl_interop, GLX_MESA_query_renderer,
GLX_MESA_gl_interop, GLX_MESA_query_renderer, GLX_MESA_swap_control,
Extended renderer info (GLX_MESA_query_renderer):
OpenGL renderer string: Mesa Intel(R) HD Graphics 405 (BSW)


Wayland-plasma working fine. Glxgears cogwheeling. Towards 15 we go!

/grandpa
 
And on 15 it breaks.

I am beginning to think that the commit in #19, #20 and #22 also is a herring since I can see this code in drm-515 intel_ring_submission.c:

C: 
GEM_BUG_ON(timeline->hwsp_ggtt != engine->status_page.vma);

        if (gen7_wa_vma) {
                err = gen7_ctx_switch_bb_init(engine, &ww, gen7_wa_vma);
                if (err) {
                        intel_ring_unpin(ring);
                        intel_timeline_unpin(timeline);
                }
        }

I will put a memstick in and go to 14.4 and just comment out the >14.1 restriction and build drm-510 to verify.

/grandpa
 
You must log in or register to reply here.
Back
Top