A Microsoft "Directx on Linux" patchkészletet küldött be az LKML-re; az örömbe üröm is vegyült

Kernel

Sasha Levin, a Microsoft alkalmazásában álló "Linux Kernel Hacker" egy "DirectX on Linux" patchkészletet küldött be a Linux Kernel Mailing List-re (LKML). Az általuk végzett munkáról a "DirectX is coming to the Windows Subsystem for Linux" blogbejegyzés ad részletes áttekintést. A munka része a dxgkrnl Linux kernel driver, amelyet Sasha beküldött:

Dxgkrnl is a brand-new kernel driver for Linux that exposes the /dev/dxg device to user mode Linux. /dev/dxg exposes a set of IOCTL that closely mimic the native WDDM D3DKMT kernel service layer on Windows. Dxgkrnl inside of the Linux kernel connects over the VM Bus to its big brother on the Windows host and uses this VM bus connection to communicate with the physical GPU.

Amellett, hogy a munkát a Linux kernel karbantartói örömmel fogadták, kifejezték bizonyos aggályaikat is. A Phoronix így ír erről:

The DXGKRNL kernel driver for Linux sits between Microsoft's to-be-published proprietary Direct3D 12 libraries that sit in Linux user-space and the host system that will receive the instructions. DXGKRNL communicates with the host system via Microsoft Hyper-V.

With Microsoft keeping their Direct3D 12 Linux libraries closed-source, that immediately created some friction to no surprise while they attempt to upstream their open-source Linux kernel driver. From the Direct Rendering Manager (DRM) perspective, they do not normally allow drivers/features into the kernel that are contingent exclusively upon a proprietary client in user-space, as is the case here. So if they are trying to play nicely with upstream DRM, that immediately causes problems with the Direct3D 12 user-space libraries not going open-source.

Intel open-source developer Daniel Vetter who helps oversee the DRM subsystem immediately pointed out a number of problems, including the closed-source user-space. Among the issues raised by Vetter is that the DirectX kernel driver is "reinventing the world" in changing around device enumeration and a lot of other interfaces/features already supported in a common manner by upstream DRM drivers. There are also questions raised about how well this integrates with other common Linux features like DMA-BUF.

DRM maintainer David Airlie was also quick to characterize this as a driver that connects a binary blob interface in Windows to a binary blob in Linux guests. He personally sees little value in having this driver upstreamed and raised concerns over how this driver will ultimately handle its planned presentation bits for displaying of Linux GUI applications within WSL2. He also raised the possibility of this landing in the Linux kernel as part of the Microsoft Hyper-V drivers rather than in the DRM driver area.

Részletek a Phoronix cikkében és az LKML szálban.

( nydn | 2020. 05. 20., sze – 09:53 )

Elértük már az extend periódust, vagy ez még csak az embrace része?

( RaptoR | 2020. 05. 20., sze – 10:42 )

Még mielőtt valaki félreértené, hogy milyen - technikai - célból készül ez: WSL2 alatt akarják elérhetővé tenni DX12-en keresztül a GPU-t CUDA/OpenCL stb. alkalmazásoknak, pl. ML meg hasonlók. Tehát (egyelőre) nem az a cél, hogy benyomják a DX12-t a Linuxba, majd miután ráállnak mondjuk a játékok fejlesztői, ellehetetlenítik valahogy a dolgot. Inkább beleillik ez is abba a szálba, hogy a fejlesztőket csábítják át a platformra, hogy amit eddig csak Linux alatt fejlesztettek, azt tegyék Windows/WSL2 páros alatt. (És ha már ott vannak, "tolják fel a végső terméket az MS felhőbe egy kis apróért"-típusú termékcsatolás.)

Ahhoz, hogy MS felhőbe dolgozz, nem kell windows platformon fejlesztened. A Visual Studio kivételével kb. minden megvan linuxon az azúrhoz fejlesztéshez, de igazából a VS amúgy is csak a .NET alapú mobilos, illetve windowsos fejlesztéshez kell (windows.forms, wpf, office). Az azúr picit linux-barátabb is mint windows, Pl. app service-t GUI-s felületen keresztül dockerrel a legutóbbi időkig csak linuxosat tudtál csinálni, de Pl. hivatalos sql szerver docker image is csak linux alapon volt amikor utoljára néztem... Az azure portálon a cloud shell-ben választhatsz hogy bash vagy powershell legyen a parancsértelmező, és a tutorialok nagy része az előbbivel van megcsinálva. Ráadásul egy rakás dolognál nem csak .NET támogatás van, hanem python, java, javascript, sőt van ahol PHP is. Szóval a MS felhőhöz ez nem igazán kell. Ez max. arra jó, hogy a windowson dolgozó fejlesztők futtathassanak linuxos progikat is ha akarnak.

( leviske | 2020. 05. 20., sze – 10:43 )

Jól értelmezem, hogy ez a kezdeményezés arról szól, hogy Linux-only fejlesztői környezetben is inkább DX12 alapokon dolgozzanak egyesek Vulkan és OpenCL helyett? Ennek mi helye volna a kernelben?

( transitive | 2020. 05. 20., sze – 12:50 )

Nyomul az MS. Kb. amit nem tudsz eltaposni, annak állj az élére. Azért szerettem eddig a Linuxot, mert mentes volt a sok MS-fostól. Tudom, nem kötelező használni.

Hat a pulse es systemd ota lehet kicsit jobb a win-t hasznalni, mint a Linux distro-kat. :D

A kernel az egy mas teszta. Amugy ez a dirctx-es driver nem biztos hogy olyan szar, ha beleolvasztjak plane. Ha meg nem (vagy a hyper-v driver resze lesz inkabb) nincs mirol beszelni (mivel a hyper-v driver ma rbenne van a Linux kernelben).

Amugy az MS eleg regota add hozza a Linux kernelhez ahogy en tudom. De lehet rosszul tudom.

Ha azt nezed egy csomo MS fostol mentes a Linux (de most a kernelrol beszelunk (elenyeszo szazalek) vagy a distro szintrol?). Viszont van sok minden ami jol hasznalhato es az MS fosta ide nekunk. :D

A linux nagy részét különféle nagy cégek rakták össze. Jött kód az IBM-től, anno még a Borlandtól, a Corel-től, de szerintem tán még az Oracle-től is. Anno még a 2000-es években olvastam valamikor, hogy akkor a linux kernel-be érkező patch-ek nagyon  nagy része (úgy 90+% ha jól emlékszem) jött céges domainről. És ezek a cégek pont úgy nem szívjóságból rakták bele a kódot a linuxba, hanem mert a linux az ő üzleti modelljüket támogatta. A MS pedig azért nem szerette a linuxot, mert az ő akkori üzleti modelljükkel ellentétes volt. Most viszont, ahogy egyre inkább a felhő az igazi üzlet, és ott ők is egyre jobban használják.

( attilam | 2020. 05. 21., cs – 11:14 )

Remélem a Wine projekt tud majd valamit profitálni belőle. ;)