Announcement

Collapse
No announcement yet.

DXVK 0.40 Brings Initial Direct3D 11.1 Bits, Other Improvements

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

  • #11
    Originally posted by oiaohm View Post

    Those doing clean installs of fedora now don't get the libtxc_dxtn library. So if you have to reinstall your system will not have it either. Yes you are right when the system does upgrade clean up its also going to by-by. So you are tick down to when it will bite you.

    There are other faults in staging like this. This one is already harming some users.

    This is the trap people go around say hey this works a new user who got a clean install of the distribution installs a package like that it does not work they come to the wine channel on freenode asking why. We have be the ones to point out the library is no more.
    ??? My version is libtxc_dxtn.fc27 and it is there in rpm-fusion-27 repositories. It isn't an .fc26 version that i accidentally didn't remove during the last version upgrade.
    Last edited by artivision; 03-25-2018, 07:45 PM.

    Comment


    • #12
      Originally posted by artivision View Post

      ??? My version is libtxc_dxtn.fc27 and it is there in rpm-fusion-27 repositories. It isn't an .fc26 version that i accidentally didn't remove during the last version upgrade.
      I rechecked my notes

      https://pkgs.org/download/libtxc_dxtn
      Its not part of ubuntu 18.04 . With fedora 27 when I check notes it gone from repositories that people are allowed use that delete obsolete packages this is one of the packages that gets deleted so they don't have access to it. If you have to reinstall from one of those mirrors you will be up the creek.

      Wine mainline has the same functionally but its calling out to opengl to-do it but this means its not dependant on the existence of libtxc_dxfn. Only reason to-do it the way it was for a long time was slightly higher performance less than in fact embedded the code if software mode was being used.

      This is basically a library that should start disappearing it has not been properly maintained since 2015.

      Comment


      • #13
        oiaohm thanks for the insight into wine and staging.
        sounds like wine needs some cleaning and refactoring and staging sounds like a mess.
        What is your recommendations when compiling wine? Should i skip staging or wine-d3d9?
        I don't have ane old libtxc_dxtn on my system.
        Whats a coincident is that i just finnished compiling wine 3.4 with staging and d3d9 on my laptop and it took a long time.

        Comment


        • #14
          Originally posted by Nille_kungen View Post
          oiaohm thanks for the insight into wine and staging.
          sounds like wine needs some cleaning and refactoring and staging sounds like a mess.
          What is your recommendations when compiling wine? Should i skip staging or wine-d3d9?
          I don't have ane old libtxc_dxtn on my system.
          Whats a coincident is that i just finnished compiling wine 3.4 with staging and d3d9 on my laptop and it took a long time.
          Staging is a mess. The current trio of staging maintainers are attempting to clean it up by merging stuff to mainline where they can to make their workload smaller. Of course this means they are not to the point of being able to deal with some of these hidden teeth like the dxtn issue. The prior solo maintainer with over 1100 patches to take care of did not have a chance. Next release hopefully staging will get under the 1000 patch difference but it going to be quite some time before staging is properly clean and the maintainers have time to get into full blown patch rewriting and accepting third party patches. As staging cleans there will be a reduction in the number of programs that need staging to operate.

          This mess could have been avoided if staging had been mainlining patches from the start this would have seen way lighter work load now.

          It does pay to test on mainline wine before attempting anything like galluim nine or staging. Just in case the problem with the program is coming from those projects defects.

          Wine mainline has on going cleaning and refactoring but with the size of wine none of these are quick and simple processes and its a man power problem as well. To be able to merge the staging patches at respectable rate is costing some other development time.

          Comment


          • #15
            Is it likely that DXVK could eventually result in a higher FPS on GNU/Linux with wine than on Windows with native DirectX 11? (assume that on GNU/Linux, the Vulkan drivers are well optimized and the CPU is plenty fast enough to do the extra work of translating DX11 to Vulkan)

            Comment


            • #16
              Unlikely, unless RADV makes some serious gains. And I don't think performance is moving anywhere for NVIDIA drivers, they seem to be in a permanent steady state which is why AMD has been able to catch up a bit.

              Comment


              • #17
                • Nvidia Kepler / Maxwell 1.0 (GTX 600/700 series) now expose Feature Level 11_0
                Btw, these GPUs support Feature Level 11_1 (UAVs in all pipelines).

                Comment


                • #18
                  While I'm watching this with interest, I have mixed feeling if this is a good or a bad thing.

                  It might hurt linux gaming long therm, as porting companies will be impacted, hence less native linux ports.

                  Comment


                  • #19
                    Originally posted by cybertraveler View Post
                    Is it likely that DXVK could eventually result in a higher FPS on GNU/Linux with wine than on Windows with native DirectX 11? (assume that on GNU/Linux, the Vulkan drivers are well optimized and the CPU is plenty fast enough to do the extra work of translating DX11 to Vulkan)
                    Very likely, if DXVK becomes well optimized.

                    Comment


                    • #20
                      Originally posted by xxmitsu View Post
                      While I'm watching this with interest, I have mixed feeling if this is a good or a bad thing.

                      It might hurt linux gaming long therm, as porting companies will be impacted, hence less native linux ports.
                      https://wiki.winehq.org/Wine_History really wine project has been around for a very long time. Wine always has overhead.

                      Wine being made faster will mean porting companies will be forced to put up better quality ports.

                      Comment

                      Working...
                      X