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

  • mSparks
    replied
    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.

    Leave a comment:


  • Quackdoc
    replied
    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.

    Leave a comment:


  • mSparks
    replied
    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.

    Leave a comment:


  • Quackdoc
    replied
    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.

    Leave a comment:


  • mSparks
    replied
    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.

    Leave a comment:


  • Quackdoc
    replied
    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

    Leave a comment:


  • mSparks
    replied
    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.

    Leave a comment:


  • Quackdoc
    replied
    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?

    Leave a comment:


  • mSparks
    replied
    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.

    Leave a comment:


  • mdedetrich
    replied
    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.

    Leave a comment:

Working...
X