Originally posted by mSparks
View Post
Announcement
Collapse
No announcement yet.
Microsoft Reworks The "DXGKRNL" Driver It Wants To Get Into The Linux Kernel
Collapse
X
-
-
Originally posted by mSparks View Post
"Netgpu and the hazards of proprietary kernel modules"
unlike the netgpu stuff, as stated the very article you are talking about.
it can't even be built without the NVIDIA driver's files on diskany module that imports symbols from a proprietary module
Comment
-
Originally posted by Quackdoc View Post
it doesn't require any proprietary anything on the linux side of things to function
unlike the netgpu stuff, as stated the very article you are talking about.
this doesn't even relate to the patches at hand, which does not require proprietary modules to function.
what benefit does it bring to the kernel without directx installed?
(because those testing it wont install directx on their machines btw, because they only test in a gplv2 environment, which is how they found the netgpu patch wouldnt even compile)Last edited by mSparks; 14 January 2022, 10:56 PM.
Comment
-
Originally posted by mSparks View Post
If its true it does something useful without directx they do have a chance.
what benefit does it bring to the kernel without directx installed?OpenCL, OpenVINO and OneAPI
if you are talking about using the code without Hyper-V/windows host the linux kernel dev's have never really cared about stuff like that in the first place. infact in the kernel tree, we have drivers/hv, which is hyper-v specific drivers.
- Likes 1
Comment
-
Originally posted by Quackdoc View Post
do you mean installed inside of linux? everything is opensource besides the d3d12.so, so I'll assume you mean, without d3d12.so. in which case as was already stated, confirmed support for intel as well as them open sourcing https://github.com/microsoft/libdxg which could potentially open up for AMD, specifc APIs, as well as other generic API's like vulkan.
if you are talking about using the code without Hyper-V/windows host the linux kernel dev's have never really cared about stuff like that in the first place. infact in the kernel tree, we have drivers/hv, which is hyper-v specific drivers.
They will not approve for mainline anything that they cannot test as beneficial in a pure gplv2 environment.
What will they test and approve without directx installed on their computer?
Else any patch will just be rejected as not useful/failed testing - again.Last edited by mSparks; 14 January 2022, 11:05 PM.
Comment
-
Originally posted by mSparks View Post
I mean those testing and approving it.
They will not approve for mainline anything that they cannot test as beneficial in a pure gplv2 environment.
What will they test and approve without directx installed?
Else any patch will just be rejected as not useful/failed testing.
take a look at this https://github.com/torvalds/linux/co...ter/drivers/hv everything here? needs to be tested on hyper-v. which means a non pure gplv2 env. I'm seeing patches merged as of this year.
- Likes 1
Comment
-
Originally posted by Quackdoc View Post
again, intel opencl, openvino, and openapi, will all work within linux, they do not care about a pure GPLv2 env. if it's running on a windows host, that is fine.
take a look at this https://github.com/torvalds/linux/co...ter/drivers/hv everything here? needs to be tested on hyper-v. which means a non pure gplv2 env. I'm seeing patches merged as of this year.
All those things you listed already work fine in linux, how does the dxgkrnl driver improve them?
and yes, by the sounds of it the patch needs to add value without d3d12.so.
What?
Comment
-
Originally posted by mSparks View Post
If they didnt care they wouldnt have threatened to pull all the previous netgpu patches because of one patch that needed nvidia headers installed.
All those things you listed already work fine in linux, how does the dxgkrnl driver improve them?
and yes, by the sounds of it the patch needs to add value without d3d12.so.
What?
Because its not the same case. Netgpu patches were blocked because the entire functionality being talked about was in Kernel land which is covered by GPL 2. In this case DirectX is being run outside of Linux (i.e. in a VM via Hyper-V) which is none of Linux's concern.
It was impossible to even build that functionality properly without NVidia drivers.
Again if this was an actual issue someone would have stated it in the mailing list earier and they didn't (unlike with netgpu where the concerns were immediately raised).
And if you still don't agree then you can read the actual comments in the mailing list for this patchset https://lore.kernel.org/lkml/cover.1...microsoft.com/ . As you can see, all of the replies from kernel maintainers are technical in nature or some minor detail about process (i.e. splitting it up into further commits to make reviewing easier). Unlike netgpu there isn't a single maintainer complaining about the core premise of the patchset in regards to GPL 2.
If you still have issues with this then feel free to post them to the mailing list and not here.Last edited by mdedetrich; 15 January 2022, 02:26 AM.
- Likes 2
Comment
-
Originally posted by mdedetrich View Post
https://www.phoronix.com/scan.php?pa...king-NV-NetGPU
Because its not the same case. Netgpu patches were blocked because the entire functionality being talked about was in Kernel land which is covered by GPL 2. In this case DirectX is being run outside of Linux (i.e. in a VM via Hyper-V) which is none of Linux's concern.
It was impossible to even build that functionality properly without NVidia drivers.
Again if this was an actual issue someone would have stated it in the mailing list earier and they didn't (unlike with netgpu where the concerns were immediately raised).
And if you still don't agree then you can read the actual comments in the mailing list for this patchset https://lore.kernel.org/lkml/cover.1...microsoft.com/ . As you can see, all of the replies from kernel maintainers are technical in nature or some minor detail about process (i.e. splitting it up into further commits to make reviewing easier). Unlike netgpu there isn't a single maintainer complaining about the core premise of the patchset in regards to GPL 2.
If you still have issues with this then feel free to post them to the mailing list and not here.
"A position statement on closed-source kernel modules"
which quite clearly explains who disagrees with you.
Comment
Comment