Announcement

Collapse
No announcement yet.

VKD3D Is Beginning Flight As Wine's Direct3D 12 To Vulkan Library

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

  • VKD3D Is Beginning Flight As Wine's Direct3D 12 To Vulkan Library

    Phoronix: VKD3D Is Beginning Flight As Wine's Direct3D 12 To Vulkan Library

    Back at WineConf 2017 VKD3D was announced for bringing Direct3D 12 to Wine by implementing Microsoft's latest graphics API atop the Vulkan graphics API. The initial code for this new library is beginning to take shape...

    http://www.phoronix.com/scan.php?pag...-Taking-Flight

  • #2
    I'm very excited about the progress of VK9, DXVK and VKD3D and I will follow the development closely. I'm sure that all these efforts will pay-off.

    Comment


    • #3
      Originally posted by R41N3R View Post
      I'm very excited about the progress of VK9, DXVK and VKD3D and I will follow the development closely. I'm sure that all these efforts will pay-off.
      Yes, once RADV gets more optimisations happening it should be right up near Nvidia Vulkan performance. Not sure how long that will take but the prospects of getting good performance out of DX11/12 games under Linux with these projects would be amazing.

      Comment


      • #4
        Originally posted by theriddick View Post

        Yes, once RADV gets more optimisations happening it should be right up near Nvidia Vulkan performance.
        You mean the continuous crashing, lockups, rendering issues? You don't want that in RADV.

        Comment


        • #5
          Never heard of those issues with NVIDIA Vulkan usage. Perhaps you mean NVIDIA Vulkan under Wine?

          Comment


          • #6
            Originally posted by eydee View Post
            You mean the continuous crashing, lockups, rendering issues? You don't want that in RADV.
            If you want rendering issues in RADV, play Wolfenstein 2. For the other two, just do some Vulkan development yourself - even with validation layers enabled (which *should* catch problematic things) it's not impossible to generate harmless but hard to debug segfaults, and in some rare cases even hard GPU lockups (usually caused by shader issues). Vulkan really only works if the application using it is *perfect*.

            While working on DXVK I've also had a lot of issues with LLVM segfaulting while compiling the SPIR-V shaders - which again was ultimately my own fault, but it doesn't really make life easier that LLVM just derps out while emitting instruction instead of having something that tells me "oh by the way your SPIR-V is invalid".

            Anyway it's good to see VKD3D up, this is something I'm quite excited for since it may allow playing stuff like Rise of the Tomb Raider or Hitman with near-native performance (no offense Feral, you guys did a good job on Hitman, but ultimately it's still D3D11->OpenGL)
            Last edited by VikingGe; 12-15-2017, 06:27 AM.

            Comment


            • #7
              Originally posted by VikingGe View Post
              If you want rendering issues in RADV, play Wolfenstein 2. For the other two, just do some Vulkan development yourself - even with validation layers enabled (which *should* catch problematic things) it's not impossible to generate harmless but hard to debug segfaults, and in some rare cases even hard GPU lockups (usually caused by shader issues). Vulkan really only works if the application using it is *perfect*.

              While working on DXVK I've also had a lot of issues with LLVM segfaulting while compiling the SPIR-V shaders - which again was ultimately my own fault, but it doesn't really make life easier that LLVM just derps out while emitting instruction instead of having something that tells me "oh by the way your SPIR-V is invalid".

              Anyway it's good to see VKD3D up, this is something I'm quite excited for since it may allow playing stuff like Rise of the Tomb Raider or Hitman with near-native performance (no offense Feral, you guys did a good job on Hitman, but ultimately it's still D3D11->OpenGL)
              Allowing segfaults sounds like a reasonable symptom of the desire to reduce driver overhead. Sounds like main problem there is the validation is not good enough. Permanent GPU hangs are of course inacceptable

              Comment


              • #8
                Originally posted by nanonyme View Post
                Allowing segfaults sounds like a reasonable symptom of the desire to reduce driver overhead.
                Don't get me wrong, it certainly is, and the good thing about RADV in particular is that you *can* actually debug them *at all* - I imagine this would be a lot more painful with a closed-source driver.

                Comment


                • #9
                  Originally posted by VikingGe View Post
                  If you want rendering issues in RADV, play Wolfenstein 2. For the other two, just do some Vulkan development yourself - even with validation layers enabled (which *should* catch problematic things) it's not impossible to generate harmless but hard to debug segfaults, and in some rare cases even hard GPU lockups (usually caused by shader issues). Vulkan really only works if the application using it is *perfect*.

                  While working on DXVK I've also had a lot of issues with LLVM segfaulting while compiling the SPIR-V shaders - which again was ultimately my own fault, but it doesn't really make life easier that LLVM just derps out while emitting instruction instead of having something that tells me "oh by the way your SPIR-V is invalid".

                  Anyway it's good to see VKD3D up, this is something I'm quite excited for since it may allow playing stuff like Rise of the Tomb Raider or Hitman with near-native performance (no offense Feral, you guys did a good job on Hitman, but ultimately it's still D3D11->OpenGL)
                  Not looking to be an ass here but what you describe is exactly why Vulkan exists, you have to make sure the code is perfect not the driver

                  Remember DX11/OpenGL is akin to PHP in the CPU world while Vulkan is akin to ISO C 99, so is absolutely normal behavior in either case and about SPIRV compilation is pretty much as it should since on the CPU side is like that as well(no compiler is smart enough to detect segfaults, sigabrts, etc. at compilation time).

                  I do agree that Vulkan(and D3D12 as well) need more robust debugging tools

                  Comment


                  • #10
                    I am really looking forward to it. Might try to get involved in it.

                    Comment

                    Working...
                    X