Announcement

Collapse
No announcement yet.

Mainlining The Microsoft DirectX Kernel Driver For Linux Will Be An Uphill Battle

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

  • Mainlining The Microsoft DirectX Kernel Driver For Linux Will Be An Uphill Battle

    Phoronix: Mainlining The Microsoft DirectX Kernel Driver For Linux Will Be An Uphill Battle

    On Tuesday was the big announcement of Microsoft bringing Direct3D 12 to Linux/WSL2 in the context of allowing GUI applications and GPU compute within Windows Subsystem for Linux. This also means OpenCL/OpenGL/Vulkan support by ultimately converting it into D3D12 consumption by the host Windows system. While Microsoft was quick to post patches for their "dxgkrnl" kernel driver for this Direct3D implementation, it's already facing resistance and will be an uphill battle for it to be mainlined...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Good pushback against this garbage. Show MS to the door, meaning let them support Vulkan and not push around DX lock-in.

    Comment


    • #3
      WSL2 offers a path for developers to completely ignore Win32, .NET Framework, UWP APIs and just develop Linux apps natively and have them magically work on Windows and be cross-platform. I hope developers start adopting this and just ignoring the mess of APIs that Microsoft is trying to push--their API flavor of the month sort of speak. Also DIrectX 12 is pointless for Linux unless it can run bare metal like VKD3D does.

      As for Linux users themselves, why would we want to contaminate our bare metal systems with Windows when we already have a reverse WSL2 / LSW 2 option? :P

      Last edited by Xaero_Vincent; 20 May 2020, 12:57 AM.

      Comment


      • #4
        Originally posted by shmerl View Post
        Good pushback against this garbage. Show MS to the door, meaning let them support Vulkan and not push around DX lock-in.
        There are already applications out there with DX12. They can benefit from ms work on Linux.
        Vulkan is for future applications

        Comment


        • #5
          Originally posted by Xaero_Vincent View Post
          WSL2 offers a path for developers to completely ignore Win32, .NET Framework, UWP APIs and just develop Linux apps natively and have them magically work on Windows and be cross-platform. I hope developers start adopting this and just ignoring the mess of APIs that Microsoft is trying to push--their API flavor of the month sort of speak. Also DIrectX 12 is pointless for Linux unless it can run bare metal like VKD3D does.

          As for Linux users themselves, why would we want to contaminate our bare metal systems with Windows when we already have a reverse WSL2 / LSW 2 option? :P

          Where's that screenshot from? Is it a real system or just a mockup? Looks interesting.

          Comment


          • #6
            Originally posted by QwertyChouskie View Post

            Where's that screenshot from? Is it a real system or just a mockup? Looks interesting.
            It's a screenshot of my system made just minutes ago and I've posted similar ones before. Arch Linux bare metal and Windows 10 headless VM with integration scripts to make apps appear on the GNOME desktop. This is just to point out that Linux bare-metal users can have an equally seamless hybrid configuration like WSL 2, so that Microsoft doesn't get to steal all the thunder.

            In reality this isn't all that useful for me and mainly a novelty (so I only use it sometimes for specific apps broke in Wine) but I suppose it would be a decent solution for someone who needed to use Microsoft Office 2019 or Quickbooks that run poorly in Wine but prefers Linux.
            Last edited by Xaero_Vincent; 20 May 2020, 01:19 AM.

            Comment


            • #7
              This uphill battle reminds me the first patches of AMD DAL, it took what, 18 months until it was accepted?
              But in AMD's case, there were a couple of upstream code that depends/uses thoses patches.

              About Microsoft, if they don't open the userspace driver, they should keep it out of tree as a kernel module, Nvidia does this AFAIK

              Comment


              • #8
                Originally posted by Xaero_Vincent View Post

                It's a screenshot of my system made just minutes ago and I've posted similar ones before. Arch Linux bare metal and Windows 10 headless VM with integration scripts to make apps appear on the GNOME desktop. This is just to point out that Linux bare-metal users can have an equally seamless hybrid configuration like WSL 2, so that Microsoft doesn't get to steal all the thunder.

                In reality this isn't all that useful for me and mainly a novelty (so I only use it sometimes for specific apps broke in Wine) but I suppose it would be a decent solution for someone who needed to use Microsoft Office 2019 or Quickbooks that run poorly in Wine but prefers Linux.
                Headless VM - VBox, QEmu/KVM?
                Scripts - OSS or proprietary? Is it VNC or true X forwarding?

                Comment


                • #9
                  Originally posted by bemerk View Post

                  There are already applications out there with DX12. They can benefit from ms work on Linux.
                  Vulkan is for future applications
                  Those applications can use vkd3d. No need to pollute the kernel with this stuff.

                  Comment


                  • #10
                    We have consider the possibility of bringing DX to Linux with no Windows cord attached. I'm not ready to discuss this at this time 😊... but in the hypothetical that we were do this, DX would be running on top of DRI/DRM on native Linux. We likely would be contributing some changes to DRM to address area of divergence and get better mapping for our user mode driver, but we wouldn't try to shoehorn /dev/dxg into the picture. In that hypothetical world, we would essentially have DX target DRM on native Linux and DX continue to target DXG in WSL to share the GPU with the host.
                    This quote from that thread is very interesting.

                    Comment

                    Working...
                    X