Announcement

Collapse
No announcement yet.

"Dozen" Merged Into Mesa For Implementing Vulkan On Direct3D 12

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

  • #11
    neat, I see we're at the extend part again. Can't wait for what comes next.

    Comment


    • #12
      Originally posted by Linuxxx View Post

      Serious question:
      Do you honestly think this is going to be used to provide Vulkan support on the Xbox of all of Microsoft's platforms?

      For reference:
      Nintendo's Switch actually has official Vulkan support, yet, AFAIK, not a single commercial game is making use of it.

      (Probably because it has a nVidia Maxwell GPU, which is badly suited for running Vulkan loads in the first place.)
      The primary API on Switch is simpler than Vulkan, because as your game is the only app running, you don't have to care about a lot of stuff (think of programming for DOS where you could do everything with RAM and VRAM). Also Vulkan came later, so the engines, e.g. Unity, already implemented the original API and there was no reason to add another API in the test suite.

      And to others, think of that library and WINE (or winelib) itself as an option for developers, so they can port their (originally Windows) games more easily. Similarly like you can download a Microsoft's solution to Visual Studio containing a template and their fork of the ANGLE library, so your game can use OpenGL ES, despite the target platform (Windows UWP/Store, Windows on ARM, Xbox, ...) has only DirectX 12. You simply bundle the library with your app, so no support in the OS is needed. The same exists also for DirectX 12 on Windows 7 (used by Cyberpunk 2077 and some Blizzard games) - you bundle DX12 with your game, so no DX12 is needed on Win7 (but you needed MS to create the Win7 libraries).

      Comment


      • #13
        Originally posted by dragorth View Post
        Also, this kinda makes MESA a truly agnostic graphics driver layer, which can be used by hardware manufacturers to jumpstart and test against known good implementations, doesn't it?
        I think so, as well. The license model of Mesa definitely helps, though (MIT License).

        Comment


        • #14
          Originally posted by Linuxxx View Post

          Serious question:
          Do you honestly think this is going to be used to provide Vulkan support on the Xbox of all of Microsoft's platforms?
          That's something I am doubting since most game devs just use the platform-specific graphics API or just a graphics engine...

          The problem with Vulkan is that it had a difficult and too late arrival... Metal was ready since 2013, DirectX 12 since 2015 and Vulkan.... 2016.

          Furthermore its complexity (not kidding, over 6000 lines of code just to draw a freaking triangle) turns every graphics dev off, regardless of its advantages.

          On the other hand OpenGL enjoyed lots of success because it arrived earlier than DirectX despite its "state machine" model not being so ideal...
          Last edited by tildearrow; 25 March 2022, 09:59 PM.

          Comment


          • #15
            Originally posted by Danny3 View Post
            Why the fuck this is needed when Vulkan already works on all OSes?
            Makes no sense to me why would anyone need another abstraction layer that slowes things down and consumes extra CPU cycles, hence also more electrical power.
            Not all GPUs have Vulkan drivers on Windows. So it's very much necessary.

            Comment


            • #16
              I'm curious if browsers may use this rather than having their own internal translation layers for WebGPU on windows.

              I'm assuming probably not, but it could be an interesting option.

              Comment


              • #17
                Originally posted by peterdk View Post
                Wonder what the use as reference documentation is for the DXVK/VKD3D?
                there is none as far as I am aware.

                Originally posted by Danny3 View Post
                Why the fuck this is needed when Vulkan already works on all OSes?
                Makes no sense to me why would anyone need another abstraction layer that slowes things down and consumes extra CPU cycles, hence also more electrical power.
                Driver level GPU paravirt in virtual machines and directx only devices, this should be able to provide vulkan support in WSL2 with some work if it doesn't already

                Originally posted by SWY1985 View Post
                I recently needed a Windows VM. The whole experience was a complete disaster...
                Either the Windows experience has taken a nosedive, or I just don't remember what it was like to use an animated advertisement billboard as a UI.
                What we need for this is gpu acceleration, in which case we might get it when qemu finally get vulkan support. windows VM in vmware on linux host is a fine experience. QEMU can be very slow to implement technology sometimes, and really fast and uncessary technology often gets dropped or left in an unusable state, like the qemu vmsvga driver. which stopped working during WinXP lifetime.

                Comment


                • #18
                  Originally posted by tildearrow View Post

                  That's something I am doubting since most game devs just use the platform-specific graphics API or just a graphics engine...

                  The problem with Vulkan is that it had a difficult and too late arrival... Metal was ready since 2013, DirectX 12 since 2015 and Vulkan.... 2016.

                  Furthermore its complexity (not kidding, over 6000 lines of code just to draw a freaking triangle) turns every graphics dev off, regardless of its advantages.

                  On the other hand OpenGL enjoyed lots of success because it arrived earlier than DirectX despite its "state machine" model not being so ideal...
                  OpenGL didn't just arrive earlier, DirectX was originally created not as a competitor to OpenGL, but to allow MS to implement some of OpenGL on Windows, because the hardware for OpenGL was too expensive to be sold to consumers. It later morphed into the bloated mess that was DX9 and DX11, but it started out much like Vulkan, just exposing the features of the GPU to devs.

                  Comment


                  • #19
                    I wonder whats the value of a vulkan to D3D12 layer if, if there is no D3D12 implementation in Mesa. I mean even for testing it's kind of pointless, isn't it? Can the Mesa people even test if this thing works? How does CI look like? How to be sure that a change in Mesa doesn't kill the layer? I'm not sure if this platform specific "module" wouldn't be better off out of tree.

                    I'm not saying it's bad or that Microsoft should stay away from Mesa, I just cant see the benefit and on the other hand I can see this to be a major roadblock because of testing / test integration in the future.

                    Comment


                    • #20
                      Originally posted by SWY1985 View Post
                      I recently needed a Windows VM. The whole experience was a complete disaster...
                      Either the Windows experience has taken a nosedive, or I just don't remember what it was like to use an animated advertisement billboard as a UI.

                      I love that Microsoft has added a Linux environment to their OS. Now they just need to take down the rest of Windows around it and start working on a decent user experience.
                      Or, you know... just release their own Linux distro.
                      Windows 10 can be tolerable if you rip out all the ad/spyware and patch it to support 3rd party themes. I won't go near 11 with a 10ft pole

                      Comment

                      Working...
                      X