Last week, the Microsoft developers announced several significant enhancements to the subsystem WSL (Windows Subsystem for Linux), which enables Linux applications to run on Windows. As Starting with the Windows 10 May Update, the first installation of the Linux environment it will use the WSL2 layer by default.
The WSL2 environment runs on a disk image (HDV) separate with ext4 filesystem and the virtual network adapter. The Linux kernel in WSL2 It will not be included in the Windows installation image, but Windows will dynamically load it and it will keep it in the current form, similar to how graphics drivers are installed and updated. To install and update the kernel, the standard Windows Update mechanism will be used.
The proposed nucleus for WSL2 is based on the Linux 4.19 kernel release, running in a Windows environment using a virtual machine that is already in use in Azure.
WSL2-specific patches used in the kernel include optimizations to reduce kernel startup time, reduce memory consumption, return Windows to memory freed by Linux processes, and leave the minimum set of required drivers and subsystems in the kernel. .
It is now possible to run graphical applications in WSL
In addition to the aforementioned, another of the novelties that stands out is the Initial support for Linux applications with a "WSU GPU" graphical interface.
The support sand implements by virtualizing GPU access and providing drivers through which the regular graphical subsystems of Linux distributions can work, including those based on Wayland. Linux and Windows graphical applications can run side by side on the Windows desktop.
An open dxgkrnl driver has been prepared for the Linux kernel, providing a / dev / dxg device with services that echo the Windows display driver model (WDDM) D3DKMT of the Windows kernel. The controller establishes a connection to the physical GPU using the VM bus. Linux applications have the same level of GPU access as native Windows applications without sharing resources between Windows and Linux.
In addition, the librariana libd3d12.so is provided for Linux, that provides the Direct3D 12 full graphical API.
The libd3d12.so library is built from the same code as the native Windows implementation of Direct3D 12 and it is completely similar in functionality to the d3d12.dll library.
I also know provides a simplified version of the DXGI API (DirectX Graphics Infrastructure) in the form of the DxCore library (libdxcore.so). The libd3d12.so and libdxcore.so libraries are proprietary and delivered only in binary builds (mounted on WSL as / usr / lib / wsl / lib), compatible with Ubuntu, Debian, Fedora, Centos, SUSE, and other Glibc-based distributions .
Support for OpenGL in Mesa is provided through a layer which translates the DirectX 12 API calls. The method to implement the Vulkan API is still in the planning stage.
In the first stage, in WSL environments, CUDA and DirectML will be supported, working on the D3D12 API (for example, in a Linux environment, you can run TensorFlow with a backend for DirectML). OpenCL support is possible through a layer that performs call mapping in the DirectX 12 API.
Microsoft is developing its composite manager using the Wayland protocol and based on the Weston code base. The composite manager uses RDP-RAIL (Locally Integrated RDP Remote Application) to organize the output of the Linux application interface to the main Windows desktop. RDP-RAIL differs from the RDP backend previously available from Weston in that the composite manager does not render the desktop itself, but instead redirects individual surfaces (wl_surface) through the RDP RAIL channel to display on the main Windows desktop.
In addition, a WSL installation with the simple wsl.exe –install command will soon be supported.
Finally, if you want to know more about it, you can consult the details in the following link.