App installieren
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Anmerkung: This feature may not be available in some browsers.
Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden.
Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Artikel Neuer Artikel: Bericht: x264 mit OpenCL-Beschleunigung
- Ersteller Dr@
- Erstellt am
Dr@
Grand Admiral Special
- Mitglied seit
- 19.05.2009
- Beiträge
- 12.791
- Renomée
- 4.066
- Standort
- Baden-Württemberg
- Aktuelle Projekte
- Collatz Conjecture
- Meine Systeme
- Zacate E-350 APU
- BOINC-Statistiken
- Mein Laptop
- FSC Lifebook S2110, HP Pavilion dm3-1010eg
- Prozessor
- Turion 64 MT37, Neo X2 L335, E-350
- Mainboard
- E35M1-I DELUXE
- Speicher
- 2x1 GiB DDR-333, 2x2 GiB DDR2-800, 2x2 GiB DDR3-1333
- Grafikprozessor
- RADEON XPRESS 200m, HD 3200, HD 4330, HD 6310
- Display
- 13,3", 13,3" , Dell UltraSharp U2311H
- HDD
- 100 GB, 320 GB, 120 GB +500 GB
- Optisches Laufwerk
- DVD-Brenner
- Betriebssystem
- WinXP SP3, Vista SP2, Win7 SP1 64-bit
- Webbrowser
- Firefox 13
<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!
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!
Nightshift
Grand Admiral Special
- Mitglied seit
- 19.08.2002
- Beiträge
- 4.447
- Renomée
- 81
- Standort
- Tief im Weeeeeesss-teheheheeen ;-)
- Mitglied der Planet 3DNow! Kavallerie!
- Aktuelle Projekte
- SIMAP, Docking, POEM
- Lieblingsprojekt
- SIMAP
- Meine Systeme
- Ci7-3770K@3,8 GHz, C2Q 9550@3,4 GHz, AthlonII 620 X4 (+ 2x Ci3-2100, 2x C2D 8400, 9x A4-3420, E-450)
- BOINC-Statistiken
- Prozessor
- Ryzen 7 3700X @stock
- Mainboard
- Gigabyte X570 Aorus Elite
- Kühlung
- Noctua NH-D15 chromax.black
- Speicher
- 2x 16 GB Corsair Vengeance LPX (schwarz) PC4-25600U (DDR4-3200) CL16-18-18-36 @stock
- Grafikprozessor
- Powercolor RX 5700 Red Dragon @stock
- Display
- Eizo FlexScan EV2750
- SSD
- Corsair MP600 1TB M.2 NVMe | Kingston A2000 NVMe PCIe SSD 1TB | Samsung 850 EVO 500 GB
- Optisches Laufwerk
- LG BH16NS55| NEC AD-7203S
- Soundkarte
- onboard :-P der Hardwaregott habe meine Creative Audgiy 2ZS selig
- Gehäuse
- Nanoxia Deep Silence 5, schallgedämmt
- Netzteil
- be quiet! Straight Power E11 650W
- Tastatur
- Razer Ornata Chroma
- Maus
- Logitech Lift for Business
- Betriebssystem
- Win 10 Pro 64bit
- Webbrowser
- Firefox
- Verschiedenes
- rockstable & silent
- Schau Dir das System auf sysprofile.de an
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.
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
Grand Admiral Special
- Mitglied seit
- 11.11.2001
- Beiträge
- 4.363
- Renomée
- 60
- Mein Laptop
- HP Compaq 8510p
- Prozessor
- AMD FX-8370
- Mainboard
- Asus M5A99X
- Kühlung
- Corsair H60
- Speicher
- 16GB DDR3-1866 Crucial
- Grafikprozessor
- Sapphire HD5770
- Display
- 4k 27" DELL
- SSD
- Samsung Evo 850
- HDD
- 2x Seagate 7200.12
- Optisches Laufwerk
- Pioneer, Plextor
- Soundkarte
- Creative X-Fi Xtreme Music
- Gehäuse
- Silverstone TJ-02S
- Netzteil
- Enermax 450W
- Betriebssystem
- Windows 7
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
Moderation MBDB, ,
- Mitglied seit
- 16.10.2000
- Beiträge
- 17.032
- Renomée
- 267
- Standort
- NRW
- Prozessor
- Phenom II X4 940 BE, C2-Stepping (undervolted)
- Mainboard
- Gigabyte GA-MA69G-S3H (BIOS F7)
- Kühlung
- Noctua NH-U12F
- Speicher
- 4 GB DDR2-800 ADATA/OCZ
- Grafikprozessor
- Radeon HD 5850
- Display
- NEC MultiSync 24WMGX³
- SSD
- Samsung 840 Evo 256 GB
- HDD
- WD Caviar Green 2 TB (WD20EARX)
- Optisches Laufwerk
- Samsung SH-S183L
- Soundkarte
- Creative X-Fi EM mit YouP-PAX-Treibern, Headset: Sennheiser PC350
- Gehäuse
- Coolermaster Stacker, 120mm-Lüfter ersetzt durch Scythe S-Flex, zusätzliche Staubfilter
- Netzteil
- BeQuiet 500W PCGH-Edition
- Betriebssystem
- Windows 7 x64
- Webbrowser
- Firefox
- Verschiedenes
- Tastatur: Zowie Celeritas Caseking-Mod (weiße Tasten)
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.
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
Grand Admiral Special
- Mitglied seit
- 30.01.2008
- Beiträge
- 12.228
- Renomée
- 536
- Standort
- Im wilden Süden (0711)
- Mitglied der Planet 3DNow! Kavallerie!
- Aktuelle Projekte
- NumberFields@home
- Lieblingsprojekt
- none, try all
- Meine Systeme
- RYZEN R9 3900XT @ ASRock Taichi X570 & ASUS RX Vega64
- BOINC-Statistiken
- Prozessor
- AMD Ryzen 9 5950X
- Mainboard
- ASRock 570X Taichi P5.05 Certified
- Kühlung
- AlphaCool Eisblock XPX, 366x40mm Radiator 6l Brutto m³
- Speicher
- 2x 16 GiB DDR4-3600 CL26 Kingston (Dual Rank, unbuffered ECC)
- Grafikprozessor
- 1x ASRock Radeon RX 6950XT Formula OC 16GByte GDDR6 VRAM
- Display
- SAMSUNG Neo QLED QN92BA 43" up to 4K@144Hz FreeSync PP HDR10+
- SSD
- WD_Black SN850 PCI-Express 4.0 NVME
- HDD
- 3 Stück
- Optisches Laufwerk
- 1x HL-DT-ST BD-RE BH10LS30 SATA2
- Soundkarte
- HD Audio (onboard)
- Gehäuse
- SF-2000 Big Tower
- Netzteil
- Corsair RM1000X (80+ Gold)
- Tastatur
- Habe ich
- Maus
- Han I
- Betriebssystem
- Windows 10 x64 Professional (up to date!)
- Webbrowser
- @Chrome.Google & Edge Chrome
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
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
Dr@
Grand Admiral Special
- Mitglied seit
- 19.05.2009
- Beiträge
- 12.791
- Renomée
- 4.066
- Standort
- Baden-Württemberg
- Aktuelle Projekte
- Collatz Conjecture
- Meine Systeme
- Zacate E-350 APU
- BOINC-Statistiken
- Mein Laptop
- FSC Lifebook S2110, HP Pavilion dm3-1010eg
- Prozessor
- Turion 64 MT37, Neo X2 L335, E-350
- Mainboard
- E35M1-I DELUXE
- Speicher
- 2x1 GiB DDR-333, 2x2 GiB DDR2-800, 2x2 GiB DDR3-1333
- Grafikprozessor
- RADEON XPRESS 200m, HD 3200, HD 4330, HD 6310
- Display
- 13,3", 13,3" , Dell UltraSharp U2311H
- HDD
- 100 GB, 320 GB, 120 GB +500 GB
- Optisches Laufwerk
- DVD-Brenner
- Betriebssystem
- WinXP SP3, Vista SP2, Win7 SP1 64-bit
- Webbrowser
- Firefox 13
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.
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
Grand Admiral Special
- Mitglied seit
- 23.05.2009
- Beiträge
- 3.671
- Renomée
- 135
- Aktuelle Projekte
- constalation astroids yoyo
- Lieblingsprojekt
- yoyo doking
- Meine Systeme
- Ryzen 3950x
- BOINC-Statistiken
- Prozessor
- AMD 5800X3D
- Mainboard
- Asus ROG Crosshair VIII Dark Hero
- Kühlung
- Headkiller IV
- Speicher
- 3800CL14 G.Skill Trident Z silber/rot DIMM Kit 32GB, DDR4-3600, CL15-15-15-35 (F4-3600C15D-16GTZ)
- Grafikprozessor
- AMD Radeon RX 6900 XT Ref. @Alphacool
- Display
- MSI Optix MAG27CQ
- SSD
- SN8502TB,MX5001TB,Vector150 480gb,Vector 180 256gb,Sandisk extreme 240gb,RD400 512gb
- HDD
- n/a
- Optisches Laufwerk
- n/a
- Soundkarte
- Soundblaster X4
- Gehäuse
- Phanteks Enthoo Pro 2 Tempered Glass
- Netzteil
- Seasonic Prime GX-850 850W
- Tastatur
- Logitech G19
- Maus
- Logitech G703
- Betriebssystem
- Win 10 pro
- Webbrowser
- IE 11 Mozilla Opera
- Verschiedenes
- Logitech PRO RENNLENKRAD DD
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
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
Grand Admiral Special
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.
8) ...weitere Infos zu GPU Encoding Benchmarks... NVIDIA ... AMD ... vs. Intel Quick Sync.
http://www.tomshardware.de/ivy-bridge-benchmark-core-i7-3770k,testberichte-241007-7.html
http://www.tomshardware.de/ivy-bridge-benchmark-core-i7-3770k,testberichte-241007-7.html
Und wie so schön im Artikel steht:
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...
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.... und nun sind AMD mit der Video Codec Engine und Nvidia mit NVEnc am Start.
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@
Grand Admiral Special
- Mitglied seit
- 19.05.2009
- Beiträge
- 12.791
- Renomée
- 4.066
- Standort
- Baden-Württemberg
- Aktuelle Projekte
- Collatz Conjecture
- Meine Systeme
- Zacate E-350 APU
- BOINC-Statistiken
- Mein Laptop
- FSC Lifebook S2110, HP Pavilion dm3-1010eg
- Prozessor
- Turion 64 MT37, Neo X2 L335, E-350
- Mainboard
- E35M1-I DELUXE
- Speicher
- 2x1 GiB DDR-333, 2x2 GiB DDR2-800, 2x2 GiB DDR3-1333
- Grafikprozessor
- RADEON XPRESS 200m, HD 3200, HD 4330, HD 6310
- Display
- 13,3", 13,3" , Dell UltraSharp U2311H
- HDD
- 100 GB, 320 GB, 120 GB +500 GB
- Optisches Laufwerk
- DVD-Brenner
- Betriebssystem
- WinXP SP3, Vista SP2, Win7 SP1 64-bit
- Webbrowser
- Firefox 13
@ 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.
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.
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.
WindHund
Grand Admiral Special
- Mitglied seit
- 30.01.2008
- Beiträge
- 12.228
- Renomée
- 536
- Standort
- Im wilden Süden (0711)
- Mitglied der Planet 3DNow! Kavallerie!
- Aktuelle Projekte
- NumberFields@home
- Lieblingsprojekt
- none, try all
- Meine Systeme
- RYZEN R9 3900XT @ ASRock Taichi X570 & ASUS RX Vega64
- BOINC-Statistiken
- Prozessor
- AMD Ryzen 9 5950X
- Mainboard
- ASRock 570X Taichi P5.05 Certified
- Kühlung
- AlphaCool Eisblock XPX, 366x40mm Radiator 6l Brutto m³
- Speicher
- 2x 16 GiB DDR4-3600 CL26 Kingston (Dual Rank, unbuffered ECC)
- Grafikprozessor
- 1x ASRock Radeon RX 6950XT Formula OC 16GByte GDDR6 VRAM
- Display
- SAMSUNG Neo QLED QN92BA 43" up to 4K@144Hz FreeSync PP HDR10+
- SSD
- WD_Black SN850 PCI-Express 4.0 NVME
- HDD
- 3 Stück
- Optisches Laufwerk
- 1x HL-DT-ST BD-RE BH10LS30 SATA2
- Soundkarte
- HD Audio (onboard)
- Gehäuse
- SF-2000 Big Tower
- Netzteil
- Corsair RM1000X (80+ Gold)
- Tastatur
- Habe ich
- Maus
- Han I
- Betriebssystem
- Windows 10 x64 Professional (up to date!)
- Webbrowser
- @Chrome.Google & Edge Chrome
Das kann am SI der GTX580 liegen, wesenltich mehr "bums" hat der I7-2600k defentiv nicht.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
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@
Grand Admiral Special
- Mitglied seit
- 19.05.2009
- Beiträge
- 12.791
- Renomée
- 4.066
- Standort
- Baden-Württemberg
- Aktuelle Projekte
- Collatz Conjecture
- Meine Systeme
- Zacate E-350 APU
- BOINC-Statistiken
- Mein Laptop
- FSC Lifebook S2110, HP Pavilion dm3-1010eg
- Prozessor
- Turion 64 MT37, Neo X2 L335, E-350
- Mainboard
- E35M1-I DELUXE
- Speicher
- 2x1 GiB DDR-333, 2x2 GiB DDR2-800, 2x2 GiB DDR3-1333
- Grafikprozessor
- RADEON XPRESS 200m, HD 3200, HD 4330, HD 6310
- Display
- 13,3", 13,3" , Dell UltraSharp U2311H
- HDD
- 100 GB, 320 GB, 120 GB +500 GB
- Optisches Laufwerk
- DVD-Brenner
- Betriebssystem
- WinXP SP3, Vista SP2, Win7 SP1 64-bit
- Webbrowser
- Firefox 13
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
Grand Admiral Special
- Mitglied seit
- 30.01.2008
- Beiträge
- 12.228
- Renomée
- 536
- Standort
- Im wilden Süden (0711)
- Mitglied der Planet 3DNow! Kavallerie!
- Aktuelle Projekte
- NumberFields@home
- Lieblingsprojekt
- none, try all
- Meine Systeme
- RYZEN R9 3900XT @ ASRock Taichi X570 & ASUS RX Vega64
- BOINC-Statistiken
- Prozessor
- AMD Ryzen 9 5950X
- Mainboard
- ASRock 570X Taichi P5.05 Certified
- Kühlung
- AlphaCool Eisblock XPX, 366x40mm Radiator 6l Brutto m³
- Speicher
- 2x 16 GiB DDR4-3600 CL26 Kingston (Dual Rank, unbuffered ECC)
- Grafikprozessor
- 1x ASRock Radeon RX 6950XT Formula OC 16GByte GDDR6 VRAM
- Display
- SAMSUNG Neo QLED QN92BA 43" up to 4K@144Hz FreeSync PP HDR10+
- SSD
- WD_Black SN850 PCI-Express 4.0 NVME
- HDD
- 3 Stück
- Optisches Laufwerk
- 1x HL-DT-ST BD-RE BH10LS30 SATA2
- Soundkarte
- HD Audio (onboard)
- Gehäuse
- SF-2000 Big Tower
- Netzteil
- Corsair RM1000X (80+ Gold)
- Tastatur
- Habe ich
- Maus
- Han I
- Betriebssystem
- Windows 10 x64 Professional (up to date!)
- Webbrowser
- @Chrome.Google & Edge Chrome
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
Ich bin mit Dr@ dran das Problem zu indentifizieren. Kann sich nur um Tage handeln
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
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
Dr@
Grand Admiral Special
- Mitglied seit
- 19.05.2009
- Beiträge
- 12.791
- Renomée
- 4.066
- Standort
- Baden-Württemberg
- Aktuelle Projekte
- Collatz Conjecture
- Meine Systeme
- Zacate E-350 APU
- BOINC-Statistiken
- Mein Laptop
- FSC Lifebook S2110, HP Pavilion dm3-1010eg
- Prozessor
- Turion 64 MT37, Neo X2 L335, E-350
- Mainboard
- E35M1-I DELUXE
- Speicher
- 2x1 GiB DDR-333, 2x2 GiB DDR2-800, 2x2 GiB DDR3-1333
- Grafikprozessor
- RADEON XPRESS 200m, HD 3200, HD 4330, HD 6310
- Display
- 13,3", 13,3" , Dell UltraSharp U2311H
- HDD
- 100 GB, 320 GB, 120 GB +500 GB
- Optisches Laufwerk
- DVD-Brenner
- Betriebssystem
- WinXP SP3, Vista SP2, Win7 SP1 64-bit
- Webbrowser
- Firefox 13
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.
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.
WindHund
Grand Admiral Special
- Mitglied seit
- 30.01.2008
- Beiträge
- 12.228
- Renomée
- 536
- Standort
- Im wilden Süden (0711)
- Mitglied der Planet 3DNow! Kavallerie!
- Aktuelle Projekte
- NumberFields@home
- Lieblingsprojekt
- none, try all
- Meine Systeme
- RYZEN R9 3900XT @ ASRock Taichi X570 & ASUS RX Vega64
- BOINC-Statistiken
- Prozessor
- AMD Ryzen 9 5950X
- Mainboard
- ASRock 570X Taichi P5.05 Certified
- Kühlung
- AlphaCool Eisblock XPX, 366x40mm Radiator 6l Brutto m³
- Speicher
- 2x 16 GiB DDR4-3600 CL26 Kingston (Dual Rank, unbuffered ECC)
- Grafikprozessor
- 1x ASRock Radeon RX 6950XT Formula OC 16GByte GDDR6 VRAM
- Display
- SAMSUNG Neo QLED QN92BA 43" up to 4K@144Hz FreeSync PP HDR10+
- SSD
- WD_Black SN850 PCI-Express 4.0 NVME
- HDD
- 3 Stück
- Optisches Laufwerk
- 1x HL-DT-ST BD-RE BH10LS30 SATA2
- Soundkarte
- HD Audio (onboard)
- Gehäuse
- SF-2000 Big Tower
- Netzteil
- Corsair RM1000X (80+ Gold)
- Tastatur
- Habe ich
- Maus
- Han I
- Betriebssystem
- Windows 10 x64 Professional (up to date!)
- Webbrowser
- @Chrome.Google & Edge Chrome
Daran hat sich auch nicht viel geändert, ich vermute mal, dass es sich es mit den neuen Befehlssätze überschnitten hat.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
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
Dr@
Grand Admiral Special
- Mitglied seit
- 19.05.2009
- Beiträge
- 12.791
- Renomée
- 4.066
- Standort
- Baden-Württemberg
- Aktuelle Projekte
- Collatz Conjecture
- Meine Systeme
- Zacate E-350 APU
- BOINC-Statistiken
- Mein Laptop
- FSC Lifebook S2110, HP Pavilion dm3-1010eg
- Prozessor
- Turion 64 MT37, Neo X2 L335, E-350
- Mainboard
- E35M1-I DELUXE
- Speicher
- 2x1 GiB DDR-333, 2x2 GiB DDR2-800, 2x2 GiB DDR3-1333
- Grafikprozessor
- RADEON XPRESS 200m, HD 3200, HD 4330, HD 6310
- Display
- 13,3", 13,3" , Dell UltraSharp U2311H
- HDD
- 100 GB, 320 GB, 120 GB +500 GB
- Optisches Laufwerk
- DVD-Brenner
- Betriebssystem
- WinXP SP3, Vista SP2, Win7 SP1 64-bit
- Webbrowser
- Firefox 13
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.
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 ^^
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 ^^
Dr@
Grand Admiral Special
- Mitglied seit
- 19.05.2009
- Beiträge
- 12.791
- Renomée
- 4.066
- Standort
- Baden-Württemberg
- Aktuelle Projekte
- Collatz Conjecture
- Meine Systeme
- Zacate E-350 APU
- BOINC-Statistiken
- Mein Laptop
- FSC Lifebook S2110, HP Pavilion dm3-1010eg
- Prozessor
- Turion 64 MT37, Neo X2 L335, E-350
- Mainboard
- E35M1-I DELUXE
- Speicher
- 2x1 GiB DDR-333, 2x2 GiB DDR2-800, 2x2 GiB DDR3-1333
- Grafikprozessor
- RADEON XPRESS 200m, HD 3200, HD 4330, HD 6310
- Display
- 13,3", 13,3" , Dell UltraSharp U2311H
- HDD
- 100 GB, 320 GB, 120 GB +500 GB
- Optisches Laufwerk
- DVD-Brenner
- Betriebssystem
- WinXP SP3, Vista SP2, Win7 SP1 64-bit
- Webbrowser
- Firefox 13
Hmm, also Last sollte auf der Radeon schon entstehen. Allerdings nur, wenn Du auf eine andere Auflösung skalierst.
Ähnliche Themen
- Antworten
- 0
- Aufrufe
- 465
- Antworten
- 0
- Aufrufe
- 799
- Antworten
- 21
- Aufrufe
- 9K
- Antworten
- 84
- Aufrufe
- 22K