x265 Benchmark (kein Schnelldurchgang! 64-Bit manycore und ≥12GB RAM)

1.) Intro und Ergebnisliste:

Willkommen zum Voodooalert x265 Benchmark, einem plattform- und betriebssystemübergreifenden Benchmarkprojekt zur Stabilitätsverifikation und für's Benchmarking von modernen 64-Bit Rechnern für Microsoft® Windows NT®, UNIX® (Auch Apple® macOS®/MacOS® X), Linux® und Haiku® OS. Eine Warnung vorweg: Dieser Test ist kein Schnelldurchgang, siehe Ergebnisliste!

x265 Benchmark Ergebnisliste

Hinweis: Der Zugriff auf die Ergebnisliste per HTTPS:// funktioniert nur mit älteren und ggf. mit entsprechend konfigurierten Web Browsern. Wenn man Fehlermeldungen in Bezug auf die Verschlüsselung und/oder Sicherheit der Webseite erhält, bitte einfach auf unverschlüsseltes HTTP:// wechseln.

2.) Download

Der 64-Bit VA x265 Benchmark in seiner aktuellsten Version für UNIX (inkl. macOS)/Linux/Haiku OS (~230 MiB):

• Mirror 0: [x265 Benchmark 0.4.0-r0] (Mirror hosted von [GAT], ~900 kiB/s)
• Mirror 2: [x265 Benchmark 0.4.0-r0] (Mirror hosted von [Blacktron], ~100 MiB/s)

Der 64-Bit VA x265 Benchmark in seiner aktuellsten Version für Microsoft Windows (~237 MiB):

• Mirror 0: [x265 Benchmark 0.5.0-r20] (Mirror hosted von [GAT], ~900 kiB/s)
• Mirror 2: Noch nicht aktualisiert (Mirror hosted von [Blacktron], ~100 MiB/s)

Danke an Torsten für das Melden des CMD @ Windows 11 Fehlers und für die Unterstützung bei der Fehlersuche. Gleichermaßen geht auch Dank an Maniac81 für das Melden der Inkompatibilität des Tests mit Windows 11 24H2 und an Matias für Release Candidate Tests.

SHA-512 Prüfsummen für die aktuellste Version (UNIX: 0.4.0-r0, Win64: 0.4.0-r0) , nachprüfen mittels [sha512sum] (Win64) Tool möglich:

• UNIX: 266c3ef43f82b2e97d568ced4e64dbc6de8774074ee1499f07bd738264944b255c2cc7fb5ee42d6cdc819152c2b215eb840d2051c74d2a2fc293c1880fa08ab8 UNIX/x265benchmark-0.4.0-r0-2021-10-09.tar.xz
• Win64: b319576530c0857457c6b90a9854244f79c47d7235b73177b336df9407c77d7f14f3efeca3ba368a4742577b2d4fe286e4737ab68e865e3911152637d484ec3c *win64\\x265benchmark-win64-0.5.0-r19.7z

Ältere Versionen:

• Win64 [Mirror 0] x265 Benchmark 0.4.0-r0
• Win64[Mirror 0] x265 Benchmark 0.3.1.2-r5
• UNIX[Mirror 0] x265 Benchmark 0.3.1-r3
• Win64[Mirror 0] x265 Benchmark 0.3.1.2-r4
• UNIX[Mirror 0] x265 Benchmark 0.3.1-r2
• Win64[Mirror 0] x265 Benchmark 0.3.1.2-r3
• Win64[Mirror 0] x265 Benchmark 0.3.1.1-r2
• [Win64] x265 Benchmark 0.3.1 (Release #2)
• [UNIX][Win64] x265 Benchmark 0.3.0 (Release #1)
• [UNIX][Win64] x265 Benchmark 0.2.6 / b6 rc1 (Beta 6)

Noch ältere (Entwicklungs)versionen im [ursprünglichen Thread] zur Bedarfserhebung und Entwicklung.

Die Änderungen von Version zu Version sind einen Beitrag weiter unten angeführt.

3.) Wie startet man das?

Hinweis: Der Benchmark ist bitte in einer solchen Art und Weise zu betreiben, daß er von anderen Programmen nicht übermäßig in Speicher und CPU Zeit beeinträchtigt wird, sodaß das Ergebnis nicht langsamer ausfällt, als für die Maschine zu erwarten (das sollte auch im Sinne der Nutzer sein).

Unter Microsoft Windows:

Einfach auf das Skript launch_x265benchmark.bat doppelklicken, oder selbiges innerhalb eines Konsolenfensters starten: .\launch_x265benchmark.bat. Nach dem Durchlauf wird der Benutzer im Konsolenfenster darüber benachrichtigt, daß er sein Ergebnis aus der RESULTS.txt abholen kann.

Unter UNIX / Linux / macOS / Haiku OS:

Das Skript bootstrap.sh durch Doppelklick starten oder auf einer Konsole aufrufen: $ ./bootstrap.sh. Den Aufforderungen folgen, bis der Bootstrapper alles erfolgreich kompiliert und eingerichtet hat. Danach das Skript launch_x265benchmark.sh durch Doppelklick starten oder auf einer Konsole aufrufen: $ ./launch_x265benchmark.sh. Erneut den Aufforderungen in der Konsole folgen, bis der Benchmarkbetrieb hinreichend gewährleistet worden ist, sodaß er sauber durchlaufen kann. Nach dem Durchlauf wird der Benutzer im Konsolenfenster darüber benachrichtigt, daß er sein Ergebnis aus der RESULTS.txt abholen kann.

4.) Ergebnisse einsenden; Was genau wird gebraucht?

Wie schon zuvor beim x264 Benchmark würde ich euch höflich bitten, beim Einsenden eines Ergebnisses auf das Format zu achten, und bitte die RESULTS.txt die vom Benchmark erzeugt wird als Anhang an eure Ergebnisposts anzufügen. Das Format eines Ergebnisses sollte so aussehen:

<Zeit in HHHH:MM:SS.mmm> | <Nickname des Urhebers> | <Anzahl der bestückten CPU Sockel>/<Anzahl der Kerne pro Sockel>/<Anzahl der Threads pro Sockel> | <CPU-Name(n)> | <RAM-Typ & Menge> | <Mainboard/Rechner/Plattform> | <Mainboard-Chipsatz> | <Betriebssystem> <auf Virtueller Maschine, wo anwendbar> (<Compiler, wo anwendbar>)

Es ist beim Test bitte unbedingt drauf zu achten, daß nicht an der Systemzeit gedreht wird, solange er noch läuft! Das schließt Sommer-/Winterzeiteinstellungen (DST) mit ein, solche sollte es während des Tests nicht geben! Falls dies doch passiert, so ist dies bitte unbedingt gemeinsam mit dem Ergebnis mit anzugeben!

Hier ein Beispiel:

11:09:44.290 | GAT | 1/8/8 | AMD FX-9590 4.70GHz | 16GB DDR-III/1866 9-10-9-27 | Gigabyte GA-990FX-UD3 v4.0 | AMD 990FX | FreeBSD 11.1 UNIX (Clang 4.0.0)

Für Windows Versionen muß i.d.R. kein Compiler angegeben werden, wenn man nicht wirklich von Quellen selbst übersetzt. Die Windows Version des Benchmarks so wie er ausgeliefert wird, verfügt über eine x265.exe, die mit Microsoft VisualStudio 2017, C++ Compilerversion 19.11.25547 übersetzt und tlw. mit yasm 1.3.0 assembliert wird. Das beiliegende ffmpeg.exe wird mit GCC 6.3.0 übersetzt und mit gas 6.3.0 / yasm 1.3.0 assembliert.

Wenn man virtualisiert, dann sei das bitte wie folgt anzugeben:

<Betriebssystem> (<Compiler, wo anwendbar>) in <Hypervisor+Version> auf <Hostbetriebssystem>

Ein Beispiel:

Debian 9.2.1 Linux (GCC 6.2.0) in VirtualBox 5.1.2 auf Windows 10 Pro 1703

Für UNIX und Linux kann es sein, daß die Zeit als Millisekundenwert in der RESULTS.txt steht. Ist dem so, ist der Wert entweder selbst umzurechnen, oder der ms-Wert einfach so zu posten (ich rechne dann um). Manchmal fehlen auch die Millisekunden in der Angabe der Zeitmessung, und man erhält nur Sekundengenauigkeit. In solchen Fällen werden die Millisekunden auf 0 abgerundet.

Beim RAM dürfen natürlich gerne wieder die Latenzen angegeben werden! Je mehr Info desto besser.

Weiterführende Informationen finden sich einen Beitrag weiter unten.

Inhaltsangabe:

1. ) Usertopliste, Betriebssystemstatistik und CPU Statistik
2. ) Frametime-Statistik / Verlaufsgraph
3. ) Gültige Ergebnisse aus dem Bedarfserhebungsthread, nachgereicht
4. ) Allgemeine Zusatzinformationen
   1. ) Gültigkeit von Ergebnissen
   2. ) Unter welchen Softwarelizenzen steht der Benchmark?
   3. ) Wo finde ich den Quellcode der Benchmarkkomponenten?
   4. ) Unter welcher Lizenz stehen die von mir erzeugten Bilder und Textinhalte der x265 Ergebnisliste und Beiträge in diesem Thread?
5. ) Version Changelog der Releaseversionen
6. ) Bekannte Bugs und Probleme

• 03:05:30.241 | exxe | 1/12/24 | AMD Ryzen Threadripper 1920X 3.50GHz | 32GB DDR-IV/2400 | ASUS PRIME X399-A | AMD X399 | CentOS 7.4.1708 Linux (GCC 4.8.5)
• 03:53:25.130 | GAT | 2/8/16 | Intel Xeon E5-2620 v4 2.10GHz | 64GB Reg. ECC DDR-IV/2133 | HP ProLiant DL360 G9 | Intel C610 Wellsburg | CentOS 7.3.1611 Linux (GCC 4.8.5)
• 09:01:55.138 | feinripp | 1/4/8 | Intel Core i7-4790K 4.40GHz | ASUS Z97 Pro Gamer | Intel Z97 Lynx Point | 16GB DDR-III/1600 9-9-9-24-2T | Windows 10 Pro
• 10:36:54.000 | GAT | 1/6/12 | Intel Core i7 980X 3.33GHz | 48GB DDR-III/1333 9-9-9-24-2T | ASUS P6T Deluxe V2 | Intel X58 Tylersburg | CentOS 6.9 Linux (GCC 7.2.0)
• 11:09:44.290 | GAT | 1/8/8 | AMD FX-9590 4.70GHz | 16GB DDR-III/1866 9-10-9-27 | Gigabyte GA-990FX-UD3 v4.0 | AMD 990FX | FreeBSD 11.1 UNIX (Clang 4.0.0)
• 12:28:47.687 | GAT | 1/6/12 | Intel Xeon X5690 3.47GHz | 48GB DDR-III/1333 8-8-8-24-2T | ASUS P6T Deluxe | Intel X58 Tylersburg | Windows XP Pro x64 SP2
• 16:59:23.843 | Bier.jpg | 2/4/4 | Intel Xeon X5470 3.33GHz | 64GB FBDIMM DDR-II/667 5-5-5-15 | SuperMicro X7DWA-N | Intel 5400B Seaburg | Windows XP Pro x64 SP2
• 32:28:26.000 | 666psycho | 1/4/4 | AMD Phenom II X4 955 3.20GHz | 16GB DDR-II/667 | Gigabyte M57SLI-S4 Rev 2.0 | nVidia nForce 570 SLI | Debian 9.2 Linux (GCC 6.3.0)
• 51:16:48.954 | Stranger2k1 | 1/4/4 | AMD A8-3550MX 2.00GHz | 16GB DDR-III/1333 9-9-9-24 | HP Pavilion G7-1280eg | AMD K12 | Windows 10 Home
• 64:40:37.007 | Bier.jpg | 1/2/2 | Intel Core 2 Duo T9300 (Dual IDA) [pp.] 2.50GHz | 8GB DDR-II/557 5-5-5-15 | Lenovo ThinkPad X61 | Intel GM965 Crestline | Windows 7 Ultimate x64 SP1

4.) Allgemeine Zusatzinformationen:

4a.) Gültigkeit von Ergebnissen

Beim [x264 Benchmark] war es so, daß die Gültigkeit eines Resultats davon abhing, daß eine bestimmte Binärversion von x264.exe für Windows benutzt werden mußte, um ein gültiges Ergebnis abliefern zu können. Hier half auch keine Virtualisierung, denn auch diese wurde als Grund gewertet, das Ergebnis nur als "inoffizielles" in die Ergebnisliste mit aufzunehmen. Auch das Unterschreiten der Mindestanforderungen führte zu einer Verweigerung der Gültigkeit, was im Falle der verlangten SSE Befehlssatzerweiterungen einschränkend auf die Nutzer gewirkt hat.

Ganz zu schweigen natürlich vom unsinnigen Aussperren von UNIX-, Linux-, macOS- und Haiku OS Systemen, die den portablen Benchmark natürlich auch haben ausführen können.

Der x265 Benchmark räumt mit dieser Unzulänglichkeit auf! Anstatt "binary-locked" zu sein, ist der x265 Benchmark "version-locked". Solange die x265 Version 2.5+48-bd438ce10843 und die ffmpeg Version 3.2.4 (mit libavutil 55.34.101, libavcodec 57.64.101, libavformat 57.56.101, libavfilter 6.65.100, libswscale 4.2.100 und libswresample 2.3.100) zum Einsatz kommen, und die Anforderungen an Hauptspeicher, Festspeicher und notwendiger Software zum Betrieb des Benchmarks an sich erfüllt werden, ergibt das ein gültiges Resultat!

Alle anderen Parameter wie etwa Betriebssystem, eingesetzter C/C++ Compiler (solange mit unveränderten Standardeinstellungen), vorhandene NUMA Unterstützung (sofern nicht fehlerhaft) oder auch Hardwarevirtualisierung werden als natürliche Einflüsse gewertet, die die Gültigkeit nicht beeinflussen!

Der x265 Benchmark ist in Sachen Plattformen somit fairer und unabhängiger als es der x264 Benchmark jemals war!

4b.) Unter welchen Softwarelizenzen steht der Benchmark?

Siehe -> README/README.txt des fertig entpackten Benchmarks!

4c.) Wo finde ich den Quellcode der Benchmarkkomponenten?

Siehe -> README/README.txt des fertig entpackten Benchmarks!

4d.) Unter welcher Lizenz stehen die von mir erzeugten Bilder und Textinhalte der x265 Ergebnisliste und Beiträge in diesem Thread?

Alle von mir selbst im Rahmen des x265 Benchmarks erzeugten Webseiten (//www.xin.at/x265/*, //wp.xin.at/*) sowie Forenbeiträge auf Voodooalert innerhalb dieses [Threads], wie auch des alten [Bedarfserhebungsthreads] und alle von mir erzeugten Bilder sind © Michael Lackner (GrandAdmiralThrawn) und stehen unter einer [Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0)] Lizenz.

Im Falle des Logos im ersten Beitrag sowie auf der Ergebnisliste gilt zusätzlich noch ein © David Baum in Bezug auf das Voodooalert.de Logo. Die Nutzung dieses Logos durch mich geschieht mit ausdrücklicher Erlaubnis durch David Baum (ernesto.che).

5.) Changelog: (neuere zuerst)

0.4.0-r0:

• Alle Plattformen:
  • src/x265/source/common/threadpool.h bzw. src\x265\source\common\threadpool.h, Zeilen 37-44 und die daraus resultierenden Binärprogramme bin/x265, bin\x265.exe & bin\x265-NT6.1+.exe: Ändern der Breite des CPU Adressierungsbitvektors bzw. Felds von 64 auf 256 Bit, passend zu den Konventionen moderner Betriebssysteme. Damit können auf kompatiblen non-NUMA Systemen bis zu 256 CPUs adressiert werden, auf NUMA Systemen nun bis zu 256 CPUs pro NUMA Knoten.
    
    Im Hinblick auf existierende, SMT-fähige Many-Core CPUs wie z.B. den AMD Threadripper 3990X (64 Kerne, 128 Threads) oder den Intel Xeon Platinum 8380 (40 Kerne, 80 Threads) soll dies eine Auslastung der Prozessoren ohne das Erzeugen unsinniger NUMA Threadpools gewährleisten.
    
    Zudem sollen derartige Prozessoren in Einsockel- und Mehrsockelkonfigurationen auch auf Betriebssystemen ohne Win32 NUMA oder libnuma unterstützt werden, so z.B. auf Solaris, FreeBSD, macOS, etc.
    
    Dies betrifft auch jene Systeme, wo die NUMA Unterstützung zwar vorhanden wäre, aber schlichtweg in der Systemfirmware (z.B. UEFI) deaktiviert wurde.
    
    Hinweis 1: Dies umgeht nicht die Limitierungen älterer Betriebssystemekernel! Wenn der Systemkern nur 64 CPUs zu adressieren vermag (Beispiele: Windows XP Professional x64 Edition, Linux 2.4 x64, FreeBSD 9.x x64), so gilt diese Limitierung weiterhin!
    
    Hinweis 2: Dieser Wert kann in Zukunft noch weiter erhöht werden, sodenn die Betriebssystemkerne entsprechend aufgestockt werden.
    
    Code vor der Modifikation (Max. 32 CPUs für 32-bit, max. 64 CPUs für 64-bit):
    Code

    #if X86_64
    typedef uint64_t sleepbitmap_t;
    #else
    typedef uint32_t sleepbitmap_t;
    #endif
    
    static const sleepbitmap_t ALL_POOL_THREADS = (sleepbitmap_t)-1;
    enum { MAX_POOL_THREADS = sizeof(sleepbitmap_t) * 8 };
    enum { INVALID_SLICE_PRIORITY = 10 }; // a value larger than any X265_TYPE_* macro

    Modifizierter Code (256 CPUs, 32-Bit Unterstützung entfernt, da für den Benchmark irrelevant):
    Code

    typedef uint64_t sleepbitmap_t;
    static const sleepbitmap_t ALL_POOL_THREADS = (sleepbitmap_t)-1;
    enum { MAX_POOL_THREADS = sizeof(sleepbitmap_t) * 32 };
    
    enum { INVALID_SLICE_PRIORITY = 10 }; // a value larger than any X265_TYPE_* macro

  • /sbin/transcoder.sh (Zeilen 21 & 29) bzw. sbin\transcoder.bat (Zeilen 56 & 69): Anzahl der zu kodierenden Frames nicht nur für den Encoder, sondern auch für den Decoder fixiert, um den Decoder bei Schnelltests in der Entwicklung nicht mehr unsinnig lange auf eine Pipe schreiben zu lassen, deren Gegenstelle bereits terminiert hat.
  • launch_x265benchmark.sh bzw. launch_x265benchmark.bat: Mehrere kleinere Fehlerkorrekturen.
  • share/version.txt bzw. share\version.txt: Versionsstring erhöht auf 0.4.0-r0 (Version 0.4.0, Patchlevel 0)
• UNIX:
  • Neue Systemarchitektur: aarch64, verifiziert in Zusammenarbeit mit [Bier.jpg]. Der Benchmark ist damit auf 64-Bit ARMv8 unter wenigstens Linux lauffähig, weitere Betriebssysteme verbleiben noch ungetestet. Lediglich die x265 Versionsanzeige in RESULTS.txt gibt noch "32 bit" an. Dies ist aber nur ein kosmetischer Fehler, der ignoriert werden kann.
  • launch_x265benchmark.sh: Sinnfreie Kommentarzeile von Zeile 1242 entfernt.
  • README/README.txt & README/README-GER.txt: Etliche Tippfehler korrigiert und Quellcodemodifikationen zur Erweiterung des CPU Adressierungsbitvektors in x265 dokumentiert.
• Win64:
  • bin\cpuz_x64.exe: Aktualisiert von 1.87.0 -> 1.97.0. Neuer CPU- und Plattformsupport, diese Liste ist nicht zwingend vollständig:
    • ARM: Vorabunterstützung (Windows 10 on ARM), Achtung! Das bedeutet nicht zwingend, daß der x265 Benchmark in Zukunft ARM auf Windows unterstützen wird!
    • AMD: Threadripper 3000 (Zen 2), Threadripper Pro 3000 (Zen 2), Ryzen 7/5/3 5000, Ryzen 7/5/3 3000 Pro (Zen 2), Ryzen 9/7/5 3000XT series, Ryzen Picasso (Zen+), Renoir APU, Ryzen 5000G APU, Cezanne/Lucienne
    • Hygon/海光: Dhyana/中科海光 (Zen)
    • Intel: Bestimmte Core i-9000F/KF, Core i-10000, Core i-11000 & Core i-12000 Serien (Cascade Lake, Comet Lake, Ice Lake, Tiger Lake)
    • VIA: CHA NCore, Centaur CHA
    • Zhàoxīn/兆芯: Kāixiān/开先 KX-5000 (Wǔdàokǒu/五道口) & Kāixiān/开先 KX-6000 (Lùjiāzuǐ/陆家嘴)
  • bin\ptime.exe: Neues Zeitmessungswerkzeug von [Jem Berkes], das Microsoft TimeThis.exe ersetzt. Verbesserungen: Kein ~600h Überlauf mehr. Keine einstündigen Zeitsprünge mehr, sollte die Systemuhr gerade während eines laufenden Tests von der Normalzeit auf die Sommerzeit oder in die Gegenrichtung wechseln. Auch das manuelle Ändern der Systemzeit beeinflusst die Zeitmessung jetzt nicht mehr.
  • launch_x265benchmark.bat & sbin\transcoder.bat: Überflüssiger %NicePrg% Programmcode entfernt, da kein nice Programm mehr benutzt wird.
  • README\README.txt & README\README-GER.txt: ptime.exe Lizenzinformationen hinzugefügt und TimeThis.exe Lizenzinformationen entfernt, etliche Tippfehler korrigiert und Quellcodemodifikationen zur Erweiterung des CPU Adressierungsbitvektors in x265 dokumentiert.
  • Offizielle Unterstützung von Microsoft Windows 11 (kosmetische Updates, keine funktionalen).

0.3.1.2-r5:

• Win64:
  • launch_x265benchmark.sh: Tippfehler in den Codekommentaren korrigiert.
  • bin\cpuz_x64.exe: Aktualisiert von 1.83.0 -> 1.87.0. Neuer CPU Support (Intel bis Coffee Lake, AMD bis 2nd Gen Ryzen), AMD AGESA Reporting und besserer Support für DDR-IV Speicher-Reporting.

0.3.1-r3:

• UNIX:
  • launch_x265benchmark.sh: Korrekte URLs zu den Webseiten in den Kommentaren und in den Fehlermeldungen eingepflegt und auf HTTPS geändert.
  • README\README*.txt: Korrekte URLs zu den Webseiten eingepflegt und auf HTTPS geändert.

0.3.1.2-r4:

• Win64:
  • launch_x265benchmark.bat: Korrekte URLs zu den Webseiten in den Kommentaren und in den Fehlermeldungen eingepflegt und auf HTTPS geändert.
  • README\README*.txt: Korrekte URLs zu den Webseiten eingepflegt und auf HTTPS geändert.

0.3.1.2-r3:

• Win64:
  • bin\cpuz_x64.exe: Aktualisiert von 1.81.1 -> 1.83.0. Damit unterstützt das System Reporting nun Xeon Phi "Knights Landing" manycore CPUs, sowie AMD Ryzen 2xxx "Raven Ridge" Desktop APUs.

0.3.1.1-r2:

• Win64:
  • launch_x265benchmark.bat: Der CPU-Z Aufruf war unzureichend, was das Erfassen der Chipsatzinformationen angeht. Das wurde jetzt durch ein Erweitern der grep Parameter korrigiert.

0.3.1-r2:

• Alle Plattformen:
  • launch_x265benchmark[.sh|.bat]: Neue RAM-Anforderungsskalierung. Für Systeme mit 1-32 logischen CPUs werden nur noch 12GiB RAM gefordert, anstatt 16GiB. Systeme mit 33-64 logischen CPUs benötigen weiterhin 16GiB, Systeme mit >=65 logischen CPUs benötigen 24GiB RAM. Diese Staffelung kann sich noch ändern bzw. erweitert werden.
  • README/README.txt: Information über aktuelle RAM-Anforderungsstaffelung hinzugefügt.
    share/version.txt: Version inkrementiert, 0.3.0 (r1) => 0.3.1 (r2).
• UNIX:
  • README/README.txt: Tippfehler korrigiert.
  • launch_x265benchmark.sh: String Quoting Fix für die zusätzliche Speicherbenachrichtigung unter OpenBSD UNIX und kosmetische Verbesserungen.
  • share/version.txt: Trademarksymbole hinzugefügt.

6.) Bekannte Bugs und Probleme: (neuere zuerst)

• 0.3.1-r2:
  • Win64:
    • bin\cpuz_x64.exe: Auf Windows 10 kann es passieren, daß CPU-Z beim Aufruf mit einem Treiberfehler abstürzt. Hierbei meldet CPU-Z, daß eine andere Version seines Kernelcodes schon laufen würde, daß aber 1.39 benötigt würde. Die Ursache für diesen Fehler ist noch unklar.
    • launch_x265benchmark.bat - Hotfix 0.3.1.1 r2 verfügbar: Aufruf von CPU-Z unzureichend, kein Erfassen der Chipsatzinformationen gegeben.
    • launch_x265benchmark.bat und bin\cpuz_x64.exe: Benötigt Administratorrechte per UAC bzw. per se wenn auf NT 5.2 getestet werden soll. In Zukunft ist ein Durchlaufzähler geplant, der nach 3 erfolglosen UAC Admin-Aufrufen abbricht und den Benchmark ohne CPU-Z Systemreporting weiter ausführt. Auf NT 5.2 soll einfach eine Warnung anstatt eines kritischen Fehlers erzeugt werden. So soll es Nutzern ermöglicht werden, den Test auf Windows auch dann laufen zu lassen, wenn keine Administratorrechte zur Verfügung stehen.
• 0.3.0-r1:
  • Alle Plattformen:
    • launch_x265benchmark[.sh|.bat]: Der Test verlangt auch auf Maschinen mit geringer logischer CPU-Anzahl (32 und weniger) nach 16GiB RAM, was überzogen ist. Mit der nächsten Version soll eine feinere Staffelung eingeführt werden, sodaß kleinere Maschinen auch mit 12GiB in die Gültigkeit entlassen werden.

• 0015:16:54.197 | GAT | 2/4/4 | Intel Xeon E5430 2.67GHz | 17GB FBDIMM DDR-II/667 | ASUS DSBV-D | Intel 5000V Blackford | CentOS 6.7 Linux (GCC 4.4.7)

Gibts irgendwas neues @Maniac? War heute (bzw. gestern mittlerweile) leider den ganzen Tag nicht da...