Die GPU-Auslastung lasse ich mir mit GPU-Z anzeigen.
Die Auslastung ist eigentlich immer geringt, egal ob beim Rendern oder in der Vorschau. Egal ob Schnitt oder Export. Selbst beim Multivcamschnitt ist die Auslastung gering, die Arbeit macht der Prozessor alleine.
Es ist zum einen Canon 5D 1080p H.264 und Blackmagic DNxHD Material.
Ich habe Magic Bullet Looks zur leichten Farbkorrektur und Unscharf maskieren benutzt.
Wenn ich diese Effekte deaktiviere, macht das keinen Unterschied bezüglich der Grafikkarten-Auslastung.
Dummerweise wurde die Sequenz falsch angelegt, ich schneide nicht in einer 1920x1080er sondern in einer 1440x1080er Sequenz (Das lässt sich leider nicht mehr ändern, weil Multicamsequenz und schon geschnitten). Hier muss Premiere ja also beim Abspielen (Vorschau) umrechnen. Ich ging eigentlich davon aus, dass gerade hier nun die Grafikkarte gefordert wird. Auch ohne Effekte. Ist aber nicht der Fall.
Zum decodieren des Ausgangsmaterials greift Premiere prinzipiell (wie auch andere NLEs) auf die CPU zurück. Das benötigt für die h264 Files mehr Ressourcen als für DNxHD. (Aber hier könnte es schon eine Art Flaschenhals geben, die CPU muss zur GPU "passen", also nicht zu schwach sein.) Für die Vorschau mit Effekten greift die Software dann auf die mercury engine zurück, bei bestimmten Karten Hardware-unterstützt. Ob Magic Bullet davon überhaupt profitiert (und wie stark) wäre hier die erste Frage. Könnte auch OpenGL oder sowas sein. Multicam-Schnitt sollte eigentlich in der fertigen Sequenz keine Rolle mehr spielen (weiss ich aber nicht 100prozentig).
Allgemein kann man sicher sagen, 8 Prozent GPU-Auslastung sagt nicht alzu viel aus. Schalte mal die Hardwareunterstützung aus, dann siehst du den Unterschied zur reinen Softwarelösung.
Wenn du aber glaubst, zuviel Geld in die GPU gesteckt zu haben, weil sie eher überdimensioniert für Premiere ist, wissen tue ichs nicht, aber abhängig vom Gesamtsystem wird da meiner Meinung nach viel zu häufig mit Kanonen auf Spatzen geschossen.
Also bei mir gibt es merkliche Unterschiede zwischen meiner alten Radeon 6950 und der GTX670.
Die CPU ist definitiv kein Flaschenhals, egal was für ne GPU ;-)
Bei mir (CS6) war es so, dass ich das File mit den enthaltenen CUDA-Karten (irgend etwas mit CUDA im Premiere Verzeichnis) löschen musste (ist eh nur nen Text-File mit Karten-Typen drin) und anschließend konnte ich für ein Projekt auch die Mercury Engine aktivieren.
Die Mercury-Engine muss bei GPU, nicht bei Software aktiviert sein.
moschuuu hat geschrieben:Es macht intertessanterweise keinen Unterschied, ob die Hardwareunterstützung de- oder aktiviert ist.
Entweder ist das der Beweis, dass Deine Mercury-Engine-GPU-Beschleunigung trotz allem nicht aktiv ist oder dass keiner Deiner Effekte die GPU-Beschleunigung nutzen kann.
Zuletzt geändert von TomStg am Mi 09 Okt, 2013 15:36, insgesamt 1-mal geändert.
Hi
habe grade geschaut, habe auch die 680er
im Premiere eine Full HD Sequenz mit DNxHD Material red giant denoiser und ultra Key drauf, Export als h.264 10 Mbit
CPU auslastung 5-7% GPU ca 70 % beim Rendern.
Probiere mal eine Einfach sequenz aus, ob du dort auch keine Last bei der CPU hast .
---------------------------------------------- www.bodis.tv wir machen einfach geilen scheiß
Bodis.tv hat geschrieben:Hi
habe grade geschaut, habe auch die 680er
im Premiere eine Full HD Sequenz mit DNxHD Material red giant denoiser und ultra Key drauf, Export als h.264 10 Mbit
CPU auslastung 5-7% GPU ca 70 % beim Rendern.
Probiere mal eine Einfach sequenz aus, ob du dort auch keine Last bei der CPU hast .
Gerade habe ich genau das ausprobiert. Und tatsächlich, mit dem DNxHD-Material komme ich auf die Werte von dir, also CPU bei etwa 10 Prozent, GPU bei 70-80 Prozent.
Der gleiche Test mit dem H.264-Material ergab wieder das gewohnte, traurige Bild: CPU bei 40 Prozent, GPU bei maximal 12.
Also fasse ich für mich zusammen:
- Die RED Giant Effekte werden auch durch die GPU gerendert
- DNxHD ebenfalls
- H.264 wird nicht (oder nur zum Teil) mit Unterstützung der GPU gerendert
Also kaufe ich noch ein paar Blackmagic Cinema Cameras und ersetze die Canon 5Ds :)
- H.264 wird nicht (oder nur zum Teil) mit Unterstützung der GPU gerendert
Mit solchen Schlüssen wäre ich sehr vorsichtig.
Möglicherweise braucht die CPU hier einfach zuviel Zeit fürs Encoding, als dass die GPU höher ausgelastet werden könnte.
- H.264 wird nicht (oder nur zum Teil) mit Unterstützung der GPU gerendert
Mit solchen Schlüssen wäre ich sehr vorsichtig.
Möglicherweise braucht die CPU hier einfach zuviel Zeit fürs Encoding, als dass die GPU höher ausgelastet werden könnte.
Okay, auf jeden Fall lässt sich feststellen, dass es keinen prinzipellen Fehler gibt, dass die Grafikkarte auch arbeiten kann und das dies von dem verwendeten Material abhängt.
Die Grafikkarte funktioniert also. Das ist mir ja fast das wichtigste.
Dummerweise wurde die Sequenz falsch angelegt, ich schneide nicht in einer 1920x1080er sondern in einer 1440x1080er Sequenz (Das lässt sich leider nicht mehr ändern, weil Multicamsequenz und schon geschnitten).
Warum legst nicht ne neue Sequenz an und kopierst einfach den ganzen Schnitt rüber? STRG+A, STRG+C, rüber und STRG+V?
Damit h264 über die GPU gemacht wird (encoding), brauchts den entsprechenden Encoder. Squeeze hat so einen zB drin, Premiere eben nicht.
Im Zweifel als Intermediate rendern (würde ich ohnehin machen) und anschließend komprimieren, kann gern mal schneller sein mit richtigem Encoder.
Damit h264 über die GPU gemacht wird (encoding), brauchts den entsprechenden Encoder. Squeeze hat so einen zB drin, Premiere eben nicht.
Premiere unterscheidet für die Cuda-Unterstützung meines Wissens nicht nach dem Codec. Bzw., dass Cuda und h264 in Premiere funktionieren, sieht man bekanntermaßen schon in der Vorschau. Ob besser oder schlechter sei mal dahingestellt.
In Squeeze würde ich bei mainconcept die GPU jedenfalls nicht nutzen, das ist mir zu fehleranfällig. Was nicht heisst, dass Premiere besser ist, nicht falsch verstehen. Aber Qualität ist mit wichtiger als Geschwindigkeit. Und die Aussage oben ist falsch.
Mainconcept H.264/AVC CUDA Encode has the following restrictions.
•Only supports One and Two pass VBR – no CBR or Multi-pass.
•Does not support “Interlace Mode”.
•Only supports one B-Frame.
•Does not support “Use B-Slices as Reference”.
•Does not support “Reference Frames”.
•Does not support “Multiple Slices”.
•Does not support “Black Normalization Level”.
•Does not support HRD – no Blu-Ray.
Currently not supported
■No MBAFF support
■No Hadamard transformation
■No intra prediction 8x8
■No adaptive B-frames support
■No weighted prediction
Zuletzt geändert von Alf_300 am Do 10 Okt, 2013 18:50, insgesamt 1-mal geändert.
Damit h264 über die GPU gemacht wird (encoding), brauchts den entsprechenden Encoder. Squeeze hat so einen zB drin, Premiere eben nicht.
Und die Aussage oben ist falsch.
Nein, die Aussage ist richtig.
Cuda-unterstützt, also in der Grafikarte, können nur Algorithmen laufen, die a) dafür programmiert sind und b) dahin geroutet werden (Selektion GPU-Unterstützung an/aus).
Mainconcept bietet einen H.264-Codec, der mit Cuda-Unterstützung bedient wird, und sie nutzt, wo es möglich ist. Doch nur die Teile, die dafür auch programmiert wurden.
Kann man für Premiere Pro zusätzlich erwerben. Der mit Premiere Pro ausgelieferte Codec läuft auf der CPU.
Allerdings werden in Premiere Pro selbstverständlich bei der Vorschau wie auch beim Export vor der Kodierung aufzulösende interne Berechnungen (wie Skalierungen z. B.) und Cuda-basierte Effekte GPU-unterstützt abgearbeitet, wann immer möglich. Rendern und Kodieren sind zwei paar Schuh.
Die Lastverteilung zwischen CPU und GPU ist für den Benutzer nicht vorhersehbar. Nur in dem einen Fall, wenn er GPU-Unterstützung abschaltet (oder eine nicht unterstützende GraKa verwendet), weiß er sicher, dass die CPU alles trägt. Darüber hinaus ist alles andere reine Spekulation.
Auch die Performance der Bearbeitung kann daraus nicht erschlossen werden.
Nur soviel lässt sich sagen: Eine CPU oder GPU, die nicht zu 100% ausgelastet ist, hat noch Reserven für größere Herausforderungen. Das ist sehr gut! Sie wird garantiert nicht ausgebremst. Sie würde die Aufgaben aber auch nicht schneller abarbeiten, wenn in ihr die Auslastung hochgeht. das bedeutet nämlich in erster Linie, dass sie mehr bzw. komplexere Aufgaben erledigt. Sonst nichts.
Umgekehrt stimmt es: Eine CPU oder GPU, die deutlich über 90%, gar zu 100% ausgelastet ist, ist mit der Aufgabe technisch überfordert. Performantere Modelle würden die selbe Aufgabe mit größter Wahrscheinlichkeit schneller abarbeiten.
Ich habe grade ähnliche s "Problem"
komme in der Regel nur auf 4-5 % CPU auslastung
AE und PP GPU eben bei ca 70%
wo ist dann der Flaschenhals ? die SSD? die nicht genug die Daten liefen?
bei 50% würde ich mir keine Gedanken machen, aber bei 5% kann doch auch was nicht stimmen oder?
---------------------------------------------- www.bodis.tv wir machen einfach geilen scheiß
Natürlich bremsen alle I/O- Anforderungen (Ob auf Platten oder ins RAM oder auf den Bildschirm) und nötige Systemaktivitäten (z. B. Swapping bei zu kleinem RAM) Programme aus. Ob und wie sehr das einen konkreten Ablauf behindert, müsste genauer untersucht werden.
Wenn die CPU-Auslastung gering ist, kann das aber auch schlicht bedeuten, dass es über die vorhandenen Threads verteilt nicht viel zu tun gibt. Eventuell würden hier mehr Threads mehr Durchsatz schaffen. Die CPU arbeitet deshalb jedoch nicht langsamer. Oder dass die Grafikkarte stark involviert ist - was sich nicht unbedingt in "Auslastung" ausdrückt:
Nehmen wir einen Frame. Dieser muss gerendert werden. Es sind einige harmlose Effekte darauf. Die CPU schickt den ersten Auftrag an die GPU. Die GPU arbeitet genau einen Effekt ab, erzeugt Zwischenergebnisse und schließlich das Ergebnis und schreibt und liest dabei heftig im RAM. Das sind bereits "Unterbrechungen". Danach meldet sie "fertig." Pause für die GPU. Die CPU erwacht kurz und schickt den nächsten Auftrag los und legt sich wieder schlafen. Die GPU holt sie sich völlig stressfrei zunächst wieder den Auftrag und die Daten aus dem RAM und rechnet den neuen Job durch.
Die CPU tut derweil - außer Aufträge durchreichen -, nichts, was Last bedeuten würde. Ihre Auslastung sinkt rapide. Die der GPU ist aber nominal auch nicht hoch, weil viele Unterbrechungen vorkommen. Dennoch tut sie, was sie kann. Und so können schnellere GraKas (trotz geringer Auslastung) schneller arbeiten, als langsame.
Erst wenn irgendwann das Endergebnis vorliegt, wird die CPU wieder richtig involviert.
Kommen auf einem Frame noch mehr und noch aufwändigere Effekte ins Spiel, die Massenberechnungen auf großen Frames auslösen, an denen lange und womöglich ohne Unterbrechnungen gerechnet wird, steigen Auslastung und Zeitbedarf in der GPU gemächlich bis zur nächsten Pause, in der CPU fallen sie.
Und wie sich das Ganze in konkreten Fällen verteilt, ist nicht vorhersehbar oder abschätzbar. Auf keinen Fall darf man rechnen: CPU-Last + GPU-Last = 100%. (Und ich glaube, so was in der Art wird hier erwartet).
dienstag_01 hat geschrieben:Zitat:
Damit h264 über die GPU gemacht wird (encoding), brauchts den entsprechenden Encoder. Squeeze hat so einen zB drin, Premiere eben nicht.
So wie ich das sehe ist Squeeze ein Externer Encoder und besonders gut geeignet um festzustellen wann GPU verwendet wird weil es eine Meldung gibt ob GPU verwendet werden soll (wenn die Möglichkeit dazu besteht)
Rovi/Mainconcept unterstützt Premiere nur bis CS6
Ein weiteres Beispiel wäre Twixtor Wer nicht eine GTX 680/690/780 oder Titan hat wird beim zuschschalten der GPU mit einem Absturz belohnt
Was man lernt ist also nur dass für die meisten GPU ein Fake ist
Eine Grafikkarte ist ein vollständiger Computer und will genau so bedient werden. Mit eigenem Betriebssystem (Treiber), Programmen und Daten.
Wie bei jedem Computer kann man Programme für Grafikkarten irgendwo zwischen lauffähig und optimal dafür programmieren.
Weist man der GPU Aufgaben zu, für die sie prädestiniert ist, hat sie aufgrund ihrer Architektur - die hohe Anzahl Kerne! - deutliche Vorteile gegenüber einer CPU. Das setzt aber voraus, dass die Aufgaben in echt parallel bearbeitbare Fitzelchen zerteilt werden können. Beispielsweise ist theoretisch die Farbänderung aller Pixel beim Graden gleichzeitig für alle Pixel möglich, jeder Cuda-Core schnappt sich eins. In der CPU ginge das nicht. Die CPU wäre deutlich langsamer. Sie führt zwar die gleichen Schritte aus, aber sequentiell, nicht parallel.
Beim Rendern gibt es oft solche Aufgaben, die Algorithmen fürs Kodieren bieten dagegen weniger Möglichkeiten der einfachen Parallelisierung. Weshalb Kodieren überwiegend bis ganz auf der CPU läuft, die auch noch mit umfangreicheren Befehlssätzen und hohen Taktraten für diese Aufgabe punkten kann.
Die Parallel-verarbeitung in der GPU wird in der Videoverarbeitung genutzt, muss aber auch aufwändig und fehlerfrei programmiert werden. Es passiert nicht einfach durch einstecken einer Grafikkarte und dann fluscht es schon. So einfach ist das leider nicht.
Nicht umsonst sind von Software-Herstellern bestimmte Karten "zertifiziert", "supported" oder empfohlen. D. h., die Funktion der Programme wurde auf diesen Karten validiert. Bei der Vielzahl von Karten und deren Zusammenspiel zwischen unterschiedlicher Hardware, die da verbaut wird, und sich ständig fortentwickelnden Treibern ist identisches Verhalten aller Karten für diese Anwendung nicht automatisch garantiert.
@Reiner
Wie es funktionieren soll ist theoretisch inzwischen wohl Jedem Klar, Unklar ist Wann es in der Praxis funktioniert.
Nachdem sich Keiner bereit erklärt Hier Klare Aussagen zu machen, wird es wohl auch weiterhin Jeden selbt überlassen bleiben, Premiere's Funktionen auf GPU-Tauglichkeit zu testen.
Aus meinrer Sicht kann ich nur sagen, als mir voriges Monat meine GTX580 abgebrannt ist und ich zwischenzeitlich eine GTX260 drin hatte, war ich mehr als überrascht, dass sich praktisch garnichts geändert hat wenn es um das endgültige Rendern geht.
Alf_300 hat geschrieben:
Nachdem sich Keiner bereit erklärt Hier Klare Aussagen zu machen, wird es wohl auch weiterhin Jeden selbt überlassen bleiben, Premiere's Funktionen auf GPU-Tauglichkeit zu testen.
Das verstehe ich nun nicht.
Adobe macht zu jeder Version eindeutige Aussagen darüber, welche Funktionen und Effekte mit welchen Karten in welchen Modus (Cuda / Open) auf welchem System (PC/Mac) GPU-unterstützt laufen. Steht in der Doku und auf mehreren Adobe-Seiten.
Sie haben auch immer wieder und mehrfach beschrieben, dass das Kodieren vom Rendern zu unterscheiden ist (auch, wenn es scheinbar für den Anwender der selbe Vorgang ist, weil es scheinbar gleichzeitig stattfindet) und das Kodieren auf der CPU läuft, das Rendern je nach Effekt, GraKa und Einstellung über die GPU oder die CPU geht. Alles bekannt. Seit CS5 mit Einführung der Mercury Engine.
@Reiner
Genau um das gehts ja - Große Trommel für CUDA aber dann muß man sich durchs Internet wühlen weils sich in der Praxis nicht rührt und die Erwartungen bei den meisten nicht erfüllt werden
Na, ja. Sich schlau machen hilft durchaus - wenn man etwas nicht versteht, aber es wissen möchte. Daher sind solche Fragen legitim und wichtig.
Die "Erwartungen" resultieren m. E. aber aus einem Missverständnis der Systemanzeigen.
Es ist beispielsweise oft schwer, jemanden beizubringen, dass 100% Last absolut übel sind! Die wünscht sich kein Systemadministrator. Ja, sieht toll aus, ist aber nur der Beweis, dass das System zu schwach ausgelegt ist.
Wenn ich in meinem After Effects auf CPU Multiprocessing rendere, dann zeigen bei mir 12 Kerne 100% Last über Stunden oder Tage. Ich muss die Temperaturen im Auge behalten. Schlimmer aber: Ich weiß, dass ich mit 24 Kernen nahezu doppelt so schnell wäre, die halbe Zeit sparen könnte, und das mal Stundenlohn oder mal Maschinenkosten, zuzüglich Spaßfaktor, Freizeitvorteil und Vergnügen im Kino ... ;)
Ich habe oben versucht, diesen Blick auf die Systemanzeigen etwas zu relativieren.
Neben Systemlast spielt beispielsweise Durchsatz die viel wichtigere Rolle. Aber der wird nirgends angezeigt.
Beispiel: Zwei PCs, beide zeigen 40% CPU-Last. Welcher schafft den größeren Durchsatz (ist effektiv schneller)? Oder sind sie gleich schnell?
Es ist ein Unterschied, ob sich diese 40% auf 4 Kerne, 8 oder 12 beziehen. Für GPUs ob es weniger oder mehr CUDA-Cores sind.
Wissen müsste man demnach Sachen wie: Anzahl Kerne, Taktraten, RAM-Geschwindigkeiten, Anzahl Unterbrechungen, Anzahl CUDA-Cores, Datenbusbreiten ... Das alles wird in CPU/GPU-Last nicht abgebildet. So. Und nun steht der eine bei 30%, der andere bei 40%. Und nun? Es sagt nichts ...
Jedenfalls sehr viel weniger, als viele "erwarten". ;)
Damit h264 über die GPU gemacht wird (encoding), brauchts den entsprechenden Encoder. Squeeze hat so einen zB drin, Premiere eben nicht.
Premiere unterscheidet für die Cuda-Unterstützung meines Wissens nicht nach dem Codec. Bzw., dass Cuda und h264 in Premiere funktionieren, sieht man bekanntermaßen schon in der Vorschau. Ob besser oder schlechter sei mal dahingestellt.
In Squeeze würde ich bei mainconcept die GPU jedenfalls nicht nutzen, das ist mir zu fehleranfällig. Was nicht heisst, dass Premiere besser ist, nicht falsch verstehen. Aber Qualität ist mit wichtiger als Geschwindigkeit. Und die Aussage oben ist falsch.
Ich meinte auch nur die Render-Ausgabe, nicht die Mercury Engine. Nur das Encoding. Aber wie bereits von anderswo erläutert - stimmt schon so ;)
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Adobe Premiere Pro / Elements / SpeedGrade / Creative Cloud CC Forum 
