Announcement

Collapse
No announcement yet.

DXVK 1.0.1 Released With Various Game Fixes For Direct3D On Vulkan

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

  • DXVK 1.0.1 Released With Various Game Fixes For Direct3D On Vulkan

    Phoronix: DXVK 1.0.1 Released With Various Game Fixes For Direct3D On Vulkan

    DXVK lead developer Philip Rebohle has released version 1.0.1 of this popular project that enhances Wine-based Linux gaming by allowing Direct3D 10/11 to be re-routed atop Vulkan drivers...

    http://www.phoronix.com/scan.php?pag...1.0.1-Released

  • #2
    Cool. DXVK updating is always good news. I've been using a combination of DXVK, RADV, and libstrangle capped to 30fps to play The Witness. For the most part it runs at 60fps, all settings maxed out, but some areas drop down to 45 or so fps causing bad lag and skipping; limiting it to 30 makes it play perfectly.

    Just checked before posting and the lagging and slowdowns are gone with DXVK 1.0.1...no need to cap The Witness to 30 fps anymore. Tested by running around the treehouse area like a jackass with both 1.0 and 1.0.1 using the Lutris tkg-4.3 wine build with and without the FPS env variable. That's great, one less hack to play a game. Still gonna use libstrangle for the PICMIP and AF variables though.

    The Witness doesn't render properly with AMDVLK regardless of DXVK or wine version. Just adding that little tidbit of information.

    Comment


    • #3
      Originally posted by skeevy420 View Post
      The Witness doesn't render properly with AMDVLK regardless of DXVK or wine version. Just adding that little tidbit of information.
      Other games that have rendering and performance problems with amdvlk are Just Cause 3 and Shadow of the Tomb Raider. wine-staging, dxvk and latest Mesa git drivers support most of games. Both Padoka ppa Mesa git and Oibaf ppa are updated a few hours ago. The LLVM 8 in Oibaf ppa is slower and causes colorful flashing at boot.

      Comment


      • #4
        Yet again, people said it was good AMD had their own driver out. In reality, it really fucked everyone by wasting a year doing it. And it wasted what vulkan gave AMD (a chance to base on Linux AND Windows both, but they didn't) and it really screwed the pooch everywhere. If they just documented the nuances and more stuff during that time instead of wasting thousands of hours of work porting it, they could have just helped the community more. Thanks, AMD management. Not the devs fault, it's here and okay to have AMDVLK as long as it never gets worked on outside of AMD. But AMD needs to admit defeat and look to help RADV. It's better.


        Really, really bad managment/guidance from before Vulkan was even really alive internally. This is about supporting mesa and open source, after all, right? AMD failed to provide that even on a completely new driver. I'll assume from here on out, we're all on the same page, right? It looks like I should buy Bas and Tim A. some beers for their work.

        Comment


        • #5
          This is an awesome project, and I'm glad it was done. I played Skyrim on Linux, it was amazingly smooth. Witcher 3 still doesn't work well, I'll have to try it out later with this new version and see if anything's changed.

          Also, I'm curious about the Vulkan on Bay Trail - does Bay Trail actually support Vulkan? I had the impression it was the same as the Ivy Bridge GPU, and therefore couldn't run Vulkan. If it can actually support, that would be awesome!

          Comment


          • #6
            Originally posted by skeevy420 View Post
            Just checked before posting and the lagging and slowdowns are gone with DXVK 1.0.1...no need to cap The Witness to 30 fps anymore. Tested by running around the treehouse area like a jackass with both 1.0 and 1.0.1 using the Lutris tkg-4.3 wine build with and without the FPS env variable. That's great, one less hack to play a game. Still gonna use libstrangle for the PICMIP and AF variables though.
            Thanks for mentioning libstrangle! I didn't know there was a program to limit the FPS of any given application on Linux.

            For those who are interested in it, here's the link: https://gitlab.com/torkel104/libstrangle

            Comment


            • #7
              Originally posted by Calinou View Post

              Thanks for mentioning libstrangle! I didn't know there was a program to limit the FPS of any given application on Linux.

              For those who are interested in it, here's the link: https://gitlab.com/torkel104/libstrangle
              There's also another Vulkan-only FPS Limiter, VKGHL: https://github.com/pchome/VkGHL. According to its readme, it supports the same variables that libstrangle does. I stumbled across that one night before last so I've never actually used it. It isn't on the top of my priorities since libstrangle has the same variables and works with both OGL and Vulkan.

              Comment


              • #8
                Originally posted by abott View Post
                Yet again, people said it was good AMD had their own driver out. In reality, it really fucked everyone by wasting a year doing it. And it wasted what vulkan gave AMD (a chance to base on Linux AND Windows both, but they didn't) and it really screwed the pooch everywhere. If they just documented the nuances and more stuff during that time instead of wasting thousands of hours of work porting it, they could have just helped the community more. Thanks, AMD management. Not the devs fault, it's here and okay to have AMDVLK as long as it never gets worked on outside of AMD. But AMD needs to admit defeat and look to help RADV. It's better.


                Really, really bad managment/guidance from before Vulkan was even really alive internally. This is about supporting mesa and open source, after all, right? AMD failed to provide that even on a completely new driver. I'll assume from here on out, we're all on the same page, right? It looks like I should buy Bas and Tim A. some beers for their work.
                No need to rag on AMDVLK so hard. With my previous GPU a year ago, RADV sucked ass trying to play Mad Max and AMDVLK didn't (both give 60fps smooth with my current GPU). With Retroarch, some of the emulators work better with AMDVLK, some work better with RADV. Neither Vulkan implementation is perfect. I'm just glad that we have options.

                Comment


                • #9
                  RADV would have sucked less if AMD had contributed even a few patches to it. But RADV also existed buggy when AMDVLK didn't exist at all, so who cares if it was buggy? Not like AMD had anything to give you, at the time, like they had promised.

                  Comment


                  • #10
                    Originally posted by abott View Post
                    RADV would have sucked less if AMD had contributed even a few patches to it. But RADV also existed buggy when AMDVLK didn't exist at all, so who cares if it was buggy? Not like AMD had anything to give you, at the time, like they had promised.
                    Possibly, but I'm not going to fault AMD for wanting to focus their limited Linux manpower on their OS agnostic AMDVLK over the Linux-specific RADV. They need a driver that works with Windows, Linux, BSD (powers the PS4/probably PS5), OSX, Windows fox Xbox, and probably more; it's just common sense for them to want to focus on AMDVLK and an overall driver stack that's OS agnostic and works the same for everyone. It's a daunting and laudable goal.

                    Also, just tested the latest AMDVLK with The Witness and it didn't help at all. Don't ya just love waking up to a Phoronix article that makes you want to go and compile software...

                    FWIW, we can make the same complaints about Nvidia, EGLStreams, and the usage of freakin' standards.

                    Comment

                    Working...
                    X