Sie sind nicht angemeldet.

  • »GrandAdmiralThrawn« ist der Autor dieses Themas

Beiträge: 12 607

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

Beruf: UNIX Administrator

  • Nachricht senden

201

Freitag, 10. März 2017, 19:34

RAM

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...

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!

202

Freitag, 10. März 2017, 20:03

tweaken

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.. :spitze:

€: @GAT Zeile 85 Size anpassen ;)

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »styvi« (10. März 2017, 20:08)


  • »GrandAdmiralThrawn« ist der Autor dieses Themas

Beiträge: 12 607

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

Beruf: UNIX Administrator

  • Nachricht senden

203

Freitag, 10. März 2017, 21:03

Size

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?

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!

204

Freitag, 10. März 2017, 21:52

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.. ;)

205

Samstag, 11. März 2017, 10:39

README.txt

Zitat


| • Submit result (you actually *DO* need to read 2.) for that!) |
| • Seriously, read 2.)! |
| • I MEAN IT! |


Zitat

If 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 -> :thumbsup:


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 :spitze:
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?

  • »GrandAdmiralThrawn« ist der Autor dieses Themas

Beiträge: 12 607

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

Beruf: UNIX Administrator

  • Nachricht senden

206

Samstag, 11. März 2017, 11:16

Bünsch

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..

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!

207

Sonntag, 12. März 2017, 01:29

Alpha5

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:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
launch_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 :D
»666psycho« hat folgende Datei angehängt:

208

Sonntag, 12. März 2017, 02:12

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.

Verbraucht mehr Bandbreite:

mein FTP
z7t.de ist oben ;)

  • »GrandAdmiralThrawn« ist der Autor dieses Themas

Beiträge: 12 607

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

Beruf: UNIX Administrator

  • Nachricht senden

209

Sonntag, 12. März 2017, 10:07

B

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 :rolleyes:. Aber es müßte halbwegs passen jetzt.

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!

210

Sonntag, 12. März 2017, 14:15

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!

  • »GrandAdmiralThrawn« ist der Autor dieses Themas

Beiträge: 12 607

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

Beruf: UNIX Administrator

  • Nachricht senden

211

Sonntag, 12. März 2017, 14:56

WMI

Es is eh beim CLI Aufruf per wmic auch lahm. Auf'm Terminal stört das halt nicht so, weil da kann der Nutzer lustig dabei zusehen, wie die Checks durchrennen. Aber vielleicht kannst das bei der GUI so lösen, daß du einzelne Calls in Threads auslagerst und parallel ausführst? Und launchen kann der Nutzer erst wenn alle Checks durch sind, vorher Button grau oder so?

Oder du machst auch so ein Feld in die GUI, wo man die Checks durchlaufen sieht?

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!

212

Sonntag, 12. März 2017, 15:03

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.

  • »GrandAdmiralThrawn« ist der Autor dieses Themas

Beiträge: 12 607

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

Beruf: UNIX Administrator

  • Nachricht senden

213

Sonntag, 12. März 2017, 15:25

HW

Uh... eine Minute? Das is schon heftig.. Weil die HW Infos müssen ja auch in die RESULTS.txt rein, von WMI und CPU-Z...

Wobei... Die HW Infos (ein paar davon zumindest) könntest du NACH dem Benchmark holen, und es für den Nutzer so aussehen lassen, als liefe der Test noch. Weil ob der 8 Stunden rennt oder 8 Stunden und eine Minute fällt an dem Punkt ja nicht mehr ins Gewicht.

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!

214

Sonntag, 12. März 2017, 18:50

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.

Umlüx

Pulse Gun

Beiträge: 125

Wohnort: Kärnten

Beruf: Sysadmin

  • Nachricht senden

215

Montag, 13. März 2017, 09:33

hier meine durchläufe der alpha5
einmal mit der kleinen (8vCPU, 16GB) und einmal mit der großen (64vCPU, 32GB) maschine
»Umlüx« hat folgende Dateien angehängt:
  • CMD_8.txt (4,98 kB - 0 mal heruntergeladen)
  • CMD_64.txt (5,2 kB - 1 mal heruntergeladen - zuletzt: 17. März 2017, 12:30)
  • RESULTS_8.txt (2,49 kB - 1 mal heruntergeladen - zuletzt: 17. März 2017, 12:31)
  • RESULTS_64.txt (3,56 kB - 1 mal heruntergeladen - zuletzt: 17. März 2017, 12:31)

  • »GrandAdmiralThrawn« ist der Autor dieses Themas

Beiträge: 12 607

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

Beruf: UNIX Administrator

  • Nachricht senden

216

Dienstag, 14. März 2017, 14:43

UNIX

Habe unterdies nebenher doch mit dem Bau der Linux/UNIX Version begonnen (um Mal was anderes zu machen). Entwickelt wird auf CentOS 6.8 Linux, getestet wird auf selbigem und auch auf FreeBSD 10.3 UNIX. Ziel ist es, das Skript so portabel wie möglich zu machen. Auch der x265 Quellcode wird ein wenig angepaßt, um ein bißchen besser mit UNIX umzugehen.

Aktuell bin ich am Bau eines "Bootstrappers", der erst Mal einige Abhängigkeiten prüft und dann die für den Benchmark benötigte Software automatisch von beiliegenden Quellen baut und in den Benchmark integriert. Momentan sehe ich zu, daß das für alle Teilkomponenten sowohl mit GCC als auch mit clang Platform Compilern funktioniert (Klappt aktuell bereits). clang GCC wird präferiert - ist er nicht im Suchpfad vorhanden, so wird auf GCC clang zurückgegriffen. Der Intel C Compiler wird nicht unterstützt.

Die Idee ist es, den Benchmark durch Aufruf von `$ ./bootstrap.sh´ zu bootstrappen, das dauert halt einige Minuten. Zuerst gibt es nur dieses eine Skript. Danach sollen die Binaries fertig gebaut bereitliegen (mediainfo, ffmpeg, x265), in perfekt auf den Benchmark zugeschnittener Form. Auch das launch_x265benchmark.sh und andere Skripte sollen dann fertig bereitliegen, und die Prüfsummen werden erzeugt.

Ist der Benchmark einmal bootstrapped, soll man ihn auf jede identische Zielmaschine (also mit gleichem UNIX oder Linux Betriebssystem) kopieren und direkt ausführen können. Zudem werde ich zusehen, system- oder linzenzabhängige Dinge wie etwa die GNU bash so weit es halt geht zu meiden, sodaß der Test z.B. auch mit einer klassischen /bin/sh UNIX Shell läuft, ohne Bash Specifics.

Wichtig war mir auch, keine Software systemweit zu installieren, so wie ich es beim x264 Benchmark bisher gefordert hatte. Alle Tools sollen mit reinen Benutzerrechten bauen und innerhalb des Benchmarkverzeichnisses verbleiben - so werden keine root-Rechte mehr gefordert, und es sinkt die Wahrscheinlichkeit, systemweite Komponenten durch die Installation des Benchmarks zu beeinträchtigen.

Das geht alles gar nicht Mal so katastrophal schlecht wie gedacht...

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 3 mal editiert, zuletzt von »GrandAdmiralThrawn« (14. März 2017, 15:27)


  • »GrandAdmiralThrawn« ist der Autor dieses Themas

Beiträge: 12 607

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

Beruf: UNIX Administrator

  • Nachricht senden

217

Mittwoch, 15. März 2017, 08:09

x265

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:

Source code

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


Damit 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:

Quoted from "Chen Min"

I 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! :D

Eine gefixte Version wird mit der Beta 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« (15. März 2017, 08:13)


  • »GrandAdmiralThrawn« ist der Autor dieses Themas

Beiträge: 12 607

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

Beruf: UNIX Administrator

  • Nachricht senden

218

Freitag, 17. März 2017, 14:42

x265

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:


x265 Benchmark Systemanalyse, Linux (Klicken zum Vergrößern)


x265 Benchmark Systemanalyse, FreeBSD UNIX (Klicken zum Vergrößern)


x265 Benchmark Systemanalyse, OpenBSD UNIX (Klicken zum Vergrößern)


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! :spitze:

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... ;(

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« (17. März 2017, 14:45)


219

Montag, 20. März 2017, 18:25

Alpha5

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:


nach 10h ca. 14,8GB:


nach 17h / kurz vor Ende pass 1 caq. 13,7GB:


Pass 2 braucht generell weniger RAM:
nach 21h ca. 13,3GB:


13,5GB nach 24h:


13,8GB nach 32,5h:



Und der Check, ob vcredist 2010 installiert ist funktioniert auch (ist ja beim frisch installierten Win7 nicht dabei):
»666psycho« hat folgende Dateien angehängt:

  • »GrandAdmiralThrawn« ist der Autor dieses Themas

Beiträge: 12 607

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

Beruf: UNIX Administrator

  • Nachricht senden

220

Montag, 20. März 2017, 22:00

CLI

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

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. :)

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!