Graphics issues
I'm on meetings with Zoom here which are overpowering my cpu. I'll update once the 6.2x kernels come out. But meantime, I did some hunting with vcgencmd (well hidden in /opt/vc/bin) and measured clocks. The vcgencmd Man page says:
Code:
... Code:
Slarm64-15.0 Any thoughts why so little GPU runs in slarm64? Will 6 kernel 6.2.x do anything to improve things? |
all this is configurable and has nothing to do with the system.
|
Thanks for the reply.
The page you linked is rpi-0 & rpi-1 specific and seems not even to cover the Pi 2, and doesn't have anything on the Pi 3/4. Nevertheless, there are some useful utilities in the rpi-userland package and I'll see what I can do with them. I can also compare debian's config, which does seem to get better video results. Any link that's Pi-4 specific and works would be great, because I'm heading out of hardware config (my area) and into software. Anything on the rpi-4 on raspberrypi.org seems out of date and/or broken links. One thing I noticed is that the dtoverlay command errors out with Code:
/config/device-tree: mount point does not exist |
Well, I discovered a few things. I found this one section of video that wouldn't render on slarm64. VLC had 6-8 threads open, and because of the way the load was unevenly spread, the video was stopping as htop showed the load was looking for >100% on two cores, and they could only give 100% each. Total CPU load on top showed at about 280%, with two cores more than maxed out.
I then booted Debian Bullseye (the rpiOS 64bit), loaded the same section of the same video in VLC on Debian Bullseye. Bullseye rendered it well. The total cpu load was about 80% between the 4 cores.:mad: That's a pretty striking difference. As for 'everything being configurable,' the option Code:
vcgencmd get_config [int|str] It is difficult to get any real data. Stuff on config.txt covers rpi 0-4, cm4 & 400 and the hardware differs greatly. I can only find the odd explanation for some random fact online. One such is the difference between the vc4-kms-v3d.dtbo & vc4-fkms-v3d.dtbo. There are two conflicting explanations in the RazPi documentation, and forum. The f stands for "fake kms" and gives a degree of leniency to the software. My box switches off the GPU and graphics are all kernel done by the kernel & Mesa. Debian makes the GPU work, with superior results and much lower cpu load. |
is the kernel version the same?
|
Quote:
Code:
dtoverlay=upstream |
well, these are different kernels, 5.15.y is stable and it includes and implements something that is not in 6.x.y
|
I've chased up the differences as much as I can, and stopped. Here's what I found. Slarm64's Software versions are a a few minor numbers up on RPi OS, although Debian test more and patch things.
Xorg.0.log seems similar in both systems. I compared Xorg.0.log files. They load the same modules get the same reactions in the logs. The RazPi firmware & hardware remained the same. I compared file sizes. The only patch I suspected was an (earlier) version of the vc4-kms-v3d overlay being 1K bigger, so I tried that in slarm64. It may have made a small improvement. To eliminate vlc, I tried your other mp4 players. Firefox offers to play .mp4s using QAV. It gave me a small black window, I heard the soundtrack, but saw nothing. MPV played the test video section just about, but it was spreading cpu load better over 4 cores whereas vlc seemed to concentrate the load on three. Load was up to 325% at times, to judge by the htop graphical output. Next thing is the kernel. I can't compare module size because theirs are compressed; I can't compare configs, because Debian don't supply one. Suspiciously, all their module trees are numbers like '5.15.16+' which nearly implies patching, but what I've found is a long way off Red Hat's revisions. Lastly, I'll mention my test video is 1080p, and I'm using one hdmi-1.0 monitor. I'd have no chance on 4k, requiring four times the bandwidth, let alone 2 of them! That's what the Pi is supposed to drive. |
One last try. I got your latest current on an sdcard, and tried that. It just about works with mpv at 350% cpu with tell-tale signs of overloading, e.g. legs moving jerkily. Shrinking the size of displayed video did next to nothing. Slackware Arm seems little better. Kernel 6.0.9 seems to have no acceleration enabled.
The latest kernel is 6.1.1, so 6.2 could be three months away. Debian beckons..... EDIT: I'm not a Debian fan, but on my test video, Debian is showing 60-70% on top... |
Quote:
you can try kernel 5.15.34 and use Code:
dtoverlay=vc4-fkms-v3d-pi4,cma-512 |
Slackware is much more comfortable for me, and slarm64 of the Aarch64 offerings.
But Debian doesa the business, and slarm64 doesn't, unfortunately. I have debian 64bit on an sdcard but not on disk. I'm mounting the Slackware /home to access the videos. But slarm64 isn't driving the GPU, and that needs rethinking. |
This might help you finger it. I tried three videos
On Slarm64, the same few bits of the gpu regardless. All were pretty cpu heavy. On Debian, different cpu configurations were applied. The h264 block was on for the h264 video. It remained off on Slarm64. Their Xorg modules are smaller than yours. Maybe it's a kernel thing? |
I wrote above that you need to change to the kernel 5.15.y and change the driver to fkms
|
OK, I will.
|
Quote:
I tried the video regardless of sound on 5.15.80, and it's worse. So I said to myself "Never mind, I'll stick in Debian," but the sdcard chose that moment to remind me how unreliable sdcards are. I don't see any point in trying 5.15.19-generic. So I'm stuck restoring my backup of 5.16.7-bcm2711 because I never had the package, without disturbing my recent installs. Debian isn't all plain sailing either, btw. The key difference is that when debian sets up the gpu for the job on hand, but slarm64 is doing all software. So when debian plays a h264 video, it wakes up the h264 block in the gpu, but slarm uses the cpu. That's why debian performs better. EDIT: The firmware is in the bcm2711 kernels, so that explains loads :doh: |
All times are GMT -5. The time now is 01:01 AM. |