Sunday, January 02, 2022

GPU rendering not working for video, desktop on Linux with UHD 630



I ran across some issues with Fedora 34 (and 35) running on a z590 + UHD 630 platform. The first problem was that it could not run Wayland, instead it would fall back to Xorg. An easy way to see if you are using X11 or wayland:


$ echo $XDG_SESSION_TYPE

x11

$ 


After  poking around on web searches and a bit of fiddling, I still could not get Wayland to work, so assumed my hardware was not supported, as a), it was fairly new at the time, and b), I seem to recall that when I booted off the USB drive into the Fedora installer it gave me a black screen, and I had to choose 'basic graphics' to be able go through with the GUI install.


Once I'd gotten the OS installed, I found a second problem: it was not using the GPU to render the desktop or decode video. Just moving a terminal window around, with no other windows running, would use 150% of CPU, as shown on 'top' (this was a core-i9 10900T, with 10 cores, 20 threads). Playing back a 1080p x264 video would show 800% of CPU in top, with the gnome-shell itself using another 200% as well. I tried various different video players, such as VLC, Totem and MPV, all showed the same high CPU usage. I looked at various options in VLC to see if I was perhaps missing hardware decoding, but could not find anything obvious. Using MPV on the command line gave me a hint, as it reported that it was using a software renderer: 


$ mpv --vo=gpu --hwdec=vaapi myvideo.mkv


 (+) Video --vid=1 (*) (h264 1920x1040 23.976fps)

libEGL warning: DRI2: failed to authenticate

[vo/gpu/opengl] Suspected software renderer or indirect context.

[vo/gpu/opengl] Suspected software renderer or indirect context.

[vo/gpu] VT_GETMODE failed: Inappropriate ioctl for device

[vo/gpu/opengl] Failed to set up VT switcher. Terminal switching will be unavailable.

[vo/gpu/opengl] Listing DRM devices with drmGetDevices failed! (No such file or directory)

[vo/gpu/opengl] Failed to find a usable DRM primary node!

[vo/gpu/opengl] Failed to create KMS.

[vo/gpu/vulkan/libplacebo] Found no suitable device, giving up.

[vo/gpu/vulkan/libplacebo] Failed initializing vulkan device

Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory

[vo/vdpau] Error when calling vdp_device_create_x11: 1

[vo/xv] No Xvideo support found.

[vo/sdl] Using opengl

[vo/sdl] Warning: this legacy VO has bad performance. Consider fixing your graphics drivers, or not forcing the sdl VO.

AO: [pulse] 48000Hz 5.1(side) 6ch float

VO: [sdl] 1920x1040 yuv420p

AV: 00:00:04 / 01:47:24 (0%) A-V:  0.000

Exiting... (Quit)

$ 


As above, I tried specifying vaapi (the Intel video acceleration API) and vo=gpu and it made no difference to performance (the result was the same without specifying any decoder or vo option). Playing the same mkv on another desktop machine (which had an Nvidia geforce GT 710) showed the equivalent of about 80% of one hardware thread being used.


Some tools for checking hardware and driver info:


$ inxi -GxxS

System:    Host: fedora Kernel: 5.14.16-301.fc35.x86_64 x86_64 bits: 64 compiler: gcc v: 2.37-10.fc35 Desktop: GNOME 41.1

           tk: GTK 3.24.30 wm: gnome-shell dm: GDM Distro: Fedora release 35 (Thirty Five)

Graphics:  Device-1: Intel CometLake-S GT2 [UHD Graphics 630] vendor: Micro-Star MSI driver: N/A bus-ID: 00:02.0

           chip-ID: 8086:9bc5

           Display: x11 server: X.Org 1.20.11 compositor: gnome-shell driver: loaded: vesa unloaded: fbdev,modesetting

           resolution: 2560x1440~93Hz s-dpi: 96

           OpenGL: renderer: llvmpipe (LLVM 13.0.0 256 bits) v: 4.5 Mesa 21.3.2 direct render: Yes

$


i915 driver is loaded:


# lsmod|grep i915

i915                 2936832  0

i2c_algo_bit           16384  1 i915

ttm                    86016  1 i915

drm_kms_helper        303104  1 i915

cec                    61440  2 drm_kms_helper,i915

drm                   630784  3 drm_kms_helper,i915,ttm

video                  57344  1 i915

#


I also ran a modinfo on the i915 kernel module (I forgot to put the output here prior to fixing the issue so that's why I haven't posted it. Plus it is a lot of text)


The xorg driver version (from an rpm -qa|grep xorg):


xorg-x11-drv-intel-2.99.917-51.20200205.fc35.x86_64


I had the userspace VA Intel driver packages installed:


$ rpm -qa|grep libva

libva-2.13.0-1.fc35.x86_64

libva-intel-driver-2.4.1-6.fc35.x86_64

libva-utils-2.13.0-1.fc35.x86_64

$


However, vainfo reported:


$ vainfo

libva info: VA-API version 1.13.0

libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)

vaInitialize failed with error code -1 (unknown libva error),exit

$


$ export LIBVA_DRIVER_NAME=i915 LIBVA_TRACE=1

$ vainfo --display x11

libva info: Open new log file 1.125217.thd-0x00037e8c for the thread 0x00037e8c

libva info: LIBVA_TRACE is on, save log into 1.125217.thd-0x00037e8c

libva info: VA-API version 1.13.0

libva info: User environment variable requested driver 'i965'

libva info: Trying to open /usr/lib64/dri/i915_drv_video.so

libva info: Found init function __vaDriverInit_1_12

libva error: /usr/lib64/dri/i915_drv_video.so init failed

libva info: va_openDriver() returns -1

vaInitialize failed with error code -1 (unknown libva error),exit

$


So it is looking for the 'i915' driver, but can't initialize it, though it is present: 


$ ls -l /usr/lib64/dri/i915_drv_video.so

-rwxr-xr-x 1 root root 8233672 Aug  3 11:09 /usr/lib64/dri/i915_drv_video.so

$


and is provided by 


$ rpm -qf /usr/lib64/dri/i915_drv_video.so

libva-intel-driver-2.4.1-6.fc35.x86_64

$


$ xdpyinfo | grep DRI

    DRI2

$


There were various posts mentioning using the i965 driver. The user space i965 driver is supplied by the libva-intel-driver. There is no kernel module for the i965, just the i915. I also tried specifying the i965 driver with LIBVA_DRIVER_NAME, but the same result. I saw a post that says that when using the UHD 630, the 'intel-media-driver' package should be used, which was installed. It provides the Intel HD (iHD) driver:


/usr/lib64/dri/iHD_drv_video.so


$ export LIBVA_DRIVER_NAME=iHD LIBVA_TRACE=1


$ vainfo


libva info: Open new log file 1.131754.thd-0x00001fc2 for the thread 0x00001fc2

libva info: LIBVA_TRACE is on, save log into 1.131754.thd-0x00001fc2

libva info: VA-API version 1.13.0

libva info: User environment variable requested driver 'iHD'

libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so

libva info: Found init function __vaDriverInit_1_13

libva error: /usr/lib64/dri/iHD_drv_video.so init failed

libva info: va_openDriver() returns 2

vaInitialize failed with error code 2 (resource allocation failed),exit


$


Same problem.

/usr/lib64/dri/iHD_drv_video.so exists:


$ ls -l /usr/lib64/dri/iHD_drv_video.so

-rwxr-xr-x 1 root root 36802680 Dec 19 19:36 /usr/lib64/dri/iHD_drv_video.so

$


Since I already have the intel-media-driver package installed already, maybe uninstalling the libva-intel-driver would help? I did that (it wouldn't allow me to uninstall libva, as it would remove gnome!). I then rebooted to see if it might use the iHD user-space driver. It seemed to do a lot of stuff at boot (I couldn't see what it was doing as I didn't have a monitor attached, but from the disk activity LED being so busy I think it was rebuilding the initrd). Sadly this didn't fix the issue, and the vainfo was the same as above for iHD. 


I'm not quite sure whether GL is relevant here at all (I thought that was only used for 3D stuff - perhaps only if using something like Compiz?). But perhaps the report can be useful as it shows the state of 3D support from the hardware. I didn't save the output before fixing the issue, but it reported a lot of 'slow' and 'none' on the registers in the full output. Comparing this with a functioning Nvidia setup, all those registers are 'none'. Here's the top portion of output from glxinfo which I captured, though not showing the register info, which is very extensive):


$ LIBGL_DEBUG=1 glxinfo -B


name of display: :1

libGL: Can't open configuration file /etc/drirc: No such file or directory.

libGL: Can't open configuration file /home/cm/.drirc: No such file or directory.

libGL: Can't open configuration file /etc/drirc: No such file or directory.

libGL: Can't open configuration file /home/cm/.drirc: No such file or directory.

display: :1  screen: 0

direct rendering: Yes

Extended renderer info (GLX_MESA_query_renderer):

    Vendor: Mesa/X.org (0xffffffff)

    Device: llvmpipe (LLVM 13.0.0, 256 bits) (0xffffffff)

    Version: 21.3.2

    Accelerated: no

    Video memory: 31917MB

    Unified memory: no

    Preferred profile: core (0x1)

    Max core profile version: 4.5

    Max compat profile version: 4.5

    Max GLES1 profile version: 1.1

    Max GLES[23] profile version: 3.2



Back to a web search then. I found a few posts mentioning 'nomodeset' causing issues, e.g., https://ask.fedoraproject.org/t/f33-and-uhd-graphics-630/12919. Nothing specific for my issue though. But I'd run out of ideas. So what is 'nomodeset'?


From https://itectec.com/ubuntu/ubuntu-what-do-the-nomodeset-quiet-and-splash-kernel-parameters-mean/:


"The newest kernels have moved the video mode setting into the kernel. So all the programming of the hardware specific clock rates and registers on the video card happen in the kernel rather than in the X driver when the X server starts.. This makes it possible to have high resolution nice looking splash (boot) screens and flicker free transitions from boot splash to login screen. Unfortunately, on some cards this doesn't work properly and you end up with a black screen. Adding the nomodeset parameter instructs the kernel to not load video drivers and use BIOS modes instead until X is loaded."


As I mentioned earlier in this post, I have a recollection that I got a black screen when booting off the USB, and so tried 'basic graphics' as the option to get it to work. I'm wondering if this was responsible for my system being set with 'nomodeset' on the kernel command line (or is it the default?): 


$ cat /proc/cmdline 


BOOT_IMAGE=(hd4,gpt2)/vmlinuz-5.15.12-200.fc35.x86_64 root=UUID=11fa5325-3852-49f0-9408-010943263592 ro rootflags=subvol=root nomodeset rhgb quiet selinux=0



I edited the GRUB configuration (/etc/default/grub) by finding the the string nomodeset and deleting it, saving and rebuilding grub.cfg:


$ sudo grub2-mkconfig -o /etc/grub2-efi.cfg 


I rebooted and it came up quickly (no initrd rebuilds).


It was running wayland!


$ echo $XDG_SESSION_TYPE

wayland


Also the version of DRI was now v3 instead of v2:


$ xdpyinfo | grep DRI

   DRI3


And vainfo looked healthier:


$ vainfo

libva info: Open new log file 1.135117.thd-0x00001826 for the thread 0x00001826

libva info: LIBVA_TRACE is on, save log into 1.135117.thd-0x00001826

libva info: VA-API version 1.13.0

libva info: User environment variable requested driver 'iHD'

libva info: Trying to open /usr/lib64/dri/iHD_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 iHD driver for Intel(R) Gen Graphics - 21.4.3 ()

vainfo: Supported profile and entrypoints

      VAProfileNone                   : VAEntrypointVideoProc

      VAProfileNone                   : VAEntrypointStats

      VAProfileMPEG2Simple            : VAEntrypointVLD

      VAProfileMPEG2Simple            : VAEntrypointEncSlice

      VAProfileMPEG2Main              : VAEntrypointVLD

      VAProfileMPEG2Main              : VAEntrypointEncSlice

      VAProfileH264Main               : VAEntrypointVLD

      VAProfileH264Main               : VAEntrypointEncSlice

      VAProfileH264Main               : VAEntrypointFEI

      VAProfileH264Main               : VAEntrypointEncSliceLP

      VAProfileH264High               : VAEntrypointVLD

      VAProfileH264High               : VAEntrypointEncSlice

      VAProfileH264High               : VAEntrypointFEI

      VAProfileH264High               : VAEntrypointEncSliceLP

      VAProfileVC1Simple              : VAEntrypointVLD

      VAProfileVC1Main                : VAEntrypointVLD

      VAProfileVC1Advanced            : VAEntrypointVLD

      VAProfileJPEGBaseline           : VAEntrypointVLD

      VAProfileJPEGBaseline           : VAEntrypointEncPicture

      VAProfileH264ConstrainedBaseline: VAEntrypointVLD

      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice

      VAProfileH264ConstrainedBaseline: VAEntrypointFEI

      VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP

      VAProfileVP8Version0_3          : VAEntrypointVLD

      VAProfileVP8Version0_3          : VAEntrypointEncSlice

      VAProfileHEVCMain               : VAEntrypointVLD

      VAProfileHEVCMain               : VAEntrypointEncSlice

      VAProfileHEVCMain               : VAEntrypointFEI

      VAProfileHEVCMain10             : VAEntrypointVLD

      VAProfileHEVCMain10             : VAEntrypointEncSlice

      VAProfileVP9Profile0            : VAEntrypointVLD

      VAProfileVP9Profile2            : VAEntrypointVLD

$


The gnome shell was using negligible CPU to move windows around, and to play back the x264 video that previously used massive amounts of CPU now showed 40-60% usage of one hardware thread. Result!


No comments: