Bedarfserhebung: "Zukunftssicherer" x265 Benchmark

  • hast Recht war Gedanklich bei 2GB/Thread und nicht 2gb/Prozess.
    User / Kernelspace kann man soweit ich weiss ja sogar noch verschieben. zu 3/1 soweit ich mich recht erinnere....

    Dann muesste das zu Encodierende Video erst geteilt werden und dann gerechnet. z.b. in 100 Teile a 768×372 und anschliessend Nebeneinander oder Nacheinander gerechnet werden. (geht das ueberhaubt?)

  • Du müßtest auf ein Multiprozeßmodell wechseln, statt auf ein Multithreadmodell. So ein Ansatz funktioniert allerdings in dem Fall nicht. Du kannst Videos nämlich nur an I-Frame Boundaries sauber zusammenstoppeln, nicht aber aus in-Frame Blocks. Sprich, jeder Prozeß hätte wieder ein ganzes UHD Video zu kodieren, und keinen "Teilblock" des Ganzen. Selbst wenn du alles per AviSynth Frameserver zerlegst und die kleinen Videos kodierst, kannst sie nicht einfach zusammenstoppeln. Du kannst nur die Videos als Quellblöcke nehmen, und mußt sie dann im letzten Schritt erst wieder in ein finales UHD Video kodieren. Um das kommst also nie herum. Die ganze Übung wäre also komplett umsonst.

    Sprich: Keine 32-Bit. Ist in derartigen Auflösungen und mit derartigen Einstellungen schlicht und ergreifend nicht machbar, egal wie man es dreht und wendet. Klar kannst dir ein 32-Bit x265 Binary für Windows holen. Solche [kompiliere ich sogar selber] auch, um an Windows XP-kompatible Versionen zu kommen (Auch wenn mich primär die 64-Bit Version interessiert, ich baue auch für 32-Bit).

    Und weißt du was passiert, wenn du ein 32-bit x265 mit einem derartigen UHD Video fütterst? Der stürzt dir einfach mit einem Fehler in malloc() ab, weil er den RAM nicht kriegen kann. Macht x264 auch nicht anders. Außerdem werden 10-bit und 12-bit Deep Color Encoding im 32-bit x265 Code auch nicht weiter unterstützt, was noch ein Malus ist.

    Wär sogar denkbar, daß man die 32-bit Version in Zukunft ganz fallen läßt...

    Zum Clustering: Das ist machbar. Allerdings muß sich der Nutzer selber darum kümmern, die Software auf seiner Clusterlösung auszurollen, so wie ich es z.B. mit x264 auf einer Sun Grid Engine gemacht hatte. Da jede Clustersoftware anders aussieht, ist ein generischer Ansatz nicht möglich, außer man schreibt sich die Server-/Clientlösung selbst. Das ist für mich nicht machbar. Also ein "Single Click" Clustering werde ich voraussichtlich nicht anbieten können.

    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 für mich würde so einen Test nicht unbedingt benötigen unterdessen die Liebe zum Standard ohne OC, ja für Wem machen, so unbedingt ist eben die Frage, in den nächsten zwei Jahren sollten ja für das Spielen kaum mehr als 8 Kerne ob von Intel oder AMD gebraucht werden.

    Ja sind schon so einige Obermotz-Kerner im Umlauf, aber da wurden sie wohl auch für ihren Anwendungszweck gekauft, jetzt würde das schon Sinn machen 32 Bit zu streichen, ist doch schon etwas Scheiße da 100.000 von Stunden alte Hardware etwas zu berechnen lassen wo eigentlich Jeder sicher weiß, mit dem System gewinne ich kein Blumentopf.
    Ist nur gut für Leistungsleichen und da geht der Andere Test doch prima, 16GB sicher ist das Zeitgeist, bei mir nicht angekommen, aber ja der Test ist halt für Die die das und mehr verbaut haben.

    Egal will jetzt auch nicht wie ein ewiger Nögelsack motzen, also macht woran ihr Spaß habt, ich werde gelegentlich wohl nur zum Blick erhaschen und diesen geplanten Test verfolgen, auch wenn ich denke der viele Strom der wieder verheizt wird, das kleinste und das fetteste an CPU von einer Plattform würde mir eigentlich reichen können für einen Überblick.

    Grundsätzlich ja, aber auch nicht unbedingt so das wegen 1-2 Sekunden schneller, wieder Hunderte von Systemen laufen, also voll für die Streichung von 32 BIT :spitze:

    In meinen Augen ein Fakt ist, egal ob Gott oder die Philosophie werken will, ein bedauerliches Übel bleibt erhalten, das Erbe, was an Menschen weiter gegeben wird, die es selbst nicht erwirtschaftet haben.

    Das Erbrecht muss erlöschen, erst dann wird die Vernunft triumphieren können über die Macht des Geldes als Druckmittel oder Sklavenpeitsche hinter dem Menschen selbst und die Erde wieder für folgende Generationen befreien.

    Zitat: V.F

    Einmal editiert, zuletzt von V.F (23. Dezember 2016 um 21:49)

  • Dein Zynismus ist aber schon immer sowas von bissig! :rolleyes:

    Aber was soll's, aktuell schaut's eh nicht danach aus als würde ich das bald zusammenstoppeln. Ich habe auch nichts weiter in die Richtung unternommen. Ich sollte ja wirklich eine Art "Erfolgsprüfung" auch noch einbauen, damit's nicht ganz so schwammig ist wie der x264 Benchmark, wo man tlw. gar nicht bemerkt daß etwas abgestürzt ist. Und zig andere Dinge wären da auch noch, und ich hab da nicht wirklich weitergearbeitet. Jetzt im Urlaub hätte ich ja Zeit genug, aber die verplemper ich aktuell lieber mit anderem Schwachsinn! :rolleyes: :P

    Na Mal schaun, irgendwann in 2017 wird mich die Motivation schon Mal packen.

    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!"

  • Von meiner Warte aus: Voraussichtlich nein.

    Grund: Ich bin kein GUI Entwickler. Ich habe früher Mal GUIs in Delphi gebaut (weil supereinfach), aber ich kann sowas aus aktueller Sicht einfach ned. Wenn, dann würde ich auch kein Windows GUI Framework nutzen wollen, sondern etwas plattformübergreifendes wie wxWidgets, GTK, Tk oder Qt. Aber das Zeug ist haarig und halt einfach nicht so easy für einen "Deppen" wie mich.

    Natürlich steht es anderen Contributors frei, selbst eine GUI beizusteuern, solange sie lizenztechnisch frei genug ist (GPL, LGPL, MIT, BSD, ...). Im Prinzip müßte eine GUI nicht viel mehr sein, als ein paar Buttons und ein Terminal Interface. Eventuell muß letzteres noch nicht Mal zwingend sein, ein System Call reicht ggf. auch aus.

    Steht ja nicht in Stein gemeißelt, daß alles aus meiner Hand kommen müßte.

    Es haben ja auch beim x264benchmark schon viele andere Leute mitgeholfen. Umlüx z.B. hat die erste externe Ergebnisliste an einem Vormittag in PHP/MySQL aus der Erde gestampft, CryptonNite hat z.B. (wenn ich mich recht erinnere) das Win9x Benchmarkscript geschrieben, weil meins nicht kompatibel war, selbst die Idee an sich war nicht von mir, sondern von S2 Sedan. Ganz zu schweigen von den ganzen Fehlerkorrekturkommentaren und Feature Requests, die die Qualität des ganzen laufend haben steigen lassen. Also wenn jemand eine GUI schreiben kann und will, wär das super. Weil ich glaub daß das jenseits meiner Fähigkeiten liegt.

    Selbst wenn es dann Windows-only wäre, auch ok. Eine GUI für Windows User ist besser als gar keine GUI.

    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!"

    Einmal editiert, zuletzt von GrandAdmiralThrawn (24. Dezember 2016 um 21:48)

  • Na ja, GTK dürfte mit CSharp und SharpDevelop machbar sein. Wenn man das mono-Framework nutzt, ließe sich sowas recht leicht realisieren. Dennoch halte ich Klickibunti für unsinnig.

    Ein gutes Programm benötigt keine Oberfläche. Man schaue sich mal im unixoiden Umfeld um. Da kann man auf sowas komplett verzichten. Bei Windows startet heute immer die Oberfläche, wenn auch vielleicht minimalistisch.

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

    Dennis_50300

    2 Mal editiert, zuletzt von CryptonNite (24. Dezember 2016 um 23:00)

  • Ich habe jetzt Mal gaaanz vorsichtig begonnen, Grundsteine zu legen:

    • ) Ein reduziertes avconv.exe Binary (1.8MB statt 68MB) wurde gebaut, dieses dient als notwendiger Input Decoder. Das kann wirklich fast nichts mehr, außer das, was es für den x265 Benchmark brauchen würde (H.265/HEVC Input parsen, demuxen und decoden, Dateien und Pipes benutzen, zu wrapped_avframe kodieren und zu YUV/Y4M muxen, das x265 von Pipe lesen kann). Ob der Input wirklich H.265/HEVC sein soll, steht aber noch aus. Auch beim Decoding muß die Parallelisierbarkeit bedacht werden, damit das nicht zum Flaschenhals werden kann.
    • ) Ein reduziertes x265.exe Binary (3.6MB statt 9.xMB) wurde gebaut, kein Multilib Binary. Die .exe kann nur 10-bit-pro-Kanal kodieren, sonst braucht sie auch nichts. Ersten Tests zufolge funktioniert das Mal.
    • ) Begonnen ein neues cmd Benchmarkskript für Windows zu schreiben, das logische Prozessoren auslesen und div. Parallelisierungsoptionen für hochparallele Systeme entsprechend setzen/skalieren kann. Wie das Parametertuning genau aussehen soll, ist aber noch unklar. Mein Wunsch wäre es, auch mehrere tausend Kerne unterstützen zu können.
    • ) Eine Nachricht in die x265 Entwicklermailingliste abgesetzt, mit der Bitte um Hilfe zur Parameterisierung von x265 für hochparallele ("Many Core") Systeme.
    • ) Verfassen initialer Dokumentation, Sammeln und Aufsetzen der legalen Anteile (Lizenztexte, Quellcodeangaben usw.).
    • ) Version Lock anstatt Binary Lock steht nun fest: Linux, UNIX, Haiku und VM Ergebnisse werden als gültig akzeptiert werden können, unabhängig vom verwendeten Compiler (solange die Tuningflags nicht verändert werden).
    • ) Vorläufige Systemvoraussetzungen: XP x64 / Server 2003 x64 oder höher, oder Linux/UNIX/Haiku/etc., x86_64 CPU (Athlon64+ oder Prescott P4+), 16GiB RAM, 3GiB HDD.
    • ) Separate Windows Version für XP x64 bis Vista und für Windows 7 und höher (Win7 und höher bekommen x265 NUMA Unterstützung, darunter gibt's das nicht! NUMA Support auf Linux und UNIX nur bei vorhandener libnuma).
    • ) Input: Wird 4K/UHD (3840×2160) oder 4K/DCI (4096×2160) in Form eines freien Filmclips. Der exakte Content ist noch nicht bestimmt. Kandidaten wären "Tears of Steel" oder der kommende Blenderfilm "Cosmos Laundromat" bzw. dessen "first cycle". Aus Platzgründen wird wohl nur ein Teil der Filme genutzt werden können.


    Das ganze heißt natürlich bei weitem nicht, daß irgendetwas "fix" wäre!

    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!"

  • "Brauchen" gar keine. Aber wenn möglich, dann halt ein kleiner Launcher mit einem "Start" Button, der im Hintergrund eine .bat Datei ausführt. Im Optimalfall hat der dann auch noch einen Progress Meter bzw. eine Prozentanzeige. Die Anzahl der zu kodierenden Frames wird ja bekannt sein, und eine Fortschrittsanzeige wird auf die Konsole laufend rausgeschrieben, also müßte ein Progress Meter realisierbar sein. Einer für den aktuellen von zwei Passes und einer global. Sofern es wieder 2-Pass wird..

    Einen Cancel-Button kann man auch noch einbauen, der einfach SIGINT oder SIGTERM an den Hintergrundprozeß schickt oder so, damit der Nutzer auch sauber abbrechen kann. Bei Cancel darf es dann auch noch einen Cleanup geben (quasi sowas wie del RESULTS.txt, del *stat*, del *pass*, nur halt programmatisch).

    Aber bevor du hier anfängst was zusammenzuhacken sollte erst Mal das Grundgerüst von meiner Seite aus was gleichschauen. Keine Eile; Ich habe nicht vor hier innerhalb der nächsten paar Monate schon was zu launchen.

    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!"

  • Finde ich im ANchhinein für den X264 auch nicht schlecht. wird ja noch häufig genutzt.
    Könnte man auch gleich anregungen zu ner GUI einholen.
    Eventuell wäre ein auslesen der gebenchten Hardware direkt eingebettet ganz nett.

  • Für den x264bench sicher nicht mehr.

    @Auslesen: Das ist unmöglich. Denk Mal an all die Variablen (also wirklich alle, unbekannte neue CPUs, alte RISC Plattformen auf UNIX, dessen APIs zum Auslesen man erst einmal beherrschen muss, unbekannte Chipsätze, fehlende Interfaces um SPD EEPROMS oder DMI Daten auszulesen usw.). Das kannst vergessen.

    Frage ist: Kann man die GUI so gut statisch bauen/linken, daß man z.B. "eine" x86_32 und "eine" x86_64 Linux Version baut, die dann auf JEDEM (wirklich JEDEM) Linux mit X11 rennt? Ohne weitere Interaktion? BSD? Windows XP x64 bis Windows 10 x64?

    So easy wird's wohl ned. ;)

    (Ich persönlich halte GUI Entwicklung ja für einen ziemlichen Alptraum ;)). Sollte auch nicht im Fokus des Projekts liegen, sondern maximal ein Bonusziel sein. Zudem wäre ein möglichst kleines Binary erstrebenswert, was Diskspace angeht.

    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!"

  • Für den x264bench sicher nicht mehr.

    @Auslesen: Das ist unmöglich. Denk Mal an all die Variablen (also wirklich alle, unbekannte neue CPUs, alte RISC Plattformen auf UNIX, dessen APIs zum Auslesen man erst einmal beherrschen muss, unbekannte Chipsätze, fehlende Interfaces um SPD EEPROMS oder DMI Daten auszulesen usw.). Das kannst vergessen.

    Frage ist: Kann man die GUI so gut statisch bauen/linken, daß man z.B. "eine" x86_32 und "eine" x86_64 Linux Version baut, die dann auf JEDEM (wirklich JEDEM) Linux mit X11 rennt? Ohne weitere Interaktion? BSD? Windows XP x64 bis Windows 10 x64?

    So easy wird's wohl ned. ;)

    (Ich persönlich halte GUI Entwicklung ja für einen ziemlichen Alptraum ;)). Sollte auch nicht im Fokus des Projekts liegen, sondern maximal ein Bonusziel sein. Zudem wäre ein möglichst kleines Binary erstrebenswert, was Diskspace angeht.

    hab hier mal was zusammen gecopy-pasted, vorrausgesetzt wird ein Windows System und die cpuz_x32.exe, das ganze als batch Speichern, die Ausführung dauert ca. 3-5sek:

    Code
    @echo off	cpuz_x32.exe -txt=report            for /f "tokens=6 delims= " %%v in (results.txt) do echo %%v > result.txt	findstr /r /c:"Number of processors" report.txt >> result.txt	findstr /r /c:"Number of cores" report.txt >> result.txt	findstr /r /c:"Number of threads" report.txt >> result.txt	findstr /r /c:"Name" report.txt >> result.txt	findstr /r /c:"Core Speed" report.txt >> result.txt	findstr /r /c:"Mainboard Model" report.txt >> result.txt	findstr /r /c:"Southbridge" report.txt >> result.txt	findstr /r /c:"Memory Size" report.txt >> result.txt	findstr /r /c:"Memory Type" report.txt >> result.txt	findstr /r /c:"Memory Frequency" report.txt >> result.txt	findstr /r /c:"CAS# latency (CL)" report.txt >> result.txt	findstr /r /c:"RAS# to CAS# delay (tRCD)" report.txt >> result.txt	findstr /r /c:"RAS# Precharge (tRP)" report.txt >> result.txt	findstr /r /c:"Cycle Time (tRAS)" report.txt >> result.txt	findstr /r /c:"Row Refresh Cycle Time (tRFC)" report.txt >> result.txt	findstr /r /c:"Command Rate (CR)" report.txt >> result.txt	findstr /r /c:"Windows Version" report.txt >> result.txt    	)

    Die Ausgabe sieht dann schonmal so aus (hier von einem Test PC):

    Da ist dann schonmal alles drin was du brauchst, könnte man natürlich noch etwas schöner machen.

    8 Mal editiert, zuletzt von Grindhavoc (2. Februar 2017 um 15:37)

  • Wenn man was mit GUI macht, dann sollte das unabhaengig sein. Sollte ja auch fuer andere architekturen laufen, wie GAT schon sagte. Und sollte auch unter Windows und Linux laufen. Aber das ist wohl weniger das Problem! Und GAT, notfalls liest man ein paar Informationen ueber den Kernel aus. So schwer ist es jetzt nicht informationen auszulesen.


    Was fuer genaue Hardware informationen braeuchte man denn?

    3 Mal editiert, zuletzt von Harrold (2. Februar 2017 um 17:32)

  • Najo, CPU-Z auf Windows zu nutzen ist schon Mal nicht dumm. Hab mich aber heute selbst auch schon gespielt, und sehr viel läßt sich per wmic über WMI (Windows Management Instrumentation) auslesen. So habe ich jetzt auch schon Checks eingebaut, die vorab prüfen, ob genügend Diskspace und RAM da sind (Diskspace triggered Error, RAM triggered Warning).

    Vorteil ist, daß man im Nachhinein CPU-Z nicht updaten muß. Klar liefert wmic nicht immer supersprechende Daten (Mein Core 2 Quad ist auf XP ein "Pentium III Xeon" :topmodel: ), aber man kann die CUPID auslesen, was immer reicht. Unter Linux werde ich mich auf procfs verlassen, unter FreeBSD auf sysctl. Da wäre es dann vielleicht ganz gut, die komplette RESULTS.txt zu attachen. Aber jo, man kann schon was machen.

    PS.: Fun Fact am Rande; Die cmd shell unterstützt auch als 64-Bit Version nur 32-Bit Arithmetik (weil ich die Shell auch zum Rechnen nutze). Schön schwach! Andere Shells und Interpreter wie Perl ziehen die Arithmetik mit hoch auf 64-Bit wenn man eine x86_64 Version nutzt. Pfh Microsoft... war'n wir wieder zu faul oder was... :rolleyes:

    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!"

  • 1.) Im Prinzip genau dasselbe wie beim x264 Benchmark. CPU Hersteller und Modell ("Intel Core i7-4770K", "AMD FX-9590"), diese Daten müssen auch für noch völlig unbekannte Chips ermittelbar sein. Da das wohl nicht gehen wird, sollten auch alle anderen eindeutigen Identifikationsmerkmale ausgelesen werden (CPUID, Family, Stepping usw.). Auf Windows wahrscheinlich per WMI. Dazu Referenztakt und "Overlock"/"Underclock" Takt wenn möglich. Dazu natürlich Anzahl der Sockel, Kerne und der logischen CPUs (Hyperthreads, SMTs).

    Dann RAM Menge, Typ und Speed und nach Möglichkeit auch Latenzen (48GB DDR-III/1600 CL15, 32GB DDR-IV/2666 15-15-15-30-1T, 16GB DDR-II/667 FBDIMM, 16GB PC800 RDRAM). Da hab ich noch keinen Weg mit Bordmitteln, der von XP x64 bis Win10 durchgängig funktioniert.

    Dann Plattform, also Mainboardhersteller und Modell sowie OEM Systemhersteller und Modell. Auf Windows geht auch das per WMI Calls, soviel weiß ich schon. Was mir noch fehlt ist der Chipsatz, den schlage ich im x264bench Falle auch immer manuell online nach, außer ich weiß es grade auswendig.

    Dann Betriebssystem und ggf. Host OS und Hypervisor. (Windows 7 Pro, Windows 10 Education on VirtualBox/FreeBSD 10.3 UNIX, Gentoo Linux on VMware/Windows 7 Pro).

    Danke erst Mal für den Input. Werde morgen wo Zeit ist ein wenig weiterflicken. Wenn ich Mal ein gewisses Grundgerüst habe, post ich Mal den Code vom Windows Benchmarkskript hier rein. Linux/UNIX folgen später. Windows wird aufgrund der VA Userbase weiterhin im Fokus liegen müssen.

    2.) Im Übrigen habe ich Antwort von einem Entwickler auf der x265 Mailing Liste erhalten. Laut dessen Aussage war x265 bisher in der Lage mit einer Instanz 20-25 Kerne gut auszulasten. Ob das 1080p oder 4K/UHD war, weiß ich aber auch nicht (Je mehr Res, desto parallel). Die neuen, manuellen Tuningknobs für erhöhte Parallelisierung existieren zwar, aber sogar die Entwickler selbst haben keinen Plan von der tatsächlichen praktischen Auswirkung (Frame Slicing, Lookahead Slicing, Lookahead Threading / Dedizierter Lookahead Threadpool mit manuell spezifizierter Threadanzahl). Da muß man auch aufpassen, das gehört perfekt dimensioniert, sonst erzeugt man Flaschenhälse durch Overhead.

    Man hat mich angehalten, Tests durchzuführen, und an die Entwickler zurückzumelden (eigentlich wollte ich ja Testergebnisse oder theoretische Einschätzungen von DENEN haben, uh). Leider ist mir das nicht möglich.

    Eine Testplattform für Kurztests steht mir zwar offen (64 logische CPUs, dank Umlüx). Aber auch das reicht eigentlich nicht. Ich bräuchte jemanden, der einen Shared Memory Cluster mit 512+ Kernen bzw. Hyperthreads zum Test bereitstellen kann. Das wird's wohl eher NICHT spielen... :rolleyes:

    Mal schauen, da rate ich derweil einfach Mal Werte für die Tunables und warte ab.

    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!"