Announcement

Collapse
No announcement yet.

Wine's VKD3D Lands An Initial Vulkan Pipeline Cache

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

  • #11
    Originally posted by Spazturtle View Post

    I doubt Microsoft would allow Vulkan > DX12 on the Xbox, but you can do it the other way around on Windows.

    VKD3D, DXVK and VK9 work on Windows, they compile to a .dll and you then dump the DLL in the game's folder.
    VKD3D is translation layer DirectX12 -> Vulkan, but I meant opposite: Vulkan -> DirectX12.

    Vulkan is usable on:
    * Windows 7/8/10 (but require manual drivers installation - Microsoft by default do not support Vulkan)
    * Android
    * Linux
    With MoltenVK layer (Vulkan->Metal):
    * iOS
    * MacOS

    Having "VK->DX12" layer would expand Vulkan support to:
    * Windows 10 (no need to manual driver installation)
    * XboX

    The most closed/"walled garden" company (Apple) accepted MoltenVK, so I do not see reason why Microsoft would ban hypothetical "VK->DX12" translation layer.

    Comment


    • #12
      I wish qemu would adopt some this stuff from WINE.

      Comment


      • #13
        Originally posted by xxmitsu View Post
        No, I mean.. vkd3d is d3d12 over Vulkan, but at the driver level (vulkan driver) already has this, right ? https://cgit.freedesktop.org/mesa/me...7e9da8d65407d4
        I can't seem to reach that link, but I used the commit ID to look it up on github https://github.com/mesa3d/mesa/commi...7e9da8d65407d4

        From what I understand (not much) this is a cache in the vkd3d stage, so it is caching things before they are converted to Vulkan and sent to the driver. So it's still going to speed up loading, as this stage would have to be performed anyway even if the Vulkan driver had stuff in its cache already.

        Comment


        • #14
          Originally posted by Spazturtle View Post
          I doubt Microsoft would allow Vulkan > DX12 on the Xbox, but you can do it the other way around on Windows.

          VKD3D, DXVK and VK9 work on Windows, they compile to a .dll and you then dump the DLL in the game's folder.
          Xbox applications aren't different from PC applications in this regard, you can ship all wrappers you want inside your own application folder and MS can't say shit as long as the API used to talk to the rest of the OS is the one they want.

          Same for Apple and MoltenVK, they can't enforce shit about the internal interfaces of your application.

          Comment


          • #15
            Originally posted by starshipeleven View Post
            Xbox applications aren't different from PC applications in this regard, you can ship all wrappers you want inside your own application folder and MS can't say shit as long as the API used to talk to the rest of the OS is the one they want.

            Same for Apple and MoltenVK, they can't enforce shit about the internal interfaces of your application.
            Both examples are walled gardens, as long as you don't root your device in some way you can't do anything that the garden keeper doesn't allow.

            If you want to use the online parts of XBox you have to follow Microsoft's guidelines and they are in control. Same for Apple and the App Store/iCloud. They own the devices not users.

            Comment


            • #16
              Originally posted by numacross View Post
              Both examples are walled gardens, as long as you don't root your device in some way you can't do anything that the garden keeper doesn't allow.
              This is completely unrelated, I'm saying that there is nothing the walled garden can do to decide an application internal API. What they decide is the API from the application to the system, but an application can do what it wants with its own libraries and components.

              Comment


              • #17
                Originally posted by linner View Post
                I wish qemu would adopt some this stuff from WINE.
                What would you want it for? To run D3D apps in windows under qemu? You can always install VK9, DXVK, and VK3D under windows. All that's remaining is a windows Vulkan/virgl driver, and support from qemu. Not here yet, but I guess that will come eventually. What more would you want? I won't thing qemu and wine could share a lot.

                Comment


                • #18
                  Originally posted by starshipeleven View Post
                  This is completely unrelated, I'm saying that there is nothing the walled garden can do to decide an application internal API. What they decide is the API from the application to the system, but an application can do what it wants with its own libraries and components.
                  But they can absolutely reject your app or ban it for any reason including using an internal (statically linked) API they don't like.

                  Comment


                  • #19
                    Originally posted by Weasel View Post
                    But they can absolutely reject your app or ban it for any reason including using an internal (statically linked) API they don't like.
                    Yup, but the fact that not even Apple does that should hint that it's not really good for PR.

                    I mean you can't really claim that kind of request is for some legit reason. Developers aren't end users where you can pull off shit like claiming "you are holding the phone wrong" or "you can't get your data back from the device" when there is clearly a port and a tool you specifically made to read it off a dead motherboard.

                    Comment


                    • #20
                      VKD3D isn't running too many Direct3D 12 games yet, but laying the groundwork for this pipeline cache will likely prove useful moving into the future.
                      I somehow feel like pointing out that I have not seen vkd3d run ANY game at all, and I have looked.

                      Comment

                      Working...
                      X