Die zunehmende Bedeutung von Hardwarebeschleunigung in der Grafikdarstellung stellt eine große Herausforderung für die Virtualisierung dar. Grafikvirtualisierung ermöglicht es mehreren virtuellen Maschinen gleichzeitig, auf die GPU des Hosts zuzugreifen und 3D-Beschleunigung zu nutzen, ohne dass dedizierter Pass-Through benötigt wird. Ein bedeutender Player in diesem Bereich ist virglrenderer, ein Open-Source-Projekt, das eine Vielzahl von Technologien kombiniert, um diese Funktionalität mit unterschiedlichen Ansätzen zu realisieren. Hier stehen insbesondere drei Technologien im Fokus: VirGL, Venus und der virtuelle DRM-Kontext (vDRM). Grafikvirtualisierung bedeutet insbesondere, dass innerhalb einer VM eine hardwarebeschleunigte Grafiknutzeroberfläche bereitgestellt werden kann. Im Gegensatz zum GPU-Passthrough, bei dem eine GPU exklusiv einer einzelnen VM zugewiesen wird, erlaubt die Grafikvirtualisierung die gleichzeitige Nutzung derselben Hardware durch Host und Gäste.
Dadurch können Ressourcen effizienter genutzt werden, was die Flexibilität bei der Verteilung von Grafikintensiven Anwendungen erhöht. Virglrenderer unterstützt sowohl OpenGL als auch Vulkan als Grafik-APIs, wobei unterschiedliche technologische Pfade adressiert werden, abhängig von den jeweiligen Anforderungen und Gegebenheiten des Host- und Gastsystems. Die Verwendung dieser APIs ermöglicht es, dass Anwendungen innerhalb der VM von den fortschrittlichen Grafikfähigkeiten des Hosts profitieren, ohne dass spezielle Treiber auf der Gastseite notwendig sind. Venus fungiert als Transportebene für Vulkan-Befehle. Im Wesentlichen werden Vulkan-Aufrufe vom Gast zur Host-API weitergeleitet. Ein großer Vorteil dieser Methode ist ihre Effizienz: Ressourcen wie Shader werden in Form von SPIR-V-Binärdaten übermittelt, die vom Host direkt verarbeitet werden können.
Dadurch entfallen aufwendige Zwischenübersetzungen und Neukompilierungen, was die Performance nahezu auf das Niveau einer nativen Ausführung bringt. Ein möglicher Flaschenhals liegt jedoch in der Synchronisierung zwischen Host und Gast, welche die Gesamtleistung etwas einschränken kann. Aktuell ist der Einsatz von Venus an die Unterstützung sogenannter Blob-Ressourcen im Virtual Machine Manager (VMM) gekoppelt. Während CrosVM diese bereits unterstützt, befindet sich die QEMU-Integration noch im Stabilitätsprozess. Zudem benötigt Venus eine moderne Vulkan-API mit Unterstützung für Erweiterungen wie VK_EXT_image_drm_format_modifier, wodurch ältere AMD-Grafikkarten vor der GFX9-Generation nicht kompatibel sind. Auch mit den proprietären NVIDIA-Treibern gibt es noch bekannte Probleme, die aber voraussichtlich mit zukünftigen Treiberversionen behoben werden.
Venus bietet nicht nur Vulkan-Support, sondern ergänzt OpenGL-Fähigkeiten über Zink, einem Treiber, der OpenGL-Aufrufe in Vulkan übersetzt, damit Venus diese verarbeiten kann. Durch diese Kombination ist es möglich, sowohl Vulkan- als auch OpenGL-Anwendungen effizient innerhalb der VM laufen zu lassen – ohne spezielle, hardwarebezogene Treiberinstallation im Gastbetriebssystem. Das macht Venus besonders attraktiv für vielseitige Umgebungen, in denen verschiedene Grafik-Workloads laufen müssen. VirGL dagegen ist speziell auf OpenGL ausgelegt. Im Gegensatz zu Venus verarbeitet VirGL viele Grafikanweisungen doppelt: Shaderkompilierung und -linking finden sowohl im Gast als auch auf dem Host statt. Der Shader-Code wird vom Gast im TGSI-Format (Tungsten Graphics Shader Infrastructure) übermittelt und anschließend im Host auf GLSL (OpenGL Shading Language) umgewandelt, was Performanceeinbußen zur Folge hat.
Ein strukturelles Problem von VirGL ist zudem die serielle Verarbeitung aller OpenGL-Kommandoströme innerhalb des Hosts. Dies bedeutet, dass das gleichzeitige Ausführen mehrerer OpenGL-Anwendungen im Gast zu merklichen Performanceverlusten führt. Trotz dieser Einschränkungen überzeugt VirGL durch seine Fähigkeit, auch auf Hosts mit nur OpenGL- oder gar OpenGL ES-Support zu funktionieren. Es werden Features auch dann emuliert, wenn sie vom Host nicht nativ unterstützt werden können, was die Kompatibilität mit einer breiten Palette alter und neuer Hardware erhöht. Im Übrigen hat VirGL in QEMU OpenGL-Versionen bis 4. 3 bzw. GLES 3. 2 gut implementiert, wobei es theoretisch bis Version 4. 6 skalierbar ist, dies aber an die Unterstützung von Blob-Ressourcen im VMM gebunden ist. Als Alternative zur klassischen VirGL-Lösung etabliert sich zunehmend die Kombination aus Zink und Venus.
Da Zink OpenGL in Vulkan übersetzt, profitieren Virtualisierungsumgebungen mit dieser Kombination von der Leistungsfähigkeit von Vulkan über Venus. Dadurch können einige der limitierenden Faktoren von VirGL, wie die serielle Befehlskette und die doppelte Shaderverarbeitung, umgangen werden. Für den Betrieb von mehreren OpenGL-Anwendungen gleichzeitig zeigt die Kombination von Zink+Venus deutlich bessere Performance. Allerdings sind noch Optimierungen und Bugfixes nötig, um die Stabilität und Performance vollständig auszuloten. Insbesondere in Verbindung mit Display-Servern wie Weston oder Compositoren zeigt sich noch Entwicklungsbedarf. Eine besonders spannende Entwicklung ist der virtuelle DRM-Kontext (vDRM), der eine sehr direkte Schnittstelle zur GPU des Hosts darstellt. Im Gegensatz zu den höheren API-Ansätzen von VirGL oder Venus verbindet sich vDRM näher auf Kernel-Ebene mit der Hardware.
Dabei generiert der virtuelle DRM-Kontext an den Gast quasi eine native GPU, die entsprechend von hardware-spezifischen Treibern im Gastsystem direkt angesteuert werden kann. Dieses Prinzip verspricht die bestmögliche Performance, da hierbei overheadintensive Host-Gast-Kommunikationen minimiert werden und viele Operationen nativ ausgeführt werden. Ein Nachteil von vDRM ist jedoch seine eingeschränkte Portabilität. Da die Implementierung stark vom spezifischen GPU-Treiber abhängt, sind für neue Hardware meist eigene, speziell entwickelte vDRM-Treiber notwendig. Da der Markt für Grafikchips aber auf einige wenige Anbieter limitiert ist, stellt dies in der Praxis kein wesentliches Hindernis dar. Bis Anfang 2025 ist vDRM bereits teilweise in CrosVM integriert, wobei Display-Ausgaben aktuell noch über Sommelier (einen Wayland-Protokoll-basierten X-Server-Proxy) erfolgen, da KMS-basierte Darstellung für vDRM noch nicht vollständig unterstützt wird.
Die QEMU-Integration wird ebenfalls aktiv vorangetrieben. Im Umgang mit Blob-Speicher gibt es Kernel-intern technische Herausforderungen, insbesondere durch die Interaktion zwischen KVM (Kernel-based Virtual Machine) und TTM (Translation Table Maps). Diese führen dazu, dass nicht alle Treiber Blob-Support bieten, wobei Verbesserungen mit dem Linux Kernel 6. 13 erwartet werden. Im Ergebnis gilt virglrenderer als zukunftsfähige Lösung für beschleunigte Grafik im Virtualisierungsbereich. VirGL eignet sich besonders für ältere Hardware und einfache Anwendungsfälle, bei denen OpenGL ausreicht. Venus ist ein moderner, Vulkan-basierter Ansatz, der mit Zink eine umfassende OpenGL-Unterstützung realisiert und sowohl Stabilität als auch Performance zielgerichtet vorantreibt. vDRM ist dagegen für Anwender interessant, die maximale Performance und direkten Zugriff auf die Hardwaredriver brauchen und bereit sind, spezifische Treiber im Gast zu verwenden.
Der Blick in die Zukunft verspricht eine enge Integration aller Technologien, wobei zum Beispiel QEMU und CrosVM die Unterstützung aller drei Varianten als Standard anbieten könnten. So können Nutzer je nach Anforderung und Hardwarekonfiguration die optimale Lösung für ihre Grafikvirtualisierungsbedürfnisse wählen. Die Diskussionen und Entwicklungen rund um virglrenderer sind ausgesprochen dynamisch. Die praktische Anwendung im Alltag reicht von einfachen Desktop-VMs bis hin zu komplexen Cloud-Umgebungen und Android-Emulatoren. So gibt es auch Alternativen wie gfxstream mit Magma, die vor allem im Android-Ökosystem Fuß fassen, jedoch noch nicht die Breite von virglrenderer in klassischen Linux-Systemen erreichen. Abschließend lässt sich sagen, dass virglrenderer mit Venus, VirGL und vDRM verschiedene technologische Wege angeboten hat, die unterschiedlichste Anforderungen an Grafikvirtualisierung abdecken.
Die Balance zwischen Kompatibilität, Performance, Stabilität und Support für neue Hardwaregattungen bestimmt dabei die Auswahl der geeigneten Technologie. Mit der kontinuierlichen Verbesserung von Kernel, Mesa und den VMMs rückt die Vision, virtuelle Maschinen mit nahezu nativer Grafikperformance auszustatten, immer näher.
