Microsoft Reworks The "DXGKRNL" Driver It Wants To Get Into The Linux Kernel

[mSparks]

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.

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?

[Quackdoc]

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.

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.

[mSparks]

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.

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 on their computer?

Else any patch will just be rejected as not useful/failed testing - again.

[Quackdoc]

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?

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

OpenCL, OpenVINO and OneAPI

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.

[mSparks]

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.

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?
(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)

[Quackdoc]

"Netgpu and the hazards of proprietary kernel modules"

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.

it can't even be built without the NVIDIA driver's files on disk

any module that imports symbols from a proprietary module

this doesn't even relate to the patches at hand, which does not require proprietary modules to function.

[mSparks]

the display landed in 5.14...

"Netgpu and the hazards of proprietary kernel modules"

"Kernel Developers Work To Block NVIDIA "GPL Condom" Effort Around New NetGPU Code"

[Quackdoc]

Probably included prior to it becoming mainline policy to not accept any more.

Just look at what happened with say NetGPU to see how they respond to such things now.

the display landed in 5.14...

[mSparks]

the same way hyper-v's drmfb doesn't require closed source stuff (it does) and the same way hyper-v's networking doesn't require closed source stuff (it does)

Probably included prior to it becoming mainline policy to not accept any more.

Just look at what happened with say NetGPU to see how they respond to such things now.

[Quackdoc]

It was, they think they can rework it.
Which brings us right back to my OP. How do they plan on making it useful without requiring DirectX? - because that is the only way they will get it mainlined.

the same way hyper-v's drmfb doesn't require closed source stuff (it does) and the same way hyper-v's networking doesn't require closed source stuff (it does)