Microsoft Posts Updated "DXGKRNL" Linux Kernel Driver For WSL/WSA

[middy]

i don't know why microsoft refuses to open source their directX api and help port it to linux. its not like they really make that much money off it. if they truly <3 linux like they claim, that be a big "see, we really do <3 linux." so far all their "<3" linux has been helping microsoft by making linux run better on windows and maybe that cascadia font. none of it has really been about "helping" linux. in comparison valve has done more to <3 linux than microsoft.

i wouldn't care about microsoft wanting to make linux run on windows if microsoft just gave more equal love to linux. help improve running windows things on linux at the same time. contribute to wine. open up some of their api's as open standards, etc. encourage and help make gaming more portable. especially with microsoft buying up game studios for a few billion each.

[Quackdoc]

Why does this thing has to be in the kernel repository?

The way I see it, it is a solution used on a specific Microsoft product and maintained by Microsoft people.

because it's a kernel interface. kernel interfaces should be in the kernel. should we also remove the vmware bits from the kernel?

basically, if DXGKRNL get mainlined, the easiest way to have a fully accelerated 3D linux system will be to run WSL, right?

this won't directly benefit wsl2 users other than them not needing to rely on custom kernels. they already have all of these bits, the biggest beneficiary here besides niche people in WSL2, is hyper-v with gpu-pv

i don't know why microsoft refuses to open source their directX api and help port it to linux. its not like they really make that much money off it. if they truly <3 linux like they claim, that be a big "see, we really do <3 linux." so far all their "<3" linux has been helping microsoft by making linux run better on windows and maybe that cascadia font. none of it has really been about "helping" linux. valve has done more to <3 linux than microsoft.

their DX API is a lot more than d3d, but for a second let's talk about just D3D. not only is it beneficial for them to keep it closed source on the desktop world, for a couple reasons, (they do want their pseudo tech utopia) but it is also really good for them on the console world, as it in part helps a lot to fight against things like emulation and whatnot.

[middy]

because it's a kernel interface. kernel interfaces should be in the kernel. should we also remove the vmware bits from the kernel?



this won't directly benefit wsl2 users other than them not needing to rely on custom kernels. they already have all of these bits, the biggest beneficiary here besides niche people in WSL2, is hyper-v with gpu-pv



their DX API is a lot more than d3d, but for a second let's talk about just D3D. not only is it beneficial for them to keep it closed source on the desktop world, for a couple reasons, (they do want their pseudo tech utopia) but it is also really good for them on the console world, as it in part helps a lot to fight against things like emulation and whatnot.

alright, then it goes back to my point, their whole "microsoft <3 linux" is just, well a lie. everything they have done is to make linux run better on windows and nothing in return in helping windows run well on linux. its a one sided benefit and it does nothing in the long run to benefit linux if we are going to go down the path of self interest.

[Quackdoc]

alright, then it goes back to my point, their whole "microsoft <3 linux" is just, well a lie. everything they have done is to make linux run better on windows and nothing in return in helping windows run well on linux. its a one sided benefit and it does nothing in the long run to benefit linux if we are going to go down the path of self interest.

well considering that the devs who are working on d3d12 backend have helped mr. blumenkrantz, and contributed to the OGL state tracker and tests, the idea that they have "a one sided benefit" is blatantly false. this helps a lot with running linux in a VM on hyper-v servers. unless you are some purist who thinks linux should only be allowed to work on barebones software, I do not see how running linux in a vm, is not beneficial to linux...

[CochainComplex]

i don't know why microsoft refuses to open source their directX api and help port it to linux. its not like they really make that much money off it. if they truly <3 linux like they claim, that be a big "see, we really do <3 linux." so far all their "<3" linux has been helping microsoft by making linux run better on windows and maybe that cascadia font. none of it has really been about "helping" linux. in comparison valve has done more to <3 linux than microsoft.

i wouldn't care about microsoft wanting to make linux run on windows if microsoft just gave more equal love to linux. help improve running windows things on linux at the same time. contribute to wine. open up some of their api's as open standards, etc. encourage and help make gaming more portable. especially with microsoft buying up game studios for a few billion each.

Basically: The Love Microsoft gives to Linux is the same Love a Pimp gives to his Prostitutes.

[pkese]

So 2022 is going to be "The year of Linux on Desktop"

[amxfonseca]

i don't know why microsoft refuses to open source their directX api and help port it to linux. its not like they really make that much money off it. if they truly &lt;3 linux like they claim, that be a big "see, we really do &lt;3 linux." so far all their "&lt;3" linux has been helping microsoft by making linux run better on windows and maybe that cascadia font. none of it has really been about "helping" linux. in comparison valve has done more to &lt;3 linux than microsoft.

But isn’t making Linux run good on their platform a good thing now? Wouldn’t it be nice if other vendors like nVidia, Asus, MSI would also put some effort to make Linux run better on their platforms? Instead of just not support it at all?

I am now confused. Since when improving Linux support is a bad thing? It seems that the idea of making Linux running well on a platform can now be either good or bad, based on some arbitrary points.

No company will contribute to Linux if there’s no benefit to them. AMD and many other do it so they can sell you hardware. Microsoft because it wants to attract developers and sell cloud services. It would not be smart for them to provide a Direct3D driver for Linux that would completely bypass their platform. It would be the equivalent of sharing the credentials of their bank account with Richard Stallman.

In the end what matters is that code is shared with the community and someone will also benefit.

[mdedetrich]

This could be said about almost all Kernel drivers out there...
In the same sense you could say, why GPU drivers are embedded in the kernel, they're used on specific products, and maintained by their respective vendors.

Well this is a technical argument as to whether Linux should be a monolithic kernel. Almost every other mainstream kernel is a hybrid kernel, i.e. they have a stable driver ABI which lets you treat drivers as modules. In Linux you only have DLKM but that breaks as soon as internal kernel headers break (which is very often).

For better or for worse, kernel devs actively refuse to move away from a monolithic kernel.

[Spacefish]

If it relies on properitary userspace libraries anyway, why not just use shared memory between the hypervisor and the process in the linux VM using the library to implement this? Is there really a reason to have it in the kernel?

[amxfonseca]

Well this is a technical argument as to whether Linux should be a monolithic kernel. Almost every other mainstream kernel is a hybrid kernel, i.e. they have a stable driver ABI which lets you treat drivers as modules. In Linux you only have DLKM but that breaks as soon as internal kernel headers break (which is very often).

For better or for worse, kernel devs actively refuse to move away from a monolithic kernel.

You also have DKMS to handle kernel upgrades, but then you need to install GCC and all the other build tools.

I am currently dealing with that issue. I’ve prototyped a small soundcard that attaches to a raspberry Pi Zero W. The idea is to transform an existing speaker into a smart-speaker.

I had to write a driver for it. It’s not that hard because there’s a lot already done in ALSA. So mostly I’ve added logic to control volume and mute state. Again, this just a personal project.

The issue is now to use the driver. I cannot upstream it because nobody will accept a driver for a product that only exists inside my house. And no distro would include it.

So I need to build an out of tree driver, but that brings a whole set of challenges. I can opt to build the driver on an external machine, but that will not allow me to upgrade the kernel on the Pi without first rebuilding the driver for the new kernel version. Which is a pain with Arch Linux.

DKMS seems interesting solution, but that will force me to install all the build tools on the Pi. It will then rebuild the driver on such underpowered device that is not made to run a compiler.

I never really mind the fact the all the drivers are on this single tree. I find it actually nice because you can easily find the source of any driver.

But now I finally experienced the situation where I need to build my own driver and there’s no easy way to keep it running on my device.