Artikel Neuer Artikel: Bericht: x264 mit OpenCL-Beschleunigung

[Dr@]

Bereits Mitte Mai haben wir darüber berichtet, dass für das Video-Tool HandBrake sowie für den H.264-Videoenkoder x264 eine GPU-Beschleunigung durch Nutzung der OpenCL-Programmierplattform implementiert werden sollte. Unsere Kollegen von AnandTech hatten damals zur Vorstellung der "Trinity"-APU eine erste GPU-beschleunigte Version von HandBrake in die Finger bekommen und einige vielversprechende Benchmarkwerte präsentiert. Beide Anwendungen befinden sich bis heute noch in der Entwicklung, wobei insbesondere die optimierte Version von HandBrake derzeit offenbar nur intern bei AMD verfügbar ist. Der Code und die zugehörige Dokumentation sollen erst zu einem späteren Zeitpunkt der Open-Source-Community zugänglich gemacht werden.

Wie erste Recherchen ergaben, ist dies glücklicherweise bei x264 nicht der Fall: Der entsprechende Code steht schon seit geraumer Zeit öffentlich zur Verfügung und wird auch bereits diskutiert. Dies war für uns Anlass genug, zu dem verantwortlichen x264-Entwickler Steve Borho Kontakt aufzunehmen, der uns freundlicherweise auch gleich eine fertig kompilierte Version von x264 bereitstellte, die von der OpenCL-Beschleunigung Gebrauch macht. Auf den folgenden Seiten wollen wir uns zunächst mit der grundlegenden Idee auseinandersetzen, bevor wir einige erste Messwerte präsentieren. Zudem konnten wir Steve Borho für ein kurzes Interview gewinnen.

Bedanken möchte ich mich ganz besonders bei Steve Borho, ohne den dieser Artikel nicht möglich gewesen wäre, sowie bei allen Helfern, die ihre Systeme für die Erhebung der Benchmarkwerte zur Verfügung gestellt haben.

Zum Artikel: Bericht: x264 mit OpenCL-Beschleunigung

Viel Vergnügen beim Lesen!

[Nightshift]

In der Tat etwas enttäuschend.
Andererseits steht die Entwicklung noch ganz am Anfang, zusätzlich wurde hier nur eine kleine Teilfunktion des Kodierungsprozesses in OpenCL implementiert und zuguterletzt schätze ich, dass die APUs nicht nur unter der geringen Rechenleistung des GPU-Parts leiden sondern auch unter der Speicherbandbreite die CPU und GPU sich teilen müssen.

Was sich mir trotz des Interviews noch nicht zu 100% erschließt ist, warum Kodierungsthreads nicht auf die GPU ausgelagert werden ohne Nutzung der internen Codierungseinheit (also AVC).
Dann müsste doch auch die volle Kontrolle über den Kodierungsprozess und somit die Qualität vorhanden sein.

Insofern sehe ich da noch einiges an Potential.

[bbott]

Enttäuschend, mehr gibt es dazu eigendlich nichts zu sagen. Sind da noch so viele Bugs drin? So wird OpenCL jedenfalls kein Erfolg haben.

[OBrian]

Man merkt aber, daß GCN besser dasteht als die älteren Architekturen, der Trend geht also in die richtige Richtung. Ontario ist auch einfach nicht als Rechenknecht gedacht, sondern soll nur gerade eben so ausreichende Leistung liefern bei möglichst geringem Verbrauch. Den C-60 haben wir ja auch nur spaßeshalber mitgetestet.

Warum die das Enkodieren selbst nicht auf der GPU machen, keine Ahnung, möglicherweise reicht die Genauigkeit nicht aus, oder es wäre ein wesentlich größerer Aufwand gewesen.

[WindHund]

Vielen Dank @ Dr@
Ich nehme mal an sie lagern nicht alles auf die GPU aus weil ja auch der Verbrauch eine Rolle spielt.
Es ist wohl eine Gratwanderung zwische Leistung und Verbrauch.
Es bringt ja nichts wenn das Video in der hälfte der Zeit klein gerechnet wird, dafür aber 4mal mehr Strom benötigt wird.

MfG

[TNT]

Irgendwie sehr ernuechternd ...aber gut das langsam Bewegung in OpenCL kommt.
Aber in dieser Form hier eher fuer die meisten fehl am Platze

[Dr@]

Wie die Aussagen von Steve Borho im Interview zeigen, liegt es nicht primär an OpenCL, dass ausschließlich die Berechnung der lookahead-Funktion auf die GPU ausgelagert wurde. Alle anderen Teilaufgaben lassen sich eben nicht effizient genug auf die GPU übertragen, ohne dabei die Qualität und Effizienz von x264 zu reduzieren. Was schlicht darin begründet ist, dass CPUs und GPUs auf grundlegend anderen Architekturen aufbauen. Eigentlich müsste diese Herangehensweise honoriert werden, schließlich wurde die schlechte Bildqualität bisheriger GPU-beschleunigter Enkoder hier mehr als ein Mal - zurecht - angeprangert.

Wer auf den heiligen Gral gehofft hat, muss natürlich extrem enttäuscht sein. Gerade wenn man die Ergebnisse im Two-Pass Encoding für die Tandems aus CPU und Grafikkarte betrachtet, wird auch klar warum die OpenCL-beschleunigte lookahead-Funktion nicht als Nachbrenner wirkt und somit auch nicht für gewaltige Leistungssteigerungen sorgen kann: Es wird eben nur die Analyse des Ausgangsmaterials beschleunigt. Die eigentliche Kodierung des Videos findet ausschließlich auf den CPU-Kernen statt. Die viel höheren Werte verpuffen dann aber, weil letztlich nur der sowieso schon viel schnellere Analysedurchgang beschleunigt wird. Hinzu kommt noch, dass bei aktivierter OCL-Beschleunigung die Analyse leicht andere Ergebnisse liefert, die zu einer rechenintensiveren Kodierung führen (z.B. mehr B-Frames und/oder längere Bewegungsvektoren). Dadurch wird der eh schon viel langsamere zweite Durchgang sogar noch weiter ausgebremst.

Nehmen wir mal als konkretes Beispiel aus unseren Benchmarkergebnissen die Kombination aus Intel Core i7 2600K und GeForce GTX 580 zur Hand:

Anzahl der Frames: 5906

1st Pass ohne OCL: 36,29 fps (7.782,56 kb/s) ---> 00:02:43 (2 Minuten und 43 Sekunden)
1st Pass mit OCL: 80,76 fps (7.772,53 kb/s) ---> 00:01:13

2nd Pass ohne OCL: 11,77 fps (8.001,89 kb/s) ---> 00:08:22
2nd Pass mit OCL: 11,24 fps (8.010,10 kb/s) ---> 00:08:45

T-P E ohne OCL: 00:11:05
T-P E mit OCL: 00:09:58

Es wurde also die Berechnungszeit für den bereits dreimal so schnellen ersten Durchgang nochmals halbiert. Das kann keinen Großen Effekt auf die Gesamtlaufzeit haben.


Ich habe also 1 Minute und 7 Sekunden durch Aktivierung der OCL-Beschleunigung gewonnen. Oder relativ ausgedrückt: Die Berechnungen erfolgen 10 % schneller.

Gedankenexperiment:

Ohne die Verlangsamung im zweiten Durchlauf, würde die Berechnung 9 Minuten und 35 Sekunden dauern - also 1 Minute und 30 Sekunden schneller durchlaufen. Damit könnte das T-P E theoretisch bis zu 13,5 % beschleunigt werden.

Das kann man natürlich noch auf die Spitze treiben und einfach die Zeit für die Revision 2200 ansetzen (wir ignorieren die Verbesserungen im 1. Durchlauf; 50,47 fps (7.779,52 kb/s)), die ja im zweiten Durchlauf allgemein etwas schneller ist.

r2200: 12,74 fps (8.002,16 kb/s) ---> 00:07:44

T-P E mit OCL: 00:08:57 ---> 00:02:08 schneller --> 19 % schneller
(ist aber natürlich eine Milchmädchen-Rechnung)


Für künftige 4k-Auflösungen könnte die OpenCL-Beschleunigung dann sicherlich noch etwas mehr bringen.

[Mente]

Hallo @Dr

erstmal toller Beitrag, das hat mit sicherheit einiges an arbeit gekostet.
Die Ergebnisse fand ich auch etwas schade den es sollte doch mehr möglich sein.
Warum beschleunigt eine 580 mehr im ersten Test wie die 7970?
"ok hat dem 2600k nichts gebracht den im test 2 ist er doch etwas langsam um
in der gesamtzeit das umsetzen zu können". Nur kann es sein das wir vieleicht
in den Opencl noch auf amd seite potetial liegen lassen?

lg

[Markus Everson]

Mich würde interessieren wie die Ergebnisse auf CPU, APU, GPU mit der Taktfrequenz und anzahl der Kerne skalieren. Wenn sich da kein Vorteil der OpenCL Lösung zeigt bleibt die Mainstream-Killeranwendung weiterhin der unerreichbare Topf mit Gold am Ende des Regenbogens.

[code2i]

...weitere Infos zu GPU Encoding Benchmarks... NVIDIA ... AMD ... vs. Intel Quick Sync.
http://www.tomshardware.de/ivy-bridg...-241007-7.html

[tex_]

Und wie so schön im Artikel steht:

... und nun sind AMD mit der Video Codec Engine und Nvidia mit NVEnc am Start.

In dem Diagramm unten wurde allerdings anscheinend nicht mit NVEnc von Nvidia getestet(das wohl sogar schneller als QuickSync ist), sondern mit einer Berechnung über CUDA.
Den Vergleich zu AMD kann man leider im Moment gleich ganz vergessen, weil noch keine Software verfügbar ist, die die VCE Einheit benutzt.

Das hat aber letztlich auch wenig mit der x264 Video Kodierung zu tun, die zwar langsamer, dafür aber auch qualitativ hochwertiger ist, als die ganzen Hardwareencodierer.
Solange die größte Arbeit allerdings noch auf der CPU läuft darf man wohl leider auch noch nicht so viel von Open Cl Video Encoder Software erwarten...

[Dr@]

@ Mente

Die Differenz zwischen GeForce GTX 580 und Radeon HD 7970 würde ich nicht überbewerten. Es könnte da schlicht daran liegen, dass der Intel Core i7 mehr Bums hat und der FX die Radeon bereits ausbremst. Um hier wirklich die OpenCL-Implementierung von NVIDIA und AMD vergleichen zu können, müsste man die Karten auf dem ansonsten gleichen System antreten lassen.

Zitat von Markus Everson

Mich würde interessieren wie die Ergebnisse auf CPU, APU, GPU mit der Taktfrequenz und anzahl der Kerne skalieren. Wenn sich da kein Vorteil der OpenCL Lösung zeigt bleibt die Mainstream-Killeranwendung weiterhin der unerreichbare Topf mit Gold am Ende des Regenbogens.

Die Kernskalierung hast Du doch mehr oder weniger bereits im Artikel.
2M4T mit dem FX-8150
3M6T mit dem FX-6100
4M8T mit dem FX-8150

Und da sieht man sehr schön die Auswirkungen der threaded-lookahead-Funktion.

[WindHund]

Zitat von Mente

Hallo @Dr

erstmal toller Beitrag, das hat mit sicherheit einiges an arbeit gekostet.
Die Ergebnisse fand ich auch etwas schade den es sollte doch mehr möglich sein.
Warum beschleunigt eine 580 mehr im ersten Test wie die 7970?
"ok hat dem 2600k nichts gebracht den im test 2 ist er doch etwas langsam um
in der gesamtzeit das umsetzen zu können". Nur kann es sein das wir vieleicht
in den Opencl noch auf amd seite potetial liegen lassen?

lg

Das kann am SI der GTX580 liegen, wesenltich mehr "bums" hat der I7-2600k defentiv nicht.
Zudem wurde der Test mit 32Bit ausgeführt, da 64Bit zu dem Zeitpunkt nicht funktioniert hat.
Das System mit der HD7970 lief zumindest mir Standard Einstellungen, wie das I7-2600k System lief wird nirgends erwähnt.

@Dr@
Ich kann den Test leider nicht mit 64Bit nachstellen, auch mit der verlinkten 64Bit Datei weiß ich nichts anzufangen.

MfG

[Dr@]

Zitat von WindHund

Das System mit der HD7970 lief zumindest mir Standard Einstellungen, wie das I7-2600k System lief wird nirgends erwähnt.

Welche Infos fehlen Dir da? Die Taktfrequenz war bei 3,4 GHz festgetackert, so wie es unter Methodik & Testsystem steht.

Die höhere Single-Thread-Leistung des i7 dürfte hier den Unterschied machen, denn die OpenCL-Kernel müssen on-the-fly kompiliert werden. Ist aber reine Spekulation. Um das wirklich klären zu können, müsste WindHund bei sich auf dem System sowohl die Radeon HD 7970 als auch die GeForce GTX 580 unter sonst gleichen Bedingungen testen. Aber eigentlich war das auch nicht Thema es Artikels.

[WindHund]

Mit der openCL beschleunigung mit 64Bit stimmt was noch nicht.
Ich bin mit Dr@ dran das Problem zu indentifizieren. Kann sich nur um Tage handeln