Announcement

Collapse
No announcement yet.

Microsoft Announces Direct3D 12 For Linux / WSL2

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

  • #81
    Originally posted by airlied View Post

    you win the correct conclusion cookie, as opposed to OMG DX12 on my desktop nuts.
    Your summary on the mailing list seemed most apt - its a pipe between two closed binaries and there is very little value add for upstream. Thank you

    Comment


    • #82
      Microoft can go Vulkan or gtfo .... No Embrace Extend Extinguish

      Comment


      • #83
        Originally posted by wagaf View Post
        However I guess it's a blessing for Wine/Linux gaming.
        Originally posted by L_A_G View Post
        Who in their right mind would write a DX12 front end for a Linux application, causing it to be stuck in WSL, or move an application with a DX12 front end onto Linux without re-writing that front end and cursing it to the same fate?

        Then again this is probably just there to make it easier to port Linux applications onto Windows as more of a step-by-step process rather than all in one big go. Alternatively it's also going to make it easier to port Windows applications with DX12 front ends onto Linux as a more step-by-step process.
        Originally posted by bezirg View Post
        So what is there to benefit for us the (native) Linux users? Can we use this library to develop native-linux d3d apps? Or is this only going to work for wsl2-linux-in-vm users ?
        It's just for use with WSL, you need a Windows host(with Hyper-V enabled) with WDDM graphics drivers. It's main purpose afaik is to bridge other graphic APIs on top of it that use DX12 on the host. Not really for developing software on Linux that uses DX12 directly.

        I don't see how it'd be beneficial to Wine/Linux gaming, since you'd be running Windows as the host OS anyway, there's little point to run games via WSL, but perhaps it might be useful to wine or similar devs.

        It also appears to be for better supporting CUDA projects that are better supported via Linux then Windows or macOS, often the case with Docker containers and machine learning iirc, nvidia has docker containers that can access the host GPU for CUDA accel offloading, but I believe it's only decent on Linux, there were limitations or other problems(at least for quite some time, haven't kept up to date) attempting to do such on Windows and even macOS. You can do the development locally on the OS without containers, but that can be painful to setup depending on the project, especially when you want to use third-party projects or are starting out, containers make that a much nicer experience.

        That should also allow for more adoption of Windows instances in Azure over Linux presumably. They offer linux instances with Azure, but I assume they survey users for why they choose linux over windows instances on the Azure service and seek to minimize those reasons as much as possible.

        Originally posted by Terrablit View Post
        I'm more interested on whether this could be used for virtualization purposes, like if we could use this as a target for stuff like Virgil to get free D3D support in VMs.

        Probably a lot of thankless reversing. As long as we can expose Vulkan functionality to VM guests, the rest will be relatively simple.
        Not particularly useful if it's just for running on Windows hosts?

        The lib exposes the API on linux, but is otherwise not likely offering anything else of benefit that the dll wouldn't on Windows? I thought most of the work was more to do with the calls to graphic drivers / translation, but this would just be sort of like virgl wouldn't it? Just forwarding DX12 API calls to the Windows GPU drivers DX12 API to handle.

        There is an effort/plan to have a vulkan equivalent of virgl in future afaik, then if you need DX#, can probably use the existing efforts to map that to vulkan?

        Originally posted by Scellow View Post
        people move to linux because:

        - win10 is giant slow and bloated piece of crap
        - win10 is a spyware
        - NTFS is slow
        NTFS is slow? Pretty sure it was in recent filesystem benchmarks and did pretty well? It has a fair amount of features of it's own. Doesn't seem all that bad of a filesystem (if you're on windows). It's also one of the few you can use with linux I think that doesn't enforce UID/GID ownership, which isn't something I like enforced on a filesystem for portable media that I want to use across systems or exchange with others.

        Linux has some really nice filesystems that I'd rather use for such, but the ownership thing causes frustration, even on the same system when dealing with docker/VMs that don't share the same UID/GID (in docker containers you often use third-party ones and don't really want to modify each time, VMs if using a certain fs bridge can work around it and no longer as bad as it once was with KVM via virtio-fs afaik?).

        I wouldn't mind using Win10 sometimes, it does seem to be getting to a point that it may provide an acceptable or even better experience(for running certain software at least). Although it's definitely slow still. Ran pretty poorly on a 2019Q3 released budget laptop (Comet Lake i3 2/4 cores/threads, 4GB RAM, 128GB NVMe SSD), CPU was often at 50% from some MS background optimization processes for .NET running, fans came on more often even with low power / battery life focused power options. I think around 2GB RAM was used up as well without doing anything on fresh boot.


        ​​​​​​​
        Originally posted by Scellow View Post
        They all moved to macOS because APIs are nicer, they got a better statically AOT compiled language (Swift), there is a real App Store, and everything is butter smooth and efficient
        Swift isn't useful if you want to support other OS is it?

        macOS wasn't enjoyable to use for me, it looked pretty and did well for casual user stuff, but got in the way for any power user activity when I wanted to stray from the default experience you were expected to be content with. Asking community how to do things often resulted in they didn't know or I could solve it by paying money for functionality that were either free or even provided by default on Windows or Linux.

        macOS isn't that nice API wise if you want to use Vulkan or OpenGL/OpenCL, the latter two are deprecated and vulkan isn't supported unless you use third-party lib. They have some grudge with nvidia which means tough shit if you want to stay up to date and use CUDA for any real GPU compute work, and that's what some proprietary software relies on. Bigger companies like Adobe adopt to Metal APIs to retain their marketshare on the platform, but I doubt they'd bother if they had any other option. The history macOS has with such behaviour is a red flag for why you'd want to adopt/trust Apple, unless you like supporting their vendor lock-in APIs supporting the platform exclusively or enduring the added cost for maintaining a platform specific API in addition to whatever else you support for other platforms. That may contradict with my statement about CUDA, but if you do any GPU compute work, it's still fairly dominant making it difficult to use alternatives unless you're writing the software entirely.

        macOS is butter smooth with animations, but I've experienced times where it goes to shit becoming a snail (10 sec+ delays for mouse/keyboard input response), bouncing icons on the dock or spinning beachball busy cursor remained butter smooth 60FPS during that, but it took well over 10 minutes to restore the system and save my work. I've generally not had a positive experience with macOS.

        ​​​​​​​
        Originally posted by Scellow View Post
        Same for linux, everything there is smooth
        Linux it varies. It can be good, but I've seen plenty of times when it's the opposite. So as a broad statement, that's not true. More like "everything can be smooth".

        Comment


        • #84
          Just going through that linked mailing list, here's a quote of Dave Airlie for you EEE folk to sink your teeth into :P

          I also have another concern from a legal standpoint I'd rather not review the ioctl part of this. I'd probably request under DRI developers abstain as well.

          This is a Windows kernel API being smashed into a Linux driver. I don't want to be tainted by knowledge of an API that I've no idea of the legal status of derived works. (it this all covered patent wise under OIN?)

          I don't want to ever be accused of designing a Linux kernel API with illgotten D3DKMT knowledge, I feel tainting myself with knowledge of a properietary API might cause derived work issues.
          Which is a pretty fair concern to raise.

          Comment


          • #85
            Originally posted by M1kkko View Post
            Embrace - Extend - Extinquish

            Are we now at part 2?
            Why? What I didn't see there is whether the implementation is open source. If yes, then there is no problem - free (as in speech) software is inherently safe from that, whoever develops it. If it's not free (as in speech) then I still don't see a problem. Only games will use it, but if you play games you already rely on strictly proprietary software anyway (including the distribution platform - Steam, its DRM etc) so this is no different. If anything it will make it easier for developers to build their games for Linux, which is a good thing. Even RMS agrees with that!

            Comment


            • #86
              Originally posted by tildearrow View Post

              Gallium-Twelve
              Yea although lower versions would benefit more. DX12 isn't used too much yet.

              Comment


              • #87
                Originally posted by pracedru View Post
                There is also the possibility that this will be:
                Embrace
                Extend
                Consume

                MS could be moving Windows from NT Kernel to Linux Kernel.
                There certainly would be a lot of money to be saved for having to maintain the nt kernel.
                There is no fear. Microsoft does NOT OWN the Linux kernel. But they can use it with their walled garden userland if they so choose. There is nothing wrong with that. As long as they contribute back to the kernel, i see no reason for people to be upset. It is not like Windows 10 is opensource...

                Comment


                • #88
                  Originally posted by tildearrow View Post

                  Gallium-Twelve
                  With this we avoid remapping the outputs of the fixed function shaders and averts the assert in output mapping. Move the lowering passes from finalize_nir to compile_nir like suggested by...


                  it might be nearer than I thought

                  Comment


                  • #89
                    Originally posted by TemplarGR View Post
                    There is no fear. Microsoft does NOT OWN the Linux kernel. But they can use it with their walled garden userland if they so choose. There is nothing wrong with that. As long as they contribute back to the kernel, i see no reason for people to be upset. It is not like Windows 10 is opensource...

                    Anything not Microsoft is either a threat to Microsoft or a new Market to conquer for Microsoft, they will try to get rid of Linux via first making a compatibility layer, then ensuring that Linux software works better with MS' compatibility layer than Linux, then they will find a way to make the software requiring the Linux layer dependent on functionality available on the Windows side but Linux in appearance.

                    Microsoft can't be trusted, they're like the proverbial scorpion.

                    Comment


                    • #90
                      Originally posted by numacross View Post

                      The main use case is for many Machine Learning libraries that are Linux-only to be accessible on Windows hosts.
                      What? That makes no sense. If the library runs on Linux it means it does NOT use DirectX.

                      Comment

                      Working...
                      X