ARM (nicht PI!) - und Debian ARM, Hardwareleistung?

[theSplit]

Moin,

hat schon jemand mal Debian auf einem ARM betrieben und kann dazu ein paar Informationen geben?

Ich habe gesehen das es einen Debian Port für ARM gibt, nach kurzem Googlen. Und unterschiedliche Varianten für unterschiedliche Architektur-Versionen.

Wie sieht es mit der Leistung von solchen Geräten generell aus? - Ich würde gerne einen selbst entwickelten Videoplayer darauf laufen lassen, der allerdings per Default nur Software-Dekoding unterstüzt, da für nichts optimiert auf dem Ziel-System.

Und kann man bei Debian ARM generell "die meisten" Pakete ganz normal installieren, oder läuft dies viel eingeschränkter ab was die Möglichkeiten angeht?

MetaFrage:
Kann es sein das im einem solchen Gerät auch ne "normale" Grafikkarte verbaut ist, die man über spezielle Treiber ansprechen kann bzw. die von Debian ARM unterstützt wird?

Auf dem PI kann man zum Beispiel die GPU-Dekodierung verwenden, wie sieht das hier aus - auf was muß man sich einstellen?
Oder kann ich darauf vertrauen dass das Software Decoding schnell genug funktioniert wenn es keine Beschleunigung für die Architektur gibt?

Würde mich über Tips und Hinweise sehr freuen!

 

[Pleitgengeier]

Grundsätzlich hat der Pi einen "echten" ARM drauf
Dann gibt's von ARM noch ein paar Kategorien, zB die Cortex M-Serie, die eher für µController gedacht ist und für dich vermutlich eher ungeeignet.

Wie viele Pakete es bei Debian für ARMs gibt kann ich dir leider nicht sagen - aber ich wüsste nicht warum es nicht die gleichen wie bei Raspbian sein sollten.

ARM baut keine fertigen Chips sondern entwickelt die CPU - deshalb gibt es diese Dinger von verschiedensten Herstellern und meist noch jeweils in zig Ausführungen + unterschiedliche Peripherie, die stärksten sind wohl die Dinger die dann in diversen Smartphones landen.
GPU haben sicher einige dabei

Warum willst du eigentlich keinen Pi nehmen?

 

[theSplit]

Warum keinen PI - das habe ich mich auch schon gefragt....

Aber erst mal soll ich das versuchen zu nutzen, was vorhanden ist.... wobei klar, die ganze Hardwarebeschleunigung funktioniert schon unterm PI, daher wäre das sogar um zehn längen besser, weil getestet.

Das Problem ist, ich erfahre auch erst morgen was das für ein Gerät ist, die genaue Modellbezeichnung konnte mir nicht genannt werden... sonst hätte ich mich im Vorfeld darüber schlau gemacht was genau dort verbaut ist und wie es mit Treibern für die Peripherie aussieht.... was dann natürlich auch wieder gesondert programmiert werden müsste, so fern so einfach möglich.... was ja auch nicht sicher ist.

Also du meinst, grundsätzlich, gerade wenn das Gerät etwas in den Jahren ist, kann ich vergessen da etwas aktuelles zum laufen zu bekommen oder etwas Hardware hungrigeres?

 

[nik]

Das hängt auch eher davon ab, welcher ARM-Prozessor da verbaut ist.
Kommst doch auch nicht auf die Idee, nach der Performance von ner I686-(Architektur)-CPU zu fragen, oder?

 

[theSplit]

Naja, das Gerät wird schon etwas älter sein..., also gehe ich nicht von einer Highend - ARM-CPU aus, so das ich auf die Softwaredekodierung wohl (auch wie beim Pi) nur ruckelndes Bild hätte über die CPU-Dekodierung.

Das Ding wurde vorher ebenfalls als Videodisplay verwendet, aber keine Ahnung was oder wie oder überhaupt. - Ich hab ja nicht mal nen Modellnamen. Soll wohl ein Arch-Linux drauf sein. Und das war es an Infos, leider.

Ich werd mir das mal anschauen, aber vermutlich wird es dann doch auf nen Pi hinauslaufen.... gefällt mir jedenfalls immer besser die Idee/Lösung

 

[Cazawhi]

Ich habe einen Odroid-XU4 mit "Odrobian" was effektiv ein Debian mit Custom Kernel darstellt.
Das läuft mit armhf - Pakete die es nicht gäbe habe ich bisher noch nicht gefunden. Im schlimmsten Fall müsstest du die halt selbst kompilieren.
Geschwindigkeit ist ganz normal - kommt mehr auf deine Hardware an. Ein Raspi braucht verdammt lange zum Pakete installieren, der Odroid benutzt eMMC, was deutlich schneller und (in der Shell) komplett Leistungsstark läuft.
Was Grafik angeht kann ich dir besagten Odroid-XU4 ans Herz legen - kommt mit einer externen Grafikeinheit sowie Lüfter, sollte also auch für HD-Videos in der Lage sein. Und keine Sorge, X-Server gibt es auch für arm

Odrobian
Odroid XU4

LG

 

[theSplit]

Okay, damit der Thread nichts ins Bodenlose fällt, habe das Gerät heute empfangen, es ist ein ARM AMD Dual Core mit 2,1 Ghz und 2,5 Ghz Boost Takt, einer Radeon HD6000 und einer m2 SSD mit 16 bzw. 32 GB Speicher und 2 GB RAM.

Das Gerät ist eine Displaylösung von Samsung ein SSB *irgendwas*) (Flexbox) (deklariert als "Network Box" in den Specs).

Es wird wohl auf nen Pi hinauslaufen, da ich aktuell nicht die Möglichkeit sehe mich in VDPau einzuarbeiten für "ein" einziges Gerät - für die Zukunft wäre so etwas dann schon lohnenswert, aber ein Pi schafft das was er machen soll, hervorragend aktuell.

 

[nik]

Ich kann dir jetzt nicht so ganz folgen.

Du hast nen Mediaplayer ohne Hardwarebeschleunigung, den du auf nem ARM-Rechner laufen lassen willst und hattest am Anfang bedenken, dass das nicht funktioniert, weil ARM-CPUs laut deiner Meinung zu wenig performant sein könnten.
Jetzt bekommst du statt nem lahmen ARM-Prozessor aus nem PI, nen ordentlichen und steigst lieber auf nen PI um, damit du dich nicht in VDPau einarbeiten willst, was du nur brauchst, wenn du die Hardwarebeschleunigung der Grafikkarte nutzen willst, aber eh nicht vor hattest?

 

[theSplit]

Die Hardware-Beschleunigung ist für den Pi vorhanden, aber nicht über VDPAU,

Es wäre jetzt ein Gerät, welches diese Anforderung hat, vermutlich nicht auch das letzte, aber erst mal möchte ich den Pi verwenden.

Das ich mich nochmal in VDPau einlese, darum wird kein Weg drumherum führen - und ich seh dem ganzen auch relativ locker entgegen, bin natürlich gespannt was es da alles zu beachten gibt
Aber es wird bestimmt auch nicht einfach sein.

Das Problem war auch von vornherein, bevor ich den Modellnamen hatte, was dort an Hardware vorhanden ist. Und ich habe gedacht "mei, komme ich dabei herum etwas gesondert zu implementieren"....

Edit: Was ich aber noch dazu sagen muß, das ganze würde dann über VDPau laufen, aber die Zeit bleibt hier leider nicht, daher muß ein Pi ran, und ich denke die Teile machen ihre Aufgabe sehr gut!

 

[musv]

https://de.wikipedia.org/wiki/Video_Decode_and_Presentation_API_for_Unix

Video Decode and Presentation API for Unix (VDPAU) ist eine offene Programmierschnittstelle für Grafikkarten, die ursprünglich von Nvidia geschrieben wurde.

MIr ist vdpau auch immer nur im Zusammenhang mit Nvidia begegnet. In Wikipedia sind die Allwinner-Socs noch angegeben, die vdpau unterstützen sollen. Wie man auf Heise aber immer wieder lesen kann, gibt's zwar alle paar Wochen irgendeine neue Allwinner-Platine, die allerdings aufgrund der mangelhaften Treiberunterstützung immer eine neue Totgeburt darstellt.

Zu den Paketen: Ich hab auf meiner NAS (ARMv7) ein Gentoo laufen. Dadurch dass die Source-Pakete sich fast immer unter ARM compilieren lassen, ist zumindest im Open-Source-Bereich die Software-Abdeckung nur geringfügig unter der von x86/amd64. Wird nicht anders bei Debian sein.

 

[theSplit]

@musv:

https://wiki.ubuntuusers.de/Video-Dekodierung_beschleunigen/

Intel: VA API

Nvidia: VDPAU

AMD/ATI: VDPAU, ab Ubuntu 14.04 über den radeon Treibr

AMD/ATI: XvBA nur bis einschließlich Ubuntu 14.04 über den fglrx Treiber

Durch verschiedene Treiber bzw. API-Bibliotheken ist es aber auch möglich, die beiden verbreiteten Lösungen VA API und VDPAU herstellerübergreifend zu nutzen.

 

[musv]

Dass es technisch möglich ist, heißt noch lange nicht, dass es auch sinnvoll ist.

Meine Schwester hat ein Billignotebook mit einer Intel-Graka. Auf dem Ding hab ich mal OpenSuse installiert. Man starte VLC, lade irgendeinen Film, typischerweise im MKV-Format. Und schon fängt das Ding an zu flackern. Die Lösung ist da (finde den Thread nicht mehr), die libvdpau-va-gl runterzuschmeißen. Dann geht wieder alles.

Ich mag da keine tiefergreifenden Kenntnisse haben. Nach meinen bisherigen Troubleshoot-Erfahrungen verwendet man vdpau vorzugsweise bei Nvidia-Grakas und vaapi bei Intel. Welcher Treiber (und daraus resultierende: welche Video-API) jetzt für die Video-Hardwarebeschleunigung auf den ARM-Kisten zum Einsatz kommt, weiß ich nicht. Aber ich hab dunkel in Erinnerung, dass das Fehlen vernünftiger Grafiktreiber einer der großen Hauptgründe waren, warum nur ganz wenige ARM-SoCs überhaupt Erfolg hatten.

 

[theSplit]

@musv: Ich will dir nicht zu nahe treten und danke das du deine Erfahrungen schilderst - aber ich schrieb schon das eine AMD Radeon HD6000 eingebaut ist und b) aus dem Zitat das entweder XvBA oder VDPAU genutzt werden können, je nach AMD Treiber, auch wenn das für Nvidia gültig ist, es ist nicht mehr allein dafür gültig, das steht aber alles in dem Artikel bzw. hab ich das auch zitiert.

Das ein GL Modul/Lib daran schuld ist, kann auch gut sein, ich kann dir da schlecht widersprechen, aber so etwas könnte auch an der Implementierung oder einen Videocodec/Frames... liegen, selbst wenn VLC "klasse" ist. Und die Software hat nen Fallback, wenn das GL Modul nicht installiert ist und geht auf OpenEGL2 oder was auch immer dann oder benutzt halt eine andere API um die Videodaten zu dekodieren oder gar Software-Dekoding. Könnte auch an gedroppten Frames liegen die von dem Treiber so nicht korrekt übermittelt werden oder was auch immer. Alles "irgendwie" möglich.

 

[sia]

ARM AMD Dual Core mit 2,1 Ghz und 2,5 Ghz Boost Takt

Sicher, dass es die ARM-Architektur ist?

Der einzige mir bekannte Prozessor mit 2,1-2,5GHz und einer HD6000-Series-GPU ist der
AMD A4-3310MX

Wie ist denn die Modellnummer? Unter Linux auslesbar mit [kw]grep -m1 "model name" /proc/cpuinfo[/kw].

 

[alter_Bekannter]

Beim Pi ist der Software-, Community- und Treibersupport am besten von allen mir bekannten ARM Platinen.

Und natürlich sind die Repos die gleichen wenn die CPU Architektur stimmt. Ich habe die Debioan ARM Pakete auch schon auf verschiedenen Geräten mit Chroot neben Android laufen gelassen.

 

[theSplit]

@phre4k: Das Gerät ist so eines hier, aber etwas älter: http://www.samsung.com/us/business/displays/digital-signage-accessories/SBB-B64DV4/ZA

 

[sia]

@theSplit: Sag ich doch, der AMD Bald Eagle RX425 ist ein x86-Prozessor mit 64-Bit-Erweiterung aus 2014:
https://en.wikipedia.org/wiki/List_...t_microprocessors#.22Bald_Eagle.22_.282014.29

Da GCN verbaut ist, sollte der radeon(si)-Treiber da eigentlich schon einiges rausholen können. GPU-Dekodierung mit nativer (1080p) Bildschirmauflösung dürfte mit H.264 in MKV einwandfrei funktionieren.

Als Player kann man da bspw. MPV oder omxplayer nutzen, die Themen hatten wir hier schon (Stichwort: Kiosksystem Linux).

 

[theSplit]

Nein, du hast definitiv ein falsches Modell, das ist nach wie vor ein ARM CPU 110%... es kann sein das ich hier eine falsche Angabe gemacht habe zu einer Komponente (hab das Teil nicht vor mir und kann erst nächste Woche die genaue Bezeichnung herausgeben!), falls dem so ist, sorry! - Aber es handelt sich wie gesagt um eine Network Box von Samsung (Preis aktuell um die 450 €) mit einer AMD HD 6000 im Verbund und einer m2 16 GB SSD.

Erhältliche Player fallen weg, das ist eine Eigenproduktion mit extra Features. - Aber ich glaube kaum das sich VDPAU oder was auch immer man verwendet, für einen ARM oder einen "Desktop" PC verändert. Einzig allein welcher Treiber fglrx oder der offizielle Treiber würden hierbei wohl einen Unterschied machen. (Siehe Zitat aus Ubuntu Wiki) - Die Software würde ich auf dem Gerät direkt kompilieren und wäre so gut wie Architektur unabhängiger C-Code.

PS: Die CPU müsste die hier sein: "A4-3310MX" (wobei ich sehe gerade, das wäre kein ARM...., sollte aber einer sein?!)