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.
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.)
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.
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.