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

x264 Benchmark Kompilier- & Installationsanleitung für OpenSolaris 11

OpenSolaris Logo

Systemvoraussetzungen

Um den x264 Benchmark auf OpenSolaris 11 übersetzen und installieren zu können, muß zuerst einmal eine gewisse Basissoftware, wie GCC4, autoconf, make etc. in ihren GNU Versionen vorliegen. Um das zu gewährleisten, öffnet man den Solaris Package Manager, und installiert die folgenden Pakete aus den nachfolgend angegebenen Gruppen. Einige dieser Pakete sind eventuell nicht wirklich für den Bau nötig, wenn die Sammlung aber so wie hier angegeben installiert wird, funktioniert es immerhin:

Weiters werden noch die Bash Shell und der time Befehl benötigt, die aber im Auslieferungszustand von OpenSolaris bereits installiert sind.

Um optimierten Code übersetzen zu können, brauchen wir nun noch den yasm Assembler, den wir direkt vom Quellcode selbst übersetzen. Zuerst aber wäre er einmal herunterzuladen:

Danach entpackt man das Archiv mittels tar -xzvf ./yasm-1.2.0.tar.gz und kann direkt mit Konfiguration und Bau beginnen. Im Gegensatz zu den noch kommenden Paketen ist yasm sehr gut für OpenSolaris und seine umbenannten GNU Tools vorbereitet, diese Angelegenheit gestaltet sich also relativ einfach:

Nun führen wir folgenden Befehl aus, um die Installationsverzeichnisse permanent in unserem Suchpfad zu haben, zusätzlich setzen wir den korrekten Pfad auch gleich:

yasm sollte nun im System gefunden werden und ausführbar sein (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 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 /home/user/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. Aus Sicherheitsgründen empfiehlt es sich, hier auf zu harte Optimierung zu verzichten, man sollte neben der Grundoptimierung besser nicht viel mehr als seinen CPU Typ angeben. In diesem Beispiel nehmen wir einmal einen Chip vom Typ Intel Core 2 an. Wie man andere CPU Typen vorgeben kann, ist in der [GCC Dokumentation] nachzulesen:
Ich möchte noch einmal extra darauf hinweisen, daß man auf keinen Fall das C(XX)FLAG -pipe verwenden darf! Diese Option beschleunigt üblicherweise den Vorgang des Kompilierens, bricht aber den Bauvorgang auf OpenSolaris. Zudem muß man sagen: Soviel bringt die Option ohnehin nicht. Zusätzlich dazu müssen wir noch OpenSolaris-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 libxnet und libresolv. Weiters brauchen wir noch ein Komplement zur nicht standardgemäßen libc von OpenSolaris, welches wir in /usr/lib/values-xpg6.o finden können, wir setzen also die passenden LDFLAGS:

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 ist es so, daß wir zwar einen Haufen GNU Tools installiert haben, hinter den üblichen Namen dieser Tools aber Sun Versionen lauern, die teilweise komplett anders funktionieren, und den Konfigurationsvorgang erheblich stören würden, soweit, daß es unmöglich wird, den Code zu konfigurieren, geschweige denn zu bauen. Daher müssen wir hier einige Modifikationen vornehmen. Zu aller erst öffnen wir das im libav Ordner befindliche Script configure, z.B. mit dem grafischen Texteditor gedit. Danach startet man z.B. mit CTRL+H das Suchen & Ersetzen Fenster, um daraufhin folgende Ersetzungen vorzunehmen (Man beachte das jeweils folgende Leerzeichen, das ist wichtig, um keine falschen Ersetzungen durchzuführen, die ggf. Funktionsnamen o.ä. betreffen!):

Nun starten wir den entsprechenden Konfigurationsvorgang für den libav Quellcode. Neuere libav Versionen lassen es leider nicht mehr sauber zu, Assembleroptimierungen auf OpenSolaris selektiv auszuschalten. Wir deaktivieren daher alle Optimierungen, für libav fällt das glücklicherweise nicht wirklich schwer ins Gewicht:

Nun muß man noch sicherstellen, daß auch wirklich alle Optimierungen erledigt sind, um das zu gewährleisten, suche man in den folgend genannten Dateien nach "3DNOW", "3DNOWEXT", "MMX", "MMXEXT" "SSE", "SSE2", "SSE3", "SSSE3", "SSE4", "SSE42", "AVX" und "FMA4" und deaktiviere die entsprechenden Zeilen wie folgt:
Nun bleibt noch eine letzte Veränderung zugunsten unserer GNU Tools, die an config.mak vorgenommen werden muß, man suche folgende Stelle:

INSTALL=install

Und ersetze sie mit:

INSTALL=ginstall

Nun bauen und installieren wir die libav Suite:

Damit wäre libav fertig installiert, und wir können uns den letzten Brocken vorknöpfen, x264 selbst. Zuerst setzen wir die korrekten CFLAGS und CXXFLAGS, die für libav gesetzten LDFLAGS können wir so belassen, wie sie waren, als Beispielplattform dient uns wieder unser hypothetischer Intel Core 2. Man sollte sich hier übrigens keinesfalls dazu verleiten lassen, von -O1 abzuweichen, stärkere Optimierungen münden mit ziemlich hoher Wahrscheinlichkeit in defektem Code, der dann Probleme haben wird, mit der nicht standardkonformen libc von OpenSolaris zu linken. Mehr zu diesem Thema folgt noch:

Nun ist wieder ein wenig Editiererei gefragt um dem configure Script von x264 klarzumachen, daß es besser die GNU Tools verwenden sollte, anstatt dem eigenartigen Gewirr von Sun, wir editieren also configure:

Auch config.guess sollte hier noch angepasst werden, analog zu configure:

Danach ist noch ein wenig Feinschliff in Sachen Betriebssystemdetektion anzubringen, man suche nach folgender Stelle in configure:

sunos*|solaris*)
  SYS="SunOS"
  define HAVE_MALLOC_H
  LDFLAGS="$LDFLAGS -lm"
  if cc_check "" /usr/lib/64/values-xpg6.o; then
    LDFLAGS="$LDFLAGS /usr/lib/64/values-xpg6.o"
  else
    LDFLAGS="$LDFLAGS /usr/lib/values-xpg6.o"
  fi
  HAVE_GETOPT_LONG=0
  ;;

Und ersetze das mit folgendem Code:

sunos*|solaris*)
  SYS="SunOS"
  define HAVE_MALLOC_H
  LDFLAGS="$LDFLAGS -lm -lxnet -lresolv /usr/lib/values-xpg6.o"
  HAVE_GETOPT_LONG=0
  ;;

Nun können wir die Konfiguration einmal ausführen, indem wir das Script wie folgt aufrufen:

Hiernach editieren wir noch die eben erzeugte Datei config.mak um ein paar von autoconf gemachte Annahmen wieder zu revidieren, weil wir auf OpenSolaris ansonsten defekten Code bekommen würden und weil einige Linking Optionen ins Leere laufen. Wir suchen zuerst nach einer Zeile, die in etwa so aussehen dürfte:

CFLAGS=-Wshadow -O3 -ffast-math -O1 -march=core2 -L/usr/local/lib -I/usr/local/include -Wall -I. -I$(SRCPATH) -mfpmath=sse -msse -std=gnu99 -fomit-frame-pointer -fno-tree-vectorize

Und ersetzen sie hierdurch, was unseren Code lauffähig und vor allem gegen libc linkfähig machen sollte:

CFLAGS=-Wshadow -O1 -march=core2 -L/usr/local/lib -I/usr/local/include -Wall -I. -I$(SRCPATH) -std=gnu99 -fomit-frame-pointer -fno-tree-vectorize

Nun nehmen wir noch eine Ergänzung vor, und suchen folgende Zeile:

LDFLAGSCLI = -L. -lavformat -lavcodec -lswscale -lavutil -lm -lz -lbz2 -lpthread -lswscale -lavutil

Ersetzt wird sie durch folgendes, womit das Linking gegen alle notwendigen vorhandenen Libraries restlos repariert wäre:

LDFLAGSCLI = -L. -L/usr/local/lib -lavformat -lavcodec -lswscale -lavutil -lm -lz -lbz2 -lpthread -lswscale -lavutil -lxnet -lresolv /usr/lib/values-xpg6.o

Um auch die Installationsroutine zu reparieren, müssen wir noch das Makefile editieren, und alle eingerückten Zeilen suchen, die mit install beginnen. Da das sehr viel Code ist, soll hier nur ein Ersatzbeispiel genannt sein. Wir suchen also z.B.:

install-lib-dev:
  install -d $(DESTDIR)$(includedir)
  install -d $(DESTDIR)$(libdir)
  install -d $(DESTDIR)$(libdir)/pkgconfig
  install -m 644 $(SRCPATH)/x264.h $(DESTDIR)$(includedir)
  install -m 644 x264_config.h $(DESTDIR)$(includedir)
  install -m 644 x264.pc $(DESTDIR)$(libdir)/pkgconfig

Und ersetzen alle install Aufrufe durch ginstall, was dann auch für alle weiteren ähnlichen Zeilen in gleicher Weise zu tun ist:

install-lib-dev:
  ginstall -d $(DESTDIR)$(includedir)
  ginstall -d $(DESTDIR)$(libdir)
  ginstall -d $(DESTDIR)$(libdir)/pkgconfig
  ginstall -m 644 $(SRCPATH)/x264.h $(DESTDIR)$(includedir)
  ginstall -m 644 x264_config.h $(DESTDIR)$(includedir)
  ginstall -m 644 x264.pc $(DESTDIR)$(libdir)/pkgconfig

Weitere vorzunehmende Änderungen im Makefile:

Nun ist es aber an der Zeit, daß wir das ganze auch bauen, wenn alle Modifikationen sauber vorgenommen wurden, sollte die Übersetzung und Installation reibungslos durchlaufen:

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 und die Inputvideodatei herunterladen:

Diese Datei launchbenchmark.sh kopieren wir nun in einen für den Benchmark gedachten Unterordner, den wir ggf. anlegen: mkdir -p /home/user/x264benchmark. In diesem Ordner sollte auch das Inputvideo elephantsdream_source.264 landen.
Nun wird x264 (leider) eine Art der CPU Kern Detektion verwenden, die auf OpenSolaris trotz seines Unix-Charakters fehlschlägt. 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 gedit, 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 /home/user/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):

OpenSolaris 11 Screenshot

Nach Ablauf des Tests ist das Ergebnis neben dem String "Real" 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 OpenSolaris 11 bitte einfach im [entsprechenden Forumsthread] nachfragen.

[Zurück zur x264 Benchmark Ergebnisliste]

[Anleitung kommentieren]