JavaScript ist deaktiviert. Für eine bessere Darstellung aktiviere bitte JavaScript in deinem Browser, bevor du fortfährst.

Auf Thema antworten

Nachricht: <blockquote data-quote="Dr@" data-source="post: 4632903" data-attributes="member: 54308">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: 59061st 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:132nd Pass ohne OCL: 11,77 fps (8.001,89 kb/s) ---> 00:08:222nd Pass mit OCL: 11,24 fps (8.010,10 kb/s) ---> 00:08:45T-P E ohne OCL: 00:11:05T-P E mit OCL:  00:09:58Es 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:44T-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.</blockquote>

Verifizierung: Eine Münze hat wie viele Seiten?

Oben Unten