WSU GPU, en implementering for å gi tilgang til grafiske Linux-applikasjoner i WSL

Forrige uke, den Microsoft-utviklere kunngjorde flere viktige forbedringer av delsystemet WSL (Windows Subsystem for Linux), som gjør det mulig for Linux-applikasjoner å kjøre på Windows. Som Starter med Windows 10. mai-oppdateringen, den første installasjonen av Linux-miljøet det vil bruke WSL2-laget som standard.

WSL2-miljøet kjører på et diskbilde (HDV) separat med ext4 filsystem og den virtuelle nettverksadapteren. Linux-kjernen i WSL2 Det vil ikke bli inkludert i Windows-installasjonsbildet, men Windows vil dynamisk laste det inn og den vil holde den i gjeldende form, i likhet med hvordan grafikkdrivere installeres og oppdateres. For å installere og oppdatere kjernen, vil standard Windows Update-mekanismen bli brukt.

Den foreslåtte kjernen for WSL2 er basert på Linux 4.19-kjerneutgivelsen, kjører i et Windows-miljø ved hjelp av en virtuell maskin som allerede er i bruk i Azure.

WSL2-spesifikke oppdateringer som brukes i kjernen inkluderer optimaliseringer for å redusere kjernens oppstartstid, redusere minneforbruk, returnere Windows til minne frigjort av Linux-prosesser, og la det minste settet med nødvendige drivere og delsystemer være i kjernen.

Nå mulig å kjøre grafiske applikasjoner i WSL

I tillegg til de ovennevnte er en annen av nyhetene som skiller seg ut Innledende støtte for Linux-applikasjoner med et "WSU GPU" grafisk grensesnitt.

Støtten sog implementerer ved å virtualisere GPU-tilgang og gi drivere gjennom hvilke de vanlige grafiske delsystemene til Linux-distribusjoner kan fungere, inkludert de som er basert på Wayland. Grafiske applikasjoner for Linux og Windows kan kjøres side om side på Windows-skrivebordet.

En åpen dxgkrnl-driver er utarbeidet for Linux-kjernen, og gir en / dev / dxg-enhet tjenester som replikerer Windows Display Driver Model (WDDM) D3DKMT av Windows-kjernen. Kontrolleren oppretter en forbindelse til den fysiske GPUen ved hjelp av VM-bussen. Linux-applikasjoner har samme nivå av GPU-tilgang som innfødte Windows-applikasjoner uten å dele ressurser mellom Windows og Linux.

I tillegg bibliotekarenen libd3d12.so er gitt for Linux, som gir Direct3D 12 full grafisk API.

Biblioteket libd3d12.so er bygget fra samme kode som den opprinnelige Windows-implementeringen av Direct3D 12 og det er helt likt i funksjonalitet til d3d12.dll-biblioteket.

Jeg vet det også gir en forenklet versjon av DXGI API (DirectX Graphics Infrastructure) i form av DxCore-biblioteket (libdxcore.so). Libd3d12.so og libdxcore.so biblioteker er proprietære og leveres bare i binære builds (montert på WSL som / usr / lib / wsl / lib), kompatible med Ubuntu, Debian, Fedora, Centos, SUSE og andre Glibc-baserte distribusjoner .

Støtte for OpenGL i Mesa er gitt gjennom et lag som oversetter DirectX 12. API-anrop. Metoden for å implementere Vulkan API er fortsatt i planleggingsfasen.

I den første fasen, i WSL-miljøer, vil CUDA og DirectML støttes, arbeider på D3D12 API (for eksempel i et Linux-miljø kan du kjøre TensorFlow med en backend for DirectML). OpenCL-støtte er mulig gjennom et lag som utfører samtalekartlegging i DirectX 12 API.

Microsoft utvikler sin sammensatte manager ved hjelp av Wayland-protokollen og basert på Weston-kodebasen. Den sammensatte lederen bruker RDP-RAIL (Lokalt integrert RDP Remote Application) for å organisere utdataene fra Linux-applikasjonsgrensesnittet til hovedvinduet på skrivebordet. RDP-RAIL skiller seg fra RDP-backend som tidligere var tilgjengelig fra Weston ved at komposittbehandleren ikke gjengir skrivebordet selv, men i stedet omdirigerer individuelle overflater (wl_surface) gjennom RDP RAIL-kanalen for å vises på hovedvinduet på Windows.

I tillegg vil en WSL-installasjon med den enkle kommandoen wsl.exe –install snart støttes.

Til slutt, hvis du vil vite mer om det, kan du konsultere detaljene i følgende lenke.