Debian 9.5 and coffee lake iGPU

[Mike5123]

Using Debian 9.5 with a more recent kernel it still won't properly recognize my coffee lake iGPU (Intel UHD 630). I am able to use the iGPU with hardware decoding to an extent, but OS reports it as a vmware adapter and vainfo doesn't work at all.

intel_gpu_top kind of works. It shows the render usage but everything else is missing.

[Segfault]

There are three components. Kernel driver, Xorg driver and MESA. All of them must be new enough to make your graphics work.

[Mike5123]

It's a headless server so xorg shouldn't be needed.

Installed backports for the 4.18 kernel, firmware-misc-nonfree, updated hardware ID databases with inxi, installed the mesa-glx and mesa-dri from backports and vainfo still errors out (it's not an x error, either).

intel_gpu_top doesn't see all available info, just the renderer.

Did I miss anything? This GPU works on Ubuntu 18.04 out of the box, so this is a little out of my depth.

[Segfault]

I don't think it is a kernel driver issue. Check out your Xorg log, I'm sure the answer is there.

[stevepusser]

I have it working on the same UHD 630, but it's with my own backports in the Stretch-based MX 17 Experimental repository (stretch-backports wasn't quite caught up at the time):

Code: Select all

$ vainfo
libva info: VA-API version 1.2.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_2
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.2 (libva 2.1.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Coffee Lake - 2.2.0
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Simple            : VAEntrypointEncSlice
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointEncSliceLP
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointEncSliceLP
      VAProfileH264MultiviewHigh      : VAEntrypointVLD
      VAProfileH264StereoHigh         : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointEncPicture
      VAProfileVP8Version0_3          : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileHEVCMain10             : VAEntrypointVLD
      VAProfileVP9Profile0            : VAEntrypointVLD
      VAProfileVP9Profile2            : VAEntrypointVLD

I sort of get the impression that the libva packages need to be compiled against the exact same Mesa libraries that you're using, which not might be the case in backports--they can update Mesa there without updating the libva packages. They'll install, but won't work.

I've set up a repo on the OBS with KMF packages. The OBS automatically does rebuilds of all dependent packages if you change one (unless you disable the "use for build" flag), so I'm hoping that this produces working hardware acceleration. I made sure to build libva against the existing libraries in the MX Experimental repo, and it works for me, but it's more of a pain when I update some to manually rebuild everything instead of having the OBS rebuild everything automagically.

I have the link to my OBS repo and instructions to add it in this thread. Currently I have a slightly newer kernel and libva in it than backports has.

[Mike5123]

I have the link to my OBS repo and instructions to add it in this thread. Currently I have a slightly newer kernel and libva in it than backports has.

Can you link the thread? Thanks.

[stevepusser]

Oops, got interrupted and hit submit too soon.

http://forums.debian.net/viewtopic.php?f=16&t=139003

[Mike5123]

Oops, got interrupted and hit submit too soon.

http://forums.debian.net/viewtopic.php?f=16&t=139003

Trying to use your repository here http://forums.debian.net/viewtopic.php? ... 03#p684553 but only a handful of the packages actually show up in apt.

[stevepusser]

Can you list them?

Code: Select all

apt list --upgradable

I thought mine should be higher than backports, since ~obs is seen as higher than ~bpo9+1 in the version.

[stevepusser]

I tested adding the repo to a MX Linux Stretch base on an install in Virtual Box, and this is what "apt list --upgradable" shows for me:

Code: Select all

firmware-amd-graphics/unknown 20180825.dfsg-1~obs all [upgradable from: 20180518-1~mx17+1]
firmware-atheros/unknown 20180825.dfsg-1~obs all [upgradable from: 20180518-1~mx17+1]
firmware-bnx2/unknown 20180825.dfsg-1~obs all [upgradable from: 20180518-1~mx17+1]
firmware-bnx2x/unknown 20180825.dfsg-1~obs all [upgradable from: 20180518-1~mx17+1]
firmware-brcm80211/unknown 20180825.dfsg-1~obs all [upgradable from: 20180518-1~mx17+1]
firmware-intel-sound/unknown 20180825.dfsg-1~obs all [upgradable from: 20180518-1~mx17+1]
firmware-intelwimax/unknown 20180825.dfsg-1~obs all [upgradable from: 20180518-1~mx17+1]
firmware-ipw2x00/unknown 20180825.dfsg-1~obs all [upgradable from: 20180518-1~mx17+1]
firmware-iwlwifi/unknown 20180825.dfsg-1~obs all [upgradable from: 20180518-1~mx17+1]
firmware-libertas/unknown 20180825.dfsg-1~obs all [upgradable from: 20180518-1~mx17+1]
firmware-linux-nonfree/unknown 20180825.dfsg-1~obs all [upgradable from: 20180518-1~mx17+1]
firmware-misc-nonfree/unknown 20180825.dfsg-1~obs all [upgradable from: 20180518-1~mx17+1]
firmware-myricom/unknown 20180825.dfsg-1~obs all [upgradable from: 20180518-1~mx17+1]
firmware-netxen/unknown 20180825.dfsg-1~obs all [upgradable from: 20180518-1~mx17+1]
firmware-qlogic/unknown 20180825.dfsg-1~obs all [upgradable from: 20180518-1~mx17+1]
firmware-realtek/unknown 20180825.dfsg-1~obs all [upgradable from: 20180518-1~mx17+1]
libdrm-amdgpu1/unknown 2.4.95-1~bpo9 amd64 [upgradable from: 2.4.74-1]
libdrm-dev/unknown 2.4.95-1~bpo9 amd64 [upgradable from: 2.4.74-1]
libdrm-intel1/unknown 2.4.95-1~bpo9 amd64 [upgradable from: 2.4.74-1]
libdrm-nouveau2/unknown 2.4.95-1~bpo9 amd64 [upgradable from: 2.4.74-1]
libdrm-radeon1/unknown 2.4.95-1~bpo9 amd64 [upgradable from: 2.4.74-1]
libdrm2/unknown 2.4.95-1~bpo9 amd64 [upgradable from: 2.4.74-1]
libegl1-mesa/unknown 18.1.9-1~bpo9 amd64 [upgradable from: 13.0.6-1+b2]
libegl1-mesa-dev/unknown 18.1.9-1~bpo9 amd64 [upgradable from: 13.0.6-1+b2]
ibgbm1/unknown 18.1.9-1~bpo9 amd64 [upgradable from: 13.0.6-1+b2]
libgl1-mesa-dri/unknown 18.1.9-1~bpo9 amd64 [upgradable from: 13.0.6-1+b2]
libgl1-mesa-glx/unknown 18.1.9-1~bpo9 amd64 [upgradable from: 13.0.6-1+b2]
libglapi-mesa/unknown 18.1.9-1~bpo9 amd64 [upgradable from: 13.0.6-1+b2]
libgles2-mesa/unknown 18.1.9-1~bpo9 amd64 [upgradable from: 13.0.6-1+b2]
libwayland-bin/unknown 1.16.0-1~bpo9 amd64 [upgradable from: 1.12.0-1]
libwayland-client0/unknown 1.16.0-1~bpo9 amd64 [upgradable from: 1.12.0-1]
libwayland-cursor0/unknown 1.16.0-1~bpo9 amd64 [upgradable from: 1.12.0-1]
libwayland-dev/unknown 1.16.0-1~bpo9 amd64 [upgradable from: 1.12.0-1]
libwayland-egl1-mesa/unknown 18.1.9-1~bpo9 amd64 [upgradable from: 13.0.6-1+b2]
libwayland-server0/unknown 1.16.0-1~bpo9 amd64 [upgradable from: 1.12.0-1]
libxatracker2/unknown 18.1.9-1~bpo9 amd64 [upgradable from: 13.0.6-1+b2]
libxnvctrl0/unknown 390.67-1~obs1 amd64 [upgradable from: 384.111-1~deb9u1]
linux-compiler-gcc-6-x86/unknown 4.18.10-1~obs amd64 [upgradable from: 4.15.4-1~mx17+1]
linux-libc-dev/unknown 4.18.10-1~obs amd64 [upgradable from: 4.15.4-1~mx17+1]
mesa-common-dev/unknown 18.1.9-1~bpo9 amd64 [upgradable from: 13.0.6-1+b2]
nvidia-detect/unknown 390.87-2~obs1 amd64 [upgradable from: 384.130-1]
wayland-protocols/unknown 1.13-1~bpo9 all [upgradable from: 1.7-1]
xserver-xorg-video-intel/unknown 2:2.99.917+git20180925-2~obs1 amd64 [upgradable from: 2:2.99.917+git20161206-1]
xserver-xorg-video-nouveau/unknown 1:1.0.15-3~obs1 amd64 [upgradable from: 1:1.0.13-3]

Some of the packages I just changed to "bpo9" if I took them from stretch-backports, so they won't be seen as upgrades if you already have the backports "bpo9+1" version installed.

[Mike5123]

some of the packages I just changed to "bpo9" if I took them from stretch-backports, so they won't be seen as upgrades if you already have the backports "bpo9+1" version installed.

That explains the problem then. I'd honestly just use ubuntu, but Debian gives me ~500Mbps more throughput on file transfers. Apparently the 18.04 kernel has a networking bug, and other kernels like xanmod help but don't deliver the same throughput as Debian.

So there is no way this will work if backports have already been installed and updated?

[stevepusser]

What is "apt list --upgradable" showing? You should be able to upgrade what it's showing and keep the backports packages, and it should all work, since they are basically the same as in my repo.

If not, I'll change the versioning on those bpo9 packages to obs so they will be seen as upgrades.