OpenGL 4.3 auf dem Mac: Warum es für CAD, GIS und professionelle Windows-Anwendungen wichtig ist

Eine Windows-Anwendung, die auf einem Mac mit Apple Silicon ausgeführt wird, kommuniziert mit der GPU des Macs nicht auf dieselbe Weise wie auf einer herkömmlichen Windows-Workstation.

Die Anwendung kann OpenGL-Befehle ausgeben. Die GPU von Apple ist auf Metal ausgelegt.Eine Virtualisierungsplattform muss diese Lücke überbrücken, dabei das von der Anwendung erwartete Grafikverhalten beibehalten und den Übersetzungsaufwand so gering halten, dass interaktives Arbeiten möglich bleibt.

Genau diese technische Herausforderung steckt hinter einer der bedeutendsten Neuerungen in Parallels Desktop 27: der Unterstützung von OpenGL 4.3 in virtuellen Windows-Maschinen auf Basis von Apples Metal-Framework.

Laut Tests von Parallels bietet die neue Grafikarchitektur auf Macs mit Apple M3 Chips und neuer eine bis zu 2,6-mal höhere OpenGL-Leistung. In Tests mit ArcGIS Pro war das 3D-Rendering bis zu 35 % schneller, und getestete Workflows wurden bis zu 24 % schneller abgeschlossen als mit Parallels Desktop 26.

Die Versionsnummer ist dabei nur ein Teil der Geschichte. OpenGL 4.3 führt Grafik- und Rechenfunktionen ein, mit denen viele professionelle Rendering-Engines größere Datensätze verarbeiten, komplexe Szenen effizienter übermitteln und geeignete Aufgaben von der CPU auf die GPU verlagern können.

Für Personen, die mit Karten, Geländedaten, Konstruktionsmodellen, Gebäudeentwürfen, Simulationsergebnissen oder anderen grafikintensiven Windows-Anwendungen arbeiten, kann sich das auf mehr als nur Benchmarks auswirken. Es kann die Reaktionsfähigkeit des Ansichtsfensters verbessern und den Funktionsumfang erweitern, der in einer virtuellen Maschine korrekt genutzt werden kann.

Was ist OpenGL?

OpenGL, kurz für Open Graphics Library, ist eine plattformübergreifende Grafik-API, die von der Khronos Group verwaltet wird.

Eine API definiert, wie Softwarekomponenten miteinander kommunizieren. OpenGL stellt einer Anwendung dabei einen standardisierten Befehlssatz zur Verfügung, mit dem sie die GPU zum Zeichnen und Verarbeiten von Grafiken anweisen kann.

Eine professionelle Anwendung kann diese Befehle beispielsweise verwenden, um:

• die Geometrie in einem CAD-Modell darzustellen
• Höhendaten und Bildmaterial in einer 3D-Karte zu rendern
• die Komponenten eines Building-Information-Models darzustellen
• das Ergebnis einer technischen Simulation zu schattieren
• ein Ansichtsfenster zu aktualisieren, während eine Szene verschoben, gezoomt oder gedreht wird

Die Anwendung muss nicht jedes hardwarenahe Detail der physischen GPU kennen. Sie beschreibt die erforderliche Arbeit über OpenGL, und ein Grafiktreiber ordnet diese Arbeit der verfügbaren Hardware zu.

OpenGL wird seit Jahrzehnten in Workstation- und technischer Software eingesetzt. Diese lange Historie ist relevant, weil professionelle Anwendungen häufig ausgereifte Rendering-Systeme enthalten, die für bestimmte OpenGL-Funktionen entwickelt und getestet wurden.

Warum die OpenGL-Version wichtig ist

OpenGL-Versionen sind nicht mit gewöhnlichen Anwendungsupdates vergleichbar, bei denen eine höhere Versionsnummer vor allem Verbesserungen oder Änderungen an der Benutzeroberfläche bedeutet.

Neue OpenGL-Versionen erweitern die Programmiermöglichkeiten. Eine Anwendung kann eine Funktion nur nutzen, wenn die Grafikumgebung die erforderliche Version oder Erweiterung bereitstellt.

OpenGL 4.3, 2012 von Khronos veröffentlicht, führte mehrere Funktionen ein, die für daten- und objektintensives Rendering relevant sind, darunter Compute-Shader, Shader Storage Buffer Objects und Multi-Draw-Indirect-Befehle. Khronos beschreibt diese Funktionen als Möglichkeiten, die Parallelverarbeitung der GPU für Berechnungen zu nutzen, Shadern das Lesen und Schreiben größerer Datenmengen zu ermöglichen und mehrere Zeichenoperationen effizienter zu übermitteln.

Eine leistungsfähige GPU allein reicht nicht aus. Auch der Treiber und die Virtualisierungsschicht müssen der Anwendung die erforderlichen API-Funktionen zur Verfügung stellen.

Was bietet OpenGL 4.3?

Die praktische Bedeutung von OpenGL 4.3 liegt darin, welche Aufgaben Rendering-Engines mithilfe dieser Funktionen auf die GPU verlagern können.

Nicht jede Anwendung nutzt jede Funktion, und die genaue Implementierung unterscheidet sich je nach Produkt. Drei Erweiterungen verdeutlichen jedoch, warum der Schritt zu OpenGL 4.3 für professionelle Software relevant ist.

Compute-Shader-Unterstützung für GPU-beschleunigte Windows-Anwendungen auf dem Mac

Vertex- und Fragment-Shader übernehmen jeweils einen festgelegten Teil der Grafikpipeline. Compute-Shader funktionieren anders. Anwendungen können damit parallele Verarbeitungsaufgaben an die GPU senden, ohne diese Arbeit an eine bestimmte Rendering-Phase zu binden. Software kann Compute-Shader beispielsweise für Bildverarbeitung, Geometrieberechnungen, Simulationen oder Datenvisualisierung einsetzen. Die genaue Arbeitslast hängt von der jeweiligen Implementierung der Anwendung ab.

Die Unterstützung von Compute-Shadern ist wichtig, weil einige professionelle Windows-Anwendungen den Funktionsumfang von OpenGL 4.3 voraussetzen. Ist eine Anwendung für GPU-Berechnungen ausgelegt, kann sie geeignete Aufgaben in viele ähnliche Operationen aufteilen und parallel verarbeiten. Das kann die Kompatibilität verbessern und bei diesen spezifischen Aufgaben auch die Leistung steigern. Nicht jede Berechnung wird dadurch schneller. Manche Workloads eignen sich besser für die CPU, und die Ergebnisse unterscheiden sich je nach Anwendung.

Shader Storage Buffer Objects

Shader Storage Buffer Objects, kurz SSBOs, ermöglichen Shadern Lese- und Schreibzugriff auf große Datenblöcke. Eine Anwendung kann ein SSBO verwenden, um Szeneninformationen, Geometrie, Simulationswerte oder Zwischenergebnisse zu speichern, auf die mehrere Shader-Operationen zugreifen müssen. Im Vergleich zu Uniform Buffer Objects unterstützen SSBOs größere Mindestpuffergrößen und ermöglichen Shadern, die gespeicherten Daten zu verändern.

Diese Funktion ist für Anwendungen nützlich, die mit komplexen Modellen oder umfangreichen Datensätzen arbeiten. Sie kann außerdem unnötige Datenbewegungen reduzieren, wenn eine Anwendung darauf ausgelegt ist, Arbeitsdaten für die GPU verfügbar zu halten. SSBOs wurden mit Version 4.3 Bestandteil des OpenGL-Kerns. Für Anwender ist vor allem die Anwendungskompatibilität relevant: Windows-Software, die diese Funktion voraussetzt, erhält Zugriff auf das erwartete OpenGL-Programmiermodell, sofern die Virtualisierungsplattform es unterstützt.

Multi-Draw Indirect

Eine komplexe technische Szene kann Tausende einzelner Objekte enthalten. Für jedes Objekt einen separaten Zeichenaufruf zu senden, kann viel CPU-Zeit beanspruchen, selbst wenn die GPU die Geometrie schnell rendern könnte.

Multi-Draw Indirect ermöglicht es einer Rendering-Engine, Parameter für mehrere Zeichenoperationen in einem Puffer zu speichern und die Liste mit einem einzigen API-Aufruf zu übermitteln. Khronos bezeichnet dies als besonders nützlich beim Rendern vieler Objekte mit vergleichsweise geringer Dreiecksanzahl.

Dadurch kann der von der CPU zu bewältigende Aufwand für die Befehlsübermittlung sinken. Eine bestimmte Steigerung der Bildrate ist damit nicht garantiert, da weiterhin das Anwendungsdesign und die Zusammensetzung der Szene entscheidend sind. Für objektintensive Szenen steht Entwicklern jedoch ein effizienterer Weg zur Verfügung.

Warum dies eine anspruchsvolle Virtualisierungsaufgabe ist

Auf einer herkömmlichen Windows-Workstation sendet eine Anwendung Grafikbefehle an einen Windows-GPU-Treiber, der für die installierte Grafikhardware entwickelt wurde.

Bei einer virtuellen Windows-Maschine auf einem Mac mit Apple Silicon ist die Architektur anders aufgebaut.

Die Windows-Anwendung sieht ein virtuelles Grafikgerät. Die physische GPU des Macs wird über Apples Grafik-Stack verwaltet, in dem Metal die primäre API für leistungsintensive Grafik- und Rechenaufgaben ist.

Apple hat OpenGL in macOS 10.14 als veraltet eingestuft und empfiehlt Metal für die Entwicklung neuer, leistungsintensiver Grafik- und GPU-Compute-Anwendungen. OpenGL ist auf aktuellen macOS-Systemen einschließlich Apple Silicon weiterhin verfügbar, gilt jedoch als veraltet und wird von Apple nicht im gleichen Umfang weiterentwickelt wie Metal.

Parallels Desktop kann den Mac daher nicht so behandeln, als wäre eine herkömmliche Windows-GPU mit einem vom Hersteller bereitgestellten Windows-Treiber vorhanden. Stattdessen muss dem Gastbetriebssystem eine geeignete Grafikschnittstelle bereitgestellt und die daraus entstehende Arbeit auf Metal im Hostsystem abgebildet werden.

Vereinfacht dargestellt sieht der Ablauf so aus:

Windows-Anwendung → OpenGL-Treiber in der VM → virtuelle Grafikarchitektur von Parallels → Metal → Apple-Silicon-GPU

Hinter jedem Pfeil steckt Entwicklungsarbeit.

Die Übersetzung zwischen Grafik-APIs ist keine direkte Eins-zu-eins-Übertragung einer Befehlssprache in eine andere. OpenGL und Metal verfolgen unterschiedliche Ansätze bei Ressourcenverwaltung, Befehlsübermittlung, Synchronisierung, Shader-Verhalten und Grafikzuständen.

Die Übersetzungsschicht muss das von der Windows-Anwendung erwartete Ergebnis beibehalten. Gleichzeitig muss sie unnötiges Kopieren, wiederholte Zustandsänderungen und CPU-gebundene Befehlsverarbeitung vermeiden. Andernfalls kann der Übersetzungsaufwand einen großen Teil des Leistungsvorteils durch die GPU wieder aufzehren.

Was sich in Parallels Desktop 27 geändert hat

Parallels Desktop 27 führt eine neue, für Apple Silicon entwickelte Grafiktreiberarchitektur ein und ergänzt die Unterstützung von OpenGL 4.3 für virtuelle Windows-Maschinen.

Die Änderung verfolgt zwei miteinander verbundene Ziele.

Das erste Ziel ist die Kompatibilität. Durch die Bereitstellung eines neueren OpenGL-Funktionsumfangs können Anwendungen Grafikfunktionen erkennen, die in der virtuellen Umgebung zuvor nicht verfügbar waren.

Das zweite Ziel ist eine effizientere Ausführung. Die Metal-basierte Architektur ist darauf ausgelegt, mehr geeignete Grafikaufgaben an die Apple-GPU zu übergeben und gleichzeitig den CPU-Aufwand für deren Verarbeitung und Übermittlung zu reduzieren.

Beide Verbesserungen ergänzen sich. Die Unterstützung einer Funktion ist nur begrenzt hilfreich, wenn ihre Implementierung für den normalen Einsatz zu langsam ist. Umgekehrt hilft eine schnelle Übersetzungsschicht nicht, wenn eine Anwendung ihren Rendering-Pfad aufgrund einer fehlenden erforderlichen Funktion gar nicht aktiviert.

Bessere GPU-Auslastung

Die GPU-Auslastung beschreibt, wie effektiv die Grafikarbeitslast einer Anwendung die GPU erreicht und beansprucht. Eine geringe Auslastung bedeutet nicht zwangsläufig, dass die GPU zu schwach ist. Der Prozessor kann beispielsweise darauf warten, dass die CPU Arbeit vorbereitet, Daten kopiert werden oder ein Grafikbefehl mehrere Softwareschichten durchläuft.

Durch eine verbesserte Zuordnung von OpenGL-Operationen unter Windows zu Metal-Operationen unter macOS kann die neue Architektur mehr geeignete Aufgaben auf der GPU halten. Das ist bei interaktiven Anwendungen wichtig, weil das Zeichnen eines Frames nur einen Teil der Arbeitslast ausmacht. Zusätzlich müssen möglicherweise Szenendaten aktualisiert, Sichtbarkeit verarbeitet, Zeichenbefehle vorbereitet, Shader kompiliert oder ausgewählt und Speicherzugriffe koordiniert werden.

Geringerer CPU-Overhead

Die CPU bleibt unverzichtbar. Sie führt die Anwendung aus, übernimmt Aufgaben des Betriebssystems, verarbeitet Geschäftslogik und bereitet Teile der Szene vor. Probleme entstehen, wenn die CPU zu viel Zeit mit der Übersetzung oder Ausgabe von Grafikbefehlen verbringt, die von der GPU effizienter verarbeitet werden könnten.

OpenGL-4.3-Funktionen wie Multi-Draw Indirect können bei Anwendungen, die sie nutzen, einen Teil des Aufwands für die Befehlsübermittlung reduzieren. Verbesserungen in der virtualisierten Grafikpipeline können außerdem den Übersetzungs- und Koordinationsaufwand verringern.

Ein geringerer CPU-Overhead kann sich in einer reaktionsschnelleren Oberfläche, einem gleichmäßigeren Verhalten des Ansichtsfensters oder einer schnelleren Ausführung von Workflows zeigen, die CPU- und GPU-Arbeit kombinieren. Dies ist jedoch nicht als allgemeiner Leistungsmultiplikator zu verstehen. Die Ergebnisse hängen von Anwendung, Projekt, VM-Konfiguration, Mac-Modell und konkretem Vorgang ab.

Benchmark-Ergebnisse: Parallels Desktop 26 im Vergleich zu Parallels Desktop 27

Vergleich von Funktionen und Architektur

Zusammenfassung der Performance-Benchmarks

Bis zu 2,6-mal schnellere OpenGL-Grafik

Eine Steigerung um bis zu 160 % bedeutet, dass das gemessene Ergebnis im leistungsstärksten getesteten Fall das 2,6-Fache der Vergleichsleistung erreichte. Das bedeutet nicht, dass jede OpenGL-Anwendung um 160 % schneller wird. Der Wert bezieht sich auf den Grafik-Stack insgesamt. Dazu beitragen können die erweiterte API-Unterstützung, eine effizientere OpenGL-zu-Metal-Übersetzung, geringerer CPU-Overhead und eine bessere Nutzung neuerer Apple-GPU-Architekturen. Ein synthetischer oder gezielter Grafik-Benchmark kann diese Verbesserungen klarer isolieren als ein vollständiger Anwendungsworkflow. Reale Projekte enthalten in der Regel weitere Aufgaben, die vom Grafiksubsystem nicht beeinflusst werden.

Bis zu 35 % schnelleres 3D-Rendering in ArcGIS Pro

ArcGIS Pro nutzt eine GPU zur Darstellung von Karten und Szenen. Laut Esri-Dokumentation verwendet ArcGIS Pro für das Rendering hauptsächlich DirectX, auch wenn in einigen Workflows und Umgebungen OpenGL zum Einsatz kommen kann. Für virtualisierte Umgebungen empfiehlt Esri geeignete GPU-Ressourcen, um eine flüssige Navigation in Karten und Szenen zu unterstützen. Verbesserungen beim Rendering können sich auf Vorgänge wie das Neuzeichnen einer Szene, das Ändern der Kameraposition, die Darstellung von Gelände und die Anzeige dichter visueller Ebenen auswirken. Der genaue Vorteil hängt von der jeweiligen Szene ab. Ein Projekt, das durch Datenladen, Analysecode oder einen Remote-Dienst begrenzt wird, kann insgesamt weniger profitieren als eine lokale, grafikintensive 3D-Szene.

Bis zu 24 % schnellere ArcGIS Pro Workflows

Workflow-Tests liefern ein umfassenderes Maß, weil sie mehr als nur das Zeichnen einzelner Frames berücksichtigen. Ein ArcGIS-Pro-Workflow kann beispielsweise das Laden von Inhalten, das Wechseln von Ansichten, die Navigation in einer Szene, das Ändern von Ebenen und das Warten auf den Abschluss einer Folge von Vorgängen umfassen. Einige Schritte können direkt von Grafikverbesserungen profitieren, andere hängen weiterhin von CPU, Speicher, verfügbarem Arbeitsspeicher oder der Datenquelle ab. Eine Verkürzung der Ausführungszeit um 24 % kann bei wiederkehrenden Aufgaben relevant sein. Zur Einordnung: Eine getestete Abfolge, die zuvor 100 Sekunden dauerte, würde bei der maximal gemeldeten Verbesserung etwa 76 Sekunden benötigen. Diese Rechnung veranschaulicht den Prozentsatz und stellt keine Zusage für eine bestimmte Zeitersparnis in einem Kundenprojekt dar.

Starten Sie noch heute eine kostenlose Testversion von Parallels Desktop.

Wie OpenGL 4.3 GIS-Anwendungen auf dem Mac verbessert

GIS-Anwendungen kombinieren mehrere anspruchsvolle Datentypen in einer einzigen Ansicht.

Eine 3D-Szene kann Höhenflächen, Luftbilder, extrudierte Gebäude, Beschriftungen, Punktwolken, Vektorobjekte und analytische Überlagerungen enthalten. Unterschiedliche Ebenen können verschiedene Rendering-Techniken und Detailstufen erfordern.

Gleichzeitig wird erwartet, dass sich die Ansicht beim Verschieben, Zoomen, Neigen oder Wechseln von Ebenen kontinuierlich aktualisiert.

Esri empfiehlt geeignete GPU-Ressourcen für eine flüssige Darstellung von Karten und Szenen, auch in virtualisierten Umgebungen.

Die Unterstützung von OpenGL 4.3 beschleunigt nicht automatisch jeden GIS-Vorgang über die GPU. Datenbankabfragen, Geoverarbeitungswerkzeuge, Python-Skripte, Netzwerkanfragen und viele Analyseaufgaben können weiterhin durch CPU, Arbeitsspeicher oder Ein-/Ausgabe begrenzt sein.

Die deutlichsten Vorteile sind bei Aufgaben zu erwarten, bei denen die Grafikverarbeitung einen wesentlichen Teil der Gesamtzeit ausmacht. Beispiele sind die Navigation durch detaillierte 3D-Szenen, das Neuzeichnen visuell dichter Ebenen und die Arbeit mit Projekten, bei denen das Ansichtsfenster regelmäßig aktualisiert wird.

OpenGL-4.3-Kompatibilität für CAD- und Engineering-Anwendungen

CAD- und Engineering-Software arbeitet häufig mit Modellen, die aus vielen einzelnen Objekten, präzisen Flächen, Kanten, Materialien, Anmerkungen und Darstellungszuständen bestehen.

Bei der Bearbeitung wird unmittelbares visuelles Feedback erwartet. Wird eine Baugruppe gedreht, muss die Anwendung sie aus einem neuen Winkel neu zeichnen. Wird eine Komponente isoliert, ändert sich die Darstellung erneut. Werden Schnittdarstellung, Schattierung, Kantenlinien, Transparenz oder Analyseüberlagerungen aktiviert, wird die Rendering-Arbeitslast komplexer. Eine moderne GPU kann einen großen Teil dieser Arbeit parallel verarbeiten, doch die Anwendung benötigt Zugriff auf die Grafikfunktionen, die ihr Renderer voraussetzt.

OpenGL 4.3 führt Funktionen ein, mit denen Rendering-Engines größere Datensätze verwalten und objektintensive Szenen effizienter übermitteln können. Ob ein bestimmtes CAD-Produkt diese Funktionen nutzt, muss beim Softwareanbieter geprüft und mit der jeweiligen Anwendungsversion getestet werden.

Diese Unterscheidung ist wichtig. API-Unterstützung schafft eine technische Grundlage für Kompatibilität. Sie ist nicht gleichbedeutend mit einer Zertifizierung durch Autodesk, Dassault Systèmes, Siemens oder einen anderen unabhängigen Softwareanbieter.

Vor dem produktiven Einsatz einer Windows-Engineering-Anwendung sollten Teams Folgendes prüfen:

• die vom Anbieter unterstützten Betriebssysteme und Grafikanforderungen
• ob Windows on Arm unterstützt wird
• Abhängigkeiten von Plug-ins und Gerätetreibern
• Kompatibilität des Lizenzmanagers
• Zertifizierungsanforderungen
• Leistung mit repräsentativen Projektdateien

Parallels Desktop kann eine Grafikumgebung bereitstellen. Der jeweilige Anwendungsanbieter legt seine offiziellen Support- und Zertifizierungsrichtlinien fest.

OpenGL-4.3-Unterstützung für Architektur- und BIM-Anwendungen

Gebäudemodelle stellen eigene Anforderungen an ein Grafiksystem.

Ein koordiniertes BIM-Projekt kann Architekturelemente, Tragwerkskomponenten, Gebäudetechnik, verknüpfte Modelle, Anmerkungen und importierte Geometrie kombinieren. Das Modell wird in der Regel aus vielen Blickwinkeln geprüft, statt nur einmal als finales Bild gerendert zu werden. Die Reaktionsfähigkeit der Grafik beeinflusst alltägliche Vorgänge wie das Drehen um das Gebäude, das Isolieren eines Geschosses, das Wechseln von Darstellungsmodi und das Prüfen von Kollisionen oder Konstruktionsdetails.

Eine leistungsfähigere virtuelle Grafikgrundlage kann die Nutzung von Anwendungen und Plug-ins verbessern, die unterstützte OpenGL-Pfade verwenden. Sie kann außerdem den Kreis der Programme erweitern, die ihren vorgesehenen Renderer initialisieren können, statt auf einen eingeschränkten Funktionspfad auszuweichen.

Anwendungsspezifische Ergebnisse können variieren, da Architektur- und BIM-Tools weder dieselbe Grafik-Engine verwenden noch demselben Supportmodell folgen. Einige setzen für das Rendering im Ansichtsfenster hauptsächlich auf DirectX, andere verwenden eine Mischung aus Grafik-APIs oder sind bei ausgewählten Funktionen und Komponenten auf OpenGL angewiesen.

OpenGL-4.3-Unterstützung für Simulation und wissenschaftliche Visualisierung

Simulationsarbeit lässt sich häufig in zwei Phasen unterteilen.

Der Solver berechnet das Ergebnis. In der Nachbearbeitung wird dieses Ergebnis so aufbereitet, dass es technisch ausgewertet werden kann.

Die Berechnungsphase kann hauptsächlich von der CPU, spezialisierten GPU-Compute-Frameworks, der Speicherbandbreite oder einem entfernten Rechencluster abhängen. OpenGL-Unterstützung beschleunigt diese Berechnung nicht automatisch.

Bei der Visualisierung ist das anders. Die Darstellung eines großen Finite-Elemente-Netzes, eines Vektorfelds, einer transienten Animation oder eines farbcodierten Ergebnisses kann die Grafikpipeline stark beanspruchen. OpenGL-4.3-Funktionen können Visualisierungssoftware leistungsfähigere Werkzeuge zur Verwaltung von Ergebnisdaten und zur Ausführung paralleler GPU-Operationen bereitstellen. Das tatsächliche Verhalten hängt vom Postprozessor und dem verwendeten Codepfad ab.

Warum OpenGL-4.3-Kompatibilität ebenso wichtig ist wie Leistung

Leistungswerte ziehen Aufmerksamkeit auf sich, doch die Unterstützung von OpenGL 4.3 ist zugleich ein wichtiger Schritt für die Kompatibilität.

Eine Anwendung, die eine erforderliche API-Funktion prüft, kann unterschiedlich reagieren, wenn diese Funktion nicht verfügbar ist. Sie kann einen Effekt deaktivieren, einen weniger leistungsfähigen Renderer wählen, das Öffnen einer 3D-Ansicht verweigern, eine Warnung anzeigen oder nicht starten. Wird die erforderliche Funktion bereitgestellt, kann die Anwendung einen anderen Pfad verwenden.

Das bedeutet nicht, dass nun jedes Programm unterstützt wird, das OpenGL 4.3 voraussetzt. Anwendungen sind zusätzlich vom Verhalten der Shader-Sprache, Erweiterungen, Treibereigenheiten, der Windows-Architektur, Systembibliotheken, Lizenzierungskomponenten und vom Anbieter getesteten Konfigurationen abhängig.

Dennoch beseitigt eine neuere und vollständigere OpenGL-Implementierung eine wesentliche Klasse von Einschränkungen. Sie schafft für das Parallels-Engineering-Team eine bessere Grundlage, um weitere professionelle Anwendungen zu testen und im Laufe der Zeit zu verbessern.

OpenGL und Metal stehen innerhalb der VM nicht in Konkurrenz

OpenGL und Metal lassen sich leicht als konkurrierende Technologien darstellen. In dieser Architektur erfüllen sie jedoch unterschiedliche Aufgaben innerhalb derselben Arbeitslast.

Die Windows-Anwendung verwendet OpenGL, weil ihr Renderer für diese Schnittstelle entwickelt wurde.

Parallels Desktop bildet diese Arbeit auf Metal ab, weil Metal Apples aktuelle API für den leistungsfähigen Zugriff auf von Apple entwickelte GPUs ist. Apple empfiehlt Entwicklern nativer Mac-Anwendungen, von veraltetem OpenGL-Code auf Metal umzusteigen. Ein Virtualisierungsprodukt kann jedoch nicht verlangen, dass jeder Anbieter von Windows-Software seine Anwendung für Metal neu schreibt. Die Übersetzungsschicht ermöglicht es vorhandenem Windows-Rendering-Code, die GPU des Macs über das bevorzugte Grafik-Framework der Hostplattform zu nutzen.

Diese Brücke ist die zentrale technische Leistung.

Praktische Hinweise vor dem Einsatz einer professionellen Anwendung

Die Unterstützung von OpenGL 4.3 beseitigt eine wichtige technische Einschränkung. Für die Planung einer Workstation sind dennoch Tests erforderlich.

• Verwenden Sie ein repräsentatives Projekt statt einer leeren Datei. Große Baugruppen, detaillierte Szenen, dichte Ebenen, benutzerdefinierte Shader und Plug-ins von Drittanbietern zeigen häufig Probleme, die bei einem einfachen Starttest nicht sichtbar werden.
• Weisen Sie der virtuellen Maschine ausreichend Arbeitsspeicher zu, ohne macOS zu wenig Ressourcen zu lassen. Unified Memory wird systemweit gemeinsam genutzt, daher ist eine höhere Speicherzuweisung an Windows nicht automatisch besser.
• Halten Sie Parallels Tools und die Anwendung auf dem aktuellen Stand. Grafikfehlerbehebungen können unabhängig von größeren Produktversionen bereitgestellt werden.
• Prüfen Sie die Kompatibilität mit Windows on Arm. Eine Grafik-API kann unterstützt werden, während ein Plug-in, Kernel-Treiber, eine Lizenzierungskomponente oder Hardwareintegration nicht unterstützt wird.
• Prüfen Sie die Zertifizierungsanforderungen des Anbieters. Organisationen in regulierten oder produktionskritischen Umgebungen benötigen möglicherweise eine offiziell zertifizierte Workstation-Konfiguration, selbst wenn eine Anwendung in einer VM korrekt ausgeführt wird.
• Messen Sie den Workflow, auf den es ankommt. Bildrate, Ladezeit einer Szene, Geschwindigkeit beim Neuzeichnen, Exportdauer und End-to-End-Aufgabenzeit beantworten jeweils unterschiedliche Fragen.