Announcement

Collapse
No announcement yet.

Microsoft Eyeing OpenGL Compute + GLES 3.1 For Its Mesa D3D12 Backend

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

  • #21
    Originally posted by darkdragon-001 View Post
    How is mesa structured internally? Shouldn't it be possible to provide a D3D12 backend alongside a Vulkan one and e.g. use Zink as an OpenGL frontend for both?
    zink IS a vulkan driver d3d12 IS a d3d12 driver, NOT a OGL specific thing.

    Comment


    • #22
      Originally posted by Birkett83 View Post
      Providing better OpenGL support on windows should make it easier to port existing software written in OpenGL to windows and make it easier for developers who might otherwise choose to target direct X to go with the more portable OpenGL instead.

      For the cynical among you, feel free to object that OpenGL is a legacy API at this point and anything new ought to target vulcan instead, so developers wanting the features of a modern API will still have to choose dx12 on windows... But complaining that an MIT-licenced OpenGL implementation on windows is in itself bad for the future of open source software is just silly.
      you missed the point completely. the point is that they are working on a d3d12 driver instead of an open driver like vulkan.

      they could use zink to do that, zink would be better suited for the task, as it has a larger userbase, and thus more devs potentially working on it. d3d12 backend is NOT about windows getting better opengl support, its about microsoft being able to use their GPL Shim in virtual machines.

      that is what we are talking about, not that people should abandon OGL for vulkan

      Comment


      • #23
        Originally posted by Quackdoc View Post

        zink IS a vulkan driver d3d12 IS a d3d12 driver, NOT a OGL specific thing.
        Sorry, but I still don't get it...

        My understanding is the following:

        Zink translates from Vulkan->OpenGL
        Microsoft's new thing translates from D3D12->OpenGL
        AMDVLK translates from AMD-API->Vulkan
        Gallium3D translates from Hardware-API->OpenGL

        What is wrong with it?

        Comment


        • #24
          Originally posted by darkdragon-001 View Post

          Sorry, but I still don't get it...

          My understanding is the following:

          Zink translates from Vulkan->OpenGL
          Microsoft's new thing translates from D3D12->OpenGL
          AMDVLK translates from AMD-API->Vulkan
          Gallium3D translates from Hardware-API->OpenGL

          What is wrong with it?
          I honestly can't figure out what you think G3D is, so ill just explain it entirely.

          Gallium is based on three layers,

          The driver, IE RadeonSI, ZInk, Iris
          Galliums API
          And the state tracker, IE. OpenGL, Gallium nine etc.

          The state tracker is what provieds OpenGL support. it is the "front end" so to speak, so a rendering path would look like this

          State Tracker -> G3D -> Driver -> Hardware
          OR
          OGL -> G3D -> Radeon SI -> Hardware.

          For both zink and D3D12 it looks like this

          OGL -> G3D -> Vulkan -> Vulkan Driver -> Hardware
          OGL -> G3D -> D3D12 -> D3D12 Driver -> Hardware

          Comment


          • #25
            Originally posted by Quackdoc View Post

            you missed the point completely. the point is that they are working on a d3d12 driver instead of an open driver like vulkan.

            they could use zink to do that, zink would be better suited for the task, as it has a larger userbase, and thus more devs potentially working on it. d3d12 backend is NOT about windows getting better opengl support, its about microsoft being able to use their GPL Shim in virtual machines.

            that is what we are talking about, not that people should abandon OGL for vulkan
            The GPL shim you're talking about, are you referring to the DXGKRNL driver microsoft have written and have attempted to upstream into the linux kernel? ( https://www.phoronix.com/scan.php?pa...-Uphill-Battle ) - I don't think the kernel maintainers will accept it, since there's no open source d3dx12 library for linux that would use the driver. I wholeheartedly support the kernel maintainers in not wanting a driver that isn't fully open source in their kernel.

            Regarding microsoft's new open source OpenGL implementation that uses a d3dx12 backend, either on windows or on linux (using microsoft's out-of-tree dxgkrnl driver) or - how could that be a bad thing for the open source community? It allows people who want to run WSL2 to run OpenGL apps, so more people can use open source stuff in more places (that's good!) and doesn't lock anyone into the microsoft ecosystem. It seems to me the real threat is microsoft providing the d3dx12.so for developers to port dx12 apps to linux, since those apps would only be able to run on WSL2 or hyperV, not on native linux kernels.

            Comment


            • #26
              Originally posted by Quackdoc View Post

              Gallium is based on three layers,

              The driver, IE RadeonSI, ZInk, Iris
              Galliums API
              And the state tracker, IE. OpenGL, Gallium nine etc.

              The state tracker is what provieds OpenGL support. it is the "front end" so to speak, so a rendering path would look like this

              State Tracker -> G3D -> Driver -> Hardware
              OR
              OGL -> G3D -> Radeon SI -> Hardware.

              For both zink and D3D12 it looks like this

              OGL -> G3D -> Vulkan -> Vulkan Driver -> Hardware
              OGL -> G3D -> D3D12 -> D3D12 Driver -> Hardware

              Thanks a lot for the clarification!

              A "Vulkan Driver" could then be AMDVLK for example, right?

              Everything you mentioned lives in the mesa code base, right?

              So when an application like a game or a window manager interfaces with the Vulkan API directly, Gallium3D is not needed at all?

              Would it be possible to implement a Vulkan state tracker to run any Vulkan application on a D3D12 driver then?

              Comment


              • #27
                Originally posted by darkdragon-001 View Post
                A "Vulkan Driver" could then be AMDVLK for example, right?

                Everything you mentioned lives in the mesa code base, right?

                So when an application like a game or a window manager interfaces with the Vulkan API directly, Gallium3D is not needed at all?
                This is all correct. zink returns generic vulkan calls, so any device that has a working vulkan driver should work, even proprietary ones like nvidia.

                Would it be possible to implement a Vulkan state tracker to run any Vulkan application on a D3D12 driver then?
                while this is correct, it wouldn't be the most performant, but it would do the job for getting vulkan support on d3d12, there is already dozen driver which is a WIP Vulkan over d3d12. but it is still at a proof of concept stage, I don't think it can even run vkcube yet without modification. I'm not sure if it uses gallium or not, but I think it does.

                Comment

                Working...
                X