Announcement

Collapse
No announcement yet.

It Appears FUTEX2 Will Land For Linux 5.16

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

  • #21
    Originally posted by Soul_keeper View Post
    The windows devs are laughing to the bank.
    Maybe, but I don't see how these developments could have any effect on that?

    Comment


    • #22
      Originally posted by Soul_keeper View Post
      I can't say I object to this, in particular, as just another optional kernel config choice.
      The trend however is concerning.
      I guess we can wave bye to native linux games going forward. Linux is just becoming a big windows emulator now. The windows devs are laughing to the bank.
      It is bad enough that steam is a giant sandbox/container of binaries, it's essentially a precompiled/custom wine on steroids.
      Adding new features to the Linux kernel is not what is driving down the presence of native games, it's the fact that our userbase on the home desktop is in the low 1%.

      Comment


      • #23
        Originally posted by Soul_keeper View Post
        I can't say I object to this, in particular, as just another optional kernel config choice.
        The trend however is concerning.
        I guess we can wave bye to native linux games going forward. Linux is just becoming a big windows emulator now. The windows devs are laughing to the bank.
        It is bad enough that steam is a giant sandbox/container of binaries, it's essentially a precompiled/custom wine on steroids.
        Steam does use containers around native Linux binaries as well. Started with chroot in fact.

        The reality is Linux is 1% percent market share. Now if you are porting a game engine to Linux that uses WaitForMultipleObjects without FUTEX2 support you have insane uphill battle porting. This WaitForMultipleObjects porting problem been a common cause of second rate Linux native game ports for a long time. There are a lot of systems that you find that sun and others made that kind of suggest WaitForMultipleObjects is possible without extending the features the Linux kernel provides the problem is when you get into real world usage you find that they are lot more unpredictable and problem causing. Yes wine version WaitForMultipleObjects has the habit of blowing out file usage. Sun version of WaitForMultipleObjects has the habit of causing lock stalling result in game stutters. Others cause major memory leaks and the list goes on. Yes all these different issues have result in many games have a Linux native port released only to finally be dropped use the windows binary because Linux at 1% market share does not justify solving this problem in the cost of man hours. So by using the windows binary the game developer gets to blame the problem on wine/proton.

        So this futex2 is a change that could increase the Linux native games in future by making porting to Linux of programs that use WaitForMultipleObjects not a pure disaster. Yes native Linux binary using futex2 syscall directly instead of by wine or proton will have lower overhead so higher performance.

        Some of getting Linux native games will be making sure code is able to ported without causing the developer doing the ports insane headaches of trying multi different solutions to the problem that all don't work in different ways so making them give up because it too costly. Yes having items like flatpak and snap and steam using containers is also part of this.

        Comment


        • #24
          Damn I was hoping for the variable size futexes. Still need a 64bit version of FUTEX_WAKE_OP

          Comment


          • #25
            Originally posted by oiaohm View Post
            Yes having items like flatpak and snap and steam using containers is also part of this.
            Pressure Vessel was valve taking some things into their own hands, I believe. This is another case. I'm just glad they have enough reason to.

            Comment


            • #26
              Originally posted by doomie View Post
              Pressure Vessel was valve taking some things into their own hands, I believe. This is another case. I'm just glad they have enough reason to.
              Pressure Vessel is Valve second attempt at the problem. First attempt with valve libcapsule work with chroot. This has been quite a old problem.


              libcapsule is still around for segregated dynamic linking. This does applications use this to be more portable at the cost of shipping with runtime.

              Yes making a binary that is stable portable between Linux distributions has a stack of things that must be done. Interesting enough lot of these things are like Microsoft SXS feature.
              Last edited by oiaohm; 11 October 2021, 12:31 PM.

              Comment

              Working...
              X