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
$
/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!
