Raspberry Pi 5

[Ganon]

https://www.raspberrypi.com/products/raspberry-pi-5/


Broadcom BCM2712 2.4GHz quad-core 64-bit Arm Cortex-A76 CPU, with cryptography extensions, 512KB per-core L2 caches and a 2MB shared L3 cache
VideoCore VII GPU, supporting OpenGL ES 3.1, Vulkan 1.2
Dual 4Kp60 HDMI® display output with HDR support
4Kp60 HEVC decoder
LPDDR4X-4267 SDRAM (4GB and 8GB SKUs available at launch)
Dual-band 802.11ac Wi-Fi®
Bluetooth 5.0 / Bluetooth Low Energy (BLE)
microSD card slot, with support for high-speed SDR104 mode
2 × USB 3.0 ports, supporting simultaneous 5Gbps operation
2 × USB 2.0 ports
Gigabit Ethernet, with PoE+ support (requires separate PoE+ HAT)
2 × 4-lane MIPI camera/display transceivers
PCIe 2.0 x1 interface for fast peripherals (requires separate M.2 HAT or other adapter)
5V/5A DC power via USB-C, with Power Delivery support
Raspberry Pi standard 40-pin header
Real-time clock (RTC), powered from external battery
Power button


2-3 fache Performance zum Pi 4.

Achtung: Unterstützt für hardwareseitige Videodekodierung lediglich H.265. Ein VP9, AV1 und H.264 Dekoder ist nicht enthalten. Der Pi4 hatte noch H.264 mit drin. Weiterhin wird eine aktive Kühlung empfohlen.

https://www.phoronix.com/review/raspberry-pi-5-benchmarks

[Loeschzwerg]

Der gute Jeff Geerling hat sich den Pi5 ebenfalls schon angeschaut:
https://www.jeffgeerling.com/blog/2023/testing-pcie-on-raspberry-pi-5 (gibt auch ein YT Video falls jemand nicht lesen will ^^)

---

Schade dass der SoC nicht mehr Optionen an Decodern mitbringt.

[Marscel]

Kam doch jetzt sehr plötzlich, oder? Das letzte, was ich dieses Jahr las, war, dass man sich da keine große Hoffnung machen sollte zu einem RPi5.

Jetzt wäre ja nochmal spannend, ob man mit VC7 genauso herumdruckst, treibersupportmäßig.

[nairune]

Laut tomshardware review 2,7 Watt im idle... das geht mMn in die falsche Richtung. Aber solange die Zeros ab und an refreshes bekommen ok, dann sind für meine Zwecke nur noch die interessant.
edit: sehe gerade, dass der 4 B auch schon so hoch lag, dann ist die Performancesteigerung schon gut!

[Ganon]

Ja, ein No-Brainer ist die Variante nicht unbedingt. Hoher Stromverbrauch, aktive Kühlung praktisch notwendig, praktisch keine hardwarebasierte Videodekodierung, PCIe-Erweiterung (sprich NVMe) wird vermutlich ein Kabelsalat...

Mal schauen wie der (Open-Source) Software-Support aussieht, wenn das Teil für die Masse erhältlich ist.

[Käsetoast]

Videocore VII heißt die haben das Ding einfach wieder nur von 500 auf 800 MHz hochgetaktet? Das wäre ein ziemlicher Tiefschlag abseits der Verbesserungen am Decoder & Co. Händisch bekam man den Takt beim 4er auch schon in die 700er Bereiche. Neben dem sich aus der Taktung ergebenden Performanceboost heißt das dann wohl erneut 4-5 Jahre Stillstand auf diesem Gebiet während die Rockchip Varianten in ähnlicher Preislage hier ein Vielfaches an Leistung bieten und das in den nächsten 1-2 Jahren sicher noch weiter ausbauen.

Abseits davon hat Herr Upton mal wieder bestätigt, dass wenn er sagt das nichts kommt das Dingen bald im Laden steht... :D

[Loeschzwerg]

Neben dem sich aus der Taktung ergebenden Performanceboost heißt das dann wohl erneut 4-5 Jahre Stillstand auf diesem Gebiet während die Rockchip Varianten in ähnlicher Preislage hier ein Vielfaches an Leistung bieten und das in den nächsten 1-2 Jahren sicher noch weiter ausbauen.

Das wäre echt unschön wenn das nur ein Taktboost ist. Wobei man aber auch sagen muss, so gut andere SoCs teilweise auch hinsichtlich Spec sind, so beschissen ist die Softwareunterstützung. Da ist dann oft nur Android brauchbar und/oder der Linux-Kernel uralt mit speziellem Treiberpaket. Außer gezielten Anwendungen ist das in meinen Augen alles ziemlicher Müll, egal ob Orange, Rock oder sonst was Pi :(

Dahingehend ist der Pi 5 auch weiterhin ein "No-Brainer". Neue CM und Zero Varianten folgen ziemlich sicher.

[Käsetoast]

Das wäre echt unschön wenn das nur ein Taktboost ist. Wobei man aber auch sagen muss, so gut andere SoCs teilweise auch hinsichtlich Spec sind, so beschissen ist die Softwareunterstützung.
Das Thema Software / Treiber ist in der Tat ein Problem, wobei sich das langsam zu bessern scheint. Oder sagen wir es mal so: Wenn es um das Thema Multimedia geht ist das bei den Pis auch nicht dolle. VP9 und H264 hardwarebeschleunigung läuft ja wohl immer noch nicht. Keine Ahnung ob der 5er nur noch die H265 Beschleunigung hat und man meinte den Rest kriegt man jetzt auch per Softwaredecoding gut hin, oder ob es da immer noch keine Software gibt, die es schafft die Hardwarebeschleunigung korrekt anzusprechen. Dass AV1 in Hardware nicht geht ist schade, aber ok (ist ja generell noch ein Novum am Markt), aber olles H264 endlich mal abspielen zu können ohne dass die CPU glüht oder je nachdem Frameskips da sind wäre im Jahre 2023 doch mal was...

Grundsätzlich ist der Pi5 ja gar nicht so übel - entspricht tatsächlich genau meiner Vorhersage, dass man hier auf 16nm wechselt. Sind auch viele gute Detailverbesserungen dabei. Nur warum ist die GPU Basis jetzt seit - keine Ahnung - 10 Jahren immer noch quasi die gleiche? Nur weil denen "Open Source" auf dem Papier so wichtig ist? Für die ARM GPU IP gibt's inzwischen mit PanFrost doch leidlich gut ausgereifte Treiber die Open Source sind. Gut - war in der Designphase wo diesbezüglich eine Entscheidung getroffen werden musste vielleicht noch nicht endgültig absehbar, aber irgendwas muss sich auf GPU Ebene mal tun beim Pi. Geht beim Thema Leistung ja auch nicht nur um "Spielereien", sondern man soll mit dem Ding halt auch entwickeln können und alles zum Thema KI, ML, NPU bräuchte halt mal ne Hardware die in der Richtung auch was kann.

[Loeschzwerg]

Das dürfte leider an Broadcom liegen, zu denen gehört die VideoCore IP und reicht denen vermutlich auch in deren überwiegenden Einsatzgebieten. Irgendwann wird man sich schon noch bewegen müssen.

[Ganon]

Dahingehend ist der Pi 5 auch weiterhin ein "No-Brainer".

Weiß nicht so recht. Im oft eingesetzten Fall des Multimedia-Centers ist es schon etwas fragwürdig, ob Software-Dekoding hier bei sämtlichen Inhalten was reißen kann. Im Testvideo bricht sich das Teil bei 2 Non-HD YouTube Videos schon derbe einen ab und ruckelt wie blöde.

Was soll denn erst passieren, wenn man dem Teil eine 30-80 MBit/s H.264 Bluray liefert?

[Loeschzwerg]

Ja, das ist unbestritten ungut. Aber nutzt denn echt jemand den Pi 4 als Multimedia-Center zum abspielen von Videos? In Zeiten von UHD TVs?
Und auch da sehe ich die anderen ARM SBCs nur bedingt als Alternative. Wenn man lange aktuelle Software haben möchte, dann nimmt man doch besser einen x86 NUC o.ä..

[Käsetoast]

Naja das Klischee Programmierungstutorial das bei Youtube geschaut wird gibt's ja schon. Generell läuft beim Thema Lernen heute viel über Video - sei es Udemy oder sonstwas. Das 0815 Youtube Videos laufen sollte heute eigentlich selbstverständlich sein. Dass das zum Release des Pi5 kein gelöstes Problem ist ist schon sehr schade...

Wobei es zumindest beim Pi4 ja kein Ding der absoluten Unmöglichkeit ist. Es gibt ja wohl mit viel Fummelei Möglichkeiten einen Browser mit Videobeschleunigung ans Laufen zu kriegen. Ist soweit ich weiß aber noch recht experimentell und eben alles andere als eine Selbstverständlichkeit...

Meine Hoffnung war der Pi5 kriegt ne ARM GPU und dieses Thema ist gegessen...

[Loeschzwerg]

Die Raspberry Foundation wird halt vor der Wahl gestanden haben, entweder auf einen anderen SoC Hersteller zu setzen und damit ordentlich Mehrarbeit in Software zu versenken, oder eben bei der Krücke von Broadcom zu bleiben.

[Käsetoast]

Mich wundert es trotzdem, dass es so schwer zu sein scheint die H264 Beschleunigung ans Laufen zu kriegen. Ich meine die Broadcom Chips sind ja auch in irgendwelchen Set-Top Boxen und dergleichen und da muss die Beschleunigung ja wohl funktionieren. Beim Pi4 bricht man sich jetzt aber schon seit Jahren einen ab das ans Laufen zu kriegen in z.B. einem Browser...

[Ganon]

Mich wundert es trotzdem, dass es so schwer zu sein scheint die H264 Beschleunigung ans Laufen zu kriegen.

Der aktuelle Quasistandard unter Linux für Videobeschleunigung ist halt VAAPI und das unterstützt der Treiber vom Pi nicht, da der ganze Funktionsblock auch nicht offen ist. Sprich, entweder die Software unterstützt den Pi, oder halt nicht.

Die nächste Chance für eine offene herstellerneutrale Video API wäre Vulkan Video. Ist halt die Frage wann das mal Anklang findet, wenn überhaupt.

[Marscel]

Ein paar Vulkan-Benchmarks wuppt der RPi 5 schon eine Ecke besser als RPi 4, gibt jetzt schon Treiber-Patches im Netz dafür: https://www.phoronix.com/review/raspberry-pi-5-graphics

[Fusion_Power]

Raspberry Pi5 plötzlich da? Wo kommt der denn her, hatte ich ja gar nicht aufm Schirm. Dachte das dauert noch ewig, aber nice erstmal.

Ja, das ist unbestritten ungut. Aber nutzt denn echt jemand den Pi 4 als Multimedia-Center zum abspielen von Videos? In Zeiten von UHD TVs?
Und auch da sehe ich die anderen ARM SBCs nur bedingt als Alternative. Wenn man lange aktuelle Software haben möchte, dann nimmt man doch besser einen x86 NUC o.ä..
Verbrauchen UHD TVs auch nur 5 Watt dabei? :D Das ist in dem Fall ja die entscheidende Frage. Wobei das wegen der immer noch fehlenden Hardware Videobeschleunigung des Pi natürlich nur theoretischer Natur ist.
Jedes billige China-Android-Gerät hat vernünftige Videobeschleunigung in Hardware. Ganz ohne riesen Community dahinter. Der Raspberry Pi hat die riesen Community aber Video HW Support wohl immer noch nicht. Ich weiß nicht wie gut Android aufm Pi läuft aber wenn es reicht um sich 1080p Videos ruckelfrei anzuschauen dann nur zu.

Ansonsten lesen sich die Leistungsdaten des Pi 5 ja schon nett. Bin auch gespannt auf einen Pi 500 Computer, also den Nachfolger des Pi 400. Falls der kommt. Retrotechnisch geht da ja schon so einiges.

FkI4OaTx7u4

[DrFreaK666]

Um mal deutsche Youtuber zu unterstützen...

mO-ytowm3XU

[Loeschzwerg]

Jedes billige China-Android-Gerät hat vernünftige Videobeschleunigung in Hardware.

Ja, aber der Punkt bei einem Bastel-SBC ist doch wie gut die Softwareunterstützung ist. Im Falle der Alternativen eher sehr sehr mau. Da bekommst du ein/zwei Images mit denen die Hardware und Beschleunigung halbwegs funktionieren und das war es dann. Kann für einen gezielten Einsatzzweck ausreichend sein, aber wirklich langlebig ist das irgendwie nicht.

Wer nur irgendwas zum abspielen von Streaming/Videos usw. sucht, der findet schon was passendes. TV-Stick xyz ^^

---

Raspberry Pi 5 Graphics Continue With Open-Source Driver & Crazy Fast Compared To RPi 4:
https://www.phoronix.com/review/raspberry-pi-5-graphics

Der Zuwachs bei der Grafikleistung ist schon ziemlich enorm!

[mboeller]

Der Zuwachs bei der Grafikleistung ist schon ziemlich enorm!

enorm... ist aber eine nette Untertreibung. Faktor 4-5 würde ich jetzt nicht mit enorm umschreiben. :biggrin:

Danke für den Link.

[Loeschzwerg]

:D Nachdem in der heutigen Zeit immer gerne alles superlativ ausgedrückt wird, habe ich mir angewöhnt lieber tiefer zu stapeln ^^

Jetzt frage ich mich allerdings schon ob das alles durch den Treiber kommt oder der VC7 Ausbau nicht doch mehr bietet als den Taktboost.

[drdope]

H264-Decoding als fixed function wurde vermutlich weggelassen, weil die generischen CPU/GPU-Blöcke dafür ausreichend fix sind?

Das hat in Software vor ca. 15 Jahren auf einem C2D-E8400 (3Ghz) auch schon funktioniert. Der hat damals bei H264-Softwaredecoding aber auch 50W verbraten...

Der RPi5 ist imho ein beeindruckendes Stück Hardware, speziell wenn Leistung/W/€ mit älteren Desktop-CPUs vergleicht.
Modulare Desktop-Rechner werden immer mehr zur Nischenanwendung für Freaks (wie uns).
:(

Ich würd' gern ein RPi in modernsten Fertigungsverfahren (TSMC N3) mit lokalen QuadChannel RAM on SoC sehen... (quasi analog zum dem, was Apple aktuell baut, aber ohne Apple Aufpreis).
:freak:

[Ganon]

Wäre das ARM Ökosystem nicht so ein verdongelter, nicht-standardisierter Clusterfuck, wäre das mit besseren SBCs auch nicht so das Problem. :ugly:

Mal schauen, ob ARMs angekündigte Bemühungen mehr im Open Source Bereich zu tun irgendwann mal Früchte tragen. Dann wären alternative SBCs u.a. mit Mali GPUs nicht so ein Software-Chaos.

[Fusion_Power]

Ja, aber der Punkt bei einem Bastel-SBC ist doch wie gut die Softwareunterstützung ist. Im Falle der Alternativen eher sehr sehr mau. Da bekommst du ein/zwei Images mit denen die Hardware und Beschleunigung halbwegs funktionieren und das war es dann. Kann für einen gezielten Einsatzzweck ausreichend sein, aber wirklich langlebig ist das irgendwie nicht.

Wer nur irgendwas zum abspielen von Streaming/Videos usw. sucht, der findet schon was passendes. TV-Stick xyz ^^

Das meine ich ja. Die meisten "China Dingers" haben quasi keinen Community Support aber HW Beschleunigung, Raspberry Pi hat ne gigantische und aktive Community aber die HW Beschleunigung ist oft immer noch ne Baustelle. unfair. :freak:
Man knallt sich auf seinen Orange Pi Android druff und hat plötzlich flüssige Medienwiedergabe. Aber das muss doch auch mit nem Pi gehen, ohne Android. In schön und bunt!


Raspberry Pi 5 Graphics Continue With Open-Source Driver & Crazy Fast Compared To RPi 4:
https://www.phoronix.com/review/raspberry-pi-5-graphics

Der Zuwachs bei der Grafikleistung ist schon ziemlich enorm!
Da wo die Hardwarebeschleunigung funktioniert, kriegt man in der Tat viel Power für wenig Geld und Watt. Das ist natürlich beeindruckend, keine Frage. :)

Wäre das ARM Ökosystem nicht so ein verdongelter, nicht-standardisierter Clusterfuck, wäre das mit besseren SBCs auch nicht so das Problem. :ugly:

Mal schauen, ob ARMs angekündigte Bemühungen mehr im Open Source Bereich zu tun irgendwann mal Früchte tragen. Dann wären alternative SBCs u.a. mit Mali GPUs nicht so ein Software-Chaos.
Ja, da ist wohl vieles im Chip verriegelt und verrammelt. Aber irgend wer muss doch mittlerweile schon durch reinen Zufall mal beim Reverse Engineering nen Durchbruch erzielt haben. Die Community ist wie gesagt groß und aktiv.

Und natürlich wird die Software des Pi auch weiterhin verbessert. Bin gespannt was man in Zukunft alles aus dem Pi 5 rausholen wird.

[Ganon]

Ja, da ist wohl vieles im Chip verriegelt und verrammelt. Aber irgend wer muss doch mittlerweile schon durch reinen Zufall mal beim Reverse Engineering nen Durchbruch erzielt haben. Die Community ist wie gesagt groß und aktiv.

Dazu muss es halt auch jemanden geben der das tut. Mein Kenntnisstand ist, dass man eher die Softwareseite anpasst (bzw. angepasst hat), damit sie mit dem Pi funktioniert. Also sowas wie ffmpeg, Kodi, mpv, VLC, etc. Ist vermutlich auch der Weg mit dem geringsten Widerstand. Dazu ändern die ARM CPU Bauer auch alle Nase lang alle kleinen Details hier und da, sodass man auch praktisch ein angepasstes OS für jeden individuellen SoC benötigt. Ich persönlich hätte auch keine Lust auf diesen Kampf gegen Windmühlen.

Und am Ende ist es jetzt auch wieder hinfällig, da der Pi 5 keine vernünftige Hardwaredekodierung hat.

Am Ende muss ARM es liefern. So oft wie neue ARM SoC auf den Markt gesch(m)issen werden, ist Reverse Engineering halt auch praktisch nicht zeitnah möglich. Es dauert ja teilweise schon Jahre bis ein SoC mit einem Mainline Linux Kernel _bootbar_ ist. Da reden wir noch nicht mal von all der Technik drum herum.

[Loeschzwerg]

Dazu ändern die ARM CPU Bauer auch alle Nase lang alle kleinen Details hier und da, sodass man auch praktisch ein angepasstes OS für jeden individuellen SoC benötigt.

Und da sagt man x86 nach eine komplexe und hässliche Architektur zu sein ^^ ARM funktioniert irgendwie nur in "geschlossenen" Systemen gut, das ist dann auf einer andere Art hässlich.

RISC V for the rescue :freak:

[Marscel]

Das ist eigentlich nicht das Problem, auch der x86-Code im Kernel ist voll mit Code für verschiedene Generationen und Hersteller. Darüber hinaus gibts dann auch Device-Tree-Configs, damit man theoretisch einen Haufen Custom-Geräte ohne großen Akt supporten kann.

Größer ist das Problem, dass man seitens Broadcom und/oder der RPi Foundation, vielleicht aufgrund der Vertragslage, gar keinen großen Bock hat sich mit dem Mainline-Kernel auseinanderzusetzen, anders als AMD und Intel. Da kommt dann ein Fork und da wird herumgehackt und an irgendwelche Blobs gebunden wie es für den RPi nötig ist. Und die Kernel-Leute nehmen das nicht ohne Weiteres an, weil sie mit dem Gehacke und der Code-Qualität nicht zufrieden sind. Daher dauert das teils viel, viel länger, bis der Mainline-Kernel irgendwelche Basics beim RPi unterstützt, weil es erstmal jemand i. S. der Kernel-Maintainer bauen muss.

[Ganon]

Das ist eigentlich nicht das Problem, auch der x86-Code im Kernel ist voll mit Code für verschiedene Generationen und Hersteller.

Da geht's aber in der Regel nur um bestimmte Features der entsprechenden Hardware und nicht um den grundlegenden Bootprozess. Starten kannst du die Systeme so gut wie immer, mal von Firmware Bugs abgesehen.

ARM SoC haben in der Regel kein EFI und keine ACPI Table, was den SoC vor dem OS Start grundlegend initialisiert und dem OS eine einheitliche Schnittstelle gibt. Als Beispiel mal ganz abgefahrene Sachen, dass der RPi bis Version 4 von der GPU (!) initialisiert wurde.

Im Serverbereich findet EFI bei ARM mehr Verbreitung, aber sonst halt nicht.

[Marscel]

Ich weiß, der Bootprozess ist da ganz besonders exotisch.

Aber ob nun x86, ARM oder RISC-V, man kann als Hersteller grundsätzlich zw. ACPI und EFI oder Device-Trees seinen Kram bei Linux unterbringen. Und auch Android hat Anleitungen, wie man sich da unterordnen muss.

Sind die SoCs jetzt ganz besonders designed, dass das keine Option ist, oder ist das nur eine Frage von Time-to-Market, NDAs/Lizenzen?

[SavageX]

H264-Decoding als fixed function wurde vermutlich weggelassen, weil die generischen CPU/GPU-Blöcke dafür ausreichend fix sind?


Der alte H.264-Hardware-Decoder war „nur“ für 1080p60 ausgelegt. DAS (und etwas darüber hinaus) bekommt die CPU auch problemlos hin.

[Loeschzwerg]

Zumindest in Youtube kommt es unter 1080p60 zu Framedrops. Lässt sich aber mit Overclocking gut abmildern.

[=Floi=]

Könnte eher lizenzrechtliche gründe haben, weil das in hardware einfach kein problem sein kann. Das ist alles uralt und andere schaffen es auch. Die vorteile wäre imho auch grösser als nur über die cpu.

[Seraf]

Ihr macht es euch ein bisschen leicht mit dem Meckern. Die neueren PIs verwenden MESA und probieren ohne proprietäre Bibliotheken auszukommen. Dann gibt es halt auf einmal keinen Dispmanx Upscaler mehr und keine Videobeschleunigung über OMX. Dann muss man warten bis die Open Source Community den kernel, mesa, ffmpeg und gstreamer gepflegt haben. Das kann schon einmal Monate bis Jahre dauern. Dafür hat man den Vorteil nicht ewig auf alte Bibliotheken angewiesen zu sein.