So, ich hab' Quelle und Benchmarktool neu gezogen, die hier benutzte Festplatte komplett neu partitioniert, ein anderes Betreibssystem installiert (WinXP x64) und alle verfügbaren Updates installiert. Immernoch der gleiche scheiß Fehler. Die Prüfsumme hab' ich jetzt nicht verglichen, aber trotzdem: Läuft der Benchmark in der aktuellen Version bei Euch wirklich noch ohne diese Fehlermeldung durch? Kann eigentlich kaum sein.
x264 Benchmark (kein Schnelldurchgang! 32-Bit multicore und ≥1GB RAM)
-
-
Ich hab Mal alles gelöscht (weil ich ja mit dieser OpenCL Version rumgespielt hatte) in meinem x264benchmark Folder. Grade von meinem eigenen Server alles neu gesaugt, und ich schick meinen Hexcore Mal rein. Ich seh zwar nicht wo jetzt ein Unterschied sein soll, aber beobachten wir Mal...
Edit:
[Blockierte Grafik: http://www.xin.at/thrawn/pics/screenshots/x264/x264-noproblems.png]
Konnte es nicht reproduzieren.
-
Du hast es doch auch: "skip: 27.2%" ... "skip: 45.0%" und "skip: 27.0%" ... "skip: 43.6%"
Das gab's doch früher nicht, oder sehe ich das falsch? Die Frage ist ernst gemeint.Edit: Noch so ein Bench mit 'Skips':
007:37:56.812 | SK1 | 1/2/2 | AMD Athlon64 X2 6000+ EE (3 GHz Standard) | MSI MS-7312 | 3,5 GB DDR2 / 800 | Windows XP x64 SP2 -
Das Frames übersprungen werden leuchtet ein, denn es könnten Standbilder oder auch Frames mit sehr wenig Bewegung drin sein. Wichtig ist aber, das GATs PC alle Frames bearbeitet hat - dein PC tat dies nicht.
-
Diese "Skip" Ausgabe hat aber nichts mit übersprungenen Frames zu tun, sondern mit der Motion Compensation (spezieller: Im Macroblock Tree Code, Bewegungsvektoren). [Erklärung dazu ist hier zu finden].
Das ist also normal, sowas wird man in der Ausgabe immer finden, wenn man Macroblock Trees verwendet (was der Bench auch tut bzw. immer schon getan hat).
Wichtig hingegen ist, daß zweimal dasteht, daß 15691 Frames encoded wurden, wie CryptonNite schon sagt. Das tut er bei dir aus Gründen nicht, die ich noch nicht verstehe...
Edit: Ok, versuchen wir dem auf den Grund zu gehen. Zuerst eine Prüfsummenprüfung. Ich habe dir ein Paket mit sha1sum.exe zusammengestellt (Binary und DLLs entstammen dem CygWin Projekt). [Download von sha1sum].
Das ZIP entpackst und kopierst die Files einfach in den x264 Benchmark Folder. Dort gehst dann mit der cmd Shell rein, und führst einfach 'sha1sum *' aus. Hier meine Ausgabe vom funktionierenden Bench (die neuen DLLs hat er halt auch mit geprüft jetzt, macht ja nichts):
Code
Alles anzeigen201ecc0aa4c4f6aa9653b1c1c6111156c80e83fe *FFMS2.dll 5f4834c86feec3735f96a5f7830b3a11033868ed *cyggcc_s-1.dll 54f0bf02166ec7c3e205c05ec70e3a55fc5ef535 *cygiconv-2.dll 6cbc9f444209528570f2cbd35c6b3e3a788d85a9 *cygintl-8.dll 5a9ad3cd458a921a8c735e9ee110ff38f030f471 *cygwin1.dll c01a9ab76dfe267a50998280ec3800049ca68a4b *elephantsdream_source.264 80763b669a8c77bcc0701b7fd8c4451e015d50f9 *encode dce2e8fc2ee517d965db9f723f496cd2b74ecdd1 *grep.exe aab193126bf29ac23dd04e8d70afd15c55a29faf *launchbenchmark.bat 0f73d47122080a0c5c423841b16f4e6c62d79aff *libiconv2.dll 192e597d8ff0192f6c4e4643361f84277ed51121 *libintl3.dll 6eafcc2fdfdf73abea334ac7afb903829f6ff2a6 *msvcp60.dll 457e209ab441abb501dc3bf20557b748719b8bb1 *pcre3.dll e532e5a3e74926f6a750b3a80d3ea232dd251e4a *regex2.dll 9f37172011c66c3d5e35bc87ee1cf23c988743ce *sha1sum.exe 7214d9cd8488ff4a13ab86e33e1c279803094d92 *timethis.exe e089f8e5c21a1821c9e8df52f9be458b6908c4a4 *x264.exe 0c108c80962e68a9d0768258e2016bdb83f35fe8 *x264benchmark.zip
Mal sehen, ob da was abweicht. -
Die Prüfsummen von *elephantsdream_source.264, *encode, *grep.exe, *launchbenchmark.bat, *timethis.exe und *x264.exe sind absolut gleich. Ich kriech 'ne Krise. [Blockierte Grafik: http://www.supernature-forum.de/smiley/smileys/member/quhno/kotz.gif]
Außer natürlich, dass das "skip", welches mir zumindest früher nicht aufgefallen ist, wirklich "normal" sein sollte. Die Anzahl der gerenderten Frames müsste beim letzten System (6000+) ungefähr gestimmt haben, ich hab' ihm ja dann und wann zugesehen und der erste pass müsste zumindest irgendwas über 15.000 frames (15.691???????) gehabt haben, wäre also plausibel.
-
Nochn Test, es ist egal wo ich's probier, es klappt, alles mit frischem File:
[Blockierte Grafik: http://www.xin.at/thrawn/pics/screenshots/x264/x264-noproblems-linux.png]
Mir gehn die Ideen aus...
-
-
[Blockierte Grafik: http://www.umluex.at/bilder/bench_me_1.jpg]
er läuft, zeigt aber bei den cpu capabilities kein SSE an? stimmt das so oder ist das fürn hugo?
-
Er zeigt MMX2 an, was eine Teilmenge des SSE Befehlssatzes ist, der auf dem Athlon XP existiert. Das scheint mir ok zu sein, laut Sourcecode verwendet x264 auch auf Intel den selben Satz an Instruktionen, und schreibt nur SSE hin, scheint mir ein rein kosmetischer Unterschied zu sein.
Edit: lol, ich Trottl, er zeigt eh auf meinem i7 auch nur MMX2 an. Kein Grund zur Sorge also.
-
seems legit? basst!
dann geht das MEisterhafteste aller betriebssysteme weiter seiner ungeheuer wichtigen arbeit nach! -
Bitte auf dem Me - System noch andere WinDOSen installieren und benchen!
[Blockierte Grafik: http://img818.imageshack.us/img818/7671/unbenanntxy.gif]
07:28:20.125 | SK1 | 1/2/2 | AMD Athlon64 X2 6000 (3 GHz Standard) | (scheiß) MSI MS-7270 | 3 GB DDR2 / 800 | Windows XP x64 SP2
@GAT: Wenn das legitim ist und immer so angezeigt werden muss, dann habe ich mich wohl fatal geirrt und sinnlos für Verwirrung gesorgt. Entschuldige in diesem Fall bitte. Kannst dann auch http://voodooalert.de/board/index.ph…6806#post336806 nachtragen.
Edit: Der Fehler bezieht sich dann nämlich nur auf die beiden Win98 SE - Systeme mit dem wenigen RAM!
-
encoded 15691 frames in beiden passes.
sieht doch gut aus! -
Jawohl, sauberes Ergebnis! Das heißt nur der Encode mit dem Abbruch bei 1201 Frames ist fehlerhaft. Zum Glück, ich dachte schon wir müssen hier noch auf Geisterjagd gehen.
Edit: SK1, Ergebnisse sind jetzt drin!
-
Hallo GAT
kann man nicht mal eine AGP 2x Selection mit in die Ergebnissliste mit einbauen?
Gerade wieder Aktuell hier in dem Thread währe sowas sehr praktisch. Das raussuchen der bestehenden Ergebnisse nach AGP 2x Kompatibiliät würde ich auch machen -
Nein, abgelehnt.
Begründung: AGP ist für den Test einfach irrelevant, dafür modifiziere ich nicht die Datenbank. Das ist so als würde man danach fragen ob man nicht alle Boards rausfiltern könnte, die einen 3Com Netzwerkchip haben, oder alle Rechner mit Soundblaster 16.
Ob ein Prozessor AGP1x, 2x, 4x oder 8x auf der darunterliegenden Platine hat, ist für die Leistung des Tests nicht von Belang. Sinniger wäre eine Sortierung nach Chipsatz (der sehr wohl eine Auswirkung hat), was aber bei aktuellem Stand ebenfalls ziemlich aufwendig werden würde.
Edit: Gäbe auch noch andere Szenarien, die ich vermeiden möchte, wie z.B. Sortierung nach Merkmalen wie "Board hat einen ISA-Slot" o.ä...
-
Ja ok
irgendwie schon verständlich, wird vielleicht sonst irgendwann zu unübersichtlich....
Aber ich habe mal eben einen Thread erstellt der zumindest jeweils die Top 5 Ergebnisse von singel und multi Thread Systemen zusammenfasst. Eventuell werde ich denn noch erweitern, aber die Top 5 sind ja schon mal nicht schlecht
-
...und der siebente Engel vergoss seine Schale in den Äther, und eine Stimme rief herab vom Himmel und sagte: 'Es ist getan'
025:38:23.340 | Umlüx | 1/1/1 | AMD Athlon XP 3000+ | 1GB DDR/400 | Asus A7N8X | Windows ME
-
...und der siebente Engel vergoss seine Schale in den Äther, und eine Stimme rief herab vom Himmel und sagte: 'Es ist getan'
Depp! rofl. Ich geh Mal eintragen. Scheinbar ist Me ned so direkt eine Rakete in diesem Zusammenhang.Edit: Drin! Jetzt muß ich wohl das Betriebssystemstatistikskript noch anpassen, damit er das korrekt den Win9x Systemen zuordnet.
-
[Blockierte Grafik: http://img594.imageshack.us/img594/9845/x264fehlerwin95.gif]
Marmelade.
Kann aber auch daran liegen, dass ein Pentium 60 noch kein SSE hat.
-