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

  • Originally posted by mSparks View Post

    please refer to

    "A position statement on closed-source kernel modules"

    which quite clearly explains who disagrees with you.
    where are these closed source kernel modules you constantly keep going on about?

    Comment


    • Originally posted by Quackdoc View Post

      where are these closed source kernel modules you constantly keep going on about?
      modules or drivers

      d3d12.so

      For starters.
      Then the entire directx stack it relies on after that.

      Comment


      • Originally posted by mSparks View Post

        modules or drivers

        d3d12.so
        guess what isn't necessary for this to be used at all. completely optional

        Comment


        • Originally posted by Quackdoc View Post

          guess what isn't necessary for this to be used at all. completely optional
          Well I have asked like 10 times in the thread already what use the patch is and how they will test it without directx. What is this mythical alternative option?
          Last edited by mSparks; 15 January 2022, 07:05 AM.

          Comment


          • Originally posted by mSparks View Post

            Well I have asked like 10 times in the thread already what use the patch is without directx. Whats the answer?
            I don't know if you need glasses, or if there is shit up your nose, but it's already explained many times, that directx is the entire graphics api, and that d3d12.so was optional

            Originally posted by Quackdoc View Post

            I don't think you understand what directx IS. Direct X is the ENTIRE 3d acceleration api on windows, all vulkan calls, still go through the dxgkrnl, or through directx, same with with openGL, d3d12 and d3d11 etc. are the graphics api oriented to gaming.

            EDIT: so I guess then yes, all applications would be directx applications, in the same way that literally any gpu program you run on a windows PC is a directx application.
            Originally posted by Quackdoc View Post
            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.

            Comment


            • Originally posted by Quackdoc View Post

              I don't know if you need glasses, or if there is shit up your nose, but it's already explained many times, that directx is the entire graphics api, and that d3d12.so was optional


              libdxg is not a replacement for directx nor is it open source.

              Comment


              • Originally posted by mSparks View Post

                libdxg is not a replacement for directx nor is it open source.
                im going to hope for your sake you've just been trolling this entire time. I cannot believe someone has enough brainpower to type on a keyboard but comment something like this. but for the sake of everyone reading, yes it is open source.

                To make it easy for our partners to build compute drivers, which are usable in both Windows and WSL environment, we provide a library, that provides a stable interface to our compute device abstraction. This was originally part of the libdxcore closed source API, but have now spawn that off into it's own open source project (https://github.com/microsoft/libdxg).
                and before you say something unbelievably stupid again, because apparently you will here is another quote from the patch

                we now have a fully open source implementation of our virtualized compute stack inside of WSL.
                This means, that the kernel interface, is fully open source, without relying on closed source modules, and their is a full open source userspace too.

                Comment


                • Originally posted by Quackdoc View Post

                  im going to hope for your sake you've just been trolling this entire time. I cannot believe someone has enough brainpower to type on a keyboard but comment something like this. but for the sake of everyone reading, yes it is open source.



                  and before you say something unbelievably stupid again, because apparently you will here is another quote from the patch



                  This means, that the kernel interface, is fully open source, without relying on closed source modules, and their is a full open source userspace too.
                  From the article

                  "Microsoft was also originally criticized with DXGKRNL since it relied upon closed-source CUDA and DirectX user-space components for operation. "

                  It will also be rejected for relying on any directx component.

                  You can deflect from that basic point all you want, WITHOUT an option to be useful without directx its not getting mainlined.

                  What is this mythical alternative option?

                  Originally posted by mSparks View Post

                  The points are

                  1. DXGKRNL requires DirectX
                  2. DirectX is not GPLv2 compliant, requiring it makes DXGKRNL non GPLv2 compliant
                  3. non GPLv2 compliant patches are not suitable for mainlining in the kernel

                  Which point(s) do you disagree with?
                  So far you and quackdoc have spent all your time arguing and losing against points 2 and 3.
                  Point 1 was always the sticking point of why it has no chance of getting mainlined.

                  Now you tell me DirectX is optional.
                  Great What is this mythical alternative option?
                  Last edited by mSparks; 15 January 2022, 07:44 AM.

                  Comment


                  • Originally posted by mSparks View Post
                    It will also be rejected for relying on any directx component.
                    it no longer relies on upon closed-source CUDA and DirectX user-space

                    the issue was never that it was directx, it was that it needed closed source components to function, all components needed are either open sourced, or now optional. I don't know whats so hard to comprehend about that.

                    the necessary directx component libdxcore was open sourced. as was already stated, partially, but enough to function without libdxcore. the non opensource component is now optional.

                    Comment


                    • Originally posted by Quackdoc View Post

                      it no longer relies on upon closed-source CUDA and DirectX user-space

                      the issue was never that it was directx, it was that it needed closed source components to function, all components needed are either open sourced, or now optional. I don't know whats so hard to comprehend about that.

                      the necessary directx component libdxcore was open sourced. as was already stated, partially, but enough to function without libdxcore. the non opensource component is now optional.
                      As long as that newly open sourced userspace component does not rely on any closed source components then there wont be a problem. If it does it wont get mainlined for the same reasons it was rejected last time. They dont accept patches that rely on closed source modules, drivers and recently even applications.

                      Good job directx is already open source or all that work would have been for nothing. lol.

                      Comment

                      Working...
                      X