Ergebnis 1 bis 1 von 1
  1. Beitrag #1
    Themenstarter
    Redaktion
    Redaktion
    Avatar von Dr@
    • Mein System
      Notebook
      Modell: FSC Lifebook S2110, HP Pavilion dm3-1010eg
      Prozessor: Turion 64 MT37, Neo X2 L335, E-350
      Mainboard: E35M1-I DELUXE
      Arbeitsspeicher: 2x1 GiB DDR-333, 2x2 GiB DDR2-800, 2x2 GiB DDR3-1333
      Grafikkarte: RADEON XPRESS 200m, HD 3200, HD 4330, HD 6310
      Display: 13,3", 13,3" , Dell UltraSharp U2311H
      Festplatte(n): 100 GB, 320 GB, 120 GB +500 GB
      Optische Laufwerke: DVD-Brenner
      Betriebssystem(e): WinXP SP3, Vista SP2, Win7 SP1 64-bit
      Browser: Firefox 13
    • Mein DC

      Dr@ beim Distributed Computing

      Aktuelle Projekte: Collatz Conjecture
      Rechner: Zacate E-350 APU
      Mitglied der Kavallerie: Nein
      BOINC-Statistiken:

    Registriert seit
    19.05.2009
    Ort
    Baden-Württemberg
    Beiträge
    11.964
    Danke
    337
    Gedankt 4.181 Mal für 1.144 Themen
    Blog-Einträge
    1

    Bericht: x264 mit OpenCL-Beschleunigung

    x264 mit OpenCL-Beschleunigung - Artikel-Logo


    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.

    [BREAK=Das APU-Konzept & HSA]

    Gerne protzt AMD mit den hohen GFLOP-Leistungen - also Fließkommaberechnungen pro Sekunde - seiner Accelerated Processing Units (APUs), wobei die x86-Kerne allerdings lediglich einen geringen Anteil davon erbringen. Im Falle der A10-5800K APU werden beispielsweise beachtliche 736 GFLOPS beworben, die theoretische Spitzenleistung der vier x86-Kerne (zwei Bulldozer-Module mit jeweils einer FPU) beträgt jedoch nur 122 GFLOPS. Über 80 % der GFLOP-Leistung (614 GFLOPS) erbringt allein der Grafikkern, den AMD zusammen mit den x86-Kernen auf dem APU-Die verheiratet hat.


    Angesichts der derzeitigen Unterlegenheit der x86-Kerne gegenüber Intel wird relativ schnell klar, dass das APU-Konzept nur dann funktionieren und auf die notwendige Marktakzeptanz stoßen kann, wenn es genügend Anwendungen gibt, die auf die immense Rechenleistung der Grafikeinheit zurückgreifen können. Damit - so die Hoffnung - können die APUs ihre vermeintliche Unterlegenheit gegenüber der Konkurrenz ausgleichen, oder diese gar deutlich übertreffen. Der springende Punkt dabei ist aber eben die breite Verfügbarkeit entsprechend angepasster Anwendungen. Genau hier mangelt es derzeit noch.
    Entsprechend hat AMD in den letzten Monaten einige Initiativen angeschoben, um bei den Softwareentwicklern ebenfalls für das notwendige Interesse zu sorgen. Dazu zählen neben der Bereitstellung entsprechender Tools, APIs und SDKs auch die Entwicklerkonferenz AMD Fusion Developer Summit (AFDS), welche in diesem Jahr zum zweiten Mal veranstaltet wurde, sowie die Heterogeneous System Architecture (HSA). Mit der HSA wird eine herstellerunabhängige Hardware- und Softwarespezifikation definiert, wodurch die Programmierung heterogener Systeme deutlich erleichtert werden soll. Solche heterogenen Systeme können aus unterschiedlichsten Recheneinheiten bestehen, zu denen neben x86- oder ARM-Kernen auch Grafikeinheiten oder spezielle Fixed-Function-Einheiten (z. B. zur De- und Enkodierung von Videos) gehören können.


    Für vergrößerte Ansicht anklicken

    Bis die erste Hardware zur Verfügung steht, die zur HSA kompatibel ist, wird es allerdings noch etwas dauern. Im nächsten Jahr soll zunächst AMDs "Kaveri"-APU die Spezifikation erfüllen. In der Zwischenzeit setzt AMD darauf, gezielt einzelne Softwareprojekte bei der Implementierung einer GPU-Beschleunigung zu unterstützen, wobei als Programmierplattform zumeist OpenCL zum Einsatz kommt. Dazu zählen insbesondere auch Projekte aus dem Open-Source-Umfeld. So wurde beispielsweise der Student Victor Oliveira bei der OpenCL-Portierung der Grafikbibliothek GEGL unterstützt, die künftige Versionen von GIMP als Grafikkernel nutzen werden. Zudem hat AMD die Firma MulticoreWare engagiert, um unter anderem das Video-Tool HandBrake und den H.264-Videoencoder x264 dahingehend zu optimieren, dass sie nicht länger ausschließlich die CPU-Kerne nutzen, sondern auch auf die Ressourcen der im System verbauten Grafikkarte zurückgreifen können, um so die rechenintensive Transkodierung bzw. Enkodierung von Videos zu beschleunigen.
    Der Versuch, die Software an die eigene Hardware anzupassen, ist bei AMD mit 3DNow! schon einmal schief gegangen. Immerhin setzt das Unternehmen jetzt auf den offenen Industriestandard OpenCL und versucht von Anfang an weitere Unternehmen beim HSA-Vorstoß mit ins Boot zu holen.

    [BREAK=Interview mit Steve Borho]

    Steve Borho hat sich freundlicherweise dazu bereit erklärt, uns einige Fragen zur OpenCL-Beschleunigung von x264 zu beantworten. Er geht dabei insbesondere auf die Ziele und Herausforderungen der Implementierung ein.

    Could you please introduce yourself to our readers so they know who you are and what you are doing?
    I am Steve Borho, solution architect with MulticoreWare, Inc. Prior to joining MCW one year ago, I had worked at NVIDIA since 2008 on CUDA PhysX, and so I have quite a bit of GPGPU experience.

    What were the aims for the acceleration of x264 through OpenCL?
    AMD wants to bootstrap the use of OpenCL in open-source projects, to make the technology more mainstream. x264 was a key part of this effort. The scope and direction of the project were defined by x264's lead developer, Jason Garrett-Glaser.

    Für vergrößerte Ansicht anklicken

    How was it implemented?
    Based on Jason's direction, we added an OpenCL version of the x264 lookahead, trying to stay as close as possible to the CPU lookahead quality metrics.

    Jason and I gave a talk at AFDS that went over the challenges and implementation details. The primary differences between the CPU and OpenCL lookahead implementations are in the motion search. Because motion vectors are differentially encoded in H.264, performing a motion search is an inherently serial process. In order to find the parallelism required on a GPU, we had to use an iterative search. In order to find the best motion vectors our iterative search is hierarchical, meaning it starts at a very small scale and then increases scale as it iterates.

    Für vergrößerte Ansicht anklicken

    Can you describe how your implementation differs from other GPU accelerated encoders more detailed?
    Our efforts were focused on the lookahead only. The main encode is still entirely performed on the CPU.

    For what kind of hardware configuration can be expected the most benefit of these optimizations?
    This is difficult to answer in absolute terms. Even small mobile GPUs will get some benefit from OpenCL, even if only to offload one CPU processor so that it can spend more time with the main encode. Obviously large discrete GPUs will see more benefit.

    Für vergrößerte Ansicht anklicken

    For what kind of video source or transcoding jobs do you expect the most benefit out of the OpenCL acceleration?
    Any encode that uses the lookahead should benefit from OpenCL. The most benefit is seen when x264 is bottle-necked by the lookahead processing.

    Why is the OpenCL accelerated version of x264 much smaller than the current release r2200?
    No idea. Our patch does not remove any code. The CPU lookahead is still available via a '--no-opencl' command line switch.

    Do you see additional opportunities to use OpenCL inside x264?
    The lookahead, which was quite difficult to accelerate on the GPU, was the low hanging fruit in x264. I don't see any other obvious places where OpenCL acceleration could be added without potentially degrading x264's excellent encoding efficiency (its quality per bit).

    Für vergrößerte Ansicht anklicken

    What kind of relevance has HSA to the x264 project? Do you see further opportunities to accelerate x264 by using the GPU through HSA?
    It's possible that HSA could make a non-iterative motion search feasible on the next generation GPUs.

    Are there any plans to use the hardware encoders inside Intel CPUs, AMD APUs & GPUs and NVIDIA GPUs?
    By definition, that would no longer be x264. It would be something else. Jason has not been interested in such efforts.

    Für vergrößerte Ansicht anklicken

    So you are also not going to use the entropy encoding mode (hybrid mode) offered by AMDs VCE? What is the reason for that?
    Jason doesn't want to do this; you lose control over where bits are expended and it would make their VBV responses much worse.

    Für vergrößerte Ansicht anklicken

    When do you expect the OpenCL accelerated lookahead will go into the official release of x264?
    Jason was asked this at AFDS and his response was that he expected it to take 2 months.

    Wir möchten uns herzlich bei Steve Borho für das kurze Interview bedanken.

    Wer sich für tiefergehende Details zur OpenCL-Implementierung der lookahead-Funktion interessiert, kann diese den Folien aus dem Vortrag von Jason Garrett-Glaser - dem Projektleiter von x264 - und Steve Borho auf dem AFDS 2012 entnehmen.


    [BREAK=Methodik & Testsysteme]

    Um eine möglichst gute Vergleichbarkeit einerseits zu gewährleisten und andererseits zugleich jedem die Nachstellung der Messung zu ermöglichen, setzen wir auf den frei verfügbaren x264 Benchmark 5.0 von Tech ARP. Zusätzlich zum darin verwendeten 1080p-Video haben wir für unsere Messungen das 720p-Video aus der älteren Version 4.0 des Benchmarks herangezogen.


    Alle Messreihen wurden jeweils sowohl mit der aktuellen Revision 2200 von x264 (32-Bit-Version), die bereits zusammen mit dem x264 Benchmark 5.0 ausgeliefert wird, als auch der 32-Bit-Testversion des uns zur Verfügung gestellten OpenCL-beschleunigten x264 gefahren. Weil beide Versionen nicht dem gleichen stabilen Stand des x264-Codes entstammen, testen wir die OpenCL-beschleunigte Version sowohl mit aktivierter als auch deaktivierter Beschleunigung (Parameter --no-opencl). Dabei gilt es zu beachten, dass der Code der stabilen Revision 2200 etwas jünger ist und bereits die Threaded-Lookahead-Funktion verwenden kann. Im Change Log lässt sich zu dessen Funktionalität folgende Information finden:
    Zitat Zitat von Jason Garrett-Glaser
    Threaded lookahead

    Split each lookahead frame analysis call into multiple threads. Has a small
    impact on quality, but does not seem to be consistently any worse.

    This helps alleviate bottlenecks with many cores and frame threads. In many
    case, this massively increases performance on many-core systems. For example,
    over 100% faster 1080p encoding with --preset veryfast on a 12-core i7 system.
    Realtime 1080p30 at --preset slow should now be feasible on real systems.

    For sliced-threads, this patch should be faster regardless of settings (~10%).

    By default, lookahead threads are 1/6 of regular threads. This isn't exacting,
    but it seems to work well for all presets on real systems. With sliced-threads,
    it's the same as the number of encoding threads.
    Aus Zeitgründen haben wir keine längeren Versuchsreihen gefahren, um vermeintlich optimale Konfigurationen zu suchen. Für die Single-Pass-Messreihen werden schlicht folgende Parameter gesetzt, die bereits einen guten Kompromiss aus Kompression und Bildqualität liefern sollten:
    Code:
    --crf 24 --preset slower
    An der Konfiguration für das Two-Pass-Enkoding haben wir nichts verändert, hier kommen für beide Auflösungen die normalen, extrem fordernden Einstellungen vom x264 Benchmark 5.0 zum Einsatz.

    Damit nicht auf allen System jeder einzelne Durchlauf von Hand über die Kommandozeile (cmd) gestartet werden muss, haben wir das Skript bench_script.bat für unsere Zwecke entsprechend angepasst. Wir respektieren jedoch den Wunsch von Tech ARP, dass keine modifizierten Versionen ihres Benchmarks veröffentlicht werden sollen, schließlich haben unsere Kollegen hier eine Menge Arbeit hineingesteckt. Mit obigen Ausführung und den zum Download angebotenen OpenCL-beschleunigten Versionen von x264 sollte es aber ein Leichtes sein, die Messungen nachzustellen.

    Downloads:
    Das Passwort ist jeweils P3D.

    Achtung! Diese Kompilate von x264 unterstützen das Containerformat MP4 nicht, stattdessen sollte das MKV-Format verwendet werden.

    Für die Benchmarkläufe kamen keine speziellen Testsysteme im eigentlichen Sinne zum Einsatz, sondern Alltagssysteme aus der Redaktion. Dies sollte auch bei der Begutachtung der Messwerte im Hinterkopf behalten werden, die einen Ausblick darauf gewähren sollen, was von der OpenCL-Beschleunigung von x264 erwartet werden kann. Die unterschiedlichen verwendeten Versionen des Catalyst-Grafiktreibers sind darin begründet, dass wir mit erheblichen Treiberproblemen zu kämpfen hatten und keine Version finden konnten, die auf allen Systemen gleichermaßen stabil lief. Zu den Problemen, die bei Nutzung der OpenCL-Beschleunigung auftreten, gehören vor allem TDR-Fehler (Timeout Detection and Recovery), was zur Folge hat, dass das Betriebssystem den Treiber zurücksetzt, die OpenCL-Kernel nicht kompiliert werden und der Benchmark somit nicht läuft. Auf einem System wurde der Start des Benchmarks zudem durch einen schwarzen Bildschirm quittiert.
    Unseren Erfahrungen zufolge treten die wenigsten Probleme auf, wenn für die Grafikkarten-Serien Radeon HD 5000 und 6000 der Catalyst 12.3 WHQL verwendet wird. Mit allen aktuelleren Treiberversionen, die Unterstützung für OpenCL 1.2 bieten, traten stets TDR-Fehler auf. Selbiges kann für die aktuelle Generation auf Basis der GCN-Architektur (Radeon HD 7700 bis 7900) nicht berichtet werden, hier liefen auch neuere Treiber problemlos.

    Folgende Systemkonfigurationen kamen zum Einsatz:

    CPUSpeicherGPUTreiberBetriebssystemSonstiges
    AMD C-60 APU2 GB DDR3-1066Radeon HD 6290 384 MBCatalyst 8.945 RC2Windows 7 Starter Edition 32 bit
    -
    AMD E-350 APU @ 1,7 GHz2x 2 GB DDR3-1333 @ 700 MHzRadeon HD 6310 @ 530 MHz 512 MBCatalyst 8.945 RC2Windows 7 64 bit
    SSD
    AMD A4-3400 APU2x 4 GB DDR3-1333Radeon HD 6410D 512 MBCatalyst 12.3 WHQL (Version 8.951)Windows 7 64 bit
    -
    AMD A8-3870 APU2x 4 GB DDR3-1600Radeon HD 6550D 512 MBCatalyst 12.3 WHQL (Version 8.951)Windows 7 64 bit
    SSD
    AMD A10-4600M APU #11x 4 GB + 1x2 GB DDR3-1600Radeon HD 7660G 512 MBCatalyst 8.941.1-120209a-133535C-HPWindows 7 64 bit
    BIOS F.03 vom 27.04.2012
    AMD A10-4600M APU #21x 4 GB + 1x2 GB DDR3-1600Radeon HD 7660G 512 MBCatalyst 8.941.1-120209a-133535C-HPWindows 7 64 bit
    BIOS F.03 vom 27.04.2012
    AMD FX-8150 @ 2M4T 3,9 GHz4x 4 GB DDR3-1600Radeon HD 7750 @ 800 MHzCatalyst 8.97-120418a-137336E-ATIWindows 7 64 bit
    -
    AMD Phenom II X4 9402x 2 GB DDR2-800Radeon HD 5850Catalyst 8.945 RC2Windows 7 64 bit
    SSD
    AMD FX-61002x 4 GB DDR3-1333Radeon HD 6570Catalyst 12.3 WHQL (Version 8.951)Windows 7 64 bit
    SSD
    AMD FX-81204x 4 GB DDR3-1600Radeon HD 6950 @ 1536 SPsCatalyst 12.3 WHQL (Version 8.951)Windows 7 64 bit
    -
    AMD FX-81202x 4 GB DDR3-1333Radeon HD 7770 @ 1120 MHz / 1250 MHzCatalyst 12.3 WHQL (Version 8.951)Windows 7 64 bit
    -
    AMD FX-8150 @ 3,6 GHz4x 4 GB DDR3-1600Radeon HD 6970Catalyst 12.3 WHQL (Version 8.951)Windows 7 64 bit ohne BD-Scheduler-Patches
    FX-Testsystem
    AMD FX-81504x 4 GB DDR3-1866Radeon HD 7970Catalyst 12.6 Beta (Version 8.98)Windows 7 64 bit
    SSD
    Intel Core i7 2600K @ 3,4 GHz4x 8 GB DDR3-1600GeForce GTX 580 3 GBForceWare 301.42 BetaWindows 7 64 bit
    -


    Bei den "Trinity"-Systemen AMD A10-4600M APU #1 und AMD A10-4600M APU #2 handelt es sich um zwei prinzipiell bauartgleiche Notebooks (HP Pavilion g7-2051sg (B1L64EA)). Allerdings liefern beide Systeme signifikant voneinander abweichende Ergebnisse. Woran dies liegt, konnten wir bis Redaktionsschluss nicht abschließend klären.

    [BREAK=Vorbemerkung zu den Benchmarks]

    Wie bereits aus dem Interview mit Steve Borho hervorgeht, legen die Entwickler von x264 größten Wert darauf, dass Performanceoptimierungen nicht zu Lasten der Bildqualität oder Effizienz des Enkoders gehen. Entsprechend wurde die OpenCL-Beschleunigung auch nur für eine Teilfunktion realisiert, die durch ihre datenparallele Natur hierfür gut geeignet ist. Im Gegensatz zu vielen anderen Versuchen, einen Video-Enkoder durch Zuhilfenahme der GPU zu beschleunigen, wird bei x264 die Bildqualität nicht gegen eine erhöhte Kodierungsleistung eingetauscht. Ausschließlich zur Berechnung der lookahead-Funktion greift die OpenCL-beschleunigte Version von x264 auf die immense theoretische Rechenleistung der GPU zurück. Alles andere wird auch weiterhin auf den CPU-Kernen berechnet. Größere Steigerungen der Kodierungsleistung sind also vor allem für Fälle zu erwarten, in denen die Berechnung eben dieser lookahead-Funktion bisher der Flaschenhals war. Um allzu hohen Erwartungen gleich vorzubauen: Entsprechend deutlich geringer fallen die Zuwächse auch aus. In einigen Fällen reduziert sich die Anzahl der kodierten Bilder pro Sekunde sogar. Mögliche Gründe hierfür werden an den entsprechenden Stellen genannt.

    Außerdem müssen wir noch eine Präzisierung unserer Angaben zur GPU-beschleunigten Version von HandBrake gegenüber der damaligen News vornehmen. Laut Steve Borho verwendet HandBrake die OpenCL-beschleunigte lookahead-Funktion von x264 nämlich gar nicht. Die Verdoppelung der Transkodierungsleistung, die AnandTech für die APUs in seiner News damals aufgezeigt hat, stammt demnach ausschließlich von der von HandBrake verwendeten ffmpeg-Version, die die Dekodierung auf die UVD-Einheit auslagert und für die Skalierung die GPU per OpenCL verwendet. Wenn die GPU zusätzlich von x264 zur Berechnung der lookahead-Funktion verwendet werden würde, wäre sie der neue Flaschenhals. Die Nutzung der GPU ausschließlich zur Dekodierung und Skalierung ist daher deutlich effizienter. Somit sind die damaligen Messwerte also in keiner Weise mit den heutigen vergleichbar!

    Zu guter Letzt sei noch darauf hingewiesen, dass die Portierung der lookahead-Funktion nach OpenCL von AMD zunächst für den "Trinity"-Launch initiiert wurde. Nachfolgend wurde die Optimierung auf die GCN-Architektur sowie das weitere Beheben von Bugs durch Telestream finanziert. Entsprechend kann auch angenommen werden, dass diese Hardware am meisten profitieren wird, was insbesondere für sehr leistungsfähige Grafikkarten gilt.

    Weil in diesem Artikel der Fokus auf den Auswirkungen der OpenCL-Beschleunigung liegt, werden die Messwerte für die einzelnen Systeme im Folgenden jeweils relativ zur x264-Testversion mit deaktivierter OpenCL-Beschleunigung dargestellt, die somit immer 100 % in den Balkendiagrammen darstellt. Die Revision 2200 von x264 dient als Referenz, für die sich weitere Vergleichswerte im entsprechenden Thread bei Tech ARP finden lassen.

    [BREAK=Erste Benchmarks: Single-Pass Encoding]

    Wer sich direkt hierher auf die Ergebnisse unserer Benchmarks gestürzt hat, dem möchten wir dringend empfehlen, zuvor zumindest unsere zugehörigen Vorbemerkungen zu studieren.

    Als erstes werfen wir einen Blick auf die Ergebnisse für das Transkodieren des 720p-Videos vom MPEG2- ins H.264-Format, wobei die Enkodierung durch x264 im Single-Pass-Modus - also in einem Rutsch - erfolgt.

    x264 mit OpenCL-Beschleunigung - Diagramme


    Offensichtlich können die APUs von der OpenCL-Beschleunigung nicht profitieren. Es macht nahezu keinen Unterschied, ob sie aktiviert wird oder nicht. Die kleinste APU im Testfeld bricht sogar bei Aktivierung um 12 % ein.
    Für die leistungsfähigeren Systemen mit potenter eigenständiger Grafikkarte sieht es etwas besser aus. Hier ist eine um 8 bis 9 % höhere Kodierungsleistung zu verzeichnen. Schon hier wird deutlich, dass die Grafikkarte eine gewisse Mindestperformance passend zur verwendeten CPU benötigt, damit überhaupt ein Effekt eintritt.

    Ob sich an diesen Beobachtungen bei höheren Auflösungen etwas ändert, wollen wir nachfolgend anhand des 1080p-Videos untersuchen.

    x264 mit OpenCL-Beschleunigung - Diagramme


    Auch bei der höheren Auflösung können die APUs von der OpenCL-Beschleunigung nicht profitieren. Einziger Lichtblick sind die 3 % höheren fps, die die E-350 APU erzielt.
    Die Kombinationen sowohl aus leistungsstarker CPU als auch leistungsstarker, eigenständiger Grafikkarte legen um 9 bis 12 % zu. Wie das Beispiel FX-6100 + Radeon HD 6570 zeigt, muss die Leistungsfähigkeit der Grafikkarte aber zur CPU passen, ansonsten kann sich die Kodierungsleistung sogar verringern, wenn die OpenCL-beschleunigte lookahead-Funktion Verwendung findet.

    [BREAK=Erste Benchmarks: Two-Pass Encoding 720p]

    Beim Two-Pass Encoding wird die Arbeit auf zwei Durchläufe aufgeteilt, um die variable Datenrate optimal über das Video zu verteilen, sodass für das Gesamtvideo ein vorgegebener Zielwert eingehalten wird. Im ersten Durchlauf erfolgt daher zunächst die Analyse des Videomaterials, bevor darauf basierend die eigentlich Enkodierung im zweiten Durchlauf erledigt wird.

    Im Analyse-Kompressionslauf spielt die Berechnung der lookahead-Funktion eine entscheidende Rolle, weshalb x264 stark von der OpenCL-Beschleunigung profitieren können sollte. Werfen wir also einen Blick auf die Ergebnisse für das 720p-Video.

    x264 mit OpenCL-Beschleunigung - Diagramme


    Bei aktivierter OpenCL-Beschleunigung brechen die APUs auf zwei Drittel der Kodierungsleistung ein, teilweise halbiert sie sich sogar. Unter Berücksichtigung der Ergebnisse für die Kombination aus FX-6100 und Radeon HD 6570 könnte eine mögliche Erklärung hierfür sein, dass die Rechenleistung der integrierten GPUs schlicht nicht ausreicht. Inwiefern eine Bandbreitenlimitierung vorliegt, konnte aus zeitlichen Gründen bisher nicht eingehend untersucht werden. Warum das zweite "Trinity"-System dieses Verhalten nicht zeigt, können wir aktuell ebenfalls nicht erklären.
    Ganz anders sieht es dafür erneut bei den Testsystemen aus, wo der CPU von einer eigenständigen Grafikkarte unter die Arme gegriffen wird. Besteht die richtige Balance zwischen CPU- und GPU-Power, legen die Kodierungsraten um beachtliche 80 bis 108 % zu. Einziger negativer Ausreißer in unserem Testfeld ist dabei das bereits benannte Duo aus FX-6100 und Radeon HD 6570.

    Für den nachfolgenden zweiten Durchlauf erwarten wir hingegen keine Unterschiede zwischen aktivierter und deaktivierter OpenCL-Beschleunigung, da hier von der lookahead-Funktion kein Gebrauch gemacht wird. Auf Basis der Analyseergebnisse aus dem ersten Durchlauf wird auf der CPU die eigentliche Kompression des Videos berechnet. Was aber sagen die Zahlen?

    x264 mit OpenCL-Beschleunigung - Diagramme


    Auf fast allen getesteten Systemen läuft die Berechnung des zweiten Durchlaufs minimal langsamer ab, wenn die OpenCL-Beschleunigung aktiviert ist. Steve Borho hat uns zwei potentielle Erklärungen hierfür genannt: Es ist möglich, dass die OpenCL-beschleunigte lookahead-Funktion gegenüber der CPU-Version (im ersten Durchlauf) mehr B-Frames, die sehr rechenintensiv sind, erzeugt und/oder längere Bewegungsvektoren findet.

    Wie sieht aber die Endabrechnung aus? Um diese Frage beantworten zu können, haben wir mit Hilfe der Gesamtanzahl an Frames, aus denen das Video besteht und den fps, die im ersten und zweiten Durchlauf erzielt wurden, die Gesamtlaufzeit für die Umwandlung des Videos berechnet.

    x264 mit OpenCL-Beschleunigung - Diagramme


    Der viel langsamere zweite Durchlauf relativiert die Performancesteigerungen aus dem ersten Durchlauf stark, sodass in der Endabrechnung bestenfalls eine 10 % schnellere Enkodierung zu verbuchen ist.

    [BREAK=Erste Benchmarks: Two-Pass Encoding 1080p]

    Für das 1080p erwarten wir eine nochmals höhere Leistung im ersten Durchgang, da mit der höheren Pixelanzahl die Datenparallelität weiter zunimmt, was wiederum den GPUs zugutekommen sollte.

    x264 mit OpenCL-Beschleunigung - Diagramme


    In der Tat brechen die APUs etwas weniger stark ein. Aber auch die Kombinationen aus CPU und eigenständiger Grafikkarte können nochmals stärker zulegen. Für die Tandems mit guter Balance aus CPU- und GPU-Leistung kann die Aktivierung der OpenCL-Beschleunigung mehr als eine Verdoppelung der Kodierungsleistung bedeuten.

    x264 mit OpenCL-Beschleunigung - Diagramme


    Im Gegensatz zum 720p-Video fallen hier die Unterschiede zwischen aktiver und deaktivierter Beschleunigung im zweiten Durchlauf deutlicher aus. Die von der CPU-Version abweichenden Analyseergebnisse der OpenCL-lookahead-Funktion aus dem ersten Durchlauf haben eine Reduktion der Kodierungsleistung um bis zu 8 % zur Folge. Was natürlich auch Auswirkungen auf die Endabrechnung hat.

    x264 mit OpenCL-Beschleunigung - Diagramme


    Denn hier schneiden nicht die Systeme am besten ab, die im ersten Durchgang noch am schnellsten waren. Zusammengenommen profitiert das Two-Pass Encoding in unserem Testszenario bestenfalls zwischen 10 und 15 % von der OpenCL-Beschleunigung.

    [BREAK=Vorläufiges Fazit]
    x264 mit OpenCL-Beschleunigung - Artikel-Logo


    Gerade für die APUs fällt das vorläufige Fazit auf Basis unserer Benchmarkergebnisse sehr enttäuschend aus. Fast durchgehend reduziert sich - zum Teil sogar erheblich - die Kodierungsleistung, wenn die OpenCL-beschleunigte lookahead-Funktion verwendet wird. Das "beste Ergebnis" kann die E-350 APU beim Single-Pass Encoding für sich verbuchen, wo eine zweiprozentige Leistungssteigerung sowohl für das 720p- (2,17 %) als auch das 1080p-Ausgangsmaterial (2,54 %) zu verzeichnen ist. Allerdings sorgt die andere "Ontario"-APU C-60 zugleich mit -12 bzw. -9 % hier für die größten Verluste.
    Beim Two-Pass Encoding bricht die Kodierungsleistung im ersten Durchgang, in dem gerade die Berechnung der lookahead-Funktion die entscheidende Rolle spielt, dann regelrecht ein. Im Falle der A4-3400 APU halbiert sich die Leistung sogar, wenn die OpenCL-Beschleunigung zugeschaltet wird. Weil die Berechnungen im zweiten Durchgang deutlich langsamer ablaufen, relativieren sich die Verluste in der Gesamtabrechnung, sodass die Umwandlung zwischen 6 und 19 % länger dauert. Einzig das zweite "Trinity"-System zeigt praktisch keine Veränderung zwischen aktiver und deaktivierter OpenCL-Beschleunigung.

    Kommt hingegen eine eigenständige Grafikkarte zum Einsatz, sind bis auf eine Ausnahme durchgehend höhere Kodierungsleistungen zu beobachten, wenn die OpenCL-Beschleunigung Verwendung findet. Das Single-Pass Encoding wird bestenfalls zwischen 8 und 12 % beschleunigt.
    So richtig auftrumpfen kann die OpenCL-Version der lookahead-Funktion dann im ersten Durchgang beim Two-Pass Encoding: Die Kombination aus Intel Core i7 2600K und GeForce GTX 580 erledigt die Berechnungen für das 720p-Video doppelt so schnell (+108 %). Wird das höher aufgelöste Ausgangsmaterial verwendet, schafft das selbe Duo sogar eine Steigerung um 123 %. In der Endabrechnung relativieren sich die Vorteile dann infolge des deutlich langsameren zweiten Durchgangs auf eine Verkürzung der Berechnungszeit zwischen 1 und 15 %. Lediglich der Kombination aus AMD FX-6100 und Radeon HD 6570 mangelt es offenbar an Grafikkartenpower im Verhältnis zur Leistungsfähigkeit der CPU, da hier Einbrüche um 5 % (720p) und 15 % (1080p) zu verzeichnen sind.

    Aber auch die positiveren Ergebnisse für die Kombination aus CPU und eigenständiger Grafikkarte haben einen Wermutstropfen. Die hier als Referenz dienende, tendenziell minimal schnellere Revision 2200 von x264 kann auf den Prozessoren mit acht logischen Kernen offenbar erheblich von der neuen Threaded-Lookahead-Funktion profitieren. Beim Single-Pass Encoding werden 4 bis 6 % höhere Kodierungsraten gegenüber der x264-Testversion erreicht, wenn die OpenCL-Beschleunigung deaktiviert ist. Das Two-Pass Encoding läuft dann sogar 10 bis 13 % schneller und liegt somit auf dem Niveau der Testversion mit aktivierter OpenCL-Beschleunigung.

    Wie repräsentativ die gezeigten Ergebnisse sind, lässt sich nicht final abschätzen, da hierzu schlicht die Erfahrungswerte fehlen. Es ist gut möglich, dass sich bei Verwendung eines anderen Ausgangsmaterials sowie anderer Enkodier-Parameter deutlich bessere Ergebnisse erzielen lassen. Genauso gut können diese aber auch schlechter ausfallen.
    Abschließend sei zudem nochmals darauf hingewiesen, dass es sich bei der hier verwendeten Version von x264 mit OpenCL-Beschleunigung um eine Vorabversion handelt. Eine erste finale, stabile Version, die zur Berechnung der lookahead-Funktion auf die GPU zurückgreifen kann, ist erst in den nächsten ein bis zwei Monaten zu erwarten. Auch wenn wir mit keinen größeren Veränderungen hinsichtlich der Erkenntnisse diese Artikels rechnen, ist dies natürlich nicht gänzlich auszuschließen. Bleibt zu hoffen, dass AMD bis dahin zumindest einen Grafiktreiber liefern kann, der auf allen unterstützten Systemen stabil mit x264 zusammenarbeitet.


  2. Die folgenden 20 Benutzer sagen Danke zu Dr@ für diesen nützlichen Beitrag:

    Atlan78 (27.06.2012), bbott (27.06.2012), BLJ (27.06.2012), cumulus (27.06.2012), deoroller (27.06.2012), derDruide (23.07.2012), Herr Melin (27.06.2012), ICEMAN (27.06.2012), Makso (27.06.2012), Mike (27.06.2012), Myrthain (05.07.2012), Reina (27.06.2012), Sefegiru (27.06.2012), SemtexX_ (27.06.2012), Shadowtrooper (27.06.2012), Shai Hulud (27.06.2012), tex_ (27.06.2012), Unbekannter Krieger (09.12.2013), wolle23 (27.06.2012), yakon (28.06.2012)

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  
Single Sign On provided by vBSSO