Voodooalert+x264 Logo
US+UK Flagge DE+AT Flagge
Sprache wechseln:
 

x264 Benchmark Kompilier- & Installationsanleitung für Haiku

Haiku Logo

Systemvoraussetzungen

Um den x264 Benchmark auf Haiku übersetzen und installieren zu können, muß zuerst einmal eine gewisse Basissoftware vorhanden sein. Dazu gehören hauptsächlich:


Zum Zeitpunkt zu dem diese Anleitung verfaßt worden ist, ist eine Installation der Software auf Haiku Release 3 nicht möglich, weil hier nur der sehr stark veraltete GCC 2.95 verfügbar ist. Daher muß man auf einen Developer Build bzw. ein Nightly Image, oder auf eine ggf. neuere Version zurückgreifen, wenn verfügbar. Hier kann man entweder ein [Hybridimage mit GCC4] als Primärcompiler und GCC2 als Sekundärcompiler wählen, oder man entscheidet sich für ein [reines GCC4 Image], welches dann aber den Betrieb älterer Software, die mit GCC2 gebaut worden ist nicht mehr unterstützt. Praktischerweise bieten die Entwickler von Haiku nicht nur Installationsmedien, sondern auch fertige virtuelle Maschinen an, was zu Testzwecken durchaus praktisch sein kann.

Zuerst ist es vonnöten, den yasm Assembler zu bauen, ohne den wir auf optimierten Assemblercode weitestgehend verzichten müßten. Daher empfiehlt es sich absolut, den yasm zu bauen und zu installieren. Zuerst muß der Quellcode von yasm geladen werden:

Bevor irgendetwas kompiliert werden kann, müssen wir noch sicherstellen, daß auch wirklich der korrekte, neuere Compiler verwendet wird. Dazu führen wir folgenden Befehl aus:

Danach entpackt man das Archiv mittels tar -xzvf ./yasm-1.2.0.tar.gz und editiert am besten mit dem Haiku beiliegenden Texteditor "Pe" oder "StyledEdit" die darin befindliche Datei config/config.guess. Hier sucht man nun folgende Stelle:

BePC:BeOS:*:*)
  echo i586-pc-beos
  exit 0 ;;

Danach fügt man folgenden neuen Code ein, um es dem configure Script zu ermöglichen, die Plattform Haiku dem zugrundelegenden Betriebssystemtypen BeOS zuzuordnen:

BePC:*Haiku*:*:*)
  echo i586-pc-beos
  exit 0 ;;

Da dies nun erledigt ist, sollte das configure Script sauber laufen können, wir führen es also aus, und bauen sowie installieren yasm danach auch gleich:

yasm sollte nun zur Verfügung stehen (nachweisbar mittels yasm --version), womit wir zum Bau von libav und x264 fortschreiten können.

Die Benchmark-Software selbst

Um x264 benutzen zu können, brauchen wir die Decodingfilter von libavcodec (kurz libav) und den x264 Encoder selbst, der im Verlauf der Installation gegen libav linked wird. Weiters natürlich das Benchmarkvideo, das als Input verwendet wird, Downloadmirror zum Download des letzteren sind am Ende der [Benchmarkergebnisliste] verfügbar. Als Ersatz für libav kann man auch ffmpeg/ffms verwenden, wenn man dies möchte.

Der Einfachheit halber nehmen wir hier an, daß die Dateien nun in /boot/home/x264src/ liegen. Weiters nehmen wir an, daß der yasm Assembler vorliegt. Auf der Konsole wechseln wir also in dieses Verzeichnis, und beginnen mit libav. Entpackt wird das Archiv mit tar -xzvf <filename.tgz>, wonach es einen libav Ordner gibt. In diesen Ordner wechsle man nun, und beginne mit den notwendigen Modifikationen und dem Ausführen der entsprechenden Scripts:

Zuerst müssen die passenden Umgebungsvariablen gesetzt werden. Hier ist penibelst darauf acht zu geben, daß man seine Host CPU und deren Features auch genau kennt (das wird in späteren Schritten noch wichtiger). In unserem Fall wollen wir einen Intel Core 2 mit SSSE3 als höchsten verfügbaren Erweiterungsbefehssatz annehmen. Unser hypothetischer Prozessor verfügt also über die Befehlssätze MMX, SSE, SSE2, SSE3 und SSSE3. Für den C/C++ Compiler liefern wir also die entsprechenden Werte (Eine Dokumentation u.a. aller Marches ist [hier] zu finden):

Zusätzlich dazu müssen wir noch Haiku-spezifische Linker Flags setzen, da sich einige Funktionen des Betriebssystems nicht in den Libraries verstecken, die configure von Linux oder anderen Unix Systemen her kennt. So befinden sich einige nötige Funktionen in libnetwork und die komplette Posix Thread Funktionalität, die wir zur Unterstützung mehrerer CPU Kerne/Threads brauchen, befindet sich in libroot anstatt libm oder libpthread. Wir setzen also noch Linker Flags, um dem beizukommen:

Es ist zu beachten, daß man nach dem Setzen von CFLAGS, CXXFLAGS und LDFLAGS das Terminal nicht mehr schließen sollte, ansonsten muß man die Umgebungsvariablen für ein neues Terminal auch erneut setzen!

Nun führen wir das libav configure Script aus, anhand eines hypothetischen Intel Core 2 Prozessors als Zielplattform:
Hier sehen wir schon, daß dem Script sehr viele Optionen übergeben werden, anders als z.B. in Linux. Grund ist die fehlerbehaftete CPU Detektion des configure Scripts in Haiku, welches oft keine oder auch völlig falsche Befehlssätze erkennt. Wir schalten daher alle von unserer hypothetischen CPU nicht unterstützten Befehlssätze ab. Zum gegebenen Zeitpunkt unterstützt libav folgende Befehlserweiterungen, die man hier manuell ein- und ausschalten muß, je nach vorliegendem Prozessor (Achtung! Auch virtuelle Maschinen können hierauf Einfluß nehmen!):

Hier muß man also wirklich aufpassen, daß man die korrekten Befehlssätze aktiviert und den Rest ausschaltet. Doch trotzdem kann die Sache manchmal immer noch schief gehen, auch wenn man dem configure Script alles manuell vorbetet. Daher sollte man nach dem configure und vor dem Bau unbedingt nochmals bestimmte Dateien prüfen und gegebenenfalls falsche Konfigurationen korrigieren, in einigen dieser Dateien lassen sich Befehlssätze durch ein vorangestelltes ! deaktivieren, in anderen ist das per "0" oder "1" zu setzen. Die zu prüfenden Dateien wären:
Am besten durchsucht man alle Dateien nach Stichwörtern wie "MMX" oder "AVX" usw. Diese Stichwörter können gerne mehrfach vorkommen, etwa für EXTERNAL Assembler, für INLINE Assembler oder auch einfach als globale Einstellungen. Man sollte also sehr gründlich suchen, um auch sicher alle zu erwischen und korrekt einzustellen! Ansonsten muß man alles von vorne machen. Wenn man etwa versehentlich AMD 3DNow! Code auf einem Intel Core 2 baut, dann wird das nun einfach einmal nicht laufen, weil dieser Befehlssatz nicht in der CPU vorliegt.

Des weiteren ist in der config.mak noch eine abschließende Änderung vorzunehmen, hier muß ein standardgemäß als Fehler behandelter Schluckauf auf Warnung umgestellt werden, damit der Code bauen kann, und zwar müssen implizite Deklarationen erlaubt werden. Dazu suchen wir in config.mak folgende Zeichenfolge, die wir komplett entfernen:
Da die Buildscripte das GNU coreutil Tool "env" leider in einem statischen Pfad suchen, müssen wir noch dafür sorgen, daß es da auch gefunden wird:

Damit können wir libav nun auch endlich wirklich bauen:

Nun ist libav installiert, wir können also daran gehen, x264 selbst zu linken und zu bauen, man entpacke also den x264 Quellcode mit tar -xjvf last_x264.tar.bz2 und wechsle danach in das x264 Verzeichnis, hierbei sei darauf geachtet, daß wir immer noch unsere CFLAGS und LDFLAGS gesetzt haben (export | grep -i flags sollte uns einen guten Hinweis darauf geben, ob dem auch so ist).

Bevor wir hier loslegen können, müssen wir das x264 configure Script noch für Haiku vorbereiten und sicherstellen, daß ein sauberer Link zu libav hergestellt werden kann. Dazu sind gleich mehrere Dinge nötig:

Wir müssen dafür sorgen, daß x264 gleich wie libav zuvor Posix Threads verwendet, und nicht BeOS Threads, ein solches Gemisch würde unmöglich funktionieren. Zudem sind auch hier noch zusätzliche Linker Flags zu setzen, die ansonsten ignoriert würden. Wir suchen im configure Script folgende Stelle:

case $host_os in
  beos*)
    SYS="BEOS"
    define HAVE_MALLOC_H
    ;;

Gleich nach diesem Part im Code fügen wir folgendes hinzu, um Haiku ordentlich zu detektieren, und entsprechende Linker Flags zu setzen, damit x264 auch alle Betriebssystemfunktionen finden kann, die es braucht:

  *haiku*)
    SYS="HAIKU"
    define HAVE_MALLOC_H
    LDFLAGS="$LDFLAGS -lroot -lnetwork"
    ;;

Damit ist aber noch nicht alles getan, wir linken x264 so zwar korrekt, müssen ihm aber noch mitteilen, welches Threadingmodell in "libroot" zu finden ist. Wir suchen folgende Stelle im Code:

case $SYS in
  BEOS)
    thread="beos"
    define HAVE_BEOSTHREAD
    ;;

Gleich danach fügen wir folgendes hinzu:

  HAIKU)
    thread="posix"
    libpthread="-lroot"
    ;;

Da wir nun schon so sauber gegen libroot linken, wo sich unsere wertvollen Threadingfunktionen befinden, sollten wir noch eine Prüfung der ansonsten dafür verantwortlichen libm entfernen. Wir suchen folgende Stelle:

for lib in -lpostproc -lavcodec -lavcore -lswscale --lavutil -lm -lz -lbz2 $libpthread -lavifil32; do

Alles war hier zu tun ist ist es, -lm noch durch -lroot zu ersetzen! Das schließt die Modifikationen am configure Script ab. Leider sind wir damit noch nicht am Ende.

Da x264 eine Linux/Unix Funktion namens nice() verwendet, um im Betrieb seine eigene Priorität zu senken - eine Funktion, die in Haiku so nicht existiert - müssen wir gegen den Einsatz dieser Funktion noch etwas unternehmen, da unser Quellcode ansonsten nicht kompilieren wird. Da das Senken der eigenen Priorität kein wirklich wichtiger oder gar kritischer Vorgang ist, können wir diesen Teil getrost aus dem Quellcode von x264 tilgen. Wir öffnen die Datei common/osdeps.h und suchen nach folgender Stelle im Quellcode des Headers:

define x264_lower_thread_priority(p) { UNUSED int nice_ret = nice(p); }

Wir ersetzen diese Stelle einfach hierdurch:

define x264_lower_thread_priority(p)

Damit fällt das Heruntersetzen der Priorität flach und wir greifen auf keine Funktionen zu, die es in Haiku nicht geben würde. Damit genug der Modifikationen, wir sollten den Code jetzt konfigurieren, bauen, linken und installieren können:

Bevor wir wirklich bauen können, müssen wir nun noch dafür sorgen, daß der Linker libav auch wirklich findet, da das configure Skript leider den Prefix nicht zum Linker Suchpfad erklärt. Dazu editieren wir die Datei config.mak, und suchen folgende Stelle gegen Ende der Datei:

LDFLAGSCLI = -L. -lavformat -lavcodec -lswscale -lavutil -lroot -z -lbz2 -lroot -lswscale -lavutil

Wir ergänzen diese Stelle mit einem weiteren Linkersuchpfad:

LDFLAGSCLI = -L. -L/boot/common/lib -lavformat -lavcodec -lswscale -lavutil -lroot -z -lbz2 -lroot -lswscale -lavutil

Nun kann es mit dem Bau losgehen:

Nun kann man die Funktion durch x264 --version prüfen. Funktioniert das, und zeigt das Binary an, daß es gegen libswscale und libavformat linked ist, dann hat alles sauber funktioniert, sofern man nicht Assemblercode für einen nicht in der CPU vorhandenen Befehlssatz gebaut hat, ohne es zu merken. Nun kann man folgendes Benchmarkscript herunterladen:

Diese Datei launchbenchmark.sh kopieren wir nun in einen für den Benchmark gedachten Unterordner, den wir ggf. anlegen: mkdir -p /boot/home/x264benchmark. In diesem Ordner sollte auch das Inputvideo elephantsdream_source.264 landen.

Nun wird x264 (leider) eine Art der CPU Kern Detektion verwenden, die zwar auf Linux und Unix funktioniert, nicht aber auf BeOS und damit nicht auf Haiku. Das resultiert darin, daß x264 keine Ahnung haben wird, wieviele logische Prozessoren im System verfügbar sind. Wenn das passiert, wird x264 nur einen Worker Thread starten, und damit nur einen logischen Prozessorkern auslasten, obwohl wir Multithreading Support an Bord haben. Doch auch das läßt sich richten, indem wir die launchbenchmark.sh ändern, und x264 eine fixe Anzahl von Worker Threads vorgeben. Hier soll gelten:

Bei einer CPU mit 4 Kernen wären das also 6 Threads. Bei einer CPU mit 4 Kernen und Hyper-Threading (=8 logische CPUs) wären das 12 Threads. Sollte man einen Triple Core besitzen, funktioniert diese alte, über den Daumen gepeilte Regel für x264 natürlich nicht mehr, hier rundet man einfach auf 5 Threads auf. Das Maximum an verfügbaren Worker Threads in x264 ist zum Zeitpunkt an dem diese Anleitung verfaßt wurde übrigens 32, mehr Worker lassen sich also nicht starten. Um diese Änderung also vorzunehmen, öffnen wir die launchbenchmark.sh mit StyledEdit, und fügen jeweils hinter den beiden Optionen --cqm flat einfach folgendes hinzu:

Wobei n = Anzahl der Worker Threads, also z.B. --threads 12 für ein System mit 8 logischen CPUs. Damit steht auch der Nutzung mehrerer CPUs, CPU Kerne und Hyperthreads nichts mehr im Wege!

Nun kann man den Benchmark im Prinzip ausführen, hierzu gebe man einfach folgendes ein, während man im Ordner /boot/home/x264benchmark sitzt und nachdem man geprüft hat, daß das Script auch ausführbar ist (chmod +x ./launchbenchmark.sh):

Das könnte dann zum Beispiel so aussehen (Klicken, um zu vergrößern):

Haiku Screenshot

Nach Durchlauf ist das Ergebnis einfach neben dem Wert "Real" vom Terminal abzulesen.

Je nach Maschine kann das jetzt durchwegs mehrere Stunden, in extremen Fällen auch Tage, Wochen oder Monate dauern. Bei Problemen mit dieser Anleitung oder weiteren Fragen zum x264 Benchmark auf Haiku bitte einfach im [entsprechenden Forumsthread] nachfragen.

[Zurück zur x264 Benchmark Ergebnisliste]

[Anleitung kommentieren]