Announcement

Collapse
No announcement yet.

Wine 6.14 Implements More 32-bit To 64-bit Thunks, Updated Mono

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

  • #11
    Originally posted by perpetually high View Post

    Agreed. Have you done much benchmarking with futex2? I haven't done much gaming lately but I still add it in. Are you finding it really helps a lot? Or are you referring to just the concept of futex2 in general.
    I was talking about it in general terms, since I actually never tried the FUTEX patches myself, as I tend to just stick with Ubuntu's »lowlatency« mainline kernels.

    As for gaming, about the heaviest one I recently tried on my HTPC (Intel i5-6500 + nVidia 1650) was probably "Battlefield 1", and I was actually amazed by the performance I was getting with all high settings @ 1080p (Direct3D 11 --> DXVK).
    This was with Proton-GE + no eSync, since it performed smoother this way. Plus all Intel Swiss-cheese mitigations still enabled, mind you.

    On a related note, for anyone using RPCS3 with Intel's broken TSX instructions still set to enabled:
    Since the recent µ-code update you're better off by disabling them entirely in the settings menu, because this way performance actually improves nowadays.

    Shame that my CPU keeps rotting away; nevertheless, it really speaks volumes for Linux in general that it still remains rather functional in spite of these messy flaws!

    Comment


    • #12
      Originally posted by Linuxxx View Post

      I was talking about it in general terms, since I actually never tried the FUTEX patches myself, as I tend to just stick with Ubuntu's »lowlatency« mainline kernels.

      As for gaming, about the heaviest one I recently tried on my HTPC (Intel i5-6500 + nVidia 1650) was probably "Battlefield 1", and I was actually amazed by the performance I was getting with all high settings @ 1080p (Direct3D 11 --> DXVK).
      This was with Proton-GE + no eSync, since it performed smoother this way. Plus all Intel Swiss-cheese mitigations still enabled, mind you.

      On a related note, for anyone using RPCS3 with Intel's broken TSX instructions still set to enabled:
      Since the recent µ-code update you're better off by disabling them entirely in the settings menu, because this way performance actually improves nowadays.

      Shame that my CPU keeps rotting away; nevertheless, it really speaks volumes for Linux in general that it still remains rather functional in spite of these messy flaws!
      I see. Also - You can turn off TSX through grub parameters by the way: tsx=off, unless you were talking about something different

      And yeah, our CPU's are taking a hit but they don't *need to* (and even going back to Sandy, Ivy), they're just really solid chips pound-for-pound. My core is just as good as any other core is the way I look it. And I got 4 of them. Some apps don't even use more than 1 core, so the rest of everything the new Ryzen and Intel chips provide is almost moot. Especially when you consider I run with mitigations=off, which I still feel is very sensible for a desktop user, but obviously not for a server or cloud provider, but everyone needs to make the decision themselves and not be too preachy either way

      The reason also why I optimize the crap out of everything is because a) I can and b ) I can. How cool is that? Mac won't let me do that, Windows won't let me do that. Linux sodes. I can change literally anything. And then build with -march=haswell and I'm taking the shortest path in execution code, that's the way I look at it. By the way Linuxxx, definitely give the script a chance this weekend, just gotta run ./build_kernel.sh. You've given me good tips before too, so thank you. Cheers

      edit: I could even argue Polaris provides the best AMD experience on Linux, even over all the new Navi cards. Very polished experience, no hiccups, predictable, stable, can be overclocked/underclocked, you name it.
      Last edited by perpetually high; 30 July 2021, 10:59 PM.

      Comment


      • #13
        - 32->64-bit thunks implemented in WOW64 dll.
        what this mean ?

        Comment


        • #14
          Aryma this is necessary if you want to run 32-bit Wine applications on a pure 64 bit Linux system. A number of Linux distros are reducing or removing 32-bit i386 compatibility on their amd64 port. Same for macOS.

          https://www.phoronix.com/scan.php?pa...ntu-20.04-Debs

          Comment


          • #15
            Originally posted by loligans View Post
            Does anyone know how much of the Windows API/ABI is implemented in Wine? I don't know how I could find this out, Google search isn't giving me any useful results.
            This is a pretty meaningless value you are asking for. It makes little sense to quantify a certain percentage, because it has no practical use. One application may need 45% of the API to be present, another may need 85% of it, and WINE could implement 99% of all. Yet, if only one function is missing might an application not work correctly or not start at all. Chances are WINE in fact implements all known API functions, but does not implement every feature of every function and implements a few functions only as empty stubs.

            It makes more sense to test each application to see whether it works , just as you need to do with the different versions of Windows themselves, because these do not implement all of the "Windows API/ABI" as you have put it, but a subset of what Microsoft has developed throughout the history of Windows.

            Here are some numbers for you though...
            • WINE currently implements 930 DLLs.
            • The WINE Application Database lists 5,103 applications rated as "Platinum", which is the highest rating for how well an application works with WINE.
            • 4,278 applications are rated with "Gold".
            • 3,747 applications are rated with "Silver".
            • 3,042 applications are rated with "Bronze".
            • The Steam Proton database lists 15,471 games working with WINE (plus DXVK plus modifications by Steam).
            • The Lutris database lists 13,468 games.

            Hope this helps.
            Last edited by sdack; 31 July 2021, 03:34 AM.

            Comment


            • #16
              Wine still needs 32 bit Os libraries to work?

              Comment


              • #17
                Originally posted by Azrael5 View Post
                Wine still needs 32 bit Os libraries to work?
                https://github.com/AndreRH/hangover

                Yes wine still need 32 bit host libraries. Work is under way to remove that requirement but its still not going to be something near term. Its most likely at least 2 to 3 years out still. There is a lot of complexity thunking from 32 bit to 64 bit and a lot more complexity going win16 to 64 bit. Yes all that complexity equals some very creative bugs.

                Comment


                • #18
                  Originally posted by oiaohm View Post

                  https://github.com/AndreRH/hangover

                  Yes wine still need 32 bit host libraries. Work is under way to remove that requirement but its still not going to be something near term. Its most likely at least 2 to 3 years out still. There is a lot of complexity thunking from 32 bit to 64 bit and a lot more complexity going win16 to 64 bit. Yes all that complexity equals some very creative bugs.
                  If wine had already integrated the 32 bit Os libraries needed it would't solve this problem? Linux oses need the 32 bit platform be enabled?

                  Comment


                  • #19
                    Originally posted by Azrael5 View Post
                    If wine had already integrated the 32 bit Os libraries needed it would't solve this problem? Linux oses need the 32 bit platform be enabled?
                    Its not possible to-do that there are two reasons.
                    1) Reasons are items like samba and so on. You need to use the host provided libraries to perform particular functions or applications will not work right. Like if you are expecting a network access to use the same network login as the user used you cannot use a 100 percent independent library set. So you either have to use host 32 bit library in places or have a system to thunk to the 64 bit library. Thinking from 32 bit to 64 bit is not exactly the most nice process.
                    2) when you build a distribution without 32 bit libraries you can disable the kernels 32 bit support. This is why qemu comes required. Please note wine is the only remaining user of the Linux kernel 16 bit protected mode support as well.

                    The wine hangover project is working on all the parts required to deal with 32 bit platform removal. Yes win16 support from the start wine had to be designed to thunk that from 16 to 32 because the Linux kernel and user space does not provide any 32 bit libraries.

                    Yes the number of host libraries that wine depend on for different application use cases is why attempts to containerise generic wine has run into so many problems and does normally result in many different business applications that would work under generic wine straight on the distribution not working.


                    Comment


                    • #20
                      Originally posted by oiaohm View Post

                      Its not possible to-do that there are two reasons.
                      1) Reasons are items like samba and so on. You need to use the host provided libraries to perform particular functions or applications will not work right. Like if you are expecting a network access to use the same network login as the user used you cannot use a 100 percent independent library set. So you either have to use host 32 bit library in places or have a system to thunk to the 64 bit library. Thinking from 32 bit to 64 bit is not exactly the most nice process.
                      2) when you build a distribution without 32 bit libraries you can disable the kernels 32 bit support. This is why qemu comes required. Please note wine is the only remaining user of the Linux kernel 16 bit protected mode support as well.

                      The wine hangover project is working on all the parts required to deal with 32 bit platform removal. Yes win16 support from the start wine had to be designed to thunk that from 16 to 32 because the Linux kernel and user space does not provide any 32 bit libraries.

                      Yes the number of host libraries that wine depend on for different application use cases is why attempts to containerise generic wine has run into so many problems and does normally result in many different business applications that would work under generic wine straight on the distribution not working.

                      it's very interesting. So, my question deals with the possibility to realize a gaming recompiler able to convert 32 bit libraries in 64 bit libraries. A 64bit program converter. A program which acts as video converters act.

                      Comment

                      Working...
                      X