Announcement

Collapse
No announcement yet.

Steam Play's Proton 4.11-5 Released With Fixes & Optimizations

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

  • Steam Play's Proton 4.11-5 Released With Fixes & Optimizations

    Phoronix: Steam Play's Proton 4.11-5 Released With Fixes & Optimizations

    Barely a week since the release of Proton 4.11-4, Valve's stellar Linux crew in cooperation with CodeWeavers have issued Proton 4.11-5 as the latest update to this Wine 4.11 downstream that powers Steam Play for running Windows games on Linux...

    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
    Proton 4.11-5 has a performance optimization when using an input controller while using the AMDGPU kernel graphics driver.
    what.

    Comment


    • #3
      Originally posted by AsuMagic View Post
      what.
      Apparently wine was sending "disable screen saver" events on every controller input and amdgpu can't handle it well. Now it only sends one such event every 5s.

      Comment


      • #4
        Originally posted by Masush5 View Post

        Apparently wine was sending "disable screen saver" events on every controller input and amdgpu can't handle it well. Now it only sends one such event every 5s.
        Maybe that explains why my DS4 has real screwy right stick input when my mouse doesn't.

        Comment


        • #5
          Originally posted by Masush5 View Post

          Apparently wine was sending "disable screen saver" events on every controller input and amdgpu can't handle it well. Now it only sends one such event every 5s.
          This is one of those hilariously stupid issues that remind you how cursed software is.
          I'm not blaming the developers of course.

          Comment


          • #6
            It fixes the amdgpu.dc=1 pageflipping issue about which I complained, it is also fixed for Wine 4.17.
            Simply amazing how Valve ties together loose ends across several aspects of gaming infrastructure for Linux.

            Comment


            • #7
              Originally posted by AsuMagic View Post

              This is one of those hilariously stupid issues that remind you how cursed software is.
              I'm not blaming the developers of course.
              It traces back to there being no sane way to have X.org incorporate joystick/gamepad input into its input idleness calculations without also having it do something unwanted like manipulating the mouse cursor.

              Comment


              • #8
                what does this WINEFSYNC_SPINCOUNT do? how does increasing or decreasing the value affect the games
                not that i know what fsync does either

                Comment


                • #9
                  Originally posted by loganj View Post
                  what does this WINEFSYNC_SPINCOUNT do? how does increasing or decreasing the value affect the games
                  not that i know what fsync does either
                  Good question.

                  It looks like "fsync" is referring to "FUTEX_WAIT_MULTIPLE-based esync".

                  This is a new futex operation, called FUTEX_WAIT_MULTIPLE, which allows a thread to wait on several futexes at the same time, and be awoken by any of them. In a sense, it implements one of the features that was supported by pooling on the old FUTEX_FD interface. My use case for this operation lies in Wine, where we want to implement a similar interface available in Windows, used mainly for event handling. The wine folks have an implementation that uses eventfd, but it suffers from FD exhaustion (I was told they have application that go to the order of multi-milion FDs), and higher CPU utilization. [...] -- https://lkml.org/lkml/2019/7/30/1399
                  I can't find a solid answer on WINEFSYNC_SPINCOUNT, but the meaning of "spinning" in the context of synchronization leads me to suspect that it means something like "how many times to try acquiring the futex before going to sleep". (Going to sleep and being woken by the kernel is expensive when you're working at these time scales, so it can be faster, overall, to burn a little CPU time trying and retrying before going to sleep.)

                  Comment

                  Working...
                  X