Sie sind nicht angemeldet.

  • »GrandAdmiralThrawn« ist der Autor dieses Themas

Beiträge: 12 634

Wohnort: A-8600, Bruck an der Mur, ÖSTERREICH

Beruf: UNIX Administrator

  • Nachricht senden

221

Dienstag, 28. März 2017, 09:52

UNIX & Linux

So, ich habe mich nicht an meine eigenen Aussagen halten können (sowas passiert leider, wenn mich der Hafer sticht), und habe die letzte Woche ausschließlich an der UNIX Version des Benchmarks gearbeitet. Es hat mir einfach KEINE Ruhe gelassen mit OpenBSD UNIX und Solaris, und letzten Endes habe ich Wege gefunden, es auf beiden Systemen auszurollen (zum. OpenBSD 6.0 und Solaris 11.3). Das Testen auf sehr andersartigen Systemen hat aber auch zunehmend dazu beigetragen, diese Versions anpassungsfähiger und standardkonformer zu gestalten. Damit hat sich auch das Verhalten auf gewissen Linux Systemen verbessert, speziell solchen mit sehr strikten /bin/sh Shells wie etwa Debian 8 mit der dash (Dank an Umlüx für das Aufzeigen der Probleme auf Debian).

Weiterhin daran festhaltend, ein "Buildsystem" zu wollen, um der Versionlockphilosophie treu zu bleiben mußte das ganze an die verschiedenen Compiler/Linker Verhältnisse angepaßt werden. OpenBSD war dabei noch einfach, und wie schon beim x264 Benchmark bildete Solaris die größte Hürde. Hier muß sogar ein Compilergemisch zum Einsatz kommen (ffmpeg per GCC 4.8 Platform Compiler, x265 per GCC 5.2 Compiler aus dem OpenCSW Projekt), weil es sonst nicht geht. Außerdem muß mein Bootstrapper ein Buildscript von ffmpeg für Solaris patchen (Nutzung von GNU install statt Solaris install). Speziell der Bau von 64-bit Code ist auf dem Multilib Solaris ein Alptraum... Aber vieles davon kommt eben auch Linux zugute, was Robustheit angeht.

Natürlich ist auch (gerade) Linux nicht vor Absonderlichkeiten gefeit, die ich nicht vollständig abfangen kann, so z.B. gesehen bei OpenSUSE Leap 42.2, wo man CC/CXX setzen muß, und wo lspci in /sbin/ liegt, von wo SuSE die Ausführung als non-root blockiert (warum auch immer).

Na jedenfalls:

Bootstrapping (immer nur der Anfangsteil) auf Sabayon Linux und openSUSE Leap 42.2 Linux, Ausführung (hier immer ohne Encode) auf CentOS 6.8 Linux. Auf openSUSE sehen wir, wie der Bootstrapper auf eine nicht-kritische, fehlende Komponente reagiert. Im Prinzip gibt es drei Stufen: "Recht unwichtige" Komponenten, bei denen eine Warnung erscheint, aber kein Prompt. Dann "eher wichtige", die den Betrieb nicht gefährden, aber doch nennenswert einschränken. Hier wird der User gefragt, ob er wirklich so weitermachen möchte. Und dann zuletzte "kritische", die einen Abbruch mit entsprechender Fehlermeldung auslösen. (Klicken zum Vergrößern)



Bootstrapping und Ausführung auf FreeBSD 10.3 UNIX (11.0 wird ebenfalls unterstützt). (Klicken zum Vergrößern)



Bootstrapping und Ausführung auf OpenBSD 6.0 UNIX, hier sehen wir, wie das System vor dem nicht-Vorhandenseit der MKVtoolnix warnt. Das ist relativ unwichtig, daher gibt es nicht Mal eine Userabfrage dazu. (Klicken zum Vergrößern)


Bootstrapping und fehlschlagende Ausführung auf Oracle Solaris 11.3, hier spricht der Speichercheck an. ffmpeg wird auf "SunOS" gezwungenermaßen als 32-Bit Binary ausgeführt, da ansonsten das Linking kolossal bricht. Da ffmpeg und x265 aber über UNIX Pipes kommunizieren, ist das kein Problem. x265 baut und läuft sauber als 64-Bit Binary, solange man den von OpenCSW ausgelieferten C/C++ Compiler und Linker einsetzt, deren Installation ist dankenswerterweise recht simpel. Von OpenCSW brauchen wir auch cmake, da die Version auf Solaris für das x265 Buildsystem zu alt ist. Auf all das weist der Bootstrapper inkl. Kurzanleitungen auch hin, wenn noch nicht vorhanden. (Klicken zum Vergrößern)

Aktueller Quellcode der UNIX Prealpha 2 hier: [Bootstrapper] [Benchmark Launcher] (Kein vollständiger Bench, da fehlen noch Teile!).

Im Großen und ganzen ist hier durch die Vielfalt der Systeme (aber auch innerhalb von nur Linux schon!) sehr viel mehr Anpassungsarbeit nötig. Selbst wenn man voll POSIX-kompatibel arbeitet, läuft man manchmal in einige kleinere Fallen, so wie auf openSUSE. Da wird dann eben doch Userinteraktion nötig, wenn auch bisher nichts grobes. Der Weg zur vollständig automatischen Übesetzung des Quellcodes wird aber zunehmend eben.

Zudem: Der Defaultcompiler wird nun doch mit clang/llvm festgesetzt. Ist clang vorhanden, wird er präferiert, weil clang plattformübergreifend bisher eine höhere Kompatibilität an den Tag gelegt hat, vor allem wegen des modernen Linkers, wo die GNU bintools bzw. GNU ld manchmal in stark veralteter Form daherkommen. Hat eine Maschine keinen clang/llvm, so wird einfach der GCC benutzt.

Mein Versprechen, den Windows Release nicht durch UNIX Entwicklung zu bremsen ist damit eindeutig gebrochen. :P Werde auch noch mehr Linux Distros testen müssen, um noch mehr Eventualitäten abzudecken..

Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:
  • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700 (defekt)
[http://wp.xin.at] - No RISC, no fun!

QotY: Girls Love, BEST Love; 2017 - The second Coming; The second great Year of Yuri!

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »GrandAdmiralThrawn« (28. März 2017, 10:03)


  • »GrandAdmiralThrawn« ist der Autor dieses Themas

Beiträge: 12 634

Wohnort: A-8600, Bruck an der Mur, ÖSTERREICH

Beruf: UNIX Administrator

  • Nachricht senden

222

Dienstag, 28. März 2017, 15:36

MacOS X

Nachtrag:

Und jetzt ist das am Desktop am weitesten verbreitete UNIX auch mit dabei, nämlich MacOS X. Das war gar nicht so schwer, nur ein wenig zeitaufwendig. Etwas Code war dafür schon vorbereitet, und wenn der Mac User zu [Homebrew] greift und den Anweisungen des Bootstrappers folgt, sollte es relativ einfach sein. Xcode muß der User halt schon haben.

Getestet auf OS X 10.9.4 Mavericks mit Darwin/XNU Kernel 13.3.0:

Bootstrapping und Ausführung auf Apple MacOS X 10.9.4 Mavericks, mkvtoolnix geht auf diesem alten System mit Homebrew nicht mehr, auf neueren funktioniert auch das wieder. Alle anderen Tools die man per Homebrew installieren muß/kann laufen auch auf dem "alten" OS X Betriebssystem noch. (Klicken zum Vergrößern)

Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:
  • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700 (defekt)
[http://wp.xin.at] - No RISC, no fun!

QotY: Girls Love, BEST Love; 2017 - The second Coming; The second great Year of Yuri!

  • »GrandAdmiralThrawn« ist der Autor dieses Themas

Beiträge: 12 634

Wohnort: A-8600, Bruck an der Mur, ÖSTERREICH

Beruf: UNIX Administrator

  • Nachricht senden

223

Gestern, 09:50

*buntu

Ein schneller Test auf Ubuntu 16.10 hat dazu beigetragen, noch eine Verletzung der POSIX Standards in bootstrap.sh aufzudecken, hier war noch ein Wertevergleich mit == anstatt = drin, oder er hat sich etwas später eingeschlichen. Ansonsten war Ubuntu erwartungsgemäß schmerzlos, nachdem Debian 8 ja schon viel beigetragen hat, der Bootstrapper führt den User schön durch die zu installierende Software, bis alles fertig ist:


Bootstrapping und Ausführung auf dem neuesten Ubuntu 16.10 "Yakkety Yak" (Klicken zum Vergrößern)

Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:
  • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700 (defekt)
[http://wp.xin.at] - No RISC, no fun!

QotY: Girls Love, BEST Love; 2017 - The second Coming; The second great Year of Yuri!

224

Gestern, 21:10

Ah, super, vielen Dank! Da sind wir ja schon ziemlich nahe am untersten Ende des Spektrums? Wer einen Dualcore reinschickt, ist selber schuld! :topmodel:


Ich kenne mindestens zwei Kandidaten, die auch mindestens einen Singlecore durchjagen werden :spitze:
Aber schön, dass du mit der Linux und Co Entwicklung weiter machst, dann werd ich demnächst mal auf meinem Debian testen.

Weiß man eigentlich schon mit welcher x265 Version der von dir gemeldete Bug behoben sein wird? Hattest je mal erwähnt, dass das erst in die Beta geht und dann irgendwann in eine der nächsten Versionen mit einfließt.

  • »GrandAdmiralThrawn« ist der Autor dieses Themas

Beiträge: 12 634

Wohnort: A-8600, Bruck an der Mur, ÖSTERREICH

Beruf: UNIX Administrator

  • Nachricht senden

225

Gestern, 23:04

x265

Ah, das ist aller Wahrscheinlichkeit nach schon behoben. Der Benchmark an sich (in Versionen, die noch nicht öffentlich sind) behebt das ohnehin selbst, weil er die Parameter entsprechend anpaßt. Allerdings erlaubt der Benchmark das Abändern des Launchers, was es dem Nutzer ermöglichen würde, diesen Fix auszuhebeln (und einen Programmabsturz zu provozieren). Das heißt: Ich muß das erst noch testen! Es kann aber gut sein, daß es in der von mir aktuell benutzten Version 2.3+23 schon behoben ist.

Mh, werde mir ein Mail Notify schicken, und das morgen Mal ausprobieren, schaun ob der vorgeschlagene Patch schon upstream submitted is. Wenn nicht, bringe ich den Patch einfach selbst in den gegebenen x265 Quellcode ein. Ich mußte ohnehin schon ein paar Sachen an x265, ffmpeg und MediaInfo patchen (meist nur Buildscripte, aber auch C++ Code), um die plattformübergreifende Kompatibilität zu verbessern!

Wenn die Windows Beta kommt, wird das in jedem Fall fixed sein (egal ob von den Entwicklern oder von mir selbst).

Edit: Soeben für die UNIX wie auch Windows Version verifiziert, eine Angabe von 16 oder mehr Slices gibt:

Source code

1
x265 [warning]: maxSlices can not be more than min(rows, MAX_NAL_UNITS-1), force set to 15

Das heißt, der Fix ist in der aktuellen Entwicklungsversion bereits drin, und wird in jedem Fall mit dem nächsten Release mit ausgeliefert.

Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:
  • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700 (defekt)
[http://wp.xin.at] - No RISC, no fun!

QotY: Girls Love, BEST Love; 2017 - The second Coming; The second great Year of Yuri!

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »GrandAdmiralThrawn« (Heute, 08:08)


Ähnliche Themen