i915 Gallium Driver missing from mesa package

shbon · 2022-10-09 12:21:21

I've noticed that the i915 Gallium driver isn't built into the standard mesa package in the extra repo.

Why is that? Searching the forum, I could only find this archlinux32 reference: https://bbs.archlinux32.org/viewtopic.php?id=3219, but the URL in the final (cryptic) message leads to "invalid bug id"...

I'm asking because I have a user application that doesn't work* with the current mesa package in the extra repo, but does work with mesa-amber AND it also works with mesa-git from the AUR, if I add i915 to the list of Gallium drivers in PKGBUILD.

[*The application produces a "Permission Denied" error calling drmModeSetCrtc (libdrm)]

My laptop architecture: DELL Inspiron 5370 / i5 8250U / UHD 620 (c. 2017)

Can the i915 Gallium driver be added to the mesa package?

Slithery · 2022-10-09 12:44:33

The forums are the wrong place to ask as the devs usually don't hang around here.
Create a feature request against mesa on the Arch bugtracker instead.

Scimmia · 2022-10-09 12:54:26

That CPU should be using the iris driver, it shouldn't be anywhere near i915.

Edit: Are you using xf86-video-intel? That hasn't been recommended for a long time and can really screw things up with the new mesa setup. That would explain why mesa-amber works.

Last edited by Scimmia (2022-10-09 13:04:26)

shbon · 2022-10-09 14:38:14

Perhaps I should explain the application setup I have and further context to how I've arrived here.

I'm trying to use this i5 8250U laptop and Arch Linux to run RetroArch in KMS Mode (https://docs.libretro.com/guides/kms-mode/). i.e. Run RetroArch with the lowest possible latency using KMS/DRM (no X11/Wayland or a WM). This works well!

I also want to use a front end for RetroArch called Attract Mode (https://github.com/mickelson/attract). This application can be compiled to use KMS/DRM. It depends on a fork of SFML called SFML-pi (https://github.com/mickelson/sfml-pi) which adds support to SFML to use KMS/DRM. (This KMS/DRM support has been back-ported into SFML 2.6 but hasn't been formally released yet. SFML 2.5.1 is available in the arch repo).

I'm not sure of the inner-workings of SFML/SFML-pi, but I know that SFML-pi errors with a call to drmModeSetCrtc (in libdrm) with the standard mesa package on Arch Linux. As you mention, for my CPU/GPU, I assume that I should be using the iris (or crocus?) driver. (How can I check this is actually the case?).

My (long) attempt to solve this problem lead me first to an Ubuntu Server 20.04 LTS setup, where the above problem doesn't occur. I tracked this down to mesa version differences (21.2.6 on 20.04 LTS, 22.1.7 on Arch Linux). I'm aware of i915-DRI being dropped in mesa 22, so that's how I found mesa-amber. Looking at the mesa source, I could see there's a i915 gallium driver...

I found two solutions to my issue: install mesa-amber or compile mesa to include the i915 gallium driver, but I can see from your comment, that it may be beneficial to work out why this setup seems to involve i915 drivers, given my laptop's architecture.

Any lines of investigation anybody can point me at?

(I've already posted on the developer's github and user forum a while back, but didn't receive any comment).

Last edited by shbon (2022-10-09 14:41:26)

Scimmia · 2022-10-09 15:15:27

Well that's different. I have no idea how to tell what it's trying to do outside of X/Wayland.

Try setting LIBGL_DEBUG=verbose, maybe, and see what you get in stdout?

Last edited by Scimmia (2022-10-09 15:50:02)

V1del · 2022-10-09 19:18:30

Did you export MESA_LOADER_DRIVER_OVERRIDE=i915 somewhere? That could explain this, you should definitely be using the iris driver normally

shbon · 2022-10-10 12:23:39

I admit to little naivety when a started this thread.

I had assumed because my hardware (i5 8250U / UHD 620) doesn't have Intel Iris graphics, I wasn't using the Mesa iris driver and was "probably" using i915. I now understand that the Mesa iris driver covers all Intel iGPUs from Broadwell onwards and the Mesa driver name "iris" is something of a misnomer...

I recompiled mesa-git using the default PKGBUILD (i.e. no i915 Gallium). My user application works fine under this build of mesa (22.3 dev).

So my problem is actually why my user application errors with the current mesa package (mesa 22.1.7) from the arch repo.

As the problem appears "fixed" upstream, I think I'll wait for a new arch repo version and retest with that. Apologies for the noise.

Eirikr · 2023-04-29 23:30:45

This is interesting, I have multiple systems with Intel 915G, 915GV and 925X boards using the Intel 900/915 Accelerated Graphics. Had to revert back to the Amber branch. Less than Ideal given Gallium i915 is a difference of like 15FPS for Amber and 45FPS for Gallium on my test laptop.

The post originally referenced was a post made by me on the Arch32 forum.

I have an Dell 32-bit 910GM device that I use as a reference device for testing... I support a few home OTA DVR machines for the price of some caffeine juice... and need to make sure my test system is slightly in line. The desktops all have a either a Pentium 662 or 672: single core, hyperthreaded, 64-bit Netburst; 4GB or 8GB RAM, a dual-antenna TV tuner and a Broadcom Crystal HD mini PCie card via a mini PCIe to PCIe adapter.

Gallium worked fine briefly in the 22.0.0 testing branch then something happened so reverted to Amber.

Kodi and libretro functionality perform much better with Gallium OpenGL acceleration.

I wanted to provide friends and neighbors with the freedom to watch OTA-signal televsion, record and pause live shows, and play some older games - all with components liberated from becoming part of a global eWaste problem for the cost of free. No need to increase the power draw by adding a dedicated Radeon card or something. There is already a low-power decoder that handles media very well.

So that is the backstory of the 64-bit machines, and here is my quoting myself from the link during my attempts to clone and build mesa from teh PKGBUILD:

Eirikr1848,Arch32Forums wrote:

When trying to compile the mesa PKGBUILD on Arch32 or Arch systems I receive:
mesa-23.0.3/src/gallium/winsys/i915/drm/meson.build:30:15: ERROR: Unknown variable "libintel_common".

A full log can be found at /home/eirikr/Playground/mesa-i915g/src/build/meson-logs/meson-log.txt
==> ERROR: A failure occurred in build().
    Aborting...
So if we look at mesa-23.0.3/src/gallium/winsys/i915/drm/meson.build we can then find the offending line, which here has been corrected from libintel_common
libi915drm = static_library(
  'i915drm',
  files(
    'i915_drm_batchbuffer.c', 'i915_drm_buffer.c', 'i915_drm_fence.c',
    'i915_drm_winsys.c'
  ),
  include_directories : [
    inc_include, inc_src, inc_gallium, inc_gallium_aux, inc_gallium_drivers
  ],
 [color=#FF0000] link_with : [libintel_common],[/color]
  dependencies : [dep_libdrm, dep_libdrm_intel],
)
So here is where was stuck on both 32-bit and 64-bit systems for a bit during 23.0.x beta and then my attention shifted. Back to this project. (On the 64-bit machine side have many OTA DVRs for people that I support in exchange for a coffee)
So then alright. for the specific meson.build in that folder I just did
cp meson.build meson.build.patched
and then made the change in .patched to replace libintel_common with libi915drm]
Now:
diff -u mesa-23.0.3/src/gallium/winsys/i915/drm/meson.build mesa-23.0.3/src/gallium/winsys/i915/drm/meson.build.patched > fix-libintel_common.patch
And here are the contents of fix-libintel_common.patch:
-- src/mesa-23.0.3/src/gallium/winsys/i915/drm/meson.build     2023-04-20 16:06:54.000000000 -0700
+++ src/mesa-23.0.3/src/gallium/winsys/i915/drm/meson.build.patched     2023-04-29 15:50:41.423603504 -0700
@@ -27,6 +27,6 @@
   include_directories : [
     inc_include, inc_src, inc_gallium, inc_gallium_aux, inc_gallium_drivers
   ],
-  link_with : [libintel_common],
+  link_with : [libi915drm],
   dependencies : [dep_libdrm, dep_libdrm_intel],
 )
And then Added this to to PKGBUILD after build() {:
   cd "$srcdir/$pkgname-$pkgver"
    patch -p1 -i ../fix-libintel_common.patch
    #Remaining Build Items

Last edited by Eirikr (2023-04-29 23:31:39)

Arch Linux

#1 2022-10-09 12:21:21

i915 Gallium Driver missing from mesa package

#2 2022-10-09 12:44:33

Re: i915 Gallium Driver missing from mesa package

#3 2022-10-09 12:54:26

Re: i915 Gallium Driver missing from mesa package

#4 2022-10-09 14:38:14

Re: i915 Gallium Driver missing from mesa package

#5 2022-10-09 15:15:27

Re: i915 Gallium Driver missing from mesa package

#6 2022-10-09 19:18:30

Re: i915 Gallium Driver missing from mesa package

#7 2022-10-10 12:23:39

Re: i915 Gallium Driver missing from mesa package

#8 2023-04-29 23:30:45

Re: i915 Gallium Driver missing from mesa package

Board footer