Comment by codetrotter | Hacker News Reader

Comment by codetrotter | Hacker News Reader

Parent Full thread

I think a big part of the reason is also the fact that several parts of the userland don’t compile for aarch64.

See e.g. https://github.com/raspberrypi/userland/issues/314

One of the first comments there also say about the RPi 3:

> The GPU is a 32 bit processor. I haven't checked, but I'm expecting that there's a heck of a lot more work to do to get Khronos or other multimedia extension stuff up and running against a 64bit kernel than just getting userland to build.

Don’t know if that’s the case for the RPi 4 as well.

And another comment too:

> I'm sure there are certain applications where having a 64-bit kernel (let alone userland) may be beneficial, but I suspect the hoped-for performance improvements didn't materialise, otherwise people would be waving benchmark results at us demanding an RPi-supported aarch64 kernel.

I’m missing this too, and am planning on eventually doing some benchmarking of my own to see if there is any advantage of running the aarch64 kernel for my applications.

The GPU has nothing to do with what the OS on the CPU is doing - it's an entirely separate architecture anyway (VideoCore 6 on RPi4).

The reason their /opt/vc stuff doesn't support 64bit is because there are proprietary binaries directly from Broadcom. Also, they use interfaces provided only by the downstream RPi kernel.

There is a blog post from the RPi foundation about support for VC6 in Mesa.

What do you exactly mean by "/opt/vc" stuff? OpenGL?

Because I am decoding, encoding and rendering 1080p H264 with the VC on a 64-bit kernel.

Things like vcgencmd that allow you to read and write values to the GPU OS that actually controls the physical hardware.

For what it's worth, Fedora support arm7/aarch64 images for the rpi3: https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_P...

The raspberry pi 4 apparently isn't supported. I'm not exactly clear on why, and how this links to the above issue, and if any of the things they suggest are problems in their bug tracker are also not solved in Fedora, or are simply raspberry pi people being unwilling to fix in their setup.

The fedora/etc problem has to do with the lack of uboot/edk2 and upstream kernel support. Once support lands in the appropriate repos you can expect fedora will enable it.

There's a full 64-bit Gentoo image available. It seems to work fine for all my use-cases. I'm not sure which parts of your comments really apply at this point in time.

Hardware accelerated OpenGL. As far as I have been able to tell, that will still be missing if you run an aarch64 kernel.

And I think using the GPU to get hardware accelerated video decoding and encoding will not be available either.

Edit: But if I understand https://github.com/popcornmix/omxplayer/issues/714 correctly then you could do hardware accelerated decoding of HEVC on the CPU. I don’t know how the performance of that compares to the kind of video decoding that the GPU can do. That’s one of the things I’d like to see someone benchmark, or benchmark myself.

That was the case but the VC4 instruction set is open/documented and there is a Mesa driver worked on to REPLACE the closed binary driver which is only available for 32-bit. When you use the Mesa VC4 driver you can also compile the whole user space for 64 bit including OpenGL ES support in a even newer version then the closed source one. (Supporting user kernels etc.)

You can find some info about that here: https://wiki.gentoo.org/wiki/Raspberry_Pi_VC4

Some side notes: Mesa is quite hungry in performance and memory to compile shaders (to VC4 instructions), way more then the closed driver requires, thats why older versions of the Pi with less powerfull ARM cores couldn't really use this approach.

Source: I used to write custom user shaders in VC4 assembly to run on all Pis because the closed binary didn't offer OpenCL.

The 64bit kernel is able to run a 32bit userland, so it should be possible with the correct libraries etc to run vcgencmd and friends.

I've personally had no issues - the system is overall faster than on armv7h - ioquake3 runs full speed, I can watch 1080p videos in mpv, etc.

I can't seem to get the 'kitty' terminal to work which does require the use of OpenGL, but that doesn't work on a 32bit kernel for me either.

Reply on news.ycombinator.com