This entire concept of having directx in WSL sounds like Embrace Extend Extinghish, all over the place. This means we will have some linux programs only running in WSL. This is fucked.
> libd3d12.so and libdxcore.so are closed source, pre-compiled user mode binaries that ship as part of Windows. These binaries are compatible with glibc based distros and are automatically mounted under /usr/lib/wsl/lib and made visible to the loader.
Mesa is a freedesktop project and this is not the freedesktop I was imaginating.
It's closer to the way vendors like Qualcomm shipped GPU drivers for ARM Linux until relatively recently, where they would ship a patched kernel with a DRM driver, and then a closed source userspace .so blob that you had to rely on, on top of that, which implemented the shader compiler, pipeline, etc. This is basically that. Except it's a virtual machine, so it's also kind of like how VMware Workstation does graphics acceleration.
The main difference here from the ARM world is that Microsoft seems to have invested dev work in upstream Mesa so that Mesa actually implements the nitty gritty parts of the spec on the Linux side, and then translates it all to underlying D3D12 host calls for you. This is conceptually similar to VirGL, which is basically the same thing but for OpenGL inside QEMU. If anything Microsoft seems to have taken a less arduous approach to this by going to upstream first to Mesa. The other thing here is that Microsoft is using a patched kernel that hasn't been merged upstream; but then again Asahi Linux is in the same boat, and they work upstream in Mesa now, too. And Mesa isn't just limited to Linux, of course, and can be used in userspace in theory a lot of places.
If you have some weird desire to use DirectX APIs on Linux, you can already do that in many ways with subprojects of Wine and Proton such as d3dvk. It's a well known API with a well known ABI so it's not like this is impossible. You can already run many Windows programs through Wine, so unless this hypothetical Windows/Linux monstrosity thing is going wildly out of its way to be WSL only through active hostility, it's not like there's some magical API that can't be emulated in most of these cases.
> If anything Microsoft seems to have taken a less arduous approach to this by going to upstream first to Mesa... If you have some weird desire to use DirectX APIs on Linux, you can already do that in many ways with subprojects of Wine and Proton such as d3dvk.
Interesting where Google's efforts to commodotize d3d12 with SwiftShader (as opposed to Mesa) and Angle fits in to this.
3. Cleanliness/simplicity (This is vague, but I have exactly the software I asked for and nothing else).
4. Configurability (I can adjust quirky in-the-middle software like my file manager, taskbar/clock, etc. No immutable one-size-fits-all UI/UX)
5. Repairability (Given time and patience, I can fix Linux problems. Fixing Windows is black magic, and I'm very often reminded, simultaneously, how much of an expert and how much of a novice I am on the CR/LF hand path.)
6. Auditability (Open source is more trustworthy, since source code can be freely audited by anyone at any time. Active free software projects accept security patches quickly and cleanly.)
---
Windows' design is diametrically opposed to all of these, and I can scarcely imagine a version that would allow a true tiling window manager (as opposed to the contemporary explorer.exe hacks).
Give me these features, and I will be truly impressed.
Do all that, then do the extinguish step, and you will really blow my mind.
Well of course you're inoculated from the embrace but a ton of people aren't. If enough of the Linux people around you are embraced by WSL, there might come unforeseen consequences.
Most of the casual windows users I've talked to have complained to me, unprovoked, about how bad windows is for them.
Microsoft has a long way to go, even for the average user, and they are still moving clearly in the opposite direction.
The casual Linux users I know feel the same, but more stubbornly.
Windows getting better is, for me, a fantasy, not a fear. At least then I would have fewer people begging me for the kinds of tech support needs that should have been factored out in 2008 (or much sooner), that Windows has instead kept alive into 2023.
Of course Linux offers tons of features people like me or you might like (I'm a KDE dev), but there is also a vast amount of Linux user who for example discovered Linux by installing a VM for an uni project or have to use a POSIX environment for a programming project and then decided to stick with Linux because they liked it. There is a serious risk that people won't be tempted to try the Linux desktop anymore and instead will just use WSL. This is bad as it means less potential new contributors and enforce even more the dominance of Windows on the desktop.
Depends on which stack you're picking on Windows side, just like there are two major APIs on iOS and Android, three on macOS,...
The last useful Gtk in comparison with what is there on Windows was version 3, they even killed their designer for version 4, and version 5 roadmap was recently announced at FOSDEM.
what do you mean? raw GPU compute from the host GPU has been available in WSL for a while now, and this is just a layer on top which allows access to the encoding and decoding hardware on the card.
They had to pick an API to expose, so they picked theirs.
I guess I don't see the big deal, here. Nothing MS does for WSL will change anything that exists outside of WSL.
There is no shortage of people who hate Microsoft on this site, or on the Internet in general, and I would be very surprised if any application of substance chose to both run on Linux and be Microsoft-only (WSL only). That seems so unlikely that it's almost not feasible for a logical human person to come to a decision like that. And if that happens, don't use that software, and protest their decision, just as you're doing here with WSL.
Linux is far bigger than Microsoft, no matter what anyone thinks. And the percentage of Linux users and developers who hate Microsoft is very high. I just do not see the situation you're describing where there are Linux apps which only work in WSL. This hasn't even extended what Linux can do, it's just another way to do it.
There is no reason to keep Windows installed on a new computer. Wipe everything, install Linux, any distro. WSL will always be worse than a native setup.
The only thing I see that Microsoft could do is use their weight with AMD and NVidia to somehow sabotage Linux hardware driver support for GPUs, artificially making WSL the superior solution, but that's a long shot; I'm not sure what hardware mfg would gain from that.
Not really anymore. Wine, Proton, VK3D, .. have improved so much that the native gaming experience on Linux is more than viable. The Steam Deck might be the best example of that.
I'm very happy that the last few years I didn't have to keep a horrid Windows install around, just to play a game every now and then.
I'm pretty excited for linux gaming, and it really does seem to work well for singleplayer games. But online games (with anticheat, Valorant for example) often times don't run at all.
This will never happen. Linux is way too big for this. The percentage of developers using Linux is so large that making your tool only work under WSL makes very little sense, especially when the native approach is usually easier/simpler.
Wine exists, so we already have an open source DirectX implementation for Linux. It's not currently exactly compatible with libd3d12.so, because wine provides a Windows PE .dll, not a Unix ELF .so. Though I think Winelib may already allow you to access the Windows APIs via en ELF toolchain.
> Mesa is a freedesktop project and this is not the freedesktop I was imaginating.
Taking OpenGL and converting to a closed source device driver interface doesn't seem that different, morally, from converting to a closed source graphics driver device API.
And they even have the balls to label the blog "DirectX Loves Linux", heart symbol included. What a god-forsaken aberration. The people writing for this blog must be incredibly oblivious or incredibly drowned in kool-aid. Like they know nothing of computing history and how Microsoft has always tried to make Windows the gaming platform at the expense of other graphics APIs and ecosystems.
> This entire concept of having directx in WSL sounds like Embrace Extend Extinghish, all over the place.
That's because it is. The Linux Desktop has been 'embraced' and 'extended' on Windows via WSL + NVIDIA GPU drivers all supported on it. Making Windows 11 the best Linux desktop distro and there is no need to 'Partition and Install Linux' when it is all running on Windows itself.
'Extinguish' in this case is all the other Linux Desktop distros that will wither away into obscurity since little to no-one would directly install a distro or go through the steps of dual booting other than the techies.
Microsoft's new strategy of targeting and selling to developers seems to be a great bet that is clearly working.
Windows is effectively dead outside of desktops. Nobody that isn't mired in 90s/00s processes (ex: the banking and energy sectors are minor players in the enterprise universe, but are still stuck in process hell in many cases); Microsoft's biggest customers on Azure are all Linux; using Azure for Window is almost unheard of (their biggest client on Windows is the Office 365 exchange cluster itself, a decidedly legacy application that would be nearly impossible to port or replace).
Microsoft is admitting that Linux won, and the only way to exist is to have Windows be able to transparently be Linux too, by running a captive Linux VM. Linux embraced and extinguished Windows, and did it so subtly that most people didn't even see it until it was too late. Microsoft's creation of WSL2 is their admission of this truth.
Side note: Half of the software developers and systems engineers that work at Microsoft are not qualified to work on Windows, Windows software, or even really know how to use Windows beyond the obvious metaphors that all modern desktops share. They use Linux desktops, and work on Linux software, on Linux systems. At Microsoft, home of Windows. Linux won.
This is Microsoft's new EEE strategy, except that the new "Extinguish" target isn't all Linux systems but rather just any non-WSL based Linux systems. Microsoft offers WSL based Linux on Azure and they want developers to write software that's locked into WSL based Linux.
Non-WSL Linux systems are the majority. They are in your pocket, in your car, your TV, in space, on Mars. Microsoft will never be a player here but is still invited to the bazaar if they wish to participate.
And yes, I agree with Microsoft on this: all apps that people care about their 3D performance should move to DX12 or Vulkan. Microsoft in-house works on supporting DX9/10/11 and OpenGL purely as a legacy API, and eventually, Windows won't allow drivers to implement them anymore, and it will be some shim. I'm not going to shame Microsoft for promoting DX12 over Vulkan; they're both largely the same API, driven entirely by AMD and Nvidia development teams to reflect the current state of hardware, not the whims of some bald CEO that threw chairs at people.
Could the shim be just DXVK-based? Sure. Could the shim be DX9/10/11 state trackers being added to Mesa, and then the Mesa-on-DX12-on-Windows method used? Also sure. Intel is already using DXVK as a legacy shim in their new Arc drivers, and its performing quite well. DXVK also outperforms Nvidia's DX9/10/11 emulation in some games. I could easily see a DXVK-based solution just ship with a future Windows.
> Non-WSL Linux systems are the majority. They are in your pocket, in your car, your TV, in space, on Mars. Microsoft will never be a player here but is still invited to the bazaar if they wish to participate.
I agree this isn't what they are targeting, at the moment based on the design this doesn't appear to be a play for the embedded Linux market, it's a play for controlling the server/desktop markets(at least the segments of those markets that would potentially use the WSL only Linux userspace API).
> And yes, I agree with Microsoft on this: all apps that people care about their 3D performance should move to DX12 or Vulkan. Microsoft in-house works on supporting DX9/10/11 and OpenGL purely as a legacy API, and eventually, Windows won't allow drivers to implement them anymore, and it will be some shim. I'm not going to shame Microsoft for promoting DX12 over Vulkan; they're both largely the same API, driven entirely by AMD and Nvidia development teams to reflect the current state of hardware, not the whims of some bald CEO that threw chairs at people.
The issue is that they are effectively bringing a WSL only userspace to Linux(https://devblogs.microsoft.com/directx/directx-heart-linux/) and are pushing for developers to target that WSL only userspace. Specifically they provide Linux native libraries like libd3d12.so and libdirectml.so which have a hard requirement on WSL.
> Could the shim be just DXVK-based? Sure. Could the shim be DX9/10/11 state trackers being added to Mesa, and then the Mesa-on-DX12-on-Windows method used? Also sure. Intel is already using DXVK as a legacy shim in their new Arc drivers, and its performing quite well. DXVK also outperforms Nvidia's DX9/10/11 emulation in some games. I could easily see a DXVK-based solution just ship with a future Windows.
The Mesa work seems to be effectively used for the "Embrace" part of the EEE strategy, it ensures that any existing Linux only software runs well under WSL, it's not really the main worry IMO.
The WSL only userspace(ie Linux applications targeting libd3d12.so and libdirectml.so) is the "Extend" part(extends the Linux userspace with WSL only userspace functionality).
Encouraging developers to drop support for non-WSL only API's/libraries on Linux is the "Extinguish" part.
So the main issue is that critical libraries like libd3d12.so and libdirectml.so have been designed to be WSL only. If this wasn't an EEE strategy I would expect that there would be some path to eventually use libd3d12.so and libdirectml.so without WSL, but that isn't possible and there appears to not be any plans to make it possible.
> This is the real and full D3D12 API, no imitations, pretender or reimplementation here… this is the real deal. libd3d12.so is compiled from the same source code as d3d12.dll on Windows but for a Linux target.
> libd3d12.so and libdxcore.so are closed source, pre-compiled user mode binaries that ship as part of Windows.
> D3D12 wouldn’t be able to operate without a GPU specific user mode driver (UMD) provided by our GPU manufacturer partners. The UMD is responsible for things like compiling shaders to hardware specific byte code and translating API rendering requests into actual GPU instructions in command buffers to be executed by the GPU. Working closely with our partners, they have recompiled their D3D12 UMD to a Linux target, enabling execution of these drivers in a WSL environment. This support is being integrated in upcoming WDDMv2.9 drivers such that GPU support in WSL is seamless to the end user. WDDMv2.9 drivers will carry a version of the DX12 UMD compiled for Linux.
No they don't, not if you're not using a Windows desktop in Azure. They have their own Linux distro for embedded stuff, extremely low power stuff, but that's very far from anything WSL2 related.
How would they even offer a WSL-based Linux on Azure without Windows?
Via a Windows WSL server on Azure, direct WSL based Linux VM's on Azure should be possible as well although it doesn't look to have been implemented yet:
yes, I know about Hyper-V and I know that WSL is virtualized, but a standalone Linux VM is just Linux. It isn't WSL. WSL isn't just a name, it's the "Windows Subsystem for Linux" which is worded weird, but it's an NT Kernel subsystem which provides Linux compatibility. WSL v1 used syscall translation from Linux to Windows, meaning it was not a VM, and WSL 2 uses a Hyper-V virtual machine (two, actually) along with some glue to pull it together into a nice feature for Windows.
If you remove Windows, it's just a Linux VM. Just Linux. Azure already offer this as do all other cloud providers.
> yes, I know about Hyper-V and I know that WSL is virtualized, but a standalone Linux VM is just Linux. It isn't WSL. WSL isn't just a name, it's the "Windows Subsystem for Linux" which is worded weird, but it's an NT Kernel subsystem which provides Linux compatibility. WSL v1 used syscall translation from Linux to Windows, meaning it was not a VM, and WSL 2 uses a Hyper-V virtual machine (two, actually) along with some glue to pull it together into a nice feature for Windows.
I'm probably not being that clear with the terminology, I'm referring to WSL2(WSL v1 is the legacy translation layer that isn't important here, I was always referring to WSL2).
> If you remove Windows, it's just a Linux VM. Just Linux. Azure already offer this as do all other cloud providers.
Different VM hypervisors have the ability to expose additional features to guest operating systems, in this case a Hyper-V/WSL2 host like Azure can provide critical functionality to the guest Linux VM that other hypervisors are not able to provide.
If you remove the Hyper-V/WSL2 host you lose the ability for the Linux guest userspace applications to make use of libraries like libd3d12.so and libdirectml.so.
The fundamental issue is that the WSL2 Linux userspace(which is basically a port of a number of Windows userspace components to Linux) has closed source libraries like libd3d12.so and libdirectml.so which have a hard requirement on dxgkrnl and a compatible Hyper-V hypervisor/Windows based VM host. If Linux applications are developed targeting these closed source libraries they will not function on normal non-WSL2/Hyper-V VM's.
> Over the last few Windows releases, we have been busy developing client GPU virtualization technology. This technology is integrated into WDDM (Windows Display Driver Model) and all WDDMv2.5 or later drivers have native support for GPU virtualization. This technology is referred to as WDDM GPU Paravirtualization, or GPU-PV for short. GPU-PV is now a foundational part of Windows and is used in scenarios like Windows Defender Application Guard, the Windows Sandbox or the Hololens 2 emulator. Today this technology is limited to Windows guests, i.e. Windows running inside of a VM or container.
> To bring support for GPU acceleration to WSL 2, WDDMv2.9 will expand the reach of GPU-PV to Linux guests. This is achieved through a new Linux kernel driver that leverages the GPU-PV protocol to expose a GPU to user mode Linux. The projected abstraction of the GPU follows closely the WDDM GPU abstraction model, allowing API and drivers built against that abstraction to be easily ported for use in a Linux environment.
> Projecting a WDDM compatible abstraction for the GPU inside of Linux allowed us to recompile and bring our premiere graphics API to Linux when running in WSL.
> This is the real and full D3D12 API, no imitations, pretender or reimplementation here… this is the real deal. libd3d12.so is compiled from the same source code as d3d12.dll on Windows but for a Linux target.
To clarify it's the functionality which is provided using the dxgkrnl(which has both Linux kernel and WSL2/Hyper-V hypervisor components that are required to function) passthrough that makes the "Extend" functionality not work in a normal Linux VM with say a KVM based hypervisor.
The issue is that the WSL2 Linux userspace(which is basically a port of a number of windows userspace components to WSL2 Linux) has closed source libraries like libd3d12.so and libdirectml.so which have a hard requirement on dxgkrnl and a Hyper-V hypervisor/Windows based VM host. If Linux applications are developed targeting these closed source libraries they will not function on normal non-WSL2/Hyper-V VM's.
> Over the last few Windows releases, we have been busy developing client GPU virtualization technology. This technology is integrated into WDDM (Windows Display Driver Model) and all WDDMv2.5 or later drivers have native support for GPU virtualization. This technology is referred to as WDDM GPU Paravirtualization, or GPU-PV for short. GPU-PV is now a foundational part of Windows and is used in scenarios like Windows Defender Application Guard, the Windows Sandbox or the Hololens 2 emulator. Today this technology is limited to Windows guests, i.e. Windows running inside of a VM or container.
> To bring support for GPU acceleration to WSL 2, WDDMv2.9 will expand the reach of GPU-PV to Linux guests. This is achieved through a new Linux kernel driver that leverages the GPU-PV protocol to expose a GPU to user mode Linux. The projected abstraction of the GPU follows closely the WDDM GPU abstraction model, allowing API and drivers built against that abstraction to be easily ported for use in a Linux environment.
> Projecting a WDDM compatible abstraction for the GPU inside of Linux allowed us to recompile and bring our premiere graphics API to Linux when running in WSL.
> This is the real and full D3D12 API, no imitations, pretender or reimplementation here… this is the real deal. libd3d12.so is compiled from the same source code as d3d12.dll on Windows but for a Linux target.
Alive in the marketshare sense but they don't have as much going on as they used to.
People who use Linux use it because of what it is, a fantastic piece of software that puts trillion dollar corpo to shame.
Most Windows users have never tried any alternatives. The 'tech normies' would switch to Mac in a heartbeat if they could afford them, they don't really care about what they use as long as it has shiny buttons.
I think it is reasonable to assume they mean “desktop apps”. Windows is a platform to run desktop apps and that is the area where it leads. Windows laptops also run desktop apps. Laptop apps is not a category.
The other big buckets are mobile and server but “mobile” as an application category does not refer to laptops.
I mean, people call those desktops a lot of the time in broad conversations about architectures. Did you have a point that affects their actual argument?
Well, mostly that there are not that many desktops being sold or used these days, but still lots and lots and lots of laptops. So if Windows is still king of the laptops, its very, very far from being "dead".
I'm not sure I follow what level the EEE plays on. I think if anything, Windows has a serious issue of long-term viability because of the dominance of the browser in modern desktop applications. The browser has succeeded in opening the walled gardens of OS makers, and there is really no reason for most apps to be running on a specific OS, or even for most apps to have an installation. (I know, HN is probably averse to this, but for most users this is really the truth).
Your OS is basically a gateway into the internet, the days of win32 are gone, and now Windows leans into that bundling Webview2 into win11, so that your electron-like apps won't have to be so bloated, and so slow.
I think this move is in the same direction: Windows admitting defeat in the developer space and trying to become the gateway to linux to avoid being obsolete. WSL is kind of the inverse of EEE from the perspective of Windows.
So what about directX specifically? Maybe I'm missing something but I doubt there will be a future where Linux loses much from this:
If you start building an app now, would you build it on Linux but then link to DX12 WITHOUT also having vulkan support for native linux? Not really, you would just build it on windows completely.
If you have a Linux app now, and you include DX12 support, would you transition to windows? Not really, your entire app depends on the linux standard libs, and you can now have windows support through wsl anyway.
If you're doing some scientific computing or ML would you now do it on windows against DX12 from Linux? Ultimately you won't deploy on WSL in the cloud, I hope. Why make your dev/prod so different?
I think what Windows could be doing here is moving to become the best linux distro in 20 years. I think ultimately thats a good thing. Imagine Windows is just Linux with a proprietary desktop shell around it, and everyone uses it for their daily use. That just means that Linux adoption is much greater, and porting apps to linux from windows is already 90% done because they share a backend. I think Microsoft may realise the best way to make money is to not have to maintain an entire OS in the first place.
Basically that would mean OSes become like the car market: no matter what you buy, it looks a bit different, but you get kind of the same thing under the hood. And that thing would be linux.
It may mean that Desktop Linux will never make it, but I'm not so sure. Those 2.5% marketshare are not people who are easily sold to Windows, and will see it as an inferior Linux anyway.
Nope, and it's pretty clear this is being designed in a way to ultimately prevent users from running applications on non-WSL Linux systems, Microsoft isn't even hiding that at all as they even list it as a specific goal of the directx related changes being pushed to mesa:
https://devblogs.microsoft.com/directx/in-the-works-opencl-a...
> Make it easier for developers to port their apps to D3D12. For developers looking to move from older OpenCL and OpenGL API versions to D3D12,
It is the exact opposite. Microsoft has always tried to kill gaming on non-Microsoft platforms. Labelling the blog "DirectX Loves Linux" is the ultimate brainwash attempt on those who are too ignorant of computer history.
> libd3d12.so and libdxcore.so are closed source, pre-compiled user mode binaries that ship as part of Windows. These binaries are compatible with glibc based distros and are automatically mounted under /usr/lib/wsl/lib and made visible to the loader.
Mesa is a freedesktop project and this is not the freedesktop I was imaginating.