Dietmar
02.12.2019, 15:55
Ein Developer von Laminar hat auf der org einen interessanten Beitrag zu der kommenden Vulcan- und Metal-Anwendung für die Graphik geschrieben.
Ich habe den Beitrag hier mit google übersetzt.
Das große Problem ist der OpenGL-Treiber-Overhead, der ausschließlich auf der CPU-Seite liegt. Es ist eine massive Zustandsmaschine, die ständig neue Eingaben validieren und bewerten muss, ob der Zustand auf der GPU neu kompiliert werden muss. Letzteres ist besonders schmerzhaft, weil es in Form von seltsamen und unvorhersehbaren Stottern auftritt. Für Tausende von Frames kann alles in Ordnung sein, und dann stößt der Treiber plötzlich auf eine etwas andere Grafik-Pipeline und muss jetzt die Welt in der Bildmitte anhalten, um den neuen Status zu kompilieren.
Währenddessen ist die Client-Anwendung auf Vulkan und Metal für das Vorkompilieren aller erforderlichen Grafik-Pipelines verantwortlich. Bei X-Plane geschieht dies beim ersten Laden oder beim anschließenden Laden von Szenen im Hintergrund, wenn neue DSFs gestreamt werden. Wenn es darum geht, die Welt zu zeichnen, müssen wir nicht mehr mitten im Bild stehen bleiben, alle unsere Enten sind hintereinander. Und da Vulkan und Metal keine gewaltigen Zustandsautomaten sind, die eine unglaubliche Menge an Validierung durchführen müssen, wird auch der Aufwand für die Frame-Zeit generell verringert. Die allgemeine Idee dieser APIs besteht darin, die Treiberseite viel schlanker zu gestalten und die API-Aufrufe viel näher an das heranzuführen, was direkt von der Hardware verbraucht werden kann.
All dies ist exklusiv für die CPU, die GPU wird nicht magisch schneller oder macht Dinge anders. Aber um das ins rechte Licht zu rücken, habe ich mich bei KSEA auf 34R mit max world objects gesetzt. Mit der OpenGL-Version generiert X-Plane 59774 Aufrufe des OpenGL-Treibers pro Frame. Auf der Vulkan-Seite gibt es nur 23064 Aufrufe des Vulkan-Treibers. Dies entspricht 9325 tatsächlichen Draw Calls in der Szene. Für OpenGL gibt es also durchschnittlich 5 ½ Calls für jeden tatsächlichen Draw Call! Während auf Vulkan ist es nur 1 und ein halber Anruf pro Draw-Anruf! Dies ist die Art von Overhead, die Vulkan und Metal ausschneiden.
Nun, dies ist nur ein kleiner Teil dessen, was Vulkan / Metal fantastisch macht, aber ich kann nicht verstehen, welchen großen Unterschied dies bereits macht. Dies geschieht, ohne eine der Multithread-Rendering-Möglichkeiten zu berühren. Ich weiß, weil X-Plane noch kein Multithread-Rendering durchführt. Es könnte in _theorey_ sein, dass alle Abstraktionen vorhanden sind, aber es gibt wichtige Probleme wie Plugin-Kompatibilität, Frame Graph Refactoring, die durchgeführt werden müssen, sowie natürlich unseren alten Freund OpenGL. Denken Sie daran, dass X-Plane 11 weiterhin das OpenGL-Backend unterstützt und dass man auf magische Weise keine bessere Multithreading-Unterstützung erhält.
Natürlich gibt es eine Menge aufregenderer Dinge, die Vulkan und Metal erlauben. Zum Beispiel die Unterstützung einer sehr präzisen Profilerstellung für einen Frame auf der GPU selbst, die es uns ermöglicht, tatsächlich zu sehen, wo die GPU ihre Zeit damit verbringt, was zu tun und wie gut wir darin sind, die Ausführungs-Pipeline gefüllt zu halten. Und so viele Möglichkeiten, es endlich auf allen Plattformen richtig zu machen. Ich jedenfalls bin super begeistert von dem, was wir endlich tun können. Aber ich bin auch voreingenommen
Ich habe den Beitrag hier mit google übersetzt.
Das große Problem ist der OpenGL-Treiber-Overhead, der ausschließlich auf der CPU-Seite liegt. Es ist eine massive Zustandsmaschine, die ständig neue Eingaben validieren und bewerten muss, ob der Zustand auf der GPU neu kompiliert werden muss. Letzteres ist besonders schmerzhaft, weil es in Form von seltsamen und unvorhersehbaren Stottern auftritt. Für Tausende von Frames kann alles in Ordnung sein, und dann stößt der Treiber plötzlich auf eine etwas andere Grafik-Pipeline und muss jetzt die Welt in der Bildmitte anhalten, um den neuen Status zu kompilieren.
Währenddessen ist die Client-Anwendung auf Vulkan und Metal für das Vorkompilieren aller erforderlichen Grafik-Pipelines verantwortlich. Bei X-Plane geschieht dies beim ersten Laden oder beim anschließenden Laden von Szenen im Hintergrund, wenn neue DSFs gestreamt werden. Wenn es darum geht, die Welt zu zeichnen, müssen wir nicht mehr mitten im Bild stehen bleiben, alle unsere Enten sind hintereinander. Und da Vulkan und Metal keine gewaltigen Zustandsautomaten sind, die eine unglaubliche Menge an Validierung durchführen müssen, wird auch der Aufwand für die Frame-Zeit generell verringert. Die allgemeine Idee dieser APIs besteht darin, die Treiberseite viel schlanker zu gestalten und die API-Aufrufe viel näher an das heranzuführen, was direkt von der Hardware verbraucht werden kann.
All dies ist exklusiv für die CPU, die GPU wird nicht magisch schneller oder macht Dinge anders. Aber um das ins rechte Licht zu rücken, habe ich mich bei KSEA auf 34R mit max world objects gesetzt. Mit der OpenGL-Version generiert X-Plane 59774 Aufrufe des OpenGL-Treibers pro Frame. Auf der Vulkan-Seite gibt es nur 23064 Aufrufe des Vulkan-Treibers. Dies entspricht 9325 tatsächlichen Draw Calls in der Szene. Für OpenGL gibt es also durchschnittlich 5 ½ Calls für jeden tatsächlichen Draw Call! Während auf Vulkan ist es nur 1 und ein halber Anruf pro Draw-Anruf! Dies ist die Art von Overhead, die Vulkan und Metal ausschneiden.
Nun, dies ist nur ein kleiner Teil dessen, was Vulkan / Metal fantastisch macht, aber ich kann nicht verstehen, welchen großen Unterschied dies bereits macht. Dies geschieht, ohne eine der Multithread-Rendering-Möglichkeiten zu berühren. Ich weiß, weil X-Plane noch kein Multithread-Rendering durchführt. Es könnte in _theorey_ sein, dass alle Abstraktionen vorhanden sind, aber es gibt wichtige Probleme wie Plugin-Kompatibilität, Frame Graph Refactoring, die durchgeführt werden müssen, sowie natürlich unseren alten Freund OpenGL. Denken Sie daran, dass X-Plane 11 weiterhin das OpenGL-Backend unterstützt und dass man auf magische Weise keine bessere Multithreading-Unterstützung erhält.
Natürlich gibt es eine Menge aufregenderer Dinge, die Vulkan und Metal erlauben. Zum Beispiel die Unterstützung einer sehr präzisen Profilerstellung für einen Frame auf der GPU selbst, die es uns ermöglicht, tatsächlich zu sehen, wo die GPU ihre Zeit damit verbringt, was zu tun und wie gut wir darin sind, die Ausführungs-Pipeline gefüllt zu halten. Und so viele Möglichkeiten, es endlich auf allen Plattformen richtig zu machen. Ich jedenfalls bin super begeistert von dem, was wir endlich tun können. Aber ich bin auch voreingenommen