Video graphics in Linux is very tedious and complicated thing. Take a huge cup of coffee if you really want to get into it right. Because there are lot of things here. You might even want to revisit this page multiple times as it's kinda hard to get everything from one set. It took me like a number of hours to get a head and a tail out of it, but yet I'm not 100% I'm giving you all correct information here. But at least you should get an idea.
There're multiple components in this topic we need to know about:
kernel driver ("DRM")
this is the piece of code in kernel which actually makes some low level calls to GPU device to make it to display something. If you don't do anything on purpose about it, Linux kernel probably fallback to some compatible driver which will allow it to talk at least some basic common language with your GPU so it can display things. But don't expect that fallback driver to give you any performance.
There're two types of drivers:
- opensource - usually from Mesa project
- binary / proprietary / aka blobs - made by hardware manufacturers
Opensource drivers are good not only because they're opensource, but also because they'll be supported in next versions of Linux Kernel. Which means if you decide to upgrade your distro or jump to some other distro with updated Kernel, you'll be able to do that, as your videodrivers will be there.
On a contrary, proprietary drivers are created by manufacturers for very specific kernel version, and usually they are not updated.
Here you should ask a question, like "So what? Can I just use this Linux Kernel for the rest of this device life?" The answer is yes, sure. As long as the core libs in Linux (like glibc) are supporting it. So chances are, after few years, they won't be any longer, which means you won't be able to install updates to any software, which depends on those core libs.
user-space driver (usually from Mesa project).
What they do is they provide Open GL or Vulkan API to application, who needs that in one hand, and in the other they make calls to appropriate kernel driver. This is what usually called mesa rendering backend. In case if you don't have GPU kernel drivers to support Mesa, it can fallback to one of the software rendering "backends", the most famous one is llvmpipe, but there're others. What does software rendering mean here, is that all the math calculations needed to display 3D graphics will be done on you CPU rather than on GPU. Usually it's a bad thing, as GPU are much more sophisticated
Xorg configuration files
xxx
WindowManager configuration (e.g. kwin can use XRender or OpenGL)
xxx
Here I'm not even speaking about video acceleration yet (i.e. how to make your YouTube videos not to consume 100% cpu)
Since I installed the KDE desktop environment on a top of retropi distro from Ream.It (effectively it's just Debian installed with Armbian scripts and a custom kernel to support my RK3399) I was noticing few issues.
Issue 1: playing video - both YouTube or via VLC/dragon player - was maxing out CPU
Basically the machine was screaming at me saying it does not use hardware video acceleration. I'll deal with it bit later
Issue 2: in KDE my CPU was quite oftten maxed out by kwin_x11
I figured it out, that this issue goes away if you switch kwin renderer from OpenGL 2/3.1 to Xrender:KDE System Settings -> Display and monitor -> Compositor -> Rendering backend
I'm guessing when kwin attempts to use OpenGL which was so far done by llvmpipe backend (software renderer in Mesa), the CPU was doing twice as much job as it should do:
kwin_x11 -> OpenGL -> software renderer driver of mesa (llvm)
And switching it directly to XRender - a purely software renderer made things so much easier for CPU:
kwin_x11 -> XRender
It is a workaround of course, the final goal is to make OpenGL working
Going deeper
In X glxinfo is showing I'm using llvmpipe - i.e. software renderer.
I have mesa installed of version 20.3.5 from Debian bullseye stable and kernel from Rearm.It. The kernel has some DRM modules though:
pi@orangepi4-lts:~/projects$ lsmod | grep rock
snd_soc_rockchip_i2s 20480 4
rockchip_vdec 81920 0
v4l2_vp9 24576 2 rockchip_vdec,hantro_vpu
snd_soc_core 266240 5 snd_soc_hdmi_codec,snd_soc_simple_card_utils,snd_soc_rockchip_i2s,snd_soc_simple_card,snd_soc_es8316
rockchip_iep 24576 0
v4l2_h264 16384 2 rockchip_vdec,hantro_vpu
videobuf2_dma_contig 24576 3 rockchip_vdec,hantro_vpu,rockchip_iep
v4l2_mem2mem 40960 3 rockchip_vdec,hantro_vpu,rockchip_iep
videobuf2_v4l2 32768 4 rockchip_vdec,hantro_vpu,rockchip_iep,v4l2_mem2mem
videobuf2_common 61440 7 rockchip_vdec,videobuf2_dma_contig,videobuf2_v4l2,hantro_vpu,rockchip_iep,v4l2_mem2mem,videobuf2_memops
videodev 249856 6 rockchip_vdec,videobuf2_v4l2,hantro_vpu,videobuf2_common,rockchip_iep,v4l2_mem2mem
mc 61440 6 rockchip_vdec,videodev,videobuf2_v4l2,hantro_vpu,videobuf2_common,v4l2_mem2mem
phy_rockchip_dphy_rx0 20480 0
Just for the sake of sanity I also installed mesa-utils-extra and none of the demos work (no surprise)
However if I stop X and run kmscube it detects proper renderer "Mali-T860 (Panfrost)" and says that I have mesa of version 22.1.4
No comments:
Post a Comment