Announcement

Collapse
No announcement yet.

Wine 4.14 Released With The Latest Bits For Running Windows Games/Programs On Linux

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

  • Wine 4.14 Released With The Latest Bits For Running Windows Games/Programs On Linux

    Phoronix: Wine 4.14 Released With The Latest Bits For Running Windows Games/Programs On Linux

    Wine 4.14 was released earlier today as the newest bi-weekly point release for running Windows games and applications on Linux and other operating systems...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    This wine version recognize geforce GTX 1660ti, thanks to kai krakow patch and have too more virtual memory work of remi bernon:

    ntdll: Implement zero_bits parameter in virtual alloc functions.

    Use alloc_area.limit field to limit the search in reserved areas to the
    desired memory range, or call find_free_area to get a pointer to a free
    memory region which matches the zero_bits constraint, then mmap it with
    MAP_FIXED flag.
    And d9vk still working:

    Nascar 15

    Last test with Pentium G3258 @ 4.1ghz + Artic Cooling Alpine 11 Plus



    D9VK With Core i3 8350K Tri-Core @ 5.0ghz + Zalman CNPS 10x Performa+



    Comment


    • #3
      Here's your friendly PSA on how to get the most performance & smoothest frame-rates out of your Linux machine for WINE gaming easily:

      1.
      Install Feral's GameMode daemon and enable & start it like this:
      Code:
      systemctl --user enable gamemoded
      
      systemctl --user start gamemoded
      2.
      For Direct3D 10 &11 games, install DXVK like this:
      Code:
      WINEPREFIX=~/path/to/your/prefix/ winetricks -q dxvk
      3.
      Create a "dxvk.conf" where the game.exe is located & add this to it to enable "Triple-Buffering":
      Code:
      dxgi.numBackBuffers = 3
      4.
      Now, run your game like this:
      Code:
      WINEPREFIX=~/path/to/your/prefix/ WINEDEBUG=-all WINEESYNC=1 DXVK_LOG_LEVEL=none gamemoderun wine game.exe
      NOTE: For vanilla WINE, disregard the WINEESYNC environment variable! (Still, you should really consider WINE-Staging...)

      5. [OPTIONAL, but HUGE bonus points]
      Install a Linux-CK kernel & add this to a "gamemode.ini" file in your ~/.config/ folder:
      Code:
      softrealtime=on
      With the above tweaks, anyone is able to get the best experience possible out of their Linux computers for WINE gaming (including our new friends; those who just switched over from Windows)!

      Enjoy your WINE gaming like never before, my fellow Linux advocates!

      PS:
      Always remember, in the not so distant future our Operating System will be the absolute gold standard when it comes to gaming!

      Comment


      • #4
        Might as well add some for the Wine Staging users:

        Add to /etc/security/limits.conf
        Code:
        @$YOURGROUPNAME       -       rtprio          90      #My group gets priority except for root.
        @$YOURGROUPNAME       -       nice            -10     #My group gets the lowest nice next to root
        $YOURUSERNAME        -       rtprio          90       #My user gets priority except for root.
        $YOURUSERNAME        -       nice            -10      #My user gets the lowest nice next to root
        #these one's aren't needed for Wine but I'm including the rest of my nice tweaks
        *                hard    nice            -5        # Prevent non-root users and not me from running a process at maximum nice.
        root             hard    nice            -20        # Allows root to run a process at maximum nice to fix the system when unresponsive.

        I have these set globally in /etc/environment since I normally only run one Wine thing at a time.
        Works just fine prepended like WINEPREFIX
        Code:
        export STAGING_RT_PRIORITY_SERVER=90
        export STAGING_RT_PRIORITY_BASE=90
        Max the user nice limit and give full IO priority.
        Code:
        $PREPENDS nice --10 ionice -c2 -n7 wine game.exe
        note the two dashes with nice, one dash gives positive priority which defeats the purpose
        I've found that I don't need gamemode with the nice and ionice tweaks with BMQ or PDS and shedutil. As much as I like gamemode and what it wants to achieve, all the log spam in the terminal that comes with it gets old fast.

        I'll also add that, after doing the above limits edits, tweaking the launch parameters in KDE Menu Editor to prepend "nice --5" to the existing command really helps mitigating that program from GUI lag when doing compiles.

        Prepending "nice -5 ionice -c3" before a compile will really, really help with compiler GUI lag but it also has a noticeable effect on compile times -- takes my usual 20 minute kernel compile times to 21-22 minutes. I consider it a worthwhile compromise for desktop users. Also useful to prepend that before applications that consistently cause GUI lag (like CKAN).
        Last edited by skeevy420; 17 August 2019, 11:46 AM.

        Comment


        • #5
          Originally posted by pinguinpc View Post
          This wine version recognize geforce GTX 1660ti, thanks to kai krakow patch and have too more virtual memory work of remi bernon:



          And d9vk still working:

          Nascar 15

          Last test with Pentium G3258 @ 4.1ghz + Artic Cooling Alpine 11 Plus



          D9VK With Core i3 8350K Tri-Core @ 5.0ghz + Zalman CNPS 10x Performa+



          Please test Resident Evil 2 (remake)

          Comment


          • #6
            Originally posted by skeevy420 View Post
            Might as well add some for the Wine Staging users:

            Add to /etc/security/limits.conf
            Code:
            @$YOURGROUPNAME - rtprio 90 #My group gets priority except for root.
            @$YOURGROUPNAME - nice -10 #My group gets the lowest nice next to root
            $YOURUSERNAME - rtprio 90 #My user gets priority except for root.
            $YOURUSERNAME - nice -10 #My user gets the lowest nice next to root
            #these one's aren't needed for Wine but I'm including the rest of my nice tweaks
            * hard nice -5 # Prevent non-root users and not me from running a process at maximum nice.
            root hard nice -20 # Allows root to run a process at maximum nice to fix the system when unresponsive.

            I have these set globally in /etc/environment since I normally only run one Wine thing at a time.
            Works just fine prepended like WINEPREFIX
            Code:
            export STAGING_RT_PRIORITY_SERVER=90
            export STAGING_RT_PRIORITY_BASE=90
            Max the user nice limit and give full IO priority.
            Code:
            $PREPENDS nice --10 ionice -c2 -n7 wine game.exe
            note the two dashes with nice, one dash gives positive priority which defeats the purpose
            I've found that I don't need gamemode with the nice and ionice tweaks with BMQ or PDS and shedutil. As much as I like gamemode and what it wants to achieve, all the log spam in the terminal that comes with it gets old fast.

            I'll also add that, after doing the above limits edits, tweaking the launch parameters in KDE Menu Editor to prepend "nice --5" to the existing command really helps mitigating that program from GUI lag when doing compiles.

            Prepending "nice -5 ionice -c3" before a compile will really, really help with compiler GUI lag but it also has a noticeable effect on compile times -- takes my usual 20 minute kernel compile times to 21-22 minutes. I consider it a worthwhile compromise for desktop users. Also useful to prepend that before applications that consistently cause GUI lag (like CKAN).
            Notice the focus on easily?

            Also, why aren't you using "WINEDEBUG=-all WINEESYNC=1 DXVK_LOG_LEVEL=none"?

            Another problem is the use of 'schedutil'!
            At least on INTEL, it roughly equals P-State's 'powersave'!
            Have you compared it to the 'performance' governor?

            Comment


            • #7
              Originally posted by Linuxxx View Post

              Notice the focus on easily?

              Also, why aren't you using "WINEDEBUG=-all WINEESYNC=1 DXVK_LOG_LEVEL=none"?

              Another problem is the use of 'schedutil'!
              At least on INTEL, it roughly equals P-State's 'powersave'!
              Have you compared it to the 'performance' governor?
              I consider editing a file to be easy. It's also a necessary step to use the nice/priority tweaks I listed.

              Why would I add WINEDEBUG, etc when they were covered one post up? I was just adding some additional tweaks that can be done with Wine Staging.

              On my system with dual Westmeres, shedutil keeps it at max freq when I'm under any form of load and drops it back down when not. Gaming wise, I notice no difference between it and performance.

              Since they haven't been mentioned yet...and Google is your friend...

              Code:
              Wine: WINEFSYNC=1, PBA_ENABLE=1,  WINE_LARGE_ADDRESS_AWARE=1, STAGING_SHARED_MEMORY=1
              
              DXVK: DXVK_ASYNC=1 (use caution, can trigger anti-cheat software and cause bans)
              
              Proton: PROTON_USE_D9VK=1, PROTON_NO_FSYNC=0
              If y'all are using an FSync enabled Wine (yes, that exists), you only need to use WINEFSYNC=1 because that'll fallback to Esync when Fsync isn't available. Running both at the same time has reports of bad things happening. Most of the above aren't in Wine or DXVK by default and requires patching the sources and compiling to use them.

              Comment


              • #8
                Originally posted by Linuxxx View Post

                PS:
                Always remember, in the not so distant future our Operating System will be the absolute gold standard when it comes to gaming!
                Which will never happen as long as there is a single config file an user must edit manually.

                Comment

                Working...
                X