Playing with a Raspberry Pi 4 64-bit
blog.cloudkernels.net
blog.cloudkernels.net
No it's not. The pi is punchy enough for it sure, but the above doesn't follow in my mind. Low power = limited resources so ideally you want it run on bare metal to minimise overheads
Is that really true for rasp level gear? Haven't tested it but my gut feel tells me the hit is sizable.
Anyway - don't let that dissuade you from the mission. Container goodies on a rasp is a grand idea...just don't think it's quite as hit free as the article suggests ;)
If you do have numbers available I'd love to see a write-up on what the real world hit is.
I used to run a rasp3b for home server but that just wasn't punchy enough (crappy fake gigabit etc). So my old gaming laptop became a server w/ docker etc.
But itching to justify a rasp 4.
Anyway...thanks for exploring 64...thought the 32 on rasp 3 was unfortunate.
stay tuned ;)
The PoE hat makes attaching a proper heat sink (or using the flirc case) impossible, so I have now rolled my own using copper coins.
I am not comfy with letting my pi run that hot 24/7, and I don't want active cooling. I bought a rock pi 4 which has a PoE hat that can be combined with a HUGE heat sink, and there I have no heat issues at all.
There are cases you can use when you don't have a PoE hat, but the original pi 4 case almost throttles the pi at idle.
I have been trying to figure out the cheapest way to cool the RPI4, I am thinking a single slow 5V fan blowing across the card would be the best solution. This would also cool off the VLI, and take up less room on the card. I am just hoping someone will make the case, fan combination the works at a good price point. If things get too pricey then other SBC look very interesting.
I am really disappointed the thermal issues were not considered. A simple fan header like on UDOO boards, or an official case with space and air flow so a heat-sink could actually work would make me feel a lot better.
I believe the old binary is there and you can revert using the same mechanism
For my rock pi, that is more than enough.
My biggest concern with that is the blocking of the camera connector.
It is also 4 times more expensive than a cheap 5V fan.
I just got my rock pi 4. It is undocumented and is probably full of hacks (someone mentioned 5 different partitions just to get it to boot), but it has an official huge heatsink for $8 that can be combined with a poe hat. My rpi4+poe hat now has a heat sink consisting of 5 cent euro coins and one of those very very small heat sinks that does nothing :D
Progress for actual mainline support can be followed here: https://github.com/lategoodbye/rpi-zero/tree/bcm2838-initial
This looks like a fun FOSS subject to contribute to once I get my hands on a Pi4. I like the low-level stuff.
Does anyone here have recommendations where to contribute to?
Regarding the GIC, first I think we should spend some time examining the benefits from the A72 upgrade. Then, breaking down the time spent on each step of the VM lifecycle should be fairly straightforward (annotate EL changes, capture numbers with perf or something similar).
Or is this about some 1GB barrier DMA limitation?
I did notice VideoCore can only access maximum 1GB of RAM. Related to that?
probably some kind of address mapping, but I'm no expert on this stuff ;-)
You don't even have to run Linux at all. FreeBSD/aarch64 works great on a Pi3 (as a headless server at least, VC4 is not ported)
root@pi:~# cat /etc/issue.net
Ubuntu 18.04.2 LTS
root@pi:~# uname -a
Linux pi 4.19.57-v8+ #2 SMP PREEMPT Tue Jul 9 20:31:37 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux
root@pi:~# file /bin/ls
/bin/ls: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-, for GNU/Linux 3.7.0, BuildID[sha1]=de05fcef79d88af9cf9a71ed38e73af0b179bfb2, stripped
Is there an SD image that works?
will provide a link once I manage to upload it somewhere
it's quite beefy, 2.5GB -- apologies for that. We should be able to craft a much smaller image based on the ubuntu server release. Apparently, something was off about mounting the root partition on the first boot, so we went with our original image.
What am I missing here?
C:\Windows\System32>ssh -l root 192.168.178.184 root@192.168.178.184's password: Permission denied, please try again. root@192.168.178.184's password: Permission denied, please try again. root@192.168.178.184's password: root@192.168.178.184: Permission denied (publickey,password).
The behaviour should be identical to installing on a RPi3 (user/pass ubuntu/ubuntu, ethernet networking setup correctly etc.)
1 TB RAM supported by 32-bit ARM is not enough? I don't think increasing process virtual address size is the most pressing need at this point. Although it would help with things like WebAssembly, and anything else that benefits from mapping a lot of stuff in the address space.
The myth that you need to have 64-bit to access more than 4 GB RAM seems to still be very strong, despite not being true for a long time on modern x86 (since Pentium Pro in 1995) and ARM platforms (since LPAE designs, like 2013 Cortex A7/A15, etc.).
Of course I'd also like to get AArch64 on RPi4, but for entirely different reasons. To support double precision NEON SIMD and to get more registers to help Cortex A72 core out-of-order engine to keep the execution units busy. More registers helps to reduce dependencies, giving OoO more freedom to rearrange instructions for optimal execution.
1) https://www.realworldtech.com/forum/?threadid=76912&curposti... 2) https://www.realworldtech.com/forum/?threadid=76912&curposti...
Anyways, Linus is being... Linus. He is of course right in some ways, from kernel point of view it does suck, when you can't map all of the caches and buffers simultaneously. But PAE is pretty good for a bunch of large processes.
(I am not sure Dolphin-emu would run with considerable performance, but damn if I’m not curious.)
So basically, I should just cross compile RPi Linux and Mesa and it should work?
To be honest, I have been confused about the VideoCore driver situation from day 1, but I thought it was a blob.
The overhead should be zero by design.
What am I missing?
Linux containers provide native performance for almost all applications, true; but there are tons of implications when it comes to multi-tenancy (security, QoS, trusted execution etc.).
Moreover, spawning an application as a docker container can incur significant overhead on startup time, fs setup, FS access etc.
So in theory yes, containers provide native performance. But do we really want to run apps on multi-tenant edge devices as containers ? I would argue not necessarily ;)
Other than that, the A72 handles VMEnters/VMExits by trapping in/out of EL0/EL1/EL2.
Emulating the PS1 is a lot easier on modern hardware than emulating e.g. the SNES, because most of what it does is push polygons, and PS1 games just don’t push very many of them; so even the most anemic mobile GPU core is more than enough to handle the load.
I imagine this is still true of the PS2 to an extent. It’s even more just a polygon pusher than the PS1; and the 3D is still generations-old.
There’s this forum post linked to on the PCSX2 website: https://forums.pcsx2.net/Thread-Sticky-Will-PCSX2-run-fast-o..., that says the recommended specs are something like:
• Intel Core 2 Duo / Core i3 @ 3.2Ghz or faster
• Nvidia Geforce 9600GT / 8800GT or better
Probably all you need here, to answer this question in theory, is to compare raw benchmark scores between those components and the Pi4’s CPU/GPU.
Or, for another angle, here’s a forum post about Play! (an emulator that has aarch64 support) running on the Nintendo Switch’s Tegra X1: https://gbatemp.net/threads/play-ps2-emulator-is-running-on-...
Spoilers: it gets 10FPS. And the Pi4’s GPU is no Maxwell. (And, while Play! isn’t the most optimized of emulators, it’s the one you’d have to use on aarch64. Even if you optimized it 6x, so that the Tegra got 60FPS, the Pi4’s Videocore GPU wouldn’t be pulling nearly that.)
However they were inaccurate and lots of games weren't exactly great. MGS for example didn't work well on ePSXe for years because it used many more hardware tricks than same the original ridge Racer. Ridge Racer R4 doesn't even work properly on a PS2 backwards PS1 compatibility because the PS1 on a chip isn't perfect.
I think you mean 128mb. Otherwise, that must have been some Pentium system!
Accuracy makes things slower, sure, but the PS2 emulators in question (like Play!) aren’t striving for accuracy. They’re striving just to get the darn thing to run. But there’s only so much accuracy you can trade off when the only thing you’re really being asked to do is push polys. What are you going to do; drop some on the floor?
But actually, something like that might be possible. You know how the mobile port of FFXV looks—same game, lower-detail textures, all the models replaced with re-rendered low-poly versions? It’d totally be possible to build a PS4 (or any other 3D console) emulator that can achieve that effect “automatically.” We already have “HD texture packs” for emulators like Dolphin and Citra. We could have “LQ texture+model packs”, to reduce PS4/3/2-era graphics down to PS1-era graphics. That’d take most of the workload off the emulator, and let basically anything run these games. (And, in theory, you could compute such a pack automatically. For the textures, you’re just downsampling. For the models, 3D-geometry simplification algorithms exist, although they’re not realtime. But you could run them over a whole game’s worth of assets in a couple hours; and so, with disc images in hand, you could stand up a server and work your way through the whole console library over a few months.)
Some of the SNES/NES emulators require a lot of resources (relatively) to run accurately. I wondered if it was the same situation. So yeah it appears the GPU isn't capable.
I do wonder what the performance numbers of the Nintendo Switch vs the RPi 4 would be.
Maybe. With a herculean effort, way surpassing tricks and techniques used by x86 PCSX2 and other PS2 emulators.
Pure CPU computational performance wise yes. You'd need to have very clever ways to emulate the "Emotion Engine", like VPU0 and VPU1 vector processors. A single RPi4 core would far exceed those, but using it in an emulator might be very hard, because you'll probably need to synchronize execution and to emulate PS2 internal memory model. Emulating PS2 300 MHz MIPS core would be a walk in the park compared with the other issues.
But memory bandwidth might be the true showstopper. I think RPi4 has just one 32-bit DDR4 channel at 2400 MHz, which yields just 9.6 GB/s theoretical maximum bandwidth. More than what PS2 got, but the margins for emulation are uncomfortably low.
So while it's "possible", I don't think it'll happen at playable framerates. It'd be easier to reverse engineer the rendering engines in popular PS2 games and to simply port them.
What do you mean by that?
The state of emulation has come a long way since then, but still, that was a "desktop replacement" rig back in the day. I don't know how well a Pi can pull that off.
The PS2 architecture was famously a pain in the butt to program for, to boot.
I used an RPi2 as a Retroarch (Lakka) box maybe... oh, two years ago or so. At that time, it managed the handful of PSX games I threw at it just fine, which kinda surprised me, but almost no N64 games ran at a playable framerate—only one that really worked was Mario 64, which I gather is one of the best-optimized and lightest-weight games on the system. I didn't try PS2 because PSX was OK but from its performance and how the N64 was doing I figured it didn't have a chance.
16-bit consoles were pretty good. Couldn't run the full-accuracy cores for SNES but that's not surprising. Everything before that 100% fine. Filters (say, for mimicking a CRT) weren't feasible on the hardware, beyond the simplest ones.
The software's gotten a bit better—I think the Rarch team has done some major work pushing more of the computation of later emulator cores, like N64 and up, onto the graphics chip instead of the CPU—so I'm not sure how the RPi2 would fare now.
The only benchmark I can find compares the RPi4 to the RPi3, not the 2, and the 4's single-core performance measures 3-5x better than the 3 (wow!) so I'm going to answer your question with a very confident probably, pending actually trying it.