Für die GPU-Unterstützung in seinem Windows Subsystem für Linux (WSL) hat Microsoft seine Grafikschnittstelle DirectX 12 mit sehr viel Aufwand und auch mithilfe der Grafikkartenhersteller auf Linux portiert. Das gibt der Hersteller auf seiner virtuellen Hausmesse Build bekannt.

Da das WSL in seiner aktuellen Version 2 auf eine Virtualisierung per Hyper-V setzt, kann Microsoft aber keinen direkten Zugriff auf die Hardware ermöglichen. Deshalb ist ein Linux-Kernel-Modul entstanden, das die unter Windows für DirectX 12 genutzte Grafikinfrastruktur schlicht an das WSL weiterleitet. Konkret hat Microsoft dafür dem Kernel-Mode-Treiber dxgkrnl ein gleichnamiges Linux-Pendant zur Seite gestellt.

Dieser Nachbau und die Abstraktion machen es möglich, dass Microsoft seine Bibliotheken für die eigene Grafikschnittstelle schlicht nur neu kompilieren musste, um diese auf Linux zu portieren, wie es in der Ankündigung heißt. Dies betrifft das D3D12-API, das unter Linux nun als libd3d12.so verfügbar ist, sowie das neue DxCore (libdxcore.so).

Beide genannten Bibliotheken sind weiterhin proprietäre Software und werden von dem Loader des WSL beim Start automatisch in die Umgebung eingefügt. Zusätzlich dazu hat Microsoft auch noch seine Machine-Learning-Bibliothek DirectML auf diesen neuen Stack portiert und die Grafikkartenhersteller haben ihre Userspace-Treiber daran angepasst, die mit der Windows-Technik nun ebenfalls in Linux laufen.

Gleiches gilt für Cuda von Nvidia, das nun auch auf Grundlage von DirectX12 in Linux laufen kann. All diese Arbeiten und Ports dienen bisher der Unterstützung für Machine-Learning-Aufgaben oder ähnlichen Compute-Anwendungen auf der GPU.

Konkrete Angaben zur Unterstützung von Vulkan macht Microsoft derzeit nicht. Aber die unter Linux häufig verwendeten Schnittstellen OpenGL und OpenCL werden derzeit von Collabora ebenso auf den neuen Stack portiert. Damit sollten dann auch jene Linux-Anwendungen, die diese freien Schnittstelle nutzen, vergleichsweise einfach auf die Grafikbeschleunigung in dem neuen WSL-Stack zugreifen können.

Für die Portierung setzt das Linux-Team auf die freie 3D-Grafikbibliothek Mesa. Ziel ist es hier, die nun auf Linux portierte DirectX-12-Technik als Backend für Mesa verfügbar zu machen, sodass die freie Technik als eine Art Übersetzungsschicht fungiert. Das ist nicht ungewöhnlich, ähnliche Ansätze gibt es mit der Vulkan-API als Backend. Der Code zu den Arbeiten an Mesa steht bereits als Open Source zur Verfügung.

Ob und inwiefern der von Microsoft und seinen Partnern erstellte Code jedoch in den Hauptzweigen der kanonischen Linux-Projekte landen wird, ist schwierig abzuschätzen. Das zeigt beispielhaft die Diskussion der Kernel-Community.

Wie es für Microsoft inzwischen zum guten Ton gehört, versucht das Unternehmen auch, für diese Arbeiten aktiv und eng mit der Linux-Community zusammenzuarbeiten. Der von Microsoft erstellte Linux-Kernel-Treiber steht deshalb nicht nur als Open Source bereit. Das zuständige Team hat den Code dafür darüber hinaus auch auf der Linux-Kernel-Mailing-Liste zur Aufnahme in dem Hauptzweig von Linux vorgeschlagen und will aktiv daran mitwirken.

Der bei Microsoft angestellte Linux-Entwickler Sasha Levin erklärt in der E-Mail erneut detailliert den beschriebenen Aufbau sowie zusätzlich dazu auch weitere Details zu dem Linux-Treiber selbst. Dort wird unter anderem erneut explizit dargestellt, dass der Aufbau bisher keine Display-Funktionalität enthält. Levin schreibt außerdem: „Dieser GPU-Stack steht effektiv neben dem nativen Linux-Grafikstapel.“

Vor allem Letzteres dürfte eine Aufnahme in das Grafiksubsystem des Kernels deutlich erschweren. Immerhin hat Microsoft für den DirectX-12-Port lediglich seine eigenen Windows-Schnittstellen für Linux nachgebaut, statt die vorhandenen Kernel-Schnittstellen und -Technik wiederzuverwenden. Vor allem diese Wiederverwendung und die damit verbundene Kooperation untereinander sind eine Stärke der Linux-Community, die diese immer wieder forciert.

Es ist deshalb zumindest derzeit nicht absehbar, dass der Code in seiner aktuellen Form in das Grafik-Subsystem eingepflegt wird. Das schreibt etwa auch Dave Airlie, der es als hauptverantwortlicher Betreuer pflegt. Airlie vermutet, dass die Technik wohl nie außerhalb des WSL von Microsoft genutzt werden würde und klassische Linux-Distributoren entsprechend kaum Interesse daran haben dürften. Die Pflege des Treibers hält Airlie auch deshalb derzeit nicht für sinnvoll.

Ähnlich argumentiert auch Daniel Vetter, der Hauptbetreuer für den Intel-Grafiktreiber unter Linux. Dieser schreibt, es gebe einige fundamentale Probleme mit dem Code. Das Wichtigste ist wohl, dass der Userspace-Teil dazu bisher komplett proprietär ist. Voraussetzung für die Aufnahme im Grafiksubsystem des Kernels sind jedoch freie Userspace-Treiber. Vetter kritisiert darüber hinaus, dass Microsoft einige vorhandene Linux-Technik schlicht nicht genutzt, sondern komplett neu erstellt hat. Vetter fehlen ebenso weitere Integrationen mit vorhandener Technik etwa zur Speicherverwaltung.

Sowohl Vetter als auch Airlie sehen trotz ihrer technischen Kritik jedoch die Möglichkeit, dass der Microsoft-Code ähnlich behandelt wird wie andere Beschleunigerkarten und damit in einem anderen Subsystem landet, für das diese keine Verantwortung tragen. Die nun von beiden vorgetragene Kritik haben diese so ähnlich vor etwas mehr als einem Jahr schon einmal vorgetragen, als die Linux-Community über die Schaffung eines Subsystems für Beschleunigerkarten diskutiert hat.

Sollte Microsoft jedoch tatsächlich die nun neu geschaffene Technik jemals auch um eine echte Grafikdarstellung erweitern wollen, könnte die Diskussion von vorn beginnen, befürchten die Grafikentwickler. Dementsprechend sollte der Code schon jetzt angepasst werden, falls die Umsetzung für eine Grafikdarstellung seitens Microsoft geplant ist.

Der Diskussion folgend ist davon auszugehen, dass der Code in seiner jetzigen Form zumindest nicht im Grafiksubsystem von Linux landen wird. Eine Aufnahme als Beschleunigertreiber scheint jedoch mittelfristig durchaus naheliegend. Dafür spricht auch, dass sich der Entwickler Greg Kroah-Hartman bereits mit dem Code auseinandergesetzt hat. Kroah-Hartman war einer der Befürworter zur Schaffung des Beschleuniger-Subsystems.

Autor des Artikels ist Sebastian Grüner.