Announcement

Collapse
No announcement yet.

Microsoft Gets OpenGL 4.3 Implemented Atop Direct3D 12 With Mesa

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

  • #11
    I wonder if Intel will leverage this (or zink) for their Alchemist card drivers on Windows? Also, I'm a bit confused: this is a DX12 back end for the OGL state tracker, correct? Like zink is a Vulkan back end for Gallium? Is it a Gallium back end as well? If so, that opens up some other possibilities such as Nine or OpenCL (with RustiCL) over DX12 (possibly over DXVK over Vulkan? :P).

    Comment


    • #12
      Originally posted by uid313 View Post
      We have Windows 11 at work, and I haven't experienced any of this "spam" that you mention. No idea what you're talking about, there are no spam in Windows 11. Overall Windows 11 is really nice, but Edge is rather bloated. At home I run Linux though.
      I haven't touched Windows 11 that much yet, but in a previous job I managed hundreds of Windows 10 workstations and no one user never got any advertisement from Windows, not because of Microsoft, but because of me blocking them all. Scripts and default config files to disable advertised wallpapers with adds, disable adds in start menu, disable Cortana listening to the room and looking at all your searches in our drives and outside of them, etc. were parts of our standard installation and deployment procedures. This was Windows 10 Pro and it was full of adds without those tricks. Outside of Windows advertisements some other features were even directly filtered out with some transparent proxy, for example telemetry and some unmanaged download were disabled both with aggressive Windows tweaks and on the filtering bridge.
      Last edited by illwieckz; 08 November 2023, 11:06 PM.

      Comment


      • #13
        Are we at the point yet where we can have an infinite chain of API translation layers?

        Comment


        • #14
          Glad to see this work being done, opengl on windows has been nothing but a nightmare, Im looking forwards to trying this with QT apps since so far, most i have tried wind up crashing or exhibiting really bad bugs, zink almost never works for qt apps.

          Originally posted by andyprough View Post
          I don't see any profitable business-related reason for Microsoft to be working on integrating the GNU/Linux graphics stack, unless they are planning to re-base Windows on it in the future in some kind of WinNT/Linux kind of hybrid setup. They may have decided that they can cut costs by ditching a lot of the maintenance of their own OS and just ride the back of the open source software community to riches like Apple did with NetBSD.
          Linux on windows VMs are somewhat popular, this includes WSA, WSL, and Hyper-v. all three of these greatly benefit from this work.

          Originally posted by rmfx View Post
          Microsoft is really like the kid that says can I join you? to then bring his own toys and do not share.

          Rather than redoing what Zink already does well, they could contribute to it to make it better, (or give a 10 million usd tip a year to Mesa), but no, they come and do their proprietary based shit for dx12 nobody asked for....
          they have been, their d3d12 backend work has brought numerous improvements to mesa, the most important one for me being the vaapi improvements we had a while back​. people forget that gallium is a shared interface. if d3d12 needs to work on the middle gallium bits or opengl part of the gallium bits, then that benefits everyone. not just d3d12​​. not to mention the maintainer for the d3d12 stuff offers technical commentary on PRs and whatnot.

          Originally posted by M@yeulC View Post
          I wonder if Intel will leverage this (or zink) for their Alchemist card drivers on Windows? Also, I'm a bit confused: this is a DX12 back end for the OGL state tracker, correct? Like zink is a Vulkan back end for Gallium? Is it a Gallium back end as well? If so, that opens up some other possibilities such as Nine or OpenCL (with RustiCL) over DX12 (possibly over DXVK over Vulkan? :P).
          Intel is already using dxvk for d3d9 support. I think in general it could be possible to use zink or glond3d12, however I dont think it's nearly close to a priority for them since both zink and glond3d12 hardly work on windows very well.​

          Comment


          • #15
            Originally posted by Eirikr1848 View Post
            Then Apple can’t bother do do GL on Metal or contribute to MoltenVK
            Actually they can. OpenGL on Apple Silicon Macs is implemented on top of Metal. Metal itself has a bunch of hidden stuff that is not used or even supported by Metal applications but exists for OpenGL compatibility.

            While they indeed don't care about MoltenVK, it seems that they sometimes implement things in Metal that helps MoltenVK improve compatibility with Vulkan extensions.

            Comment


            • #16
              Originally posted by andyprough View Post
              I don't see any profitable business-related reason for Microsoft to be working on integrating the GNU/Linux graphics stack, unless they are planning to re-base Windows on it in the future in some kind of WinNT/Linux kind of hybrid setup. They may have decided that they can cut costs by ditching a lot of the maintenance of their own OS and just ride the back of the open source software community to riches like Apple did with NetBSD.
              I don't think we are going to see this, because Microsoft is obsessed with maintaining control. Therefore they rather would go with a BSD kernel as apple does. GNU Linux is rather restrictive in comparison due to it's licenses. It is very hard to restructure the kernel without the consent of the kernel developers. This is one of the reasons, why google drives the fuchsia zircon project in parallel to linux.

              As for Microsoft we can speculate all day long about their future plans and extending linux. But one thing is for sure. It does not make sense to wrap open source graphics apis around a proprietary graphics api, while Microsoft could just simply support the open source ones instead. This is unless you actually don't want people to use the open source alternatives. And the reason for this is simple. Proprietary APIs just as proprietary ISAs have always been a tool for companies and corporations to vendor-lock-in their customers and cut off the better competition. This alone exposes Microsoft's whole ambition here as a self-serving means to maintain their monopoly.
              Last edited by M.Bahr; 09 November 2023, 03:05 PM.

              Comment


              • #17
                Originally posted by rmfx View Post
                Microsoft is really like the kid that says can I join you? to then bring his own toys and do not share.

                Rather than redoing what Zink already does well, they could contribute to it to make it better, (or give a 10 million usd tip a year to Mesa), but no, they come and do their proprietary based shit for dx12 nobody asked for....
                For real. Is there any DX12 (tier 3 at that!) device that also doesn't support Vulkan? They could have avoided reinventing the wheel here. Ahh well, Microsoft's infamous "NIH" (Not invented Here) kicks in. Although IMHO redundant given the existence of Zink, they've done it anyway and no harm done.

                Comment


                • #18
                  Originally posted by hwertz View Post

                  For real. Is there any DX12 (tier 3 at that!) device that also doesn't support Vulkan? They could have avoided reinventing the wheel here. Ahh well, Microsoft's infamous "NIH" (Not invented Here) kicks in. Although IMHO redundant given the existence of Zink, they've done it anyway and no harm done.
                  no they couldn't the d3d12 backend is used on multiple things, including VMs. MS has a very good paravirtualized gpu solution that is based on the directX stack (which is more then just 3d acceleration). if they went with vulkan they would need to overhaul the entire stack into something probably inferior. They also need to support devices which don't provide vulkan drivers like windows on qualcomm

                  Comment


                  • #19
                    Originally posted by Quackdoc View Post

                    no they couldn't the d3d12 backend is used on multiple things, including VMs. MS has a very good paravirtualized gpu solution that is based on the directX stack (which is more then just 3d acceleration). if they went with vulkan they would need to overhaul the entire stack into something probably inferior. They also need to support devices which don't provide vulkan drivers like windows on qualcomm
                    Fair! (Wait, Windows on Qualcomm doesn't support Vulkan? That's a shame, the Mesa driver has full OpenGL and Vulkan support.) It's a net win though, any changes that had to made to the Mesa internals to support OpenGL to DX12 just makes Mesa that much more flexible for future use.

                    Comment


                    • #20
                      Originally posted by hwertz View Post

                      Fair! (Wait, Windows on Qualcomm doesn't support Vulkan? That's a shame, the Mesa driver has full OpenGL and Vulkan support.) It's a net win though, any changes that had to made to the Mesa internals to support OpenGL to DX12 just makes Mesa that much more flexible for future use.
                      yeah, weird qualcomm is weird. at the very least, mesa is actually more or less explicitly designed for what d3d12 did. Opengl, OpenCL, and the gallium vaapi driver on mesa are designed to be as generic as possible so vendors only have to support gallium, and they get the full opengl, opencl, windowing infranstructure working. vulkan doesn't share that however. but it makes developing gpu drivers for linux really nice since you only really need to support that gallium API. Nvida (nouveau), AMD (radeonsi, r{6,7}00g) Intel (Iris Crocus), Mac (asahi), D3D12, Zink (vulkan), Vivante (entaviv) etc See more here.

                      all share the same gallium interface. this makes it so they can all share code to support. Opencl (Clover, Rusticl) Directx 9 via wine (winenine/nine), OMX (omx though Im not sure how many drivers enable this outside of amd), Opengl, etc.

                      We have actually already had benefits from the d3d12 stuff, as we have gotten a nice performance bump in radeonsi's vaapi code. See here.

                      Comment

                      Working...
                      X