Announcement

Collapse
No announcement yet.

DXVK 0.54 Brings Better AMD Performance, Improved GPU Utilization

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

  • #11

    Tremendous results, I'm cheating on the progress in the development of this library. I'm waiting for the Portwine-linux project to include DXVK. This will allow even novice lynx to play games Steam \ BattleNet (windows).
    P.S. Sorry for my English!

    Comment


    • #12
      Originally posted by theriddick View Post
      Not sure why people are so upset with meson & ninja, they function fine under Linux and there must be reasons for using it (perform better?, is easier?, also supported on other platforms?)
      I don't know who is upset about these tools, but there is certainly a lot of hype and false information floating around, which one can blame. For instance did the GNOME project switch from autoconf & make to meson & ninja, because someone was getting major performance gains with it. The claims were real, but the arguments were one-sided. Nobody looked at why they failed as badly as they did with autoconf & make. One can create a mess with any tool if it's only complex enough, and end up regretting it. Whatever the problems were did it not end up as feedback and improvements to autoconf & make or only in a better use of the tools, but instead did they switch to a new build system, which hasn't even matured yet.

      However, this is what any project wants, to get feedback, but young developers always quickly run off at the slightest sign of adversity to do their own thing. They are simply not used to working in diverse teams (they are more used to cherry-picking their friends via Facebook i.e.) and so this sort of thing always creates drama understandably. It's the "Starbucks wrote my name on my cup"-generation or Facebook-generation if you will, but they are the next generation of developers no less. So they do a lot of old stuff in different ways, they isolate themselves from established projects, only to make it their own. (It reminds a bit of the story of the Lost Son.)
      Last edited by sdack; 06-07-2018, 08:38 AM.

      Comment


      • #13
        Originally posted by sdack View Post
        He isn't contributing to WINE. He is contributing to Windows gamers. The toolchain of DXVK however appears to only oppose the WINE project, which uses autoconf & make, C and winegcc, whereas DXVK uses meson & ninja, C++ and mingw. DXVK is a Windows DLL and it is distributed as a binary on GitHub aside its source code. Frankly, solo artists like him who avoid and oppose the established projects such as WINE is what Microsoft is now trying to get their hands on.
        Hmmm... I would disagree that Phillip is not contributing to Wine. He has stated that he doesn't run Windows and clearly DXVK is targeted at Linux+Wine (primarily due to the tier 1 Vulkan support on Linux at the moment). The benefits to Windows users are significantly lower than to Linux users. The former able to chose from 1-2 alternative graphics stacks and the latter currently having no really performant DX11 translation stack (although Wine Staging+Wine-PBA is a start).

        We can argue whether DXVK would have iterated as fast and been as successful, as it has been... If say DXVK had to be subject to Wine's code restrictions (old C standard, etc.) and slow-review process. There are probably some benefits from using a more modern language like C++ and a modern toolchain. Especially so if a developer is more comfortable using a more modern language.

        Because DXVK is cross-platform, bugs can be cross-referenced between say the Linux graphics driver stack and the Windows driver stack. There is a good reason for Nvidia and Mesa developers to be lurking on the DXVK Issue tracker!

        We should not forget that simply DXVK shims above the Wine-Vulkan layer when running on WIne. The developer of the Wine-Vulkan patchset has been actively supporting DXVK.

        What matters to me, as a Wine user, is that DXVK can integrate very easily with existing Wineprefix('s). There will even be a winetricks verb for this (soon I hope!) Despite it being a third party project.



        Comment


        • #14
          Originally posted by sdack View Post
          He isn't contributing to WINE. He is contributing to Windows gamers. The toolchain of DXVK however appears to only oppose the WINE project, which uses autoconf & make, C and winegcc, whereas DXVK uses meson & ninja, C++ and mingw. DXVK is a Windows DLL and it is distributed as a binary on GitHub aside its source code. Frankly, solo artists like him who avoid and oppose the established projects such as WINE is what Microsoft is now trying to get their hands on.
          Nonsense. Wine is also free to start accepting C++ libraries.

          Comment


          • #15
            Originally posted by shmerl View Post
            Nonsense. Wine is also free to start accepting C++ libraries.
            DXVK is free to accept Rust and Fortran code, or to use C for that matter. Only such ignorance doesn't get you very far. You will have to make your own project when you cannot get yourself to conform to the standards of others. There you'll learn that there are others like you who have the same problem but with your project, and it will be you who doesn't accept their contribution. It's a story as old as the bible, mate.

            GitHub is then full of solo artists, who want to redefine everything like the barista who puts another spin on a cup of coffee. And I'm sure Microsoft has thought about it when they bought GitHub. They want this.

            Originally posted by bowya
            We can argue whether DXVK would have iterated as fast and been as successful, as it has been... If say DXVK had to be subject to Wine's code restrictions (old C standard, etc.) and slow-review process.
            That's true. But if you've been following the development then you also know that wine-vulkan couldn't move on, because Vulkan had changed it's license with 1.1. It's lucky that the lawyers removed the problem as quickly as they did, because if not then wine-vulkan and DXVK would have remained at Vulkan 1.0 forever. If DXVK hadn't been built on top of wine-vulkan, then it could already have used features of Vulkan 1.1. So it's not simply an advantage, but an additional layer can be a blessing as well as an impossible hurdle.

            I don't believe it needs much of a discussion, because it should be common knowledge that the closer one can build to the bare metal, the better the results will be. It's the story of Linux after all and also the reason for Vulkan's performance. DXVK is really just a cheap glue, but an effective one and it would have been better if it had been built right into WINE from the start.

            The moment WINE has caught up with its efforts will DXVK disappear. And there is no guarantee for any of the DXVK code to finds its way into WINE. Probably none of it will.
            Last edited by sdack; 06-07-2018, 11:25 AM.

            Comment


            • #16
              Originally posted by sdack View Post
              He isn't contributing to WINE. He is contributing to Windows gamers. The toolchain of DXVK however appears to only oppose the WINE project, which uses autoconf & make, C and winegcc, whereas DXVK uses meson & ninja, C++ and mingw. DXVK is a Windows DLL and it is distributed as a binary on GitHub aside its source code. Frankly, solo artists like him who avoid and oppose the established projects such as WINE is what Microsoft is now trying to get their hands on.
              DXVK has null interest for Windows gamers because D3D11 native drivers will outperform DXVK in the forseeable future.
              Of course, you could gain fractions of FPS by making DXVK a native Wine library but you will instantly make it harder to compare results against Windows Vulkan drivers and to test games that cannot run under Wine, mostly because of DRM issues. Solving problems in games that are not playable under Wine yet still allows to improve the shape of DXVK for Wine gaming because games may share issues that are more easily debuggable in a game or another.
              Plus with a DLL you will not need separate builds for separate platforms e.g. macOS which could potentially benefit from DXVK soon as moltenVK seems to get the job done.
              People have been compiling DXVK as a native Wine library just fine but there were major issues and the measured performance gain was near null IIRC. Making a native library is not going to automagically solve all performance problems, and it's clearly not worth the debugging & maintenance time.

              Just because Wine and DXVK do not rely on the same internal technology doesn't mean they're incompatible and useless to each other. That's nonsense. Meson (and ninja) was picked because it's the less painful and efficient solution. Please get me any result where autotools gets faster and easier to use than Meson. It is only convenient to put releases on GitHub because it's easy to find and use. What's the trouble? Should it be hosted the exact same way as Wine does just in order to look like it's done the same way as Wine? What is the trouble of using proper modern C++ to implement a C++ API? The sole arguments you can find in defense of using exclusively ANSI C is Wine is compatibility as per their wiki, which is mostly a legacy reason that isn't even remotely affected by DXVK.

              Obviously, Wine's work is great, and while wined3d has to adapt to an API that maps less well DXVK has destroyed the entire field in terms of development time. I would personally not doubt the developer's choices in that regard.

              Again, saying that DXVK doesn't contribute to Wine gaming just because they are independent projects that are implemented differently is nonsense, because DXVK is virtually useless for Windows gaming... And it's very obviously targetted at Wine gaming.

              Comment


              • #17
                Not to mention, Wine still depends on C89 maximum, right? That's even less of a solid and reasonable technical choice as much more sane C standards exist and are basically supported on every platform Wine would ever wish to be usable on.

                Comment


                • #18
                  Originally posted by sdack View Post
                  DXVK is free to accept Rust and Fortran code
                  I wouldn't mind Rust code. Fortran - not really. You should stop this condescending tone anyway. Make something better than dxvk to help Linux gaming if you think you can.
                  Last edited by shmerl; 06-07-2018, 11:26 AM.

                  Comment


                  • #19
                    Originally posted by shmerl View Post
                    I wouldn't mind Rust code. Fortran - not really. You should stop this condescending tone anyway. Make something better than dxvk to help Linux gaming if you think you can.
                    I'm not being condescending. You should lighten up, or don't.

                    Originally posted by AsusMagic
                    DXVK has null interest for Windows gamers
                    Sure, and the issues just happen to be all game related by mere accident. First it's a "contribution to WINE". Now it's only a "contribution to WINE gaming". Come on, be honest. You don't see yourself making excuses?

                    It is what it is. It is not a contribution to the WINE project. Contributions to the WINE project happen in form of patches to the code base of WINE, such as wine-vulkan for example. DXVK is a stand-alone project and entirely targeted at Windows games.

                    And yes, Nvidia and Valve help out with DXVK, but they do it for their own agenda. Nvidia does it to make their drivers look good and Valve wants to get more Windows game running under Linux.

                    You haven't even noticed that we aren't talking about game makers writing games native to Linux. This is simply an attempt to get Windows games onto Linux. It is not the other way around and that's what you need to see.

                    I'm thinking you love your Windows games too much.
                    Last edited by sdack; 06-07-2018, 12:38 PM.

                    Comment


                    • #20
                      Originally posted by shmerl View Post
                      I wouldn't mind Rust code. Fortran - not really. You should stop this condescending tone anyway. Make something better than dxvk to help Linux gaming if you think you can.
                      I'm not being condescending. You should lighten up, or don't.

                      Originally posted by AsusMagick
                      DXVK has null interest for Windows gamers
                      Nonsense. Of course it has. It isn't not by accident that it is full of issues of Windows games and tries to fix them. You should be more honest with yourself if you think DXVK isn't meant to make Windows games run on Linux.

                      A contribution to WINE happens in form of patches to the code base of WINE, such as is the case for wine-vulkan. DXVK is a stand-alone project. The author even says DXVK can run under Windows. You'll have to talk to him why this is a feature.

                      This is nothing more than an attempt of getting Windows game onto Linux. Nvidia and Valve are helping out, because they have their own agenda. You forget that we aren't talking about games on Linux written for Linux, but that this is all about getting Windows games onto Linux.

                      You love your Windows games too much is what I'm thinking and now you fail to see what's really in front of you.

                      Comment

                      Working...
                      X