Thanks for reporting this issue! Could you post your edited /etc/hosts file to include in future Debian images?jdonald wrote: ↑Sun Dec 09, 2018 8:29 amOn 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.ejolson wrote: ↑Wed Dec 05, 2018 6:00 amThe 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.
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.
One issue I encountered with the MATE 64-bit image is that whenever I run sudo it says:To fix this I had to edit /etc/hosts.Code: Select all
sudo: unable to resolve host debian-mate-rpi3
Re: 64-bit operating system
Ubuntu 18.04 LTS desktop images for the Raspberry Pi 3.
https://github.com/CodeExecution/Ubuntu-ARM64-RPi
https://github.com/CodeExecution/Ubuntu-ARM64-RPi
Re: 64-bit operating system
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?
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?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges
Raspberries are not Apples or Oranges
Re: 64-bit operating system
Edit the top line to this:code_exec wrote: ↑Sat Dec 15, 2018 7:03 amCould you post your edited /etc/hosts file to include in future Debian images?jdonald wrote: ↑Sun Dec 09, 2018 8:29 amTo fix this I had to edit /etc/hosts.Code: Select all
sudo: unable to resolve host debian-mate-rpi3
Code: Select all
127.0.0.1 localhost debian-mate-rpi3
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.
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.All four of those 64bit 1.4GHZ Arm, 128 bit NEON cores I suspect will be needed?
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.WebGL uses OpenGLES
Re: 64-bit operating system
Tried on newish tablet Android 8.1, 4 x 1GHz core, Mali 400, it also got 29fps for blobs.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.
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?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges
Raspberries are not Apples or Oranges
Re: 64-bit operating system
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.
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.
Yes. For example on Debian/Ubuntu-based distros the libgl1-mesa-dri:arm64 package contains aarch64-linux-gnu/dri/vc4_dri.so.
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.Raspbian 32 is using OpenGLES blob firmware?
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.
Re: 64-bit operating system
Nope. 64-bit Debian does not use the OpenGL driver.
Ubuntu 18.04 LTS desktop images for the Raspberry Pi 3.
https://github.com/CodeExecution/Ubuntu-ARM64-RPi
https://github.com/CodeExecution/Ubuntu-ARM64-RPi
Re: 64-bit operating system
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
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
Re: 64-bit operating system
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?
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?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges
Raspberries are not Apples or Oranges
Re: 64-bit operating system
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?
Interesting, Chromium 71.0.3578.98 - Blobs 60fps, Aquarium ~53fps.
Opera - same as Chromium - 60fps, ~53fps, does it use the Chromium engine?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges
Raspberries are not Apples or Oranges
Re: 64-bit operating system
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?
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?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges
Raspberries are not Apples or Oranges
Re: 64-bit operating system
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?
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?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges
Raspberries are not Apples or Oranges
Re: 64-bit operating system
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
demouser@pi64 ~ $ sudo emerge -av www-client/chromium
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
Re: 64-bit operating system
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?
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?

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?
Yikes indeed, so not something to mess about with for the average Pi userChromium 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!

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?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges
Raspberries are not Apples or Oranges
Re: 64-bit operating system
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.
Microsoft pushing hard into Arm64 space and to Chromium?
Microsoft will make a browser for Pi's?
Watch this space, interesting things are happening.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges
Raspberries are not Apples or Oranges
Re: 64-bit operating system
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.
Re: 64-bit operating system
but he is showing off for all pi users!Gavinmc42 wrote: ↑Tue Dec 18, 2018 1:50 amBoth 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?
Yikes indeed, so not something to mess about with for the average Pi userChromium 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!![]()
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?

I do strange things and am sometimes the techhead stereotype.
deal with it!
deal with it!
Re: 64-bit operating system
I only know 2 drivers for the RPi:jdonald wrote: ↑Tue Dec 18, 2018 6:22 amI 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.
-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.
Re: 64-bit operating system
Yes she is, but she has serious Gentoo fu skills.but he is showing off for all pi users!
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.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges
Raspberries are not Apples or Oranges
Re: 64-bit operating system
Yikes! I should pay more attention to the authors of the stuff I use/think about using!
now who made minecraft forge?
now who made minecraft forge?
I do strange things and am sometimes the techhead stereotype.
deal with it!
deal with it!
Re: 64-bit operating system
Rhetorical? https://minecraft.gamepedia.com/Mods/Forgenow who made minecraft 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.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges
Raspberries are not Apples or Oranges
Re: 64-bit operating system
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.
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.
Shouldn't video decoding still work with Fake KMS? Per:without the closed-source graphics driver, there is no hardware video decoding and the OpenGLES performance is much worse.
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?dom wrote: ↑Wed Sep 14, 2016 8:13 pmedit the vc4-kms-v3d overlay to: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.Code: Select all
dtoverlay=vc4-fkms-v3d
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.
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.
Re: 64-bit operating system
Agree.When performance is the key concern, a path forward is to keep improving the open-source drivers.
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

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.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges
Raspberries are not Apples or Oranges
Re: 64-bit operating system
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.Gavinmc42 wrote: ↑Wed Dec 19, 2018 1:16 amYes she is, but she has serious Gentoo fu skills.but he is showing off for all pi users!
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.
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.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.
-
- Posts: 25300
- Joined: Tue Mar 25, 2014 12:40 pm
- Location: Delightful Dorset
Re: 64-bit operating system
jamesh wrote: ↑Wed Dec 19, 2018 10:43 amBrain 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.Gavinmc42 wrote: ↑Wed Dec 19, 2018 1:16 amYes she is, but she has serious Gentoo fu skills.but he is showing off for all pi users!
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.
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......
The information is out there....you just have to let it in.
My other Linux machine is a ChromeBox
My other Linux machine is a ChromeBox