Announcement

Collapse
No announcement yet.

Wine's Vulkan Code Seeing Performance Improvements, Further Enhancing DXVK

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

  • Wine's Vulkan Code Seeing Performance Improvements, Further Enhancing DXVK

    Phoronix: Wine's Vulkan Code Seeing Performance Improvements, Further Enhancing DXVK

    D9VK (now part of DXVK) developer Joshua Ashton has proposed a set of patches to Wine's Vulkan library (Winevulkan) that should help with performance...

    http://www.phoronix.com/scan.php?pag...Improve-Alloca

  • #2
    LEL, even his email is a frog joke
    about the new itself, its great and i hope it lands soon

    Comment


    • #3
      Good stuff. I wonder if dx 8 and 7 compatibility are still planned. A full vulkan translation of d3d and d2d would be great, though unlikely until codeweavers does their own thing that Josh vices concerns about.

      Comment


      • #4
        Originally posted by Wine-devel mailing list
        I can name Detroit Become Human... This game is already reported by some users to run faster under Wine than on Windows though.
        That kind of thing just never gets old.

        Comment


        • #5
          Originally posted by Snaipersky View Post
          Good stuff. I wonder if dx 8 and 7 compatibility are still planned. A full vulkan translation of d3d and d2d would be great, though unlikely until codeweavers does their own thing that Josh vices concerns about.
          If you are interested, DXWrapper is a great open source project that you can combine quite easy with DXVK. I could play several games successful, it is only sometimes not obvious which DirectX version is in use by which game. DirectDraw 1-7 games should run plus D3D8, all this is converted to D3D9 which can then run with DXVK on Vulkan :-)

          https://github.com/elishacloud/dxwrapper
          Last edited by R41N3R; 03-05-2020, 06:45 PM.

          Comment


          • #6
            Originally posted by Snaipersky View Post
            Good stuff. I wonder if dx 8 and 7 compatibility are still planned. A full vulkan translation of d3d and d2d would be great, though unlikely until codeweavers does their own thing that Josh vices concerns about.
            That's not really needed with dgVoodoo 2.

            Supposedly, dgVoodoo paired with DXVK will turn any Glide 2/3, DirectDraw, and Direct3D 1 thru 8.1 game into a Direct3D 11 compatible and then to Vulkan via DXVK. It also supports Direct3D 9 but that isn't needed now that DXVK has that.

            http://www.dege.freeweb.hu/

            I have yet to try it but I have a few old games I could give it a test with.
            Last edited by Xaero_Vincent; 03-05-2020, 06:02 PM.

            Comment


            • #7
              Originally posted by Snaipersky View Post
              Good stuff. I wonder if dx 8 and 7 compatibility are still planned...
              Were they ever planned?

              Comment


              • #8
                Originally posted by R41N3R View Post

                If you are interested, DXWrapper is a great open source project that you can combine quite easy with DXVK. I could play several games successful, it is only sometimes not obvious which DirectX version is in use by which game. DirectDraw 1-7 games should run plus D3D8, all this is converted to D3D9 which can then run with DXVK on Vulkan :-)

                https://github.com/elishacloud/dxwrapper
                There is a consideration here to both comments something both need to remember wine is not windows. Thing that give gain under Windows may not be as wise of move as one would think.

                Originally posted by Xaero_Vincent View Post

                That's not really needed with dgVoodoo 2.

                Supposedly, dgVoodoo paired with DXVK will turn any Glide 2/3, DirectDraw, and Direct3D 1 thru 8.1 game into a Direct3D 11 compatible and then to Vulkan via DXVK. It also supports Direct3D 9 but that isn't needed now that DXVK has that.

                http://www.dege.freeweb.hu/

                I have yet to try it but I have a few old games I could give it a test with.
                It turns out for Dx 1-7 wine dx to opengl performs quite well on modern hardware more than enough for the old applications that need dx 1-7. That really on wine there is no low hanging fruit of performance gains in the dx 1-7. So since there is no true low hanging fruit in the dx 1-7 area adding wrappers can in fact be making everything run slower in that area. Map Dx 1-7 forwards on windows is required on wine since dx 1-7 is still there not so much because of this and is more often hurting your performance than helping.

                There are big performance gains possible at dx8 and newer because this is when direct x starts doings thing that does not map to opengl very well at all. Lot of ways it would be good to see someone fork d9vk and make a d8vk as d8vk would mostly d9vk with less features and different function names because that is how dx8 is in fact is as Microsoft straight took dx 8 structures and all and extend it to make dx9 without changing much .

                Also when you look at d9vk it does not make any sense to map from 8.1 to Direct3d 11 with dxvk as you are adding extra transformations that d9vk gets to avoid by just map dx 8/8.1 to dx9. Remember you have to ask if wrapper for dx 8/8.1 to dx9 even makes sense as d8vk could be made by someone to allow straight dx8/8.1 to vulkan.

                Yes dx 8/8.1 to dx9 with d9vk makes sense at the moment if you are after performance. Where the dgVoodoo to direct3d 11 for dx 8.0 and 8.1 is not making any sense under wine because you are making your compatibility layer thicker and more cpu time consuming.

                There is a simple problem here on wine the ideal location you are looking for is direct x to either Vulkan or opengl not direct x to direct x. Both Vulkan and opengl are the host and is not thickening your compatibility layer stuff.

                Something to remember just because something can kind of work does not make it the correct solution.

                Wine is really not windows. Optimal work around for windows can be the pure wrong choice for wine.

                The best performing Glide 2/3 solutions under wine are either opengl or vulkan backend and there is very little performance difference between the opengl and the vulkan versions under wine.

                The ones doing Glide 2/3 on top direct x 9/11 on dxvk/d9vk are slower and even worse if you disable dxvk and drop back to wined3d.

                Other thing under windows the performance difference between a opengl/vulkan/dx9/dx11 implementations of glide 2/3 there is no major performance advantages these are areas where wine starts coming its own unique platform need it own unique choices.


                Generic choices that work equally under windows don't always work equally under wine. I am sorry to say a lot of people bring across what they do under windows the complain in irc help with wine about bad performance with dx 1-7 application and we in there direct them to try wined3d and its like hey my performance improved a lot. Same with glide being told to change to either a vulkan or opengl backend version and they watch performance jump a lot.

                Some areas of wine are very well performing. Not all of wine dx to opengl implementation performance suxs.

                There is a generic rule you are looking for wrappers that go the shortest path to host with wine this is vulkan or opengl backends. Yes one will be better than other in lots of cases that being the vulkan ones there are some cases like glide where opengl or vulkan back end makes bugger all difference.

                Yes wine support multi WINEPREFIX and I do recommend application per WINEPREFIX so you can optimise correctly for performance.

                Comment


                • #9
                  Note that the improvements pretty much only affect 32-bit applications, since 64-bit apps don't require struct conversion.

                  Originally posted by oiaohm View Post
                  There are big performance gains possible at dx8 and newer because this is when direct x starts doings thing that does not map to opengl very well at all.
                  Honestly, Dx8 games - and many earlier Dx9 games - are so old that performance is not really a concern, wined3d is fine for those. I think Josh mentioned wanting to add D3D8 support at some point but it has absolutely no priority whatsoever.
                  Last edited by cute2dgirl; 03-06-2020, 04:12 AM.

                  Comment


                  • #10
                    Originally posted by cute2dgirl View Post
                    Note that the improvements pretty much only affect 32-bit applications, since 64-bit apps don't require struct conversion.

                    Honestly, Dx8 games - and many earlier Dx9 games - are so old that performance is not really a concern, wined3d is fine for those. I think Josh mentioned wanting to add D3D8 support at some point but it has absolutely no priority whatsoever.
                    There are a few dx8 and dx9 games where you see high than normal cpu usage caused by dx 8/9 to opengl conversion miss matches that require decent amount of cpu time to deal with the differences wined3d. Please note I should have been more exactly when I said performance gains possible it is only in select titles that uses those dx 8/9 features that cannot map to opengl well but do map to vulkan very well.

                    Lot of early dx8 games engines were converted from dx7 so never really used the dx8 new features.

                    Dx 1-7 to opengl is a very direct mapping so there is basically nothing to gain there other than sorting out horrible allocation issues in enterprise applications that can be like opengl, dx1-7,dx8, dx 9, dx10, dx11 all working on the same memory buffer these are not games any more but pure ass enterprise applications doing horrible things like controlling a factory floor.

                    Most 64 bit applications are dx10 or newer. There are a handful for dx 8/9 applications for x86-64/amd64 for windows. They were programs for "Windows XP Professional x64 Edition" yes that was dx8/9 system. We are talking application count here less than 100 world wide across all enterprise that have ever existed that need dx8 for a 64 bit windows binary. So saying windows 64 bit applications don't need this structure conversion is wrong its just so rare that you will hit it you will more likely be more likely to win the loto by dumb luck picking up a random ticket on the street someone lost.

                    The fun attempting to support all windows applications that have ever existed is dx 1-12 + interactions with opengl and vulkan on 32 bit and 64 bit. Of course does get simpler when you ingore these horrible corner cases like "Windows XP Professional x64 Edition" created.

                    Comment

                    Working...
                    X