64-bit operating system

[code_exec]

The Pi 3B+ running in 32-bit compatibility mode completes the computation in 15.43 seconds. Based on rescaling the clock speeds of a different ARM-based single-board computer, it was estimated that the Pi 3B+ running in 64-bit mode should complete this same computation in only 7.49 seconds. If true, that would be a two-fold increase in speed for a particular application just by switching operating systems.

It would be nice if someone who is running a 64-bit operating system on real 3B+ hardware could confirm that this estimate is correct.

On code_exec's Debian image with a 3B+ I'm consistently getting 33 seconds for 32-bit and 17 seconds for 64-bit, so it's very close to a 2x speedup but the absolute runtimes are not matching others' results. I'll follow up on the other thread.

It also turns out I was unfortunately mistaken on Docker 32-bit. With packages named both docker and docker-ce, I did not realize I had docker-ce:arm64 installed at the time. Testing again, I'm unable to run any aarch64 Docker images on docker-ce:armhf.

I'm building a Debian XFCE image at the moment. Hopefully, it will be released tomorrow.

One issue I encountered with the MATE 64-bit image is that whenever I run sudo it says:

Code: Select all

sudo: unable to resolve host debian-mate-rpi3

To fix this I had to edit /etc/hosts.

Thanks for reporting this issue! Could you post your edited /etc/hosts file to include in future Debian images?

[Gavinmc42]

http://webglsamples.org/blob/blob.html
This runs at 29fps on my Blade A475 cheap mobile phone.
Android 5.1, 1GHz 4 core A53 with Mali T720 MP1.
Is the Mali 720 6 times faster than the VC4?
Gentoo64 uses Eric's Mesa driver, is it 6 times slower?

[jdonald]

Code: Select all

sudo: unable to resolve host debian-mate-rpi3

To fix this I had to edit /etc/hosts.

Could you post your edited /etc/hosts file to include in future Debian images?

Edit the top line to this:

Code: Select all

127.0.0.1         localhost debian-mate-rpi3

It breaks again as soon as someone reconfigures with hostname so I don't think it's the proper fix. You may need to investigate.

5fps on my Gentoo64 Pi3B+.
Aquarium crashed Firefox on Gentoo64 and runs 10fps on Mint.
Gentoo64 Firefox is the Nightly 63.0.3 Developers? version.

I'm seeing the same with Gentoo on a Pi 3B+, which is odd because my old Firefox 59.0.2 32-bit build could run the Blobs scene at 9 fps on Raspbian. (Depends on the window size and selected blobs configuration at the top left, but in any case Gentoo is twice as slow.) I went back and updated the armhf build for Firefox 64.0 (see the Firefox thread) and reran, same result. Aquarium runs for a while at 1 fps and eventually crashes too.

Firefox is such a mess so I doubt this is an issue of 64-bit performing worse than 32-bit. We need to run an apples-to-apples comparison just as was done with the Fibonacci benchmark.

All four of those 64bit 1.4GHZ Arm, 128 bit NEON cores I suspect will be needed?

Maybe. Note that 2D rendering in Chromium and Firefox is built on Skia and has been NEON-accelerated for quite some time. In fact, crashes in Skia's NEON code are what kept Firefox broken on the Pi for almost a year.

WebGL uses OpenGLES

Well, with an ideal mobile implementation yes. Running strace on firefox and its Web Content subprocess shows it talking to libGL.so but not libEGL.so nor libGLES. There's certainly performance lost in this configuration due to limitations of the GLX spec (source: anholt), on top of the Mozilla team not testing or optimizing at all for ARM Linux systems. Hence your smartphone renders WebGL way better.

[Gavinmc42]

Well, with an ideal mobile implementation yes. Running strace on firefox and its Web Content subprocess shows it talking to libGL.so but not libEGL.so nor libGLES. There's certainly performance lost in this configuration due to limitations of the GLX spec (source: anholt), on top of the Mozilla team not testing or optimizing at all for ARM Linux systems. Hence your smartphone renders WebGL way better.

Tried on newish tablet Android 8.1, 4 x 1GHz core, Mali 400, it also got 29fps for blobs.

Every 64Bit OS on Pi is using Eric's OpenGL driver?
Raspbian 32 is using OpenGLES blob firmware?

Clues for 64bit performance improvements are in Anrdoid drivers?
Android SoCs are very similar to Pi SoCs, CPUs plus OpenGLES GPUs.
Time to look in the Android posts?

Anyone else notice Vulkan 1.1 has support for cameras and codecs?
Vulkan is intended to run on everything including Smartphones and tablets, these all have cameras and codec libs
Designing Vulkan for AR/VR purposes, Vulkan 1.1 for VC4/5/6
Probably only the quad core Pi's will get much benefit, so no point restricting them to 32bit OS?

[jdonald]

I made a custom 64-bit build of Firefox 64.0 to try a fairer test. On Raspbian it also shows 5 fps WebGL performance with the 10-blob 24^3 resolution configuration, same as Gentoo. It's a mystery why 32-bit Firefox renders these blobs twice as fast. With other scenes or configurations the difference is less pronounced. For example with 1-blob at 16^3 it's roughly 13 fps (32-bit) vs 11 fps (64-bit). With the WebGL Aquarium, reducing the number of fish to 1 gets it running at a consistent 5 fps for both 32-bit and 64-bit.

Every 64Bit OS on Pi is using Eric's OpenGL driver?

Yes. For example on Debian/Ubuntu-based distros the libgl1-mesa-dri:arm64 package contains aarch64-linux-gnu/dri/vc4_dri.so.

Raspbian 32 is using OpenGLES blob firmware?

Vanilla Raspbian supports both the closed-source brcm driver and Mesa with vc4_dri. To switch between the two, run sudo raspi-config and select one of the OpenGL options under Advanced.

Being able to use one driver or the other depends more so on the application at hand. Mozilla does not support GLES as a WebGL backend on Linux according to their table, so running the legacy brcm driver is not an option here.

[code_exec]

Every 64Bit OS on Pi is using Eric's OpenGL driver?

Nope. 64-bit Debian does not use the OpenGL driver.

[sakaki]

Confirmed here on my local gentoo-on-rpi3-64bit system (RPi3B+, FLIRCv2 case, on-demand governor), 5fps with vc4-fkms-v3d,cma-256, firefox-63.0.3, hwaccel USE, 10-blob 24^3 res. Usage about 25% to 30% all cores. Tried also with chromium-71.0.3578.62-r2 (bindist build, available on the binhost now), same setup - it gave about 22fps, but the playback was very glitchy, CPU load about 60% all cores.

Then, I commented out the dtoverlay=vc4-fkms-v3d,cma-265 line in /boot/config.txt, to go back to the default driver. Firefox still yielded 5fps under these conditions, although the CPU load was much higher than before (around 55% all cores). With chromium however, there was smooth playback at 14fps when configured this way, CPU load about 65% all cores.

hth, sakaki

[Gavinmc42]

Thanks Sakaki,
I did wonder about Chromium
Gentoo64 now has two browser options?

Been looking at Android as a performance benchmark, 20-29fps is pretty common, not sure CPU usage yet.
With Chromium getting about 1/2 speed that is pretty good for open drivers.
Android drivers seem to come from the SoC suppliers so are tweaked for speed?
Got the new Opera Touch, need to test that with WebGL blobs.

If there is high CPU usage on all cores that suggest software rendering, not GPU.
I have not tested latest Raspbian yet.

Browsers on Pi's are getting close to usable?
Youtube benchmarks next?

[Gavinmc42]

Work PC Dell 9020, Windows 7 with Firefox 65.0b4 Blobs 60fps, Aquarium 60fps
Interesting, Chromium 71.0.3578.98 - Blobs 60fps, Aquarium ~53fps.
Opera - same as Chromium - 60fps, ~53fps, does it use the Chromium engine?

[Rascas]

Every 64Bit OS on Pi is using Eric's OpenGL driver?

Nope. 64-bit Debian does not use the OpenGL driver.

Yes it does. The closed source Broadcom driver does not support 64 bits OSs.

[Gavinmc42]

Raspbian ran blobs at 1fps but had issues with textures/lighting?
Aquarium ran at 0fps and did not crash, also texture issues.

Used raspi-config to enable OpenGL and broke Raspbian.
Boots to 4 colour square and then nothing

Gentoo64 with Firefox is looking pretty good
Can it be made better?
Firefox on Desktop is winning in WebGL, Firefox on mobile?
An Android version of Firefox is going to be the closest to a Pi version?

[Gavinmc42]

Android Chrome, Firefox, Microsoft Edge all run the Webglsamples, Blobs, Aquarium at about the same fps.
Firefox Focus, Nightly, Beta are buggy.

Tested other Android browsers, Opera Touch, Phoenix, Dolphin... they report webgl not supported.
Webglsamples seems to be a good benchmark test for Android too

The surprise was Edge, Microsoft stuff works on Android?

[sakaki]

Thanks Sakaki,
I did wonder about Chromium
Gentoo64 now has two browser options?

Yes, the plan is to ship both Firefox and Chromium on the forthcoming 1.3.1 gentoo-on-rpi3-64bit image release, in fact that's partly why it's taking a while to get through the testing phase - browsers probably impact user experience more than any other software package. Hopefully landing before the 25th though ^-^

Here's a screenshot of both browsers running at the same time on my test version of 1.3.1, on an Rpi3B+:


Firefox's fps drops to 2 when fighting for resources with Chromium like this; comes back to 5 if Chromium stopped (or browsing a less 'busy' page). Chromium's drops from 22fps to around 17fps. The above screenshot was captured under vc4-fkms-v3d,cma-256, compositing on, RPi3B+. The Chromium render shows considerable 'tearing', not visible in the above; as mentioned, this goes away if using the default (non-gl) graphics driver.

You can install 64-bit Chromium right now if you want of course. Just run a genup (using sudo, or as root) to ensure your system is fully up-to-date, and then:

Code: Select all

[email protected] ~ $ sudo emerge -av www-client/chromium

The package and its various deps are on the binhost, so this should be a relatively fast, pure binary install. Bear in mind that the binary package version has h264 disabled, as this codec is patent-encumbered, so I cannot lawfully distribute it.

Chromium currently holds the award for longest build time (in CPU seconds) btw: just over 8 hours wall-time on a 88-thread Xeon under user-mode QEMU with binfmt_misc, maxing out (unlike e.g. rust) all 88 threads for more than half the build. Yikes!

best, sakaki

[Gavinmc42]

Both at the same time
That's just showing off, well done.
Chromium is nearly usable at that speed
Driver or Chromium code causing the tearing issue?
Wonder if a browser will ever get to 60fps?

Chromium currently holds the award for longest build time (in CPU seconds) btw: just over 8 hours wall-time on a 88-thread Xeon under user-mode QEMU with binfmt_misc, maxing out (unlike e.g. rust) all 88 threads for more than half the build. Yikes!

Yikes indeed, so not something to mess about with for the average Pi user

Wonder if there is any browsers that just do WebGL?
Roll a DIY browser with Webkit?
Anyway WebGL is not a glTF gaming engine running on Vulkan which is my goal.
Perhaps glTF on GLES first?

Time to re-look at some OpenGL/ES benchmarks, Mesa3D examples?

[Gavinmc42]

https://github.com/MicrosoftEdge/MSEdge
Microsoft pushing hard into Arm64 space and to Chromium?
Microsoft will make a browser for Pi's?
Watch this space, interesting things are happening.

[jdonald]

64-bit Debian does not use the [Eric's VC4] OpenGL driver.

Yes it does. The closed source Broadcom driver does not support 64 bits OSs.

I was unsure about this so I did more testing. code_exec seems to be correct with regards to his own Debian MATE image. That is, it does not support either mode for GPU acceleration.

Although libgl1-mesa-dri is a preinstalled dependency, setting dtoverlay=vc4-fkms-v3d in config.txt on this system has no effect. After booting I can even modprobe vc4 but applications aren't using it. All GL apps seem to crawl at the speed of CPU rendering.

I recall seeing the same problem on bamarni's Debian Pi64. Now I'm wondering what Gentoo and Crazyhead90's Raspbian 64 do differently to properly accept dtoverlay=vc4-kms-v3d or vc4-fkms-v3d.

[Will5455]

Both at the same time
That's just showing off, well done.
Chromium is nearly usable at that speed
Driver or Chromium code causing the tearing issue?
Wonder if a browser will ever get to 60fps?

Chromium currently holds the award for longest build time (in CPU seconds) btw: just over 8 hours wall-time on a 88-thread Xeon under user-mode QEMU with binfmt_misc, maxing out (unlike e.g. rust) all 88 threads for more than half the build. Yikes!

Yikes indeed, so not something to mess about with for the average Pi user

Wonder if there is any browsers that just do WebGL?
Roll a DIY browser with Webkit?
Anyway WebGL is not a glTF gaming engine running on Vulkan which is my goal.
Perhaps glTF on GLES first?

Time to re-look at some OpenGL/ES benchmarks, Mesa3D examples?

but he is showing off for all pi users!

[Rascas]

64-bit Debian does not use the [Eric's VC4] OpenGL driver.

Yes it does. The closed source Broadcom driver does not support 64 bits OSs.

I was unsure about this so I did more testing. code_exec seems to be correct with regards to his own Debian MATE image. That is, it does not support either mode for GPU acceleration.

Although libgl1-mesa-dri is a preinstalled dependency, setting dtoverlay=vc4-fkms-v3d in config.txt on this system has no effect. After booting I can even modprobe vc4 but applications aren't using it. All GL apps seem to crawl at the speed of CPU rendering.

I recall seeing the same problem on bamarni's Debian Pi64. Now I'm wondering what Gentoo and Crazyhead90's Raspbian 64 do differently to properly accept dtoverlay=vc4-kms-v3d or vc4-fkms-v3d.

I only know 2 drivers for the RPi:
-the closed-source Broadcom drivers (aka "Original non-GL desktop driver") which is the default on Raspbian
-the open-source VC4 driver developed by Eric Anholt (aka "OpenGL desktop driver". This driver has 2 modes: the Full KMS and the Fake KMS.
viewtopic.php?t=192017#p1204401

I am not familiar with that Debian Mate, but if it really has a 64 bit kernel and userland, it is running some sort of open-source graphics driver. It can't be running the Broadcom drivers because they don't support 64 bit mode. This was talked about and explained by some RPi Foundation enginners here on this forums when first talking about 64 bit OSs for the Pi, when the RPi 3B was released. If I remember correctly, I got the idea this was one of the major problems, and one of the reasons for the RPI Foundation to not make an "oficial" Raspbian 64 build.
As some people probably know, without the closed-source graphics driver, there is no hardware video decoding and the OpenGLES performance is much worse. For example, OMXPlayer doesn't work, the new VLC with hardware video decoding doesn't work, Kodi is much slower, most game emulators are much slower, etc, etc. Unfortunately I could not find that topic anymore, but if you look deeper you will find it.
So, if the OpenGL performance in that Debian MATE is not similar with Raspbian (running the open-source drivers) or even others 64 bit OSs, something must be wrong with that OS. Messed up graphics driver or so.

[Gavinmc42]

but he is showing off for all pi users!

Yes she is, but she has serious Gentoo fu skills.
Without Sakaki we would not have Gentoo64 on Pi's.

RPF, Suse, Fedora even Microsoft have not done what she has done, made a usable Aarch64 Linux OS on Pi3's.
I would hate to think of the amount of time "she" had spent doing this for us.

And yes it does not have access to the 32bit libs for the VideoCore accelerated features.
But Eric Anholt's has given us an alternative accelerated open graphics driver.
This driver is now mainstreamed, which means it is in the Linux Kernel source code
As Eric does more GPU drivers he gets better at it
Other like Boris do lots and more VC5/6 stuff is done too, bugs are found and squished and VC4 gets better.

Sakaki has also shown us how to run 32bit apps in Gentoo64.
Could it be used to access the 32bit VC4 stuff ?
With a real 64bit OS we can now try to figure out how to get access to the secret sauce recipes buried in the VC4 firmware.

RPF say "oh we cannot use VC5/6 chips because they don't have camera hardware" etc
The industry has spoken, Vulkan 1.1 now has camera stuff in it.
Arm Smartphones and tablets all have cameras. Vulkan will run on everything?
Broadcom don't make Smartphone/Tablet chips anymore, interesting future for RPF and Broadcom.

By the time Pi4 comes out I hope to know how 64bit AArch64 and Vulkan stuff works.
Perhaps even by hacking tablets and Phones. Gentoo64 phone, Pi phone?
Rockbox and Cyanogenod user here, have hardware, will hack

RPF do not have to make a 64 bit Raspbian, the users are doing it for them.
RPF have more important things to do, "The Mission" education.
RPT's mission is to make the cheap hardware RPF need for their Mission.

Remember how 32bit Raspbian started?
It was a independent project by Mike and Peter.
https://en.wikipedia.org/wiki/Raspbian

Most of my time these days I use Ultibo, a baremetal way of talking to the VC4 firmware without Linux.
Even Microsoft could not do this, but Garry figured it out.

The VC4 hardware has pretty much stayed the same, but the software is not sitting still.
Now anyone, everyone can mess about with 64bit OS's and discover more, fix more, improve more.
Remember the early browser days in Raspbian - Epiphany etc.
Now we have Firefox and Chromium, not perfect but getting usable.

OMXplayer, Kodi, VLC don't work?
I don't care, I'm too busy learning to code this without an OS.

[Will5455]

Yikes! I should pay more attention to the authors of the stuff I use/think about using!
now who made minecraft forge?

[Gavinmc42]

now who made minecraft forge?

Rhetorical? https://minecraft.gamepedia.com/Mods/Forge
Mind you, most ten year olds can tell you Notch invented Minecraft without googling it;)

One for the first demos for OpenGL after the triangle is cubes and texturing them, wonder if that's how Notch started?
Been seriously looking at skyboxes and cubes as my first steps into this 3D world.
Modded the Ultibo OpenGLES example and did a dirt textured cube, instantly recognized by said 10 year old as a Minecraft cube.
Then he went back and made a video of himself completing the Car slalom game he made in Roblox in 15mins while I struggled with one cube.
I think I need to go to YouTube school, this poor old dad is a bit slow

DIY Cubeworlds, lots have done it before, I just want to try it in the bigger 64bit Pi OS world before doing it baremetal.

[jdonald]

Raspbian ran blobs at 1fps but had issues with textures/lighting?
Aquarium ran at 0fps and did not crash, also texture issues. Used raspi-config to enable OpenGL and broke Raspbian. Boots to 4 colour square and then nothing

With regards to that first test, as you saw it's not meaningful to run GL apps without a GPU driver. It this particular case it doesn't merely fall back to swrast (CPU rendering). Rather, something goes horribly wrong and it chokes. glxgears doesn't render properly either.

As for why you're unable to boot with GL enabled, first thing that comes to mind is that your firmware or kernel is out of date, but it's hard to know. If you have a spare SD card you could image the latest Raspbian where the driver definitely works on Pi 2 and above. For existing installations, I posted a checklist in the Quake 2 thread.

If the OpenGL performance in that Debian MATE is not similar with Raspbian (running the open-source drivers) or even others 64 bit OSs, something must be wrong with that OS. Messed up graphics driver or so.

Right, in a nutshell this is what code_exec are seeing with that image. It has Mesa without any 3D graphics acceleration, so falls back to swrast.

without the closed-source graphics driver, there is no hardware video decoding and the OpenGLES performance is much worse.

Shouldn't video decoding still work with Fake KMS? Per:

edit the vc4-kms-v3d overlay to:

Code: Select all

dtoverlay=vc4-fkms-v3d

you will end up with Eric's arm side v3d driver, supporting desktop GL from X, but using the original firmware for the kms part.
This means that tvservice, dispmanx, omxplayer(*), raspivid etc should work as before, but you can also run desktop GL apps from X. The one thing you cannot do with this driver is use firmware side 3D.

GLES performance: I agree that's a problem and hope this part gets better over time. As for Kodi, you mentioned that it's a lot slower but from what I've seen it doesn't even attempt to run (goes straight to the "failed to add service" message). Is there some compile flag or commandline option to get Kodi to try to run with Mesa EGL/GLES?

Sakaki has also shown us how to run 32bit apps in Gentoo64.
Could it be used to access the 32bit VC4 stuff ?

You can't directly link a 32-bit closed-source kernel module in a 64-bit kernel. Running Raspbian inside kvm and virtualizing VC4 comes to mind but that sounds hard.

The cleanest approach for existing applications is to port their codebases to use standard GLES headers, then they compile the same way on the Pi along with other single-board computers. Even for closed-source applications, we've seen with Minecraft Pi that this can be dealt with via a wrapper. When performance is the key concern, a path forward is to keep improving the open-source drivers.

[Gavinmc42]

When performance is the key concern, a path forward is to keep improving the open-source drivers.

Agree.
Bench marking is easier for me than writing Browser engines.
Mesa gears and gearbox both run at 60fps

What was surprising is Sakaki got Chromium to compile and then run at that speed.
Is there some Pi fans working at Google?

Open source drivers for Mali are getting close? Freedreno etc might give clues.
The Mali 400 is about the same as the VC4, OpenGLES 2.0, OpenVG etc
So comparing Pi's against a tablet or mobile with a Mali 400 is more realist than a PC with Nvidia card

As I understand the current OpenGL situation, Vertices are VC4 accelerated but shaders/textures are Arm software?
I could be wrong (bound to be), but that leaves room for more improvement?
This is 2 years out of date, but so am I Playing catch up.
https://github.com/anholt/mesa/wiki
Most of it is over my head but every now and again I understand a bit more
That's what learning is about.

[jamesh]

but he is showing off for all pi users!

Yes she is, but she has serious Gentoo fu skills.
Without Sakaki we would not have Gentoo64 on Pi's.

RPF, Suse, Fedora even Microsoft have not done what she has done, made a usable Aarch64 Linux OS on Pi3's.
I would hate to think of the amount of time "she" had spent doing this for us.

And yes it does not have access to the 32bit libs for the VideoCore accelerated features.
But Eric Anholt's has given us an alternative accelerated open graphics driver.
This driver is now mainstreamed, which means it is in the Linux Kernel source code
As Eric does more GPU drivers he gets better at it
Other like Boris do lots and more VC5/6 stuff is done too, bugs are found and squished and VC4 gets better.

Sakaki has also shown us how to run 32bit apps in Gentoo64.
Could it be used to access the 32bit VC4 stuff ?
With a real 64bit OS we can now try to figure out how to get access to the secret sauce recipes buried in the VC4 firmware.

RPF say "oh we cannot use VC5/6 chips because they don't have camera hardware" etc
The industry has spoken, Vulkan 1.1 now has camera stuff in it.
Arm Smartphones and tablets all have cameras. Vulkan will run on everything?
Broadcom don't make Smartphone/Tablet chips anymore, interesting future for RPF and Broadcom.

By the time Pi4 comes out I hope to know how 64bit AArch64 and Vulkan stuff works.
Perhaps even by hacking tablets and Phones. Gentoo64 phone, Pi phone?
Rockbox and Cyanogenod user here, have hardware, will hack

RPF do not have to make a 64 bit Raspbian, the users are doing it for them.
RPF have more important things to do, "The Mission" education.
RPT's mission is to make the cheap hardware RPF need for their Mission.

Remember how 32bit Raspbian started?
It was a independent project by Mike and Peter.
https://en.wikipedia.org/wiki/Raspbian

Most of my time these days I use Ultibo, a baremetal way of talking to the VC4 firmware without Linux.
Even Microsoft could not do this, but Garry figured it out.

The VC4 hardware has pretty much stayed the same, but the software is not sitting still.
Now anyone, everyone can mess about with 64bit OS's and discover more, fix more, improve more.
Remember the early browser days in Raspbian - Epiphany etc.
Now we have Firefox and Chromium, not perfect but getting usable.

OMXplayer, Kodi, VLC don't work?
I don't care, I'm too busy learning to code this without an OS.

Brain dumps like this are not helpful, this one contains a number of inaccuracies. You also do some very smart people a disservice by saying what they haven't done, and overly given credit to others for relatively simple achievements.

The reasons why we (The RPF) haven't yet done a 64bit OS are numerous. But the main ones : a) We do not have the support stuff to support two different OS's. b) The interface from ARM to VC4 is currently based on the 32bit architecture of the VC4. Moving to a 64bit host OS means that interfaces need a lot of work. Memory addresses move from 32 to 64 bits - and the interface supports only 32, so a load of work would be need to shim it.

That said, we are certainly going to need to do a specific 64bit OS at some point. Eric's driver takes us a long way towrads that, but there are still problems with it in certain circumstances. The camera is one, where the white balance routines uses the quads, BUT in Eric's driver in ARM space, it doesnt know when the camera might be doing it, and that causes conflicts. So we need to change the WB routines to run nicely with the ARM side driver. Making EVERYTHING required work correctly with a 64 bit OS is not a trivial task.

[fruitoftheloom]

but he is showing off for all pi users!

Yes she is, but she has serious Gentoo fu skills.
Without Sakaki we would not have Gentoo64 on Pi's.

RPF, Suse, Fedora even Microsoft have not done what she has done, made a usable Aarch64 Linux OS on Pi3's.
I would hate to think of the amount of time "she" had spent doing this for us.

And yes it does not have access to the 32bit libs for the VideoCore accelerated features.
But Eric Anholt's has given us an alternative accelerated open graphics driver.
This driver is now mainstreamed, which means it is in the Linux Kernel source code
As Eric does more GPU drivers he gets better at it
Other like Boris do lots and more VC5/6 stuff is done too, bugs are found and squished and VC4 gets better.

Sakaki has also shown us how to run 32bit apps in Gentoo64.
Could it be used to access the 32bit VC4 stuff ?
With a real 64bit OS we can now try to figure out how to get access to the secret sauce recipes buried in the VC4 firmware.

RPF say "oh we cannot use VC5/6 chips because they don't have camera hardware" etc
The industry has spoken, Vulkan 1.1 now has camera stuff in it.
Arm Smartphones and tablets all have cameras. Vulkan will run on everything?
Broadcom don't make Smartphone/Tablet chips anymore, interesting future for RPF and Broadcom.

By the time Pi4 comes out I hope to know how 64bit AArch64 and Vulkan stuff works.
Perhaps even by hacking tablets and Phones. Gentoo64 phone, Pi phone?
Rockbox and Cyanogenod user here, have hardware, will hack

RPF do not have to make a 64 bit Raspbian, the users are doing it for them.
RPF have more important things to do, "The Mission" education.
RPT's mission is to make the cheap hardware RPF need for their Mission.

Remember how 32bit Raspbian started?
It was a independent project by Mike and Peter.
https://en.wikipedia.org/wiki/Raspbian

Most of my time these days I use Ultibo, a baremetal way of talking to the VC4 firmware without Linux.
Even Microsoft could not do this, but Garry figured it out.

The VC4 hardware has pretty much stayed the same, but the software is not sitting still.
Now anyone, everyone can mess about with 64bit OS's and discover more, fix more, improve more.
Remember the early browser days in Raspbian - Epiphany etc.
Now we have Firefox and Chromium, not perfect but getting usable.

OMXplayer, Kodi, VLC don't work?
I don't care, I'm too busy learning to code this without an OS.

Brain dumps like this are not helpful, this one contains a number of inaccuracies. You also do some very smart people a disservice by saying what they haven't done, and overly given credit to others for relatively simple achievements.

The reasons why we (The RPF) haven't yet done a 64bit OS are numerous. But the main ones : a) We do not have the support stuff to support two different OS's. b) The interface from ARM to VC4 is currently based on the 32bit architecture of the VC4. Moving to a 64bit host OS means that interfaces need a lot of work. Memory addresses move from 32 to 64 bits - and the interface supports only 32, so a load of work would be need to shim it.

That said, we are certainly going to need to do a specific 64bit OS at some point. Eric's driver takes us a long way towrads that, but there are still problems with it in certain circumstances. The camera is one, where the white balance routines uses the quads, BUT in Eric's driver in ARM space, it doesnt know when the camera might be doing it, and that causes conflicts. So we need to change the WB routines to run nicely with the ARM side driver. Making EVERYTHING required work correctly with a 64 bit OS is not a trivial task.

IMO I do not see any value in having 2 Operating Systems considering the SoC Architecture..

It would be better if a new OS was released with the next RPi family which is ARM64.

Debian seem prepared to offer ARMHF AArch32 in Buster / Bullseye, so that is comparable Apple & Google OS life cycle offerings......