Bedarfserhebung: "Zukunftssicherer" x265 Benchmark

  • ?

    Nach dem - ich denke man kann das so hinstellen? - lokalen Erfolg des [x264 Benchmarks] sind im Verlaufe der Jahre auch einige Probleme mit der x264 Version mit der alles angefangen hat aufgetaucht.

    Einige Nutzer merken langsam, daß die Skalierbarkeit auf "Manycore" Systemen (16 Threads+ sag ich jetzt Mal) deutlich abnimmt. Umgehbar ist das nur durch Austausch der EXE und damit durch Invalidierung des Resultats.

    Jetzt experimentiere ich schon länger an einer künftigen Version des Konzepts, aktuell auf Basis von x265 (aber auch x264 ist nach wie vor nicht ausgeschlossen, frisst halt NOCH mehr Speicher, s.u.). Um die Parallelisierbarkeit zu erhöhen kommt aber nicht nur neue Software zum Einsatz, sondern auch völlig neuer Content - in 21:9 cinemascope 8K Auflösung (7680×3720, ein non-anamorphic Crop von normalem 8K, 7680×4320). Echtes cinemascope 8K wie für Kinos verabschiedet (10240×4320) kann aktuell kein freier Encoder.

    Folgendes würde sich daraus ergeben:

    • 64-Bit CPUs und Betriebssystem würden zum Minimum erhoben!
    • Windows XP x64 und Server 2003 x64 würden die ältestmöglichen Windows Plattformen darstellen (getestet!).
    • 16GB RAM wären absolutes Minimum (aktuell frißt der Encoder 15.5GB im Test, der Decoder 430MB, mit etwas Tweaking wär das knapp unter 16GB zu drücken)!
    • CPU Threading ist noch ungetestet, könnte aber gut bis 128 Kerne und höher gehen (Testplattformen könnten in einigen Monaten bereitstehen, nicht früher von meiner Seite).

    Das Projekt wäre theoretisch ähnlich angesetzt wie bisher, nur mit ein paar kleinen Veränderungen, die ich planen würde:

    • Der Bench sollte mit Quellcode kommen. Gültige Resultate wären nicht an irgendeine schwindelige EXE gebunden, sondern an die Versionsnummer des Benchmarks. So ließe sich die Software auf allen Zielplattformen bauen, und man könnte auch von Linux, UNIX usw. "gültige" Ergebnisse für Direktvergleiche einsenden. Minimale Schwankungen durch Compilerversionen würde ich planen hinzunehmen, solange der Nutzer die Compilerflags nicht manuell anpasst!
    • Es sollten (für Windows) Tools dabei sein, für Linux zumindest die Steuerskripte, mit denen man aus dem Ergebnis des Benchmarks einen funktionierenden Film zusammenbauen kann (MKV Datei), und zwar mit nur einem Klick! So kann jeder den eben kodierten Film händisch testen. Per VLC oder MPC-HC oder wie auch immer. Ich mein, flüssig spielt sowas eh keine Maschine ab, aber jo. :spitze:
    • Evtl. eine etwas bessere Abbruchbehandlung für Crashes, sodaß der Nutzer eine Warnung (und kein Resultat!) bekommt, falls der Test abstürzt.

    Das ganze hat natürlich offensichtliche Nachteile, gerade für eine Community wie diese hier. Und die dürften auch einleuchten, wenn man sich die Systemanforderungen anschaut. Das ist auch noch lanczos-upscaled 8K aktuell (Film: Sintel: Quelle: 21:9 cinemascope 4K), wenn ich die Quelldaten hole und den nativ auf 8K mit Blender selbst rausrendere (sofern meine HW das überhaupt in endlicher Zeit schafft und ich ned zu dumm dafür bin), dann könnten die Anforderungen sogar noch steigen.

    Daher die klaren Nachteile:

    • Die Laufzeit würde steigen. Allerdings so brutal, daß der Benchmark für "gemeines Volk" (=Leute mit weniger als 64 Kernen) unausführbar wird. Das ließe sich noch regeln, nimmt man halt nicht 14min Quellvideo, sondern nur 1min und passt wieder. Aaaaber...
    • ...Retrosysteme wären kategorisch ausgeschlossen, einfach aufgrund des 32-Bit Adressraums. Und damit auch alte Betriebssysteme. Diese lustigen Windows Me/9x und Windows NT/2000 Resultate auf guten alten Pentiums, Athlons, K6, usw. würden damit der Vergangenheit angehören.
    • ...Freakplattformen wie Raspberry Pi oder diverse ARM Development Boards für Android wären ebenfalls weg vom Fenster (auch aus dem Bereich gibt es einige User hier). Diverse MIPS und die meisten PowerPC Systeme wären genauso dahin, zumindest solange sie nicht genug RAM mitbringen können.

    Jetzt ist VA natürlich eine Retro Community. Und hat schon einen CPU Benchmark, der sehr viel abdeckt, der aber eben mit sehr fetten Boxen mit sehr vielen Kernen nicht mehr so gut kann. Er schafft's mit der alten x264 Version und der "niedrigen" Quellauflösung von 1920×1080 halt nicht mehr, 32 Threads auszulasten, zum. nicht in Pass 1.

    Daher stelle ich die Frage:

    Macht so etwas auf VA überhaupt Sinn? Wollen wir so etwas? Oder pfeifen wir drauf und lassen alles wie es ist - so schlecht funktioniert es ja nicht. Beide Projekte würden ohnehin parallel weiter laufen.

    Aber: Macht so etwas auf VA überhaupt Sinn?

    Alternativfrage: Man könnte 1080p auch lassen, das "Quellcodeversion = Referenzergebnis" Konzept aus der 8K Idee auskoppeln und auf den x264bench anwenden. Alle aktuellen Resultate würden bleiben und rot markiert werden. Alle neuen sind dann weiß, so sie aus Referenz kommen. Durch Übernahme einer neuen x264 Version als Referenz würden wir auch bei 1080p einiges an Skalierbarkeit hinzugewinnen, nur halt nicht GANZ so weit in die Zukunft wie bei der 8K Idee. Sollte man das machen? Die Zukunftssicherheit zugunsten alter Plattformen einschränken?

    Oder sollte man einfach gar nichts tun?

    Edit:

    Auf Anfrage von SK1 hier eine kleine Zusammenfassung des aktuellen Status' des Projekts.

    Aktive Entwicklungsphase: Beta 2 (Windows, unreleased) und Alpha 17+ (UNIX, unreleased)

    Solange sich das Projekt in der Alphaphase befindet, ist keine Feature Completeness erreicht. Ergebnisse aus der Alpha können und sollen bitte gerne gepostet werden, aber ich möchte darauf hinweisen, daß das eine frühe Testphase ist, d.h. diese Ergebnisse werden nie in irgendeiner Liste landen. Ein erstes Erfassen der Resultate kann frühestens in der Betaphase beginnen!


    Bisherig verfügbare Versionen (Open Alpha / Open Beta):

    • Windows 64-bit x86:


      • [Pre-Alpha 1] (2017-02-06, erste lauffähige Version)
      • [Pre-Alpha 2] (2017-02-07, erste Version mit Prüfsummenchecks)
      • [Pre-Alpha 3] (2017-02-17, Wechsel auf ffmpeg, neuer Compiler, viele Fixes)
      • [Alpha 1] (2017-02-18, MediaInfo hinzugefügt, Framecountprüfung implementiert, viele kleine Optimierungen)
      • [Alpha 2] (2017-02-22, NUMA Weiche mit zwei x265 Binaries, CPU-Z hinzugefügt, UAC implementiert, Rechteprüfungen auf NT5.2 implementiert, optionaler 8K Support. 8K Videofile: [input8K.h265], Anweisungen zur Nutzung [hier].)
      • [Alpha 4] (2017-02-24, Kommadozeilenparameter implementiert, Screenbuffer wird gesetzt, Ordnerstruktur in Anlehnung an POSIX komplett aufgeräumt, umfangreiche Bugfixes und Codekonsolidierung)
      • [Alpha 5] (2017-03-10, 8K ist nun Standard, Inputvideowechsel von 12-bit YUV 4:4:4 auf 10-bit YUV 4:2:0 um Decoder-RAM zu sparen, Encoding Chroma Subsampling aktiv, YUV 4:2:0 um Encoder-RAM zu sparen, Reduktion der B-Frames von 16 auf 4 um Encoder-RAM zu sparen, Vergrößerung des 8K Videos von 500-600 auf 800 Frames um schnellere Laufzeiten zu kompensieren, Virtuelle Speicherprüfung eingeführt um RAM und Gesamtspeicher RAM+Swap korrekt zu behandeln, RAM Limit jetzt bei 16GB mit Warnung bei Unterschreiten, virtuelles Speicherlimit bei 16GB mit Fehler bei Unterschreiten, duale Prüfsummen eingeführt, womit das System auch geänderte Dateien erkennen und vermerken kann. Dateien deren Änderung durch den Benutzer nicht zulässig ist lösen einen Fehler aus sobald sie modifiziert wurden. Das alte 720p Video wird derweil noch optional mit ausgeliefert, alles in einem Archiv. Diskanforderung aktualisiert: 512MiB.)
      • [Win64 Beta 1] (2017-04-06, Deutsche README.txt hinzugefügt, Quelltextänderungen dokumentiert, kosmetische Anpassungen der Checks um die Windows und UNIX Versionen aneinander anzugleichen.)
      • [Win64 Beta 5] (2017-11-10, Neue x265 Version 2.5+48, zahlreiche Verbesserungen im Bereich Robustheit des Launchers und der Prüfsummenverifikationen, Bugfixes in seltener aufgerufenen Teilen des Skripts, kosmetische Verbesserungen, Cleanup der Ordnerstruktur.)
      • [Win64 Beta 6 / RC1] (2017-11-15, VC++ Redistributables konsolidiert, VC++2010 x86 in VC++2017 x64 migriert bzw. colorecho.exe mit VC++2017 x64 neu kompiliert, dadurch nur mehr eine Redistributable nötig. Launcher angepaßt/konsolidiert, VC++2010 x86 Abfrage entfernt. Bug in der Betriebssystemweiche des Deutschen Hardwarereportingzweigs gefixed. NT5.2 Systeme erzeugen jetzt bei Einsatz eine Warnung statt nur einer Notiz, da die Leistung beeinträchtig wird - XP x64 & Server 2003 x64, Ergebnisse bleiben aber gültig. CPU-Z zur Unterstützung neuerer Plattformen von 1.78.3 -> 1.81.1 aktualisiert, Hardwarereporting im Launcher an die neue Version angepaßt. Einbau eines Benutzer-Prompts auf NT5.2 Systemen, wenn KB932370 fehlt, damit der Nutzer interaktiv entscheiden kann, ob er in diesem Zustand fortfahren oder vorerst abbrechen will. Microsofts' choice.exe dafür durch eine Freewareversion ersetzt. README*.txt Dateien aktualisiert. LINK DEAKTIVIERT, BLOCKER BUG GEFUNDEN!)
      • [Win64 Beta 6 / RC2] (Blocker Bug gefixed: Fehlendes Klammer-Escaping in einem ECHO Befehl des Softwarereportings, der fieserweise erst nach dem Encodingdurchlauf schlagend wird, und den kompletten Benchmark zunichte macht.)
    • UNIX, Linux und HaikuOS 64-bit x86:


      • [UNIX Alpha 16] (2017-04-06, Bootstrapping und Betrieb erstmals öffentlich möglich, siehe Anforderungen unten.)
      • [UNIX Beta 5] (2017-11-10, Neue x265 Version 2.5+48, zahlreiche Verbesserungen im Bereich Robustheit des Launchers sowie Bootstrappers und der Prüfsummenverifikationen, Bugfixes in seltener aufgerufenen Teilen des Skripts, kosmetische Verbesserungen, Cleanup der Ordnerstruktur.)
      • [UNIX Beta 6 / RC1] (2017-11-15, HAL deprecated unter Linux & FreeBSD UNIX, bessere Detektion und Behandlung des "time" Befehls als Reserved Shell Keyword wie Binärprogramm, neue Deutsche README-GER.txt, Verbesserungen der Debian Versionserkennung, Bugfixes und kosmetische Fixes am Launcher. README*.txt Dateien aktualisiert.)


    Aktuelle Systemanforderungen (Windows):

    • Windows XP Professional x64 Edition / Windows Server 2003 x64 oder neuer (Vista, 7, 8.x, 10), ausschließlich in x86_64!
    • 64-Bit x86 Prozessor (Ab Intel Prescott oder AMD Athlon64)
    • 16GiB RAM
    • 1.2GiB Diskspace


    Aktuelle Systemanforderungen (UNIX / Linux / Haiku OS):

    • Ein POSIX-kompatibles 64-bit Betriebssystem (UNIX, Linux, Haiku OS)
    • 64-Bit x86, PowerPC, ARM oder Itanium Prozessor (RISC und VLIW Architekturen noch ungetestet)
    • 16GiB RAM
    • 1.5GiB Diskspace
    • Für spezifischere Softwareanforderungen siehe README/README.txt oder die Ausgaben von $ ./bootstrap.sh


    Unterstützte UNIX Betriebssysteme:

    • Apple MacOS X, Versionen 10.9.4, 10.9.5
    • DragonFly BSD UNIX, Version 4.8.0-RELEASE
    • FreeBSD UNIX, Version 10.3-RELEASE, 11.0-RELEASE
    • NetBSD UNIX, Version 7.1
    • OpenBSD UNIX, Version 6.0
    • Sun/Oracle Solaris, Version 11.3
    • TrueOS UNIX, Version FreeBSD 12.0-CURRENT


    Unterstützte Linux Distributionen (andere können natürlich gut und gern auch funktionieren, hier gibt es keine distributionsspezifischen Abfragen, das ist einfach eine Liste getesteter Systeme):

    • CentOS Linux, Versionen 6.8, 7.3.1611
    • gNewSense Linux, Version 5 (benötigt neueren yasm, der von Hand kompiliert werden muß)
    • Linux Mint, Version 18.1
    • openSUSE Leap Linux, Version 42.2 (lspci muß manuell zum Suchpfad hinzugefügt werden)
    • Sabayon Linux, Version 16.11
    • Slackware Linux, Version 14.2
    • Ubuntu Linux, Version 16.10


    Unterstützte BeOS Betriebssysteme:

    • Haiku OS, Version hrev51051 (Sauberes Multithreading erst ab UNIX Alpha 17!)

    Ausführung unter unixoiden Systemen mittels `$ ./bootstrap.sh`, danach Befolgen der Anweisungen auf dem Terminal.

    Die Reduktion des 8K Speicherverbrauchs auf <= 16GiB RAM ist mit Beta 1 auf Windows und Alpha 16 auf UNIX abgeschlossen.

    Aktuellstes Struktogramm: [Kurz vor Alpha 5] (PNG)

    Weitere Struktogramme und Detailinformationen zu den Releases sind bitte dem Gesamtverlauf des Threads zu entnehmen!

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

    19 Mal editiert, zuletzt von GrandAdmiralThrawn (26. April 2019 um 00:28)

  • Ja so ein Benchmark macht sinn. Aber Rechne damit das irgendwer wieder einen pentium 4 mit 16 gb ram daran setzen wird (mal nach einem Mainbord suchen).

    8GB ram sind ehh schon zum aussterben verdammt.


    Das auskoppeln halte ich echt fuer eine sauschlechte Idee der x264 ist so gut wie er ist und wuerde viele ergebnisse durcheinander wirbeln.

  • Ich sehe den Bedarf ehrlich gesagt nicht. Ein cooles Feature wäre sicherlich wenn der Enduser eindeutig erkennen kann, wenn der Durchlauf nicht complete war - wenn er nämlich kein Ergebnis bekommt, sondern eine Fehlermeldung. Aber gerade, weil man hier alles mögliche als Platform einsetzen kann ist der x264 so genial (imho!).

    Worüber man NACHDENKEN könnte (wenns denn vertretbar problemlos zu implementieren wäre), wäre ein x264 v2.0 Bench, der in einer separaten Liste geführt wird.
    Dann sollte man für den alten Bench keine weiteren Custom-Builds eintragen/annehmen, dafür wäre dann eine aktuelle x264 Version in der v2.0 Liste da. Und trotzdem kann man noch alte Systeme drüberjagen.
    Oder man packt alles in eine Liste und macht einen Filter für v2.0-only v1.0-only Ergebnisse.

    Sowas in der Richtung würde ich zumindest vorschlagen.

  • Hatte auch schon länger den x265 Gedanken im Hinterkopf und habe auch schon ein wenig darauf gewartet.
    Ich finde es schon Sinnvoll, die hohen Anforderungen werden uns in den kommenden Jahren
    vermutlich nicht mehr so "hoch" vorkommen
    (16GB Ram haben ja eh schon die meisten im GamingPC).

    Mein einziger Wunsch zu dem Projekt wäre, dass der Benchmark nicht zu lang ist.
    Gelegentlich habe ich auch mal Zugriff zu recht aktuellen Servern und ähnliches,
    jedoch kann ich die dann nicht Stundenlang zurückhalten.

    EDIT:
    Den Vorschlag von Tweakstone finde ich auch gut, wenn x264 V2.0 überhaupt zur Debatte steht.

    Einmal editiert, zuletzt von Grindhavoc (16. Juni 2016 um 15:43)

  • Doch, täte er schon. Allerdings ist x264 noch gefräßiger im RAM, wenn man ihn auf starke Parallelisierung auslegt (dann skaliert er aber sogar etwas besser). Nur der frißt dann Mal locker 25GB oder so weg.. Dann ist mit alten Systemen eh wieder nichts, also die sind so oder so raus mit sowas, egal welchen Encoder man nimmt. Ich wollte eigentlich unter der 16GB Marke ansetzen, eben weil das aus 2016er Sicht für Enthusiasten ein sinnvoller Startpunkt ist. Das wäre (neben "moderner") noch ein Grund für x265, weil der eine Spur weniger RAM frißt bei vergleichbaren Settings.

    Die Laufzeit kann man anpassen, aber der x264 Benchmark hatte auch immer den Anspruch, ein halbwegs sinnvoller, praktischer Stabilitätstest zu sein. Dieser Aspekt soll nicht verschwinden. Ich dachte an eine anvisierte Laufzeit von ~4 Stunden für ein aktuelles top-end Single Socket System. Das wäre dann also ein Broadwell 10-Kerner. Das müßte die Laufzeit auf meinem Xeon X5690 (~i7 990X) Hexcore in den Bereich von 10-12 Stunden pushen. Dann kann ein moderner Dual Socket Server das vielleicht in 2-3h wegrechnen..

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

  • Hmm naja wenns eh nicht mit älteren Systemen laufen würde... ich weiss nicht. Ich finds momentan nicht so reizvoll, aber ist meine Meinung.
    Klar würd ich auch mal den ein oder anderen Server rüberjagen, wenn ich grad einen zum Einrichten da hab. Aber das hat irgendwie so Standard 3D-Mark Flair für mich und die haben auch nach Version 2005/2006 spätestens den Reiz für mich verloren.

  • Mein Urplan war es ja, einen Bench zu schaffen, der "ewig" funktioniert. Aber da hat jemand die Rechnung ohne die Köche (Entwickler von Software und CPUs..) gemacht. :topmodel:

    Daß (das alte) x264 bei 32 Threads abriegelt wußte ich schon wenige Jahre nach Start, aber da war es für eine Reißleine natürlich auch schon viel zu spät (und für x265 viel zu früh). Und den Rest kennt ihr eh. Wie gesagt, parallel würde ich es sowieso laufen lassen (und beide Projekte auf unbestimmte Zeit warten).

    Nur wenn beim neuen dann 7 Ergebnisse reinkommen, und dann juckt's keine Sau mehr, dann wäre das ein Schuß in den Ofen gewesen, dann isses mir um die ganzen Verbesserungen (am Benchmark selber wie auch an der Datenbank hinter der separaten Ergebnisliste) auch leid.

    Ist halt die Frage, ob zwei davon nicht einer zuviel sind, Verbesserungen hin oder her. Da ich den Test nach wie vor nicht "auf groß" über VA hinaus transportieren will (wegen der Cheatinggefahr), muß schon hinreichendes Interesse bestehen.

    Aber ich tu mir da extrem schwer. Beim x264 dachte ich alleine schon beim Umstand daß man eine BAT Datei ausführen und dann einem Benchmark zuschauen muß, der obskure Dinge in einer Konsole macht... daß das ein kompletter Rohrkrepierer wird... war auch eine Fehleinschätzung von meiner Seite... Deswegen frage ich lieber vorher. ;)

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

  • Ich brauchs nicht. Der alte Bench tuts auch und ist kompatibler. Win98 geht ja z.B. auch.

    "Du bist und bleibst a Mensch und du kannst eben net deine menschlichkeit überwinden."

    Dennis_50300

  • Ich wäre für einen x265 Bench, schlichtweg weil wir sonst in der Zukunft keine gute Vergleichbarkeit der neueren Systeme (die auch irgendwann Retro sind) mehr haben. Für das alte Zeug gibt es ja weiterhin den x264.

    Bezüglich ARM/Sparc...: Sollte doch aber funktionieren wenn der jeweilige Prozessor 64Bit kann und das System entsprechend viel Speicher hat, oder nicht?

    Laufzeit sollte man in jedem Fall überschaubar halten.

  • [...] Bezüglich ARM/Sparc...: Sollte doch aber funktionieren wenn der jeweilige Prozessor 64Bit kann und das System entsprechend viel Speicher hat, oder nicht? [...]


    Natürlich! Aaah, auf einen dicken UltraSPARC warte ich heute noch. :rolleyes: Aber jo, bei ARM sind die Plattformen halt tendenziell eher klein. Wenn aber ein 64-Bit ARM und genug Speicher da sind, stünde dem nichts im Wege. In Zukunft dann halt Mal (x265 hat - wie x264 - auch recht starke ARM NEON Optimierungen i.Ü.).

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

  • Mein Skylake hat's noch nicht, aber Eaglelake bekommt dann auch einen H.265/HEVC ASIC rein, inkl. 10-Bit Support. Aber da is x86 halt etwas hinten nach, bzw. die GPUs eigentlich, weil denen bauens ja im x86 Sektor die Decoder/Encoder ASICs dazu, nicht der CPU..

    Bei ARM brauchst es halt wirklich unbedingt, weil die CPUs alleine schaffen das ja oft ned. Selber im Test schon gesehen mit recht neuen 4-/8-Kernern usw. Ohne HW Accel sind die für Wiedergabe von H.265 ungeeignet.

    Aber das is beinahe Offtopic jetzt. ;)

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

  • Ein Rohrkrepierer wird es sicherlich nicht werden, jedoch wird der Start zäh werden.

    Beim x264 war direkt bei allen genügend Hardware, die den Anforderungen entspricht, vorhanden.

    (Bei mir sähe das Verhältnis so aus: x264 = ca. 25 verfügbare Systeme, x265 = ca. 2 oder 3 verfügbare Systeme)

  • Aufgrund der Skalierbarkeit nach oben vom 264 bin ich hier nochmal ganz klar noch mal ein: Ja machen wir ;).

    Allerdings hab ich noch ein paar fragen zur Machbarkeit:

    Kommt das Ding mit 32bit + PAE zurecht? ich mein 16 gb ram sind ja auch mit 32 Bit CPUs kein Ding der Unmoeglichkeit ;)
    Ich denk grade an 4 pentium 3 xeons mit 900 mhz und 16 gb ram, oder an den Sossaman :)


    also es waere gut, wenn der Benchmark die 16 gb schluckt. Dazu ist evlt auch eine Clustermoeglichkeit intressant. Um zu sagen dieses Blade mit meinen 10 Pentium 3 soll das jetzt machen. ;)

  • Zitat

    Retrosysteme wären kategorisch ausgeschlossen, einfach aufgrund des 32-Bit Adressraums

    Dieses ist mit einem 36 Bit Raum erledigt. 32builds gibts: http://x265.ru/en/builds/
    Die Frage ist eher ob SSE Pflicht ist. Allerdings kann man entsprechende Compilerflags setzen.

    Die Frage ist halt nur wie lange das dauert auszufuehren.

    Aktuelle Systeme sind etwa 10-20 mal so schnell wie so ein Sossaman. Sprich wenn Gats Benchmark etwa 2 wochen braucht auf einem Aktuellen System braucht es 20 Wochen auf einem Sossaman. Ich denke das ist noch voll ok. Auf dem Pentium 3 Xeon braucht es dann halt 40-50 Wochen. Na und? es gibt hier leute die haben solche zeiten schon in den X264 gepumpt ;)

    Sogar 8gb + 8gb Auslagerungsdatei sind in dem Fall machbar.

    Athlon MP ist halt leider ausgeschlossen mit seinen Max 4 GB, Dafuer ist der Athlon 64 mit dabei.

  • [...] aktuell frißt der Encoder 15.5GB im Test, [...]


    Ich quote mich Mal schamlos selbst; Bier, was du verlangst ist technisch nicht möglich, was auch klar wird, wenn man 36-Bit PAE verstanden hat. Du hast mit dem PAE Maximalausbau (64GB) logisch keine 64GB RAM, sondern 16×4GB RAM. Jedes dieser 16 Fenster teilt sich zudem in Kernelspace und Userspace auf. Üblicherweise ist diese Aufteilung 1/1, also 2GB Kernel, 2GB User. Was du also machen kannst ist es, 32×2GB Prozesse auf's System loszulassen (eher weniger, in der Praxis, das OS belegt ja auch noch was). Jeder Prozess hat in seinem Kontext aber nur ein 4GB Speicherfenster, von dem 2GB bereits vom Kernel belegt sind.

    Ein einzelner 32-Bit Prozess kann so also niemals 4GB, 5GB, 6GB oder 60GB fressen, weil er in einem 32-Bit Fenster existiert.

    Wenn x265 mit anvisierten Einstellungen also alleine schon 15.5GB frißt, wie soll das jemals gehen? Es kann nicht gehen! Darüber haben wir jetzt schon mehrmals gesprochen, bitte lernen wie Adressräume funktionieren!

    SSE ist nicht Mal Teil des Themas, weil 64-Bit eine Mindestanforderung wäre, und alle 64-Bit x86 CPUs SSE & SSE2 haben.

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

    2 Mal editiert, zuletzt von GrandAdmiralThrawn (24. Februar 2017 um 22:46)