Raspberry Pi's Raspbian OS Finally Spins 64-bit Version

[Jabberwocky]

I've been using the beta PI OS 64 since it came out. For me it has been very solid, but then I wasn't really 'testing' it. I run it headless on a RPI4 4G booting off a USB 3.0 SSD . I've been using it as a way to learn 64Bit Arm Assembly for the most part. So my usage has been SSH, SFTP and nano. I'll be using it only on my RPI4s and CM4s. Glad to see it finally officially released. If only you could find a RPI4 or CM4 in the wild. Seem really scarce right now.

Note that in the 32 bit PI OS, an application 'only' could get 3GB (1GB of the 4GB potential is reserved) of memory to use, whereas the 64bit, it is all available. Not that there are many applications that need that much memory! Another advantage of the 64bit, is more CPU registers available to use, so potentially more efficient.

If you frequently ran apt full-upgrade you would have experienced a soft brick and the controversial Microsoft repo & gpg keys: https://github.com/RPi-Distro/raspbe...f3c1104ccb4351

I hope these "mistakes" are a thing of the past. I'll be reinstalling some of my devices.

[jaxa]

I mean, it has the horsepower of a fifteen year-old mid-range mobile chip (Core 2 Duo P8400), and half the single-thread performance. People seem to think these things are powerhouses held back by software limitations or bloat, but they're just not adequate for desktop use, nor were they designed to be (outside of exposing tinkerers to Python and electronics).

The MT8173 outperforms the Pi 4 even when the Pi is overclocked. Software limitations or the weird Broadcom VideoCore GPU are probably to blame.

Pi 5 will probably be considered adequate for desktop use unless something like the GPU holds it back.

[DrYak]

{...} nor were they designed to be (outside of exposing tinkerers to Python and electronics). {...} I love my Pis, I replaced a proper VM host with a few Pis, each handling tasks that fit within the constraints of the CPU and RAM (domain controllers, file servers, Docker running Minecraft server, and a low-throughput VPN concentrator for remote admin sessions),. Now things use a LOT less power and have much simpler upkeep,

Same here: Pi and other similar SBC are nice tools to play with and do some semi serious development/hosting of tiny services.
One of the biohackathon I took part in, we ran the demo server on a Pi.
And I user one for some home server+remote access purposes.

but I wouldn't use a Pi as a daily driver, even for browsing and email.

One of my daily driver while I am on the road is a roughly-similar hardware-class: Pine64's PineBook Pro (RK3399-based with 4GiB RAM).
But my use case need is very unusual:
Most of my work happens on the command-line (so technically even a 3 decade old 386 could do), with me only editing files locally and dispatching most of the command to a (very large and very powerful) HPC at my University (ETHZ).
The only tasks running on the local graphical interface are the browser and the editor (mostly using KDE's Kate with the sftp KIO plugin for remote access) and such machines are adequate for that and the absolute tiny power requirement is a big bonus (netbook's battery lasts forever, and I can top it up with the same 5V powerbank that I use for my phone).

So I could use a Raspberr Pi 400 as a daily driver, but that's because I don't do what 99% of regular computer users do.

(At some point in the past, my "while on the move" setup has been a Palm OS powered PDA running with an SSH client, docked into a foldable keyboard (serial, then Bluetooth), and using a dumbphone as a wireless access point (IrDA then later over Bluetooth) and that used to be enough)

Nothing will be thin enough to give a Pi a better experience than a low-end smartphone or a fifteen year-old laptop.

Smartphone have the draw back of tiny screens and poor input devices. (even psion-like keyboard limits a bit for long coding sessions)
One could compensate by lugging around a combo of a good foldable keyboard (I actually still have my 4-segment stowaway from back in the PalmOS days) and one of these tablet-sized screen with USB-C or microHDMI inputs.

But you're going to lug stuff around, you might as well go for a netbook.

(Another solution I've seen people use: lug a tablet/keyboard combo around, and SSH into a USB-C connected Pi4. GUI and editor run on the tablet, linux dev env on the Pi)

3
I run Manjaro 64 bit on my rpi4 8GB. I use it as an adblocking DNS for my lan.
Manjato ARM is great!

I second that opinion: Manrajo RAM on my Pinebook Pro.

But now the GPU bits (OpenGL and Vulkan) are getting more mature in mesa, shouldn't they put their focus on getting accelerated video decoding working in upstream Linux kernels as well?
I mean they can't just keep relying on these blobs with a fixed kernel version forever?

As others have pointed out, the Pi's CPU has a weird architecture where the GPU has an entire own 32bit real-time OS running on it. This also contributes to making opensource acceleration GPU a bit more complex.

[rclark]

...would have experienced a soft brick

I missed that misstep... I only update when I get into an RPI which sometimes can be weeks if not months between checking.

[kpedersen]

Pi 5 will probably be considered adequate for desktop use unless something like the GPU holds it back.

Nah, by then Gnome 3 or KDE and certainly web browsers will just be even more wasteful of resources.

The Pi 3 (and certainly 4) are already ready for prime time desktop. They are more powerful than most Windows XP machines that people still managed to do incredible things with. People just need to change their habits a bit more and adapt to the hardware they want to use.

But of course. They wont because extremely powerful machines are also dirt cheap.

[waxhead]

I am not familiar with the architecture for the pi too much to know if the 64 bit mode offers more CPU registered than 32bit mode. More usable general purpose registers usually help compilers not push/pop registers to stack and can help performance in tight loops. I imagine that emulators and other programs that crunch numbers a lot can benefit if compiled as 64bit in this case so do anyone knows if 64bit mode exposes more general purpose registers?!

[cRaZy-bisCuiT]

That's a very different scenario to what OP is asking, which was "s video decoding in hardware (h.264 & h.265) working now?", and the answer to that is a solid "no", the same way it's always been, other than when running an extremely-hacked version of VLC, and only on raspbian's very-modded 32-bit kernels.

The fact that you can use a pi4 to *transcode* video, provided you DON'T have a DRM client running, isn't of any use to anyone attempting to e.g. watch YouTube on it inside a desktop session. I'm pretty sure that's the context the OP was asking about.

This!

The Pi WAS NOT running with 64 bit kernels with video decoding working in the past. I'd like to have upstream kernel, mesa & video decoding APIs/players to support that with 64bit. Not sure what's so hard to deliver this after so many years.

[arQon]

Don't know about h265, but I've used Void Linux & Kodi on the original Pi. Works just fine. Are they using Raspbian kernels?

Ah. In that case, the piece that's confusing you is "on the original Pi". The Pi4 has no "working" access to the VideoCore block other than through MMAL (32-bit only, "custom" API, requires custom non-mainlined code to work at all), or, potentially / theoretically V4L (currently mostly-broken, poorly implemented, and with several key patches still missing from ffmpeg master).

Raspbian has historically provided "working" accel on the Pi4 through MMAL, which like I say requires a VERY-custom VLC+ffmpeg build, and obviously means that any other player simply doesn't work, because the few people involved have long since run out of patience trying to manage to massive patchsets. (There were significant other issues as well, like ffmpeg only supporting a single nvidia-specific format for V4L at all, and taking over a year to acknowledge RPF's patches. I *think* ffmpeg master now also has some ARM64 code for colorspace / format conversion too, which was also missing, but I've given up on this mess too after years of watching it go nowhere).

The fact that *only* VLC has accel in this new release makes it clear that the infrastructure as a whole is still a total mess, and that RPF is still burning all its effort on maintaining a very custom version of a single video player (and one that's been so utterly broken on Linux since its 3.x release that it's unusable in the first place) purely so that it can continue to bend the truth about "4K video playback", rather than actually make progress on anything resembling a standard API, or even a version of the ffmpeg libs with accel support. SOME of that isn't RPF's fault, c.f. the ffmpeg devs simply ignoring RPF's pull requests for as long as they did, but for the most part they just don't have any idea what they "SHOULD" be doing, so instead of that they're wasting staggering amounts of engineering time just to end up with the worst possible "working" outcome, with constant Chrome rebasing alone apparently taking more than half of their total development bandwidth.

I haven't tried this release yet, but given the specificity of how it's still *only* VLC that has accel, it's pretty clear that they're continuing to do things the worst way possible, expending a huge amount of effort just to achieve the bare minimum. Whether that's through V4L patches in VLC, or some form of thunking mechanism to make the MMAL layer available to 64-bit clients, I don't know.

[rclark]

anyone knows if 64bit mode exposes more general purpose registers?!

Yes. 32 bit has 16, 64 bit has 32. Actually only 31 general purpose, as X31 is the Stack Pointer (SP) which is restricted to just certain instructions to use.

Unlike Intel/AMD you can't split the registers. Ie. say you are working with 32bit numbers, you don't have a WH0 and a WL0. You just have W0 (treat as 32bit) or X0 (treat as 64bit) -- both being the same register.

Here is helpful guide for AARCH64: https://modexp.wordpress.com/2018/10...bly/#registers

[esbeeb]

I, for one, am grateful that the Raspberry Pi Foundation did all this work to get an all-around decent 64-bit OS released whatsoever, even if there are warts. For the price point (granted you can actually get one), the warts are forgivable. IMHO, they go much farther, in this regard, than any other ARM SBC maker. So big is this disparity, to my eye, that I have zero interest in any other ARM SBC maker.

The Raspberry Pi product line has earned my loyalty as a customer, even though not every decision they make is a nerd-perfect one.

If they screw up too badly in the future, this loyalty will be revoked, of course.