Viel weiter runtertweaken geht halt wirklich nicht mehr, ich bin ziemlich am Ende der Fahnenstange... Man könnte nur angeben, daß Maschinen mit >=32 logischen CPUs auch mindestens 24GB RAM brauchen. 32 is so ein Knackpunkt an dem ich die Threads hochdrehe...
Bedarfserhebung: "Zukunftssicherer" x265 Benchmark
-
Würde ich auch nicht machen. Hinweis dazu, fertig. Das passt mE sehr gut, wie Du das planst.
Rein von der Logik her ist doch davon auszugehen, daß Maschinen die >=16 Threads zeitgleich
abarbeiten auch über ausreichend RAM verfügen, oder?
Ich finde das sogar gut, daß mit steigender Parallelisierung mehr RAM beansprucht wird.
Bedeutet ja, das der Bench etwas skaliert und mächtigere Maschinen auch mehr fordert. Wenn
man das jetzt noch entsprechend dazu digital forcieren könnte.. ein feuchtes Träumchen..
€: @GAT Zeile 85 Size anpassen
-
Hm? Vernebelt mich nur das Bier? Zeile 85 ist SET "ReqDiskSpaceMB=512", das paßt aber. Der Bench sollte unter 512MiB bleiben im Lauf, also auch mit den ganzen temporären Files. Wächst er drüber?!
Oder meinst was anderes? -
Ne, ja, das meinte ich. Erstaunt mich, daß des auch unter 8k passt, bin da von knapp nem GiB ausgegangen.
Ist halt blöde, das ich den nicht regulär in 8k laufen lassen kann :-/ Aber besser mal ein Hinweis und nachfragen,
als sich später mit verstopfter HDD und Fehler plagen.. -
Zitat
| • Submit result (you actually *DO* need to read 2.) for that!) |
| • Seriously, read 2.)! |
| • I MEAN IT! |ZitatIf you cheat, you suck, and people will hate you. You should also hate yourself for that by the way.
Musste das mal als meine beiden Highlights beim Lesen der README.txt herausstellen, sehr schöne Formulierungen.
Aber auch der Rest der Readme ist super verfasst, ganz klar ->
btw. Bob mit der Shotgun auf deiner 403 Seite ist auch lustig, hab ich eben beim Versuch http://xin.at/x265/ aufzurufen zu Gesicht bekommen
Ich nehme mal an, die unter 7a.) erwähnte Seite http://wp.xin.at/x265/index-en.php mit den Unix-Anleitungen ist noch im Bau? -
Ah, da hast du einen Fehler gefunden (und ich finde grade noch ein paar weitere)! Der Link ist falsch. Aber auch der richtiggestellte Link http://www.xin.at/x265/ (statt wp.xin.at) wird dir noch nichts liefern.
Grund ist, daß die Webs nicht "in Arbeit" sind, sie sind schlichtweg komplett inexistent.
Das muß alles erst Mal gemacht werden, aber die Webs baue ich erst so im Laufe der Zeit Mal auf. Und UNIX Anleitungen.. Eh, jo.Nachdem doch die meisten User hier Microsoft Windows verwenden, werde ich die Windows Version zuerst launchen, damit die Sache nicht durch den Bau der UNIX/Linux Version verschleppt wird. Und erst danach werde ich laufend, Stück für Stück mit den unixoiden Systemen anfangen, zuerst Linux, dann FreeBSD, und dann kA. OpenBSD oder sonst was. MacOSX sollte wohl auch irgendwann Mal folgen..
-
Ein aktueller alpha5-Testlauf unter Windows 10:
06:16:29.388 | xxx** | 666psycho | 1/4/8 | Intel Core i7 4790 3,6GHz | MSI H97M Eco | Intel H97 | 20GB DDR3/1600 | Windows 10 x64
Laut Taskmanager lag der Speicherverbrauch insgesamt zwischen 14GB und 15,5GB (für x265 und ffmpeg zusammen), hab da aber nur ab und zu mal kontrollierend drauf geschaut. Passt aber sehr gut in die angepeilte 16GB-Vorgabe würde ich meinen.
Konsolenausgabe:Code
Alles anzeigenlaunch_x265benchmark aufgerufen um 18:11 am 11.03.2017! Prüfe, ob die VC++ 2010 Laufzeitumgebung installiert ist! VC++ 2010 Laufzeitumgebung gefunden, OK Prüfe Betriebssystemarchitektur! AMD64, OK Prüfe freien Speicherplatz auf E:! 640738MiB, OK Prüfe verfügbaren virtuellen Speicher (RAM+Swap)! 24048MiB, OK Prüfe verfügbaren Arbeitsspeicher! 21404MiB, OK Modernes Betriebssystem erkannt (Windows 7 oder neuer), NUMA aktiviert! Verwende modernen x265 Encoder! Verifiziere SHA-512 Prüfsummen! bin\ffmpeg.exe............. OK share\input.h265........... OK launch_x265benchmark.bat... OK sbin\transcoder.bat........ OK bin\x265-NT6.1+.exe........ OK Erzeuge CPU-Z Systemreport im Hintergrund... Starte x265 Benchmark! share\input.h265: 10-bit YUV 4:2:0 HEVC, 8192x3428 [2.40:1], 24.000fps y4m [info]: 8192x3428 fps 24000/1000 i420p10 sar 1:1 unknown frame count raw [info]: output file: .\var\temporary-output\pass1.h265 x265 [info]: HEVC encoder version 2.3+2-912dd749bdb5 x265 [info]: build info [Windows][MSVC 1600][64 bit] 10bit x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2 x265 [warning]: level 8.5 detected, but CTU size 16 is non-compliant x265 [info]: NONE profile, Level-NONE (Main tier) x265 [info]: Thread pool created using 8 threads x265 [info]: Slices : 1 x265 [info]: frame threads / pool features : 3 / wpp(215 rows)+pmode+pme x265 [info]: Coding QT: max CU size, min CU size : 16 / 8 x265 [info]: Residual QT: max TU size, max depth : 16 / 3 inter / 3 intra x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4 x265 [info]: Keyframe min / max / scenecut / bias: 24 / 250 / 40 / 5.00 x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2 x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1 x265 [info]: References / ref-limit cu / depth : 6 / off / on x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.0 / 16 / 1 x265 [info]: Rate Control / qCompress : ABR-10000 kbps / 0.75 x265 [info]: tools: rect amp limit-modes rd=6 rdoq=1 psy-rdoq=5.00 rskip x265 [info]: tools: signhide tmvp b-intra lslices=2 deblock stats-write x265 [info]: frame I: 6, Avg QP:35.35 kb/s: 33247.23 x265 [info]: frame P: 149, Avg QP:37.24 kb/s: 17577.73 x265 [info]: frame B: 645, Avg QP:40.60 kb/s: 8232.72 x265 [info]: Weighted P-Frames: Y:0.7% UV:0.7% x265 [info]: Weighted B-Frames: Y:1.6% UV:1.2% x265 [info]: consecutive B-frames: 9.0% 4.5% 5.2% 13.5% 20.6% 26.5% 4.5% 10.3% 5.8% encoded 800 frames in 11439.66s (0.07 fps), 10160.84 kb/s, Avg QP:39.94 Pass 1 erledigt, starte Pass 2: y4m [info]: 8192x3428 fps 24000/1000 i420p10 sar 1:1 unknown frame count raw [info]: output file: .\var\temporary-output\pass2.h265 x265 [info]: HEVC encoder version 2.3+2-912dd749bdb5 x265 [info]: build info [Windows][MSVC 1600][64 bit] 10bit x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2 x265 [warning]: level 8.5 detected, but CTU size 16 is non-compliant x265 [info]: NONE profile, Level-NONE (Main tier) x265 [info]: Thread pool created using 8 threads x265 [info]: Slices : 1 x265 [info]: frame threads / pool features : 3 / wpp(215 rows)+pmode+pme x265 [info]: Coding QT: max CU size, min CU size : 16 / 8 x265 [info]: Residual QT: max TU size, max depth : 16 / 3 inter / 3 intra x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4 x265 [info]: Keyframe min / max / scenecut / bias: 24 / 250 / 40 / 5.00 x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2 x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1 x265 [info]: References / ref-limit cu / depth : 6 / off / on x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.0 / 16 / 1 x265 [info]: Rate Control / qCompress : ABR-10000 kbps / 0.75 x265 [info]: tools: rect amp limit-modes rd=6 rdoq=1 psy-rdoq=5.00 rskip x265 [info]: tools: signhide tmvp b-intra lslices=2 deblock stats-read x265 [info]: frame I: 6, Avg QP:34.76 kb/s: 42079.10 x265 [info]: frame P: 149, Avg QP:37.39 kb/s: 17593.10 x265 [info]: frame B: 645, Avg QP:40.72 kb/s: 8136.38 x265 [info]: Weighted P-Frames: Y:1.3% UV:1.3% x265 [info]: Weighted B-Frames: Y:0.3% UV:0.2% x265 [info]: consecutive B-frames: 9.0% 4.5% 5.2% 13.5% 20.6% 26.5% 4.5% 10.3% 5.8% encoded 800 frames in 11145.25s (0.07 fps), 10152.26 kb/s, Avg QP:40.06 Schreibe Systembericht in .\RESULTS.txt... Multiplexe Ausgabe zu MKV Videocontainerdatei '.\var\temporary-output\output.mkv' für Wiedergabetests... OK Die ungefähre Abschlußzeit war 00:28 am 12.03.2017. Die temporären Dateien in '.\var\temporary-output\' können nach Wunsch gelöscht werden. Das Ergebnis kann nun aus der Datei '.\RESULTS.txt' ausgelesen werden! Drücken Sie eine beliebige Taste . . .**Für den Basisfaktor 1.00 würde ich den ersten 64-Bit Endkunden-Prozessor vorschlagen -> Athlon64 3000+ müsste das ja gewesen sein (analog zum ersten SSE-fähigen Prozessor beim x264 in Form des PIII 450).
Mit Sockel 754 oder 939 und DDR1 RAM dürfte es allerdings schwierig werden, auf die 16GB RAM zu kommen, daher könnte ich den Wert mit einer entsprechenden AM2 Plattform liefern, sobald ich eine passende CPU hab. Die paar Euro würd ich da aber auf jeden Fall mal dafür ausgeben, wenn man sich einig ist, dass es die passende CPU wäre. 16GB DDR2 in Form von 4x4GB Samsung Modulen für mein Gigabyte nforce570 AM2+ Board sind vorgestern hier eingetrudelt
-
Also ddr1 RAM ist kein Problem ich hab 8x 4gb ddr1 reg ECC liegen. Allerdings brauche ich eine CPU die damit auf dem 939 zurecht kommt. Ich hab Giovannies altes system da. Das werde ich mit sicherheit durchjagen.
-
Allerdings finde ich eine Spitze von 15.5GB fast noch ein wenig haarig mit "nur" 8 Threads. Vielleicht kapp ich noch 2 B-Frames weg, bevor wir eine Referenz definieren...
Würde auch vorher gern noch auf das neueste x265 updaten. Wobei, das mache ich ganz am Ende vor Launch vielleicht sowieso noch. Aber das sind Feinheiten. Ich geh jetzt Mal davon aus, daß wir feature complete sind, damit wird die nächste Version eine Beta 1.
...was natürlich nicht heißt, das "feature complete" auch wirklich stimmt, kennt man ja von diversen anderen Betas
. Aber es müßte halbwegs passen jetzt. -
Ich hab das fuck WMI endlich raus. Jetzt ist es in C++ nur arsch lahm. Mal sehen ob ich das optimieren kann. Aber so langsam mach ich da progress!
-
Ich hab mir das so gedacht, das ich ein paar generelle checks laufen lasse und solange die nicht fertig sind, kann man den Benchmark nicht starten. Wenn man jetzt ein paar HW informationen auslesen will, kann das eine Minute dauern oder so.
-
Ja. Könnte man auch machen. Ich rede allerdings von meinem hwinfo Fenster um generelle Informationen von der Hardware auszulesen. Also auch RAM, wenn möglich auch Timings und so.
-
hier meine durchläufe der alpha5
einmal mit der kleinen (8vCPU, 16GB) und einmal mit der großen (64vCPU, 32GB) maschine -
Bei der Entwicklung des x265 Benchmarks wurde ein Bug in x265, in den Checks der Option --slices aufgedeckt, der dazu führen konnte, daß x265 a.) mit Segmentation Fault abstürzt (Linux) oder b.) in einem unkillable Deadlock einfriert (BSD) oder c.) ohne Fehlercoderückgabe terminiert (Windows), sobald man zuviele Slices definiert (>16). Grund war ein falscher Check in x265, maxSlices wurde hier gegen numRows anstatt gegen slicesLimit getestet.
Der Fehler wurde an die x265 Entwickler zurückgemeldet und mittlerweile gibt es einen [Patch], der das Verhalten korrigiert. Damit steht auch fest, daß die x265 Version des Benchmarks unbedingt noch aktualisiert werden muß.
Versucht man jetzt, mehr Slices zu definieren, meldet sich x265 korrigierend zu Wort:
Codex265 [warning]: maxSlices can not be more than min(rows, MAX_NAL_UNITS-1), force set to 15 x265 [info]: Slices : 15Damit wird das bisherige maximal stabile Limit von --slices 16 auf --slices 15 reduziert, so wie im Code angegeben. Der Entwickler Chen Min begründet das wie folgt:
Zitat von Chen MinI made a restrict on count of slices because we have limited number of output NAL buffers.
Every slices need a independent NAL, but the SPS/PPS/VPS will also allocate at least one of NAL, so I made slices limit to (MAX_NAL_UNITS - 1)
Yay, wir konnten dazu beitragen, einen Fehler im x265 Encoder aufzudecken!Eine gefixte Version wird mit der Beta ausgeliefert.
-
Sodalla, der Bootstrapper ist eigentlich das weitaus präsentierenswertere, aber der erzeugt (durch's C/C++ Kompilieren) soviel Textausgabe, daß er sich nicht herzeigen läßt. Da er aber zumindest grundlegend funktioniert, habe ich auch mit dem Benchmarkskript begonnen. Es ist wirklich NICHT leicht, all die Unterschiede der verschiedenen Unices und auch von Linux sauber abzudecken und wirklich portabel zu scripten... Vieeele Weichen braucht es, speziell auch beim Auslesen der Systeminfos, das geht quasi überall völlig anders, andere Tools, andere Interfaces, andere Outputs, uah... Aber zumindest das geht Mal überall, hier zu sehen auf Linux, FreeBSD UNIX, OpenBSD UNIX und Sun / Oracle Solaris:
[Blockierte Grafik: http://www.xin.at/x265/files/worklog/development/UNIX/prealpha1/prealpha1-linux.png]
x265 Benchmark Systemanalyse, Linux (Klicken zum Vergrößern)[Blockierte Grafik: http://www.xin.at/x265/files/worklog/development/UNIX/prealpha1/prealpha1-freebsd.png]
x265 Benchmark Systemanalyse, FreeBSD UNIX (Klicken zum Vergrößern)[Blockierte Grafik: http://www.xin.at/x265/files/worklog/development/UNIX/prealpha1/prealpha1-openbsd.png]
x265 Benchmark Systemanalyse, OpenBSD UNIX (Klicken zum Vergrößern)[Blockierte Grafik: http://www.xin.at/x265/files/worklog/development/UNIX/prealpha1/prealpha1-solaris.png]
x265 Benchmark Systemanalyse, Sun / Oracle Solaris (Klicken zum Vergrößern)Hier hat er allerdings nicht encoded, weil der Teil für schnelle Tests deaktiviert war. Das Bootstrapping und das Laufenlassen des Tests funktioniert derweil auf Linux und FreeBSD, OpenBSD kommt als nächstes, und Solaris wohl gar nie so wie das ausschaut mit diesem Fuck-OS!
Ist Mal eine nette Abwechslung, aber demnächst werde ich das Windows Trumm Mal in die Beta schicken.
Edit: Und jo, die Bitness Abfrage auf OpenBSD is broken, irgendein Shit mit der Shell...
-
Noch ein Testlauf:
34:47:35.585 | xxx | 666psycho | 1/4/4 | AMD Opteron 1352 2,1GHz | Gigabyte M57SLI-S4 Rev 2.0 | nvidia nforce570SLI | 16GB DDR2/800 | Windows 7 x64
Konsolenausgabe und Results.txt im Anhang.
Dürfte von der Laufzeit her ungefähr das sein, was man sich so vorgestellt hat, oder? Ist immerhin einer der ältesten und lahmsten Quadcores (entspricht ca. einem 1er Phenom 9500).
Was RAM-Verbrauch angeht hab ich mal ein paar Screens gemacht und das passt aus meiner Sicht, da muss nix mehr optimiert werden:
nach 75 Minuten ca. 14,4GB:
[Blockierte Grafik: https://abload.de/thumb/75min_opteron1352_win1wsv2.png]nach 10h ca. 14,8GB:
[Blockierte Grafik: https://abload.de/thumb/10h_opteron1352_win7krst1.png]nach 17h / kurz vor Ende pass 1 caq. 13,7GB:
[Blockierte Grafik: https://abload.de/thumb/17h_opteron1352_win7hvszy.png]Pass 2 braucht generell weniger RAM:
nach 21h ca. 13,3GB:
[Blockierte Grafik: https://abload.de/thumb/21h_opteron1352_win7opstn.png]13,5GB nach 24h:
[Blockierte Grafik: https://abload.de/thumb/24h_opteron1352_win7h7skz.png]13,8GB nach 32,5h:
[Blockierte Grafik: https://abload.de/thumb/32_5h_opteron1352_winy9sjm.png]Und der Check, ob vcredist 2010 installiert ist funktioniert auch (ist ja beim frisch installierten Win7 nicht dabei):
[Blockierte Grafik: https://abload.de/thumb/vc2010missingefs6z.png] -
Ah, super, vielen Dank! Da sind wir ja schon ziemlich nahe am untersten Ende des Spektrums? Wer einen Dualcore reinschickt, ist selber schuld!
OpenBSD UNIX und Solaris gebe ich übrigens in dieser Phase auf, um die Entwicklung der UNIX/Linux Version zu beschleunigen. Mit dem Portieren kann ich mich ja auch später noch rumschlagen. Linux und FreeBSD sollen fix out-of-the-box laufen. Jetzt bräuchte ich nur noch irgendwie ein modernes MacOS X.. Meine Hackintosh VM is schon recht veraltet.. hm.
Auf Windows habe ich bald die Beta 1 fertig, da habe ich nur noch eine Winzigkeit eingebaut: Der Decoder soll normal laufen, der Encoder (also x265 selbst) aber mit "Below Normal" Priorität. Das soll sicherstellen, daß der Encoder den Decoder auch in Extremfällen nicht durch CPU Hogging aushungert. Das sollte normal nicht passieren können, aber bei SEHR schnellen (=viele Kerne meine ich) künftigen Maschinen bin ich mir da nicht so sicher.
Aktuell wird auch gerade ein neues Quellvideo erstellt, um dem durch den Benchmark aufgedeckten x265 Bug bzw. dessen Fix zu entsprechen (--slices 16 -> --slices 15). Das Video ist ansonsten identisch zum bereits ausgelieferten, aber der Bug gehört sauber entfernt, auch aus dem Video selbst.
Alle denkbaren Windows Konfigurationen lassen sich natürlich nicht durchtesten, und durch die erhöhte Komplexität im Vergleich zum x264 Bench ist eine Fehleranfälligkeit wahrscheinlicher.. Aber ich denke, grobe Schnitzer sollte es wohl keine mehr geben, also...
Danke für's Testen!
Mit der Beta sollte es hoffentlich recht flott gehen, da wird - so Gott hilf - nur noch nachpoliert.