It sounds like you're on the swrast driver! For hdmi (1080p), the stuff I watch @60hz is ≅70& on one core.

I felt - 'wait a sec, this is a bit quiet.' So I opened chromium, went to youtube, and ran some rally car dash cam footage - still no more than 150%, and chrome would have been half of that.

I did have some video issues a while back, posted about it, and took whatever advice I was given, and that sorted it. OpenGL came onstream for Pis in Mesa-5.18.x or somesuch, and VAAPI in 5.21 I think. Don't trust me; check.

EDIT: Exega posted his results on the Slackware Arm forum with OpenGL on a Pi 4 (I think) and got 2 × 4k monitors running @ 30fps. I don't know what they were running, and he didn't say. But If it's a guy giving a talk, 80% of the screen doesn't change, so graphics has it easy. 4k Videos of gaming would be different. I picked youtube dashcam footage because I don't have or want a 4k monitor, but wanted to give the monitor a changing background.

If you want to try some online test, post the url & results, and I'll post mine.

Well, "glxinfo | grep render" gives "OpenGL renderer string: V3D 4.2" which sounds about right. (Slackwareaarch64 gives llvmpipe, which is a software renderer, and yields pretty hopeless performance.

What media players are you using? I have VLC and mpv/smplayer available. VLC is set to use OpenGL output. Smplayer has options for vaapi,libmpv amongst others,but none seem to offer any significant improvement. What have you got yours set to?

--
Pete

We're hijacking this thread but it's my thread and solved so no worries.

I'm running vlc-3.0.16, chromium-98.0.something, & mesa-21.3.6. Vlc is running on OpenGL, and I have kernel 5.16.7, IIRC. The pi 4 specific overlays in /boot/config.txt are

[pi4]
dtoverlay=vc4-fkms-v3d-pi4
#dtoverlay=vc4-kms-v3d

but if I had changed that, I would have done it on the day and forgotten it.

I'm also posting on the 'Bogomips' thread and got a hilarious one
So you get 2 BogoMips for every MHz clock speed. PCs start off quick. The Pi starts very slow. Using gives a more realistic reading but it does seem the raspberry lot are thermally anxious.

Ah! You are running the fkms driver! I'm running kernel 5.19, and fkms seems to be no longer supported. It doesn't work when I try and use it, and hasn't for a while now.

I'm not sure what the relationship is between fkms and kms - there seems to be even some disagreement about what the "f" stands for - but I do know it is deprecated. And yes, several kernels ago, I got much better results with fkms than kms!

For the moment, I'm sitting tight. Like you, its not the end of the world. I can still use the Pi as an off-air DVR - even for HD content. I understand that the next kernel release should support better hardware decoding (and hopefully encoding!) operations, so I'll wait and see what happens when it comes along...

--
Pete

Lol.

Remind me not to update for a while. When x86_64 was in the 14.2 -->15.0 hiatus, I used to let current come out and wait a few days for complaints. Then I'd grab the iso, but my backup was the older version.

Enjopy the bleeding edge . With my issues, I'm trying to strictly be a user (only).

EDIT: What's your mesa version? And who maintains that fkms driver?

Sorry, been a bit tied up the last couple of days...!

Mesa is 22.1.7 on my system.

I know very little about fkms other than it worked better than kms, but needed a couple of tweaks to enable the hardware dri. Its a while since I did it, so sorry for being vague! I think I got the information from here: https://lemariva.com/blog/2020/08/ra...ecode-chromium

Although aimed at chrome / youtube / etc, it also worked for video replay via MPV and VLC, but sadly not with more recent kernels!

Hopefully we will get some improvements with 5.20/6.0....

--
Pete

That sort of thing might yield information in the logs or to a debugger. You have gdb and strace there to grab data. And if you go to runlevel 3, use startx, & get into X that way, you also get error feedback on the errors as thery happen.

The thing is that there aren't any errors! Everything is working as it should be - its just that the drivers (and maybe firmware?) for the Broadcom graphics chip aren't finished yet. The current ones only work at a very basic level, and don't appear to support hardware decoding or encoding properly yet.

--
Pete

But surely if mine works, and yours doesn't, there's been a regression?

You can probably look at the ChangeLog, and if you spot the change, reverse the patch - if you're bothered.

EDIT: You can always check for a bug, or file one if there isn't one. If you're on the bleeding edge kernel, it's clear you don't mind the sight of blood, even when it's your own!

Er, sort of. This getting above my pay grade, but as I understand the situation, fkms was a temporary bodge to get over the lack of a proper driver (and/or firmware?) for the 64 bit kernel. There was a proper driver for 32-bit, but I don't think Broadcom ever released a 64 bit version.

The improved driver was meant to be in the kernel a while back, but something (I know not what!) has slowed its deployment. As I say, we're promised a major upgrade in 5.20/6.0, which should be here in a matter of weeks, so I'm happy to sit and wait...

--
Pete

Alert: This post partly is on the original topic!

Libx265 doesn't work in ffmpeg, but the vlc build picked it up all right. So I can watch x265 movies.

On the kernel, & drivers, etc. Don't Debian put up the source code somewhere, as all mannerly GPL oriented people should do? 32 --> 64 bit is probably the easiest porting job.

Yes it does, but you have to edit the config file and recompile ffmpeg with libx265 already on the system. The standard Slackware item comes compiled without any potential patent infringing libraries.

The Broadcom stuff is proprietary. Raspbian (or whatever it is called these days) comes with a kernel patched with workarounds (I *think* this is what slarm64 comes with), but the patches aren't in the mainstream as they aren't considered good enough yet. As I say, 5.20/6.0 should contain a lot of updates in this regard.

As an aside, slackwareaarch64 comes with the default linux kernel, which is why the video performance is considerably inferior to slarm64 on Pis. Most of the development for that work is done on other hardware, which doesn't use the Broadcom graphics.

--
Pete

Ah, so this is now really a slackware-Aarch64 vs slarm64 thing? I know the slarm64 guys check this slarm64 forum, so they can speak for themselves on your kernel points in your last post.

I wanted an arm multilib system initially, but realised I was a twit. Slackware Arm stayed strictly by the x86 & x86_64 slackware recipe. slarm64 imho makes more practical decisions, e.g binary images which ease greatly the pain of an install. I chose the more practical path. From a blank sd card, slackware arm seems more difficult to install & configure, especially for someone who does it infrequently.

With the exception of the kernel, initrd, & config files The Broadcom /boot stuff is all proprietary, but so is all firmware. Most chips use microcintrollers as the laziest way of implementing the design, and giving out source code for whatever industrial cpu runs their chip, would expose the source to potential hackers, & require compiling/debugging tools for that cpu also. I'm happy as things stand, RMS notwithstanding. I was in R&D in the 1980s with a company whose firmware was in Eprom. When that needed an update, it was a costly disaster.

You could always test your 'patched kernel' theory by (heaven forbid) installing a slarm64 kernel on the quiet, making it bootable, and trying your graphics. But the slarm64 maintainers will probably chime in on this.

Not really - more a "horses for courses" thing. Slackwareaarch64 is the "official" port of Slackware, and sticks to the Slackware philosophy of being as close to the original source code as possible. Most of the developers seem to have non-Pi systems, which work fine with an un-patched kernel. Slarm64 seems to take a more liberal approach - with the kernel, at least! Also Slarm64 was the first, slackwareaarch64 coming quite late to the party. There does seem to be a lot of co-operation between the two, and I can see (and respect) the slightly different philosophies. For my purposes, at the moment, Slarm64 offers better performance.

This has actually been done (and encouraged) over on the slackwareaarch64 forum. Its not just as simple as installing the kernel as the two seem to handle the boot process somewhat differently. Basically, you have to compile the kernel from the patched version, rather than the "pure" version.

I haven't done it myself - takes too long, and too many other priorities - but those who have report graphics performance in line with slarm64.

I'll wait for the next kernel release, and see what happens then.

In the meantime, kudos to both teams for allowing us to enjoy the Slackware experience on Arm processors!

--
Pete

Yes.

The key difference for me is that slackware Arm tried to treat an Arm SBC in the same way as an X86 PC and won 'official recognition' for themselves.

But especially in the case of RazPis at boot, they are quite different. I did a little digging in my backup here. Slarm64 lump the Broadcom boot stuff on github in with the compiled kernel & initrd, afaict. They distribute Pi kernels, Pine64 kernels, etc. But slackware arm have to use the boot binaries too - there's no other way. So making the firmware a separate download is just inconveniencing the end user.

The graphics driver is kernel source code. Nearly all the fkms references grep throws up come from that 55k C file.