Infoseite // Final Cut Pro X und die Grafikkarte

Newsmeldung von slashCAM:


Hier geht es zur Newsmeldung mit Link und Bildern auf den slashCAM Magazin-Seiten




Antwort von DSLR-Freak:

Bringt man noch unsere Erfahrungen mit Adobes Mercury Engine ins Spiel, so wird das Puzzle komplett. Denn auch dort ist der Geschwindigkeitsunterschied zwischen verschiedenen GPUs sehr gering. Viel entscheidender ist hier Speicheranbindung. Das ist ja interessant. Woher habt Ihr diese Erkenntnisse? Habt Ihr selbst getestet?
Das hieße ja, man kann mit einer teuren Grafikkarte bzgl. Adobes Mercury Engine auch nicht viel schneller unterwegs sein. Von den Mindestanforderungen mal abgesehen.



Antwort von Abercrombie:

Wenn die GPU das letzt Glied in der Kette ist und der Weg zurück zur IO-Karte zu lang dauert, könnte dann nicht "IO via Thunderbolt" dieses Problem lösen? Alle Daten sind schon da und müssten nur über den Kanal zu einer aktiven Breakoutbox. Wie es dann weiter ginge wäre FCPx ja egal.
Oder sehe ich das jetzt komplett falsch? Wowu, wo biste?! ;-)



Antwort von rudi:

Das hieße ja, man kann mit einer teuren Grafikkarte bzgl. Adobes Mercury Engine auch nicht viel schneller unterwegs sein. Von den Mindestanforderungen mal abgesehen. Wir haben noch nicht systematisch getestet, aber schon viele Eindrücke. Und die scheinen zu bestätigen, dass sich eine teure Grafikkarte für die Mercury Engine nicht lohnt. Es wird bald mehr dazu auf slashCAM zu lesen geben...

Wenn die GPU das letzt Glied in der Kette ist und der Weg zurück zur IO-Karte zu lang dauert, könnte dann nicht "IO via Thunderbolt" dieses Problem lösen? Alle Daten sind schon da und müssten nur über den Kanal zu einer aktiven Breakoutbox. Wie es dann weiter ginge wäre FCPx ja egal. Einzig das das Verschieben des Framebuffers auf eine separate Hardware braucht zu viel Zeit. Daher ist es eigentlich "nur" ein Problem der Software, bzw. des GPU-Treibers. Denn aus der GPU kann ja auch ein professionelles Videosignal via HDMI-/Display-Port herausgeführt werden. Sogar mit 10 Bit und anderem Firlefanz. Es muss nur jemand programmieren. So wie ich Thunderbold verstehe, sind Display- und Daten-Streams übrigens völlig getrennt. D.h. das Problem löst sich nicht unbedingt automatisch...



Antwort von deti:

Es bleibt nur zu hoffen, dass die NLE-Hersteller diese freudlose GPU-Integration bald wieder aufhören. (GP)GPUs haben in Anbetracht der aktuellen Prozessorarchitekturen keine Existenzberechtigung mehr abseits der Bildausgabe.

Deti



Antwort von Abercrombie:

Denn aus der GPU kann ja auch ein professionelles Videosignal via HDMI-/Display-Port herausgeführt werden. Sogar mit 10 Bit und anderem Firlefanz. Es muss nur jemand programmieren. So wie ich Thunderbold verstehe, sind Display- und Daten-Streams übrigens völlig getrennt. D.h. das Problem löst sich nicht unbedingt automatisch... Vom Framebuffer wird es ja eh in den Videokanal gejagt, der Weg ist ja normal. Falls die Breakoutbox diesen Kanal überwacht sollte doch keine Verzögerung durch irgendeine Verschiebung entstehen. Es muss ja nicht zwangsweise über den Datenkanal gehen.



Antwort von rudi:

Vom Framebuffer wird es ja eh in den Videokanal gejagt, der Weg ist ja normal. Falls die Breakoutbox diesen Kanal überwacht sollte doch keine Verzögerung durch irgendeine Verschiebung entstehen. Es muss ja nicht zwangsweise über den Datenkanal gehen. Jein, kommt natürlich darauf an, was man unter einer professionellen Videovorschau versteht.

Vielleicht ein Beispiel: Adobes Mercury Engine nutzt die CPUs zum decodieren und schiebt dann (solange alle Effekte in der Filterliste CUDA-fähig sind) den unkomprimierten Frame auf die Grafikkarte (GPU). Dort wird er dann in 32 Bit pro Farbkanal (also 4 x 32 Bit, floating point) konvertiert. Ist dieser zeitaufwändige Prozess beendet, ist es ziemlich egal, wie viele Effekte man drauf rechnet. Das macht die GPU meistens mit links (wenn kein sehr aufwändiger Effekt dabei ist, wie z.b. optical flow).
Dann liegt der gerenderte Frame im Framebuffer (und zwar mit 4x32 Bit). Nun kann die Grafikkarte in Hardware diesen Frame direkt per HDMI, SDI Display-Port oder was auch immer ausgeben, wenn die entsprechenden Ports am Grafikchip quasi festgelötet sind. Die Konvertierung von 32 Bit float nach 8 oder 10 Bit, RGB oder YUV, 4:2.2 oder 4:2:0 geschieht hier in Echtzeit, meistens in Hardware. (Es ist praktisch sicher, dass Apple das alles nicht anders macht. )

Dieses 8- oder 10 Bit-Signal kann nun natürlich per Display Port oder im Thunderbold-Videotream an eine Break-Out-Box weitergegeben werden, aber wozu? Wichtig ist die Wandlung von 32 Bit nach 8 oder 10 Bit und die kann nur schnell sein, wenn sie direkt auf der GPU stattfindet. Nur an dieser Stelle machen LUT-Tabellen und Farbraumkonvertierungen Sinn, wenn sie sauber sein sollen.

Für eine professionelle Videovorschau mit alternativer Hardware müsste der 32 Bit Framebuffer wieder ausgelesen werden, damit er als Datenstrom über Thundebold übertragen wird. Denn die 32 Bit Float über den Display-Stream gehen meines Wissen nicht, bzw. sind nicht spezifiziert. Das kann auch kein Monitor in Echtzeit verarbeiten.

Die Daten müssten also auf jeden Fall zurück in den Hauptspeicher und das kostet viel Performance. Aber nur so hat eine externe Lösung zugriff auf die 4 x 32 Bit Framebuffer um hier selber mit LUTs und anderen Manipulationen einen Vorteil zu bieten (was man wohl unter einer professionellen Videovorschau verstehen darf).

war das verständlich?