search

helloSystem / hello

Desktop system for creators with a focus on simplicity, elegance, and usability. Based on FreeBSD. Less, but better!
2.31k stars 58 forks source link

Guide: How to improve Raspberry Pi 4/400 graphics #333

Open TriVoxel opened 2 years ago

TriVoxel commented 2 years ago

Outline:

Section 0: Overview

I was looking through the helloSystem Raspberry Pi documentation when I noticed help was needed with graphics. Specifically, two things come to mind:

Please let us know if you know how to get screen resolution autodetection working on FreeBSD with Raspberry Pi

The Falkon browser can be launched, but trying to load more than the most basic web pages such as http://frogfind.com/ leads to an instant crash:

Answers to these issues can be found in "Section 1".

Section 0.1: My recommended target Raspberry system

As someone who is quite invested in the world of Raspberry Pi's, I can say that it is a waste of time to support anything older than the Pi 4. While the older Pi's have their merit, they are severely underpowered for desktop applications and are not viable for anything more than retro emulation and light web browsing. While it's fair to technically support the Pi 3 (as it is essentially compatible with everything the Pi 4 runs) it only has 2 GB of memory making it useless for running more than a small handfull of applications at a time. System lockups are very common on this platform and the complete lack of 3D hardware acceleration kills any potential it has for running modern games or websites.

As far as newer Pi's (such as Pi 4, Pi 400, and future models) go, there is a 2 GB, 4GB, and 8GB model of Raspberry Pi 4. The most common model is the Pi 4. The 2 GB model is really only good for lighter tasks such as emulation or NAT servers, but not practical for running desktop environments. The 4 GB model has it's limits, but is generally capable of being a light desktop class machine. I've personally used this model for video editing, coding, web browsing, and so much more. It really is a capable system and can easily run many applications at once. The extra memory allows us to dedicate some to the GPU for enhanced performance in graphical applications. The 8 GB model is obviously the best as you can dedicate a lot more memory to the GPU and it can load more programs without the need for SWAP or similar features. It is more expensive, though, and it will probably be harder to come by with recent harware shortages.

Personally, I think the Raspberry Pi 4/400 with 4 GB of RAM should be the target platform as it is the most widely adopted system and it strikes a good balance between affordability and performance. It is far superior to last gen Raspberry Pi's, and can be enhanced even further with an SSD, overclock, and SWAP.

Section 1: Graphics optimization and resolution auto-detection

The Raspberry Pi takes is an unconventional piece of hardware. It's very capable, but has an unusual assortment of components that make using it as a standard desktop system somewhat challenging. One component that is especially problematic is the Broadcom VideoCore VI graphics chip. If you want to get more use out of the graphics processor, make the following changes to /boot/msdos/config.txt:

hdmi_safe=0
disable_overscan=1
display_auto_detect=1
max_framebuffer_width=3840
max_framebuffer_height=2160
max_framebuffers=2
gpu_mem=512

[pi4]
dtoverlay=vc4-kms-v3d-pi4
#dtoverlay=vc4-kms-v3d # This seems to be the same thing but for Pi3?

Section 1.1: Configuration explanation

hdmi_safe forces the graphics chip to only output a "safe" resolution that should, in theory, be supported by all monitors. Subsequently, it looks like garbage and is practically unusable for desktop systems. However, it is important for CLI-only operating systems, such as stock FreeBSD, as it ensures the text is readable even on high resolution displays.

disable_overscan disables the overscan borders from being rendered. Overscan is really only useful for TVs or monitors that do a stupid dumb annoying zoom to the picture for no apparent reason. It is generally better to set the TV or monitor to "just scan" or "direct" in the respective aspect ratio settings. Overscan should really be a last resort. In the event that overscan is indeed needed, you can use the following lines to define the overscan values (in pixels):

overscan_left=<number of pixels>
overscan_right=<number of pixels>
overscan_top=<number of pixels>
overscan_bottom=<number of pixels>

display_auto_detect is very self-explanatory. In all actuality, isn't strictly necessary to automatically detect the right screen resolution, but it does work. You can comment it out and have good results but it is most likely good practice to include it. What's most important is the next point.

max_framebuffer_[width|height] sets the maximum output resolution the HDMI can go to. In this example, it is set to a resolution of 3840x2160 (4K 16:9). To my knowledge, the highest resolution the Raspberry Pi can output is 4K 60 Hz. Setting this value makes the Raspberry Pi detect the correct resolution. This way, framebuffer_width and framebuffer_height doesn't need to be specifically set. If the monitor exceeds the specified resolution in max_framebuffer_[width|height], it will default to the maximum resolution. So you could, for example, set it to 1920x1080 and if the Pi were plugged into a 4K display, it would output a 1080p signal.

max_framebuffers=2 unlocks both HDMI outputs to enable dual-monitor configurations.

gpu_mem allocated a portion of system memory to act a V-RAM. It is essential to boosting the performance GPU-dependent applications such as web browsers, games and video editors. Please note, the more you increase this value, the less system memory your applications will have available to them. 512 MB is a good value as it leaves systems with 4 GB of memory some room for applications. 256 may be more ideal for 2 GB systems but, honestly, who uses a 2 GB model for desktops? It's a TERRIBLE experience for anything involving graphical interfaces.

dtoverlay=vc4-kms-v3d-pi4 loads the "vc4-kms-v3d-pi4" overlay filesystem. It is a 3D acceleration layer specifically designed for the Raspberry Pi 4. You can also use dtoverlay=vc4-kms-v3d presumable for older Rasbperry Pi models such as the Pi 3. However, the Raspberry Pi 3 is insufferably slow for desktop use and is practically useless for running more than a couple applications without the use of SWAP.

Section 2: Enhancing performance & longevity with SSD

The Raspberry Pi is designed to boot exclusively from the embedded micro SD eMMC card reader with an upper theoretical read-write speed of 50 MB/s. In practice, sequential writes are much slower, often averaging 30 MB/s. The micro SD card faces another, even worse issue, however: data corruption and write limits. The eMMC storage medium is a very frail storage format. It is not only slow, but after enough writes, the card becomes completely useless. Push your card far enough and you may even lose the ability to read and write from it entirely.

The Raspberry Pi has a very limited amount of RAM for the modern day. While 4 GB may cut it for most things, most intense applications such as video editing require more memory. While editing video on a Rasbperry Pi may sounds painful in and of itself, in my experience, the processor is actually more than capable of handling such a task and is very responsive and efficient. The issue is out-of-memory errors and system lockups poccuring due to the memory being capped. This can sometimes happen when running many browser tabs at once amongst other things. A solution on modern desktops is to use SWAP - a virtual memory page dump that gets put on the hard drive. This can enable low-spec systems to load more than they were designed to run when low on memory, but will completely obliterate an SD card. Enabling SWAP on an eMMC SD card is not for the faint of heart. While it works, the nature of SD card transfer speeds means a very long load time when accessing SWAP pages and you will experience a noticable slowdown when paging files in and out of SWAP. Furthermore, when SWAP is used frequently enough, it will become increasingly evident that your SD card is wearing out as file transfers begin to take longer and some files even begin to corrupt and lose integrity. At a certain point, you will be seeing speeds of 10 MB/s, maybe even several hundred KB/s.

The solution? Utilizing the USB booting feature of the newer Raspberry Pi firmware. You can boot from a SATA SSD with the USB 3 bus which can get you speeds of ~150-180 MB/s in my experience. The setup is the same as setting up an SD card. You simply flash the Raspberry Pi image onto your SSD and plug it in. Start your Pi without the SD card and you're off to the races with a more reliable and fast storage medium, right? Not entirely. The Raspberry Pi has had many hardware revisions since its debut, but these are most likely not installed as they must be done manually.

I'm not sure how to do this with FreeBSD, but there are commands built into Rasbperry Pi OS. I recommend downloading that and flashing your SD card. This only needs to be done once and will be persistant across reboots and different operating system images. It is flashing the internal BIOS/EEPROM which will be permenant.

Important note about SSDs: The Raspberry Pi does not have a built-in PCI-express bus. Therefore, it is not compatible with NVMe-class SSDs. You must use a SATA SSD. You can use the classic, hard drive-shaped ones or the newer M.2 drives. Both are viable options.

Section 2.1: Updating Raspberry Pi 4 firmware to enable USB boot

  1. Download the latest Raspberry Pi OS release and follow the instructions to flash it to an SD card. For those unfamiliar with flashing SD card images, it is recommended to read the instructions carefully. For those who know what they're doing, flashing goes something like this:
$ xz -d /path/to/raspberry-pi-os.img.xz
# dd if=/path/to/raspberry-pi-os.img of=/dev/<device>

Note: replace <device> with device name (don't include <> characters.) Usually it's mmcblk but sometimes it's da0 or something else. Always double check!

  1. Insert the SD card and complete the system setup.
  2. Do a full system upgrade:
# apt update
# apt full-upgrade
$ reboot
  1. Edit /etc/default/rpi-eeprom-update and replace default with stable
  2. Run the following to update the EEPROM:
# rpi-eeprom-update

This should say "update available" somewhere

# rpi-eeprom-update -a
$ reboot
  1. After you boot back into the system, run # rpi-eeprom-update. If it says "up to date" you have successfully updated!
  2. Run # rpi-eeprom-config --edit and append the following: BOOT_ORDER=0xf41 and power off.
  3. Remove the SD card
  4. Now, with any luck, you should be able to plug in your FreeBSD-formatted USB SATA device and be off to the races!

For more information, see the source of these instructions on the Raspberry Street blog.

Section 2.1: Utilizing the SSD's speed for extended memory

Since you now have a more reliable storage medium, it would be wasted potential to not use it to extend your system resources. This section will focus on setting up a rudimentary SWAP system with no encryption. It is generally not recommended to leave your SWAP unencrypted, but SWAP encryption techniques are beyond the scope of this tutorial.

  1. Create a SWAP file using
# dd if=/dev/zero of=/swap bs=1M count=8192

This will create a swap file holding up to 8192 MB (8 GB) of memory. To go much further beyond that would recommend some further tweaking. 8 GB should be more than enough. It's easy enough to convert what you want in GB to MB, but for the sake of convenience, multiply how much memory you want in gigabytes (GB) by 1024. For example, if you wanted 4 GB, you'd do 4*1024=4096.

  1. Run # chmod 0600 /swap to give it the correct permissions.
  2. Edit /etc/fstab and append the following line:
md42    none    swap    sw,file=/swap   0   0
  1. Run # swapon -aq to immediately enable SWAP
  2. Run $ swapinfo -k to verify that it's been attached correctly

This section was adapted from a guide on nixCraft. It goes into more detail and even breifly covers encryption.

Section 3: Overclocking for maximum performance gain

With an SSD, SWAP, and several GPU enhancements enabled, you should immediately notice a speed boost. This will give you a much better development system and may even replace your desktop. However, you can quickly and easily take it a step further by overclocking your system. Please note, overclocking can lead to reduced hardware lifespan and can cause permenant damage. That said, I've found that a decent heat sing and a good fan go the trick. This is necessary as not having a somewhat competatant cooling solution will bite you in the ass. If you let it heat too much, it will thermal throttle and kill your performance. Do keep in mind, you need a good power supply to run this thing, especially overclocked. A Raspberry Pi power supply is a little different than a normal phone charger by design. Your new iPhone or MacBook charger probably won't cut it. I'd recommend getting the official Rasbperry Pi power supply, manufactured by the Rasbperry Pi Foundation or whatever. Ir's OEM, it's good. Another great option is the Argon ONE power supply.

Overclocking is inherently dangerous as you are pushing the device beyond the intended spec. However, it is a very simple and robust machine that will most likely experience no ussues doing this. The Raspberry Pi is very affordable and modular, making the risk of hardware failure less of an issue. The main board can easily be swapped out and EEPROM flashed and you have your whole system back. There's a hard limit to how far you can push your Pi, so don't even worry about overdoing it. No 8 GHz liquid nitrogen overclocks I'm afraid.

To overclock you Raspberry Pi 4 to the max, edit /boot/msdos/config.txt and append the following:

over_voltage=6
arm_freq=2147
gpu_freq=700

2147 MHz is the maximum the device can go. Unlike Raspberry Pi OS, FreeBSD will boot even if you set these values higher. Even though you can set it higher, I can see no difference, even at 3000. You can set the gpu_freq up to "900" before it refuses to boot on FreeBSD. However, I can't tell if it is actually working or not. Even if you can push it past its limits, you will probaby see diminishing returns. In the event that you actually can overclock it to these badass levels, I'd recommend investing in a monster CPU cooler, maybe even running liquid cooling or higher as 2147 MHz is already pretty warm.

TriVoxel commented 2 years ago

@probonopd I've done my best to compile most of my knowledge on setting up an efficient, desktop-class Raspberry Pi 4 system. Hopefully we can get helloSystem officially supported on the Pi 4 as it's my favorite desktop operating system right now. Simple, elegant and UNIX! This project has more potential energy than a Sir Isaac Newton in an apple orchard! *drops mic*

probonopd commented 2 years ago

Thank you @TriVoxel.

I have one of the very first Raspberry Pi 4 1 GB models back from when they came out, and I find it to be unbearably slow, too slow for any real use (helloSystem or otherwise). Still not sure whether my unit is somehow broken. Was considering to get a Raspberry Pi 400 but I fear that it will end up as another "too slow" device collecting dust. If you have a chance, a video showing your desktop setup would be great to judge performance e.g., for normal use cases such as watching a video on YouTube.

probonopd commented 2 years ago

@S199pWa1k9r is working on aarch64 builds.

@TriVoxel would you consider integrating a condensed version of your findings into the documentation at https://github.com/helloSystem/docs/blob/main/developer/rpi.md?

TriVoxel commented 2 years ago

Thank you @TriVoxel.

I have one of the very first Raspberry Pi 4 1 GB models back from when they came out, and I find it to be unbearably slow, too slow for any real use (helloSystem or otherwise). Still not sure whether my unit is somehow broken. Was considering to get a Raspberry Pi 400 but I fear that it will end up as another "too slow" device collecting dust. If you have a chance, a video showing your desktop setup would be great to judge performance e.g., for normal use cases such as watching a video on YouTube.

Umm... well, I certainly have one. But it's annoying 😂 https://youtu.be/b_S93bKXyCw It's obnoxious but also a good demonstration of the power of the Pi. The whole video was actually edited and rendered on the Pi 4 itself!

The video showcases 1080p video playback in the browser, a full fat KDE install, video editing, music composing, and a bunch of cringe.

TriVoxel commented 2 years ago

@S199pWa1k9r is working on aarch64 builds.

@TriVoxel would you consider integrating a condensed version of your findings into the documentation at https://github.com/helloSystem/docs/blob/main/developer/rpi.md?

Sure!

probonopd commented 2 years ago

TODO: Check whether /usr/bin/proccontrol -m aslr -s disable /usr/local/bin/falkon makes any difference.

Reference: https://forums.freebsd.org/threads/freebsd-desktop-for-pinebook-pro.78269/page-4#post-552808