Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #91
    Originally posted by mSparks View Post
    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...

    Comment


    • #92
      Originally posted by Quackdoc View Post

      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"
      Last edited by mSparks; 14 January 2022, 10:39 PM.

      Comment


      • #93
        Originally posted by mSparks View Post

        "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.

        Comment


        • #94
          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.
          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)
          Last edited by mSparks; 14 January 2022, 10:56 PM.

          Comment


          • #95
            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?
            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.

            Comment


            • #96
              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.
              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.
              Last edited by mSparks; 14 January 2022, 11:05 PM.

              Comment


              • #97
                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.
                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.

                Comment


                • #98
                  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.
                  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?

                  Comment


                  • #99
                    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?
                    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.
                    Last edited by mdedetrich; 15 January 2022, 02:26 AM.

                    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.
                      please refer to

                      "A position statement on closed-source kernel modules"

                      which quite clearly explains who disagrees with you.

                      Comment

                      Working...
                      X