Configuring libglx, libGLX and libEGL for intel GPUs

neogeo

neogeo

I have a FreeBSD disk constructed with an M.2 NGFF SSD card, in a slim enclosure such that features a set of SATA connectors and a USB 3 port. I suppose it's a sort of a portable SSD. Unfortunately, the combination of the enclosure and the storage card - by Sabrent and KingSpec, respectively - at least, when accessed over USB, it does not appear to allow for any trim support on the SSD. The card holds a UFS2 filesystem. With periodic cleanups under 'fsck_ufs -yfErR' it seems to work out consistently, for upgrades, new installations, and even for a minimal desktop

This boot disk finds usage in two laptops. One laptop has an intel GPU, the other has an Nvidia GPU. The packages for kernel modules and GLX support for both are installed on the same root filesystem.

The chipset for the laptop with the Intel GPU may be identified with vainfo (multimedia/libva-utils).
Code: 
$ vainfo
libva info: VA-API version 1.13.0
libva info: Trying to open /usr/local/lib/dri/iHD_drv_video.so
libva info: va_openDriver() returns -1
libva info: Trying to open /usr/local/lib/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_13
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.13 (libva 2.13.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Ivybridge Mobile - 2.4.1
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Simple            : VAEntrypointEncSlice
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileH264StereoHigh         : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc
      VAProfileJPEGBaseline           : VAEntrypointVLD

I believe that the initial error message may be due to there not being any HD video line in the laptop. This laptop has a VGA port, no HDMI.

Previously, I'd observed the following message in the output from startx:
Code: 
Xlib:  extension "GLX" missing on display ":0"

I believe that I've figured out a reproducible fix for this. It involves creating a symlink for libglx.so, such that x.org would find the libglx.so for the GPU before any other libglx.so that has been installed.

I've also modified /etc/libmap.conf to ensure mesa libraries are used when available.

With the nvidia-driver-340 and xorg-server packages installed, these are the files I was seeing under /usr/local/lib/xorg/modules/extensions/

Code: 
$ find /usr/local/lib/xorg/modules/extensions/ ! -type d | xargs ls -l

lrwxr-xr-x  1 root  wheel        11 Jan 14 16:29 /usr/local/lib/xorg/modules/extensions/.nvidia/libglx.so -> libglx.so.1
-r--r--r--  3 root  wheel  16598432 Jan 14 16:29 /usr/local/lib/xorg/modules/extensions/.nvidia/libglx.so.1
-rwxr-xr-x  1 root  wheel    304176 Jan 14 15:00 /usr/local/lib/xorg/modules/extensions/.xorg/libglx.so

For when the boot disk is being used on the machine with an intel GPU, I've created a symbolic link under that directory
Code: 
# cd /usr/local/lib/xorg/modules/extensions/ && ln -s .xorg/libglx.so libglx.so

This appears to at least address the message under startx.

Double-checking the origins of the file, to be sure that it's not from the nvidia pkg:
Code: 
$ ldd /usr/local/lib/xorg/modules/extensions/libglx.so

/usr/local/lib/xorg/modules/extensions/libglx.so:
        libGL.so.1 => /usr/local/lib/libGL.so.1 (0x8006d4000)
        librpcsvc.so.5 => /usr/lib/librpcsvc.so.5 (0x800760000)
        libm.so.5 => /lib/libm.so.5 (0x80076c000)
        libthr.so.3 => /lib/libthr.so.3 (0x8007a3000)
        libc.so.7 => /lib/libc.so.7 (0x80024e000)
        libGLdispatch.so.0 => /usr/local/lib/libGLdispatch.so.0 (0x800e00000)
        libGLX.so.0 => /usr/local/lib/libGLX.so.0 (0x800eb8000)
        libdl.so.1 => /usr/lib/libdl.so.1 (0x8007d1000)
        libX11.so.6 => /usr/local/lib/libX11.so.6 (0x800eec000)
        libxcb.so.1 => /usr/local/lib/libxcb.so.1 (0x8007d5000)
        libXau.so.6 => /usr/local/lib/libXau.so.6 (0x801030000)
        libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x801036000)

For libEGL and libGLX support with mesa-libs, I've modified /etc/libmap.conf. The file originally contained this single line:
Code: 
includedir /usr/local/etc/libmap.d

With the packages installed on this disk, I see the following at the shell:
Code: 
$ find /usr/local/etc/libmap.d -type f | xargs pkg which

/usr/local/etc/libmap.d/nvidia.conf was installed by package nvidia-driver-340-340.108_3
/usr/local/etc/libmap.d/mesa.conf was installed by package mesa-libs-21.1.8

So, both files would be included in the original /etc/libmap.conf

For when the disk is being used in a machine with an Intel GPU, I've modified the original libmap.conf to include only the following configuration directives:
Code: 
include /usr/local/etc/libmap.d/mesa.conf
libGLX.so       libGLX_mesa.so
libEGL.so       libEGL_mesa.so

The first line ensures that only that file from mesa-libs is used, and not the file from the nvidia-driver-<which> package. The last two entries are tentatively added after a glance at contents of the nvidia.conf file, I believe this ensures that the Mesa libraries will be used as an alternative to those from the x.org build.

I'd tried to configure the libglx.so selection in libmap.conf. It looks like x.org may be expecting a physical file however. The symbolic link seems to address that.

With this configuration, I can then run glxinfo (graphics/mesa-demos) successfully. The desktop has graphics acceleration available now, for the window manager and for desktop applications.

Of course, I've also loaded the i915kms kernel module, from ports. This boot disk features a FreeBSD 12.3 installation.

Code: 
$ uname -a
FreeBSD tblk.cloud.thinkum.space 12.3-STABLE FreeBSD 12.3-STABLE stable/12-n1855-ce99de0241e RIPARIAN  amd64

For this boot disk, I may try putting together some scripting for rc.local, to automatically handle any symbolic linking for this configuration, before login - it could dispatch on something from dmidecode (sysutils/dmidecode) given a set of globs for matching any one machine from a known set of machine configurations. (This is already being done on the boot disk, for loading the GPU kernel module for each of these machines. It's not some very succinct scripting, it dispatches on dmidecode -s system-product-name when dmidecode is available)

For an installation that would be used singularly with an intel GPU, perhaps the configuration above might be sufficient for enabling GLX and Mesa EGL support for the intel GPU, under x.org

(HTH)
 
You must log in or register to reply here.
Back
Top