x264 Benchmark (kein Schnelldurchgang! 32-Bit multicore und ≥1GB RAM)

Zitat von SK1

Umwege... Hm, schade.

Ich denke diese Tools holen die Info einfach aus dem SPD EEPROM, da steht die Speichergröße eines Moduls nämlich in der Regel auch noch drin. Zum Ergebnis: Das kann so leider nicht eingetragen werden, wie du eh selbst gesehen haben wirst, der Test wurde vorzeitig abgebrochen, aus welchen Gründen ist halt jetzt fraglich (Nicht ganz stabiles System?). Das ist natürlich sehr schade, aber ich denke hier trifft den Test an sich keine Schuld, auch wenn ich nicht zu 100% sicher sein kann (die Samplemenge ist einfach noch sehr gering bei Win98).

Da ist schon einiges dazwischen! Sieht man, daß es nicht bloß am Eigenkompilat liegt, daß der Code schneller ist, sondern wirklich am Code selbst.

So, und hier Mal etwas spezielles, dieses hier basiert auf dem modifizierten / erweiterten Code, der tlw. von Steve Borho unter AMD's Schirm entwickelt wurde (Der Mann hat auch schon bei nVidia an CUDA gearbeitet), und zwar handelt es sich hierbei um eine Implementierung des Lookahead Codes in OpenCL, also auf der GPU. Der Lookahead Code ist in Single Pass und in 2-Pass für Pass 1 relevant, wo er mehrere voranliegende Frames inspiziert und abschätzt. In Pass 2 ist das nicht mehr interessant, weil diese Analyse bereits in die Statistikdaten aus Pass 1 eingeflossen ist.

Das ist also GPU-beschleunigt, allerdings - wie das Ergebnis unmißverständlich zeigen wird - nur in geringem Umfang (ca. +5% Leistung):

0000:38:30.125 | GAT | 1/6/12 | Intel Core i7 980X @ 4.0GHz | nVidia GeForce 580 GTX 3GB @ 1.8GHz S. / 2.2GHz R., R301.42, OpenCL | ASUS P6T Deluxe | Windows XP Pro x64 Edition

Jetzt fragt man sich natürlich: Warum nicht das Encoding selbst auf der GPU, so wie bei einigen Tools schon geschehen? Und die Antwort ist: Weil es die Qualität der Ausgabe negativ beeinträchtigt, wofür es noch keine Lösung gibt. Ein Grund, warum kein GPU-gestützter H.264/AVC Encoder momentan qualitativ mit x264 mithalten kann. Aber immerhin eine leichte Verbesserung von etwa +5% läßt sich ja schon einmal bemerken.

Dazu ein [Interview mit Steve Borho auf Planet3DNow!], wer mehr wissen möchte. Benchmarks gibt es natürlich auch dort.

Das Ergebnis werde ich nicht in die Liste aufnehmen, es verbleibt also im Forum. Es zahlt sich bei so geringen Unterschieden einfach nicht aus, eine Koprozessor-Spalte in die Datenbank und die Liste aufzunehmen.

Übrigens habe ich zwei der Grafikkarten im System, aber der Code hat nur eine davon verwendet, und die Last war eher marginal.

Ah, hatte ich den Link vergessen, [hier bitte]! Zu aktivieren über die Option --opencl, ansonsten wird der Lookahead nicht auf die GPU verlagert.

Nein, ist es nicht. Allerdings wäre es dann unmöglich die ganzen interessanten Resultate von alternativen Plattformen wie Linux, Solaris, MacOS X und von alternativen Rechnerarchitekturen wie Loongson, PowerPC, ARM etc. aufzunehmen, und das macht die Sache nun einmal viel spannender, reicher und interessanter.

Kaum zu schlagen mit seinen zwei 4GHz Gulftowns.

So ist es!

Um ein nicht reguläres Resultat zu erzeugen müßtest du schon wesentlich mehr Arbeit investieren, wie etwa libav+x264 in Solaris von Hand zu kompilieren, oder eine virtuelle Maschine dafür aufzusetzen, oder derart viel RAM aus deiner Maschine zu entfernen, daß weniger als 1GB übrig bleiben..

Ich denke, da besteht nicht viel Gefahr in die Irregularität abzugleiten.

Da hat aber jemand eine mächtig fette Kiste!

Ergebnis ist Mal eingetragen!