Artikel Neuer Artikel: Bericht: x264 mit OpenCL-Beschleunigung

Dr@

Grand Admiral Special
Mitglied seit
19.05.2009
Beiträge
12.791
Renomée
4.066
Standort
Baden-Württemberg
  • BOINC Pentathlon 2011
  • BOINC Pentathlon 2012
<center><a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=406096"><img src="http://www.planet3dnow.de/photoplog/images/54308/1_x264_Artikel-Logo-02.png" border="1" alt="x264 mit OpenCL-Beschleunigung - Artikel-Logo"></a></center>

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 <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1337147462">vielversprechende Benchmarkwerte</a> 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 <a href="http://pastebin.com/raw.php?i=c0VmaVNC" target="b">öffentlich zur Verfügung</a> und wird auch <a href="http://forum.doom9.org/showthread.php?t=164960" target="b">bereits diskutiert</a>. 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.

<b>Zum Artikel:</b> <a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=406096" target="b">Bericht: x264 mit OpenCL-Beschleunigung</a>

Viel Vergnügen beim Lesen!
 
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.
 
Enttäuschend, mehr gibt es dazu eigendlich nichts zu sagen. Sind da noch so viele Bugs drin? So wird OpenCL jedenfalls kein Erfolg haben.
 
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.
 
Vielen Dank @ Dr@ *greater*
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
 
Irgendwie sehr ernuechternd ...aber gut das langsam Bewegung in OpenCL kommt.
Aber in dieser Form hier eher fuer die meisten fehl am Platze
 
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.
 
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
 
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.
 
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...
 
@ 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.


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.
 
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
 
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.
 
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 *buck*
 
Nabend allerseits,

bei mir werden in Handbrake 0.9.9.1 die Checkboxen gar nicht angezeigt. Neben der Einstellung, welchen Container man verwenden möchte, soll es ja die Checkbox für OpenCL Support geben, aber da ist keine?!
Haben die das wieder deaktiviert oder was ist da los?

Ich weiß, der Thread ist schon etwas älter, aber es passt ja zum Thema und da wollte ich nicht gleich einen neuen Thread eröffnen ;)

VG
 
Meines Wissens ist die OpenCL-Beschleunigung noch nicht im stabilen Zweig angekommen und demnach auch nicht in der 0.9.9.1 enthalten. Eine Zeitlang gab es eine spezielle Beta-Version, mit der die OpenCL-Beschleunigung angeboten wurde. Zusätzlich gab es noch eine Beta mit Unterstützung für Intels QuickSync. Wo beide Beta-Versionen abgeblieben sind, kann ich Dir nicht sagen. Sie werden beide nicht mehr verlinkt.
Zumindest in der OpenCL-Beta war auch die Unterstützung für die Hardwarebeschleunigung der Dekodierung des Ausgangsmaterials enthalten, was über die DXVA-Schnittstelle realisiert wurde.
Eidt: http://handbrake.fr/news.php

Meinen Test zufolge hat die OpenCL-Beschleunigung nichts wirklich gebracht. Die erzielte Qualität war eine andere und dies war dann auch schon der Grund für die Unterschiede in der Codierungsdauer. Meiner Meinung nach lag da was mit dem Skalierer im Argen, für den ja OpenCL genutzt wurde. Die OpenCL-Beschleunigung von x264 wurde noch nicht in Handbrake freigeschaltet bzw. wird nicht genutzt. Allerdings ist auch hier meine Einschätzung nach wie vor, dass es nichts oder höchstens minimalst etwas bringt, dafür aber eine höheren Leistungsaufnahme und eine anderen Qualität (schlechter) des Videos verursacht, welches ausgegeben wird.

Wenn Du es dennoch ausprobieren möchtest, kannst Du den aktuellen Nightly ziehen. Das ist aber eher Alpha-Stadium und kann von entsprechenden Bugs betroffen sein.
http://handbrake.fr/downloads.php


Wie man sieht, ist meine anfängliche Begeisterung großer Ernüchterung gewichen. Meine letzte Hoffnung ist, dass HSA hier noch was bringt. Ansonsten kann man die Dekodierung über DXVA empfehlen, was aber leider nur bei einer sehr eingeschränkten Anzahl an Quellformaten nutzbar ist. Bei entsprechend starken CPUs wird das aber auch nicht weiter ins Gewicht fallen. Die OpenCL-Beschleunigung in der jetzigen Form ist ein Witz, ein schlechter. Vielleicht könnte hier die höheren Auflösungen die GPU-Beschleunigung in besseres Licht rücken, was aber auch sehr spekulativ ist.
 
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 *buck*
Daran hat sich auch nicht viel geändert, ich vermute mal, dass es sich es mit den neuen Befehlssätze überschnitten hat.
Deswegen wird es nicht Weiterentwickelt (Aufwand zu groß).
Es kommen aber immer noch regelmäßig neue x264 Versionen raus: http://www.x264.nl/x264_main.php
 
An dem Thema wird sich auch nichts ändern, weil der x264-Bench von TechARP auf verbugte Tools für den 64-Bit-Teil des Benchmarks setzt.


Ein Teil des Performancegewinns durch die OpenCL-Beschleunigung der lookahead-Funktion kann auch durch die threaded Version erzielt werden. Deswegen ist es aktuell so sinnlos. Zumal eben der zweite Durchlauf viel rechenintensiver ist und hier eben die GPU gar nichts beitragen kann. Das offloading, wenn alles in einem Rutsch berechnet werden soll, hat ja auch nicht wirklich was gebracht.
 
Danke für die schnelle und ausführliche Antwort ! :-)

Die Nightly Version hatte ich auch schon probiert und in den Settings auch OpenCL aktiviert, aber trotz performanter HD7950, war die Umwandlungszeit kaum kürzer. Und die Auslastung der Grafikkarte war weiterhin IDLE, daher hatte es mich gewundert ;-)

Schade eigtl, da mein Core i3 für alles locker ausreicht, außer die Konvertierungen ^^
 
Hmm, also Last sollte auf der Radeon schon entstehen. Allerdings nur, wenn Du auf eine andere Auflösung skalierst.
 
Jap, war eine Umwandlung von 1080p zu 720p.

Naja egal, dauert es halt etwas länger, dafür ist es fehlerfrei.
 
Zurück
Oben Unten