Announcement

Collapse
No announcement yet.

Valve Planning To Carry Mesa GL Thread Feature On SteamOS, Per-Game Features

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

  • Valve Planning To Carry Mesa GL Thread Feature On SteamOS, Per-Game Features

    Phoronix: Valve Planning To Carry Mesa GL Thread Feature On SteamOS, Per-Game Features

    It's looking like Valve will begin carrying some out-of-tree patches for their Mesa packages they use on SteamOS...

    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
    it does make sense for valve in making profiles as their highest interest is a smooth experience.
    as for developers it does not strike me to be ideal.
    they could make a list that is downloadable for instance and if its there it will take effect, but that should be valves job. not mainline devs.
    but thats just MHO

    Comment


    • #3
      The problem with Valve is that they are not releasing 64 bit verison of Steam which is unacceptable in 2017... I built kernel without 32 bit support and im not going to waste my disk space by installing multilib(32 bit versions of drivers and other libs)...

      Comment


      • #4
        Originally posted by ArchFanatic View Post
        The problem with Valve is that they are not releasing 64 bit verison of Steam which is unacceptable in 2017... I built kernel without 32 bit support and im not going to waste my disk space by installing multilib(32 bit versions of drivers and other libs)...
        That's a separate discussion that has nothing to do with the current topic.

        Anyway, I'm fine with glthread as long as it's disabled by default and only for certain whitelisted apps that are confirmed to run well with it.

        But at the same time, I don't think it's worth merging it if it causes crashes. Non-ideal performance is fine, but crashes aren't.

        Comment


        • #5
          Originally posted by ArchFanatic View Post
          The problem with Valve is that they are not releasing 64 bit verison of Steam which is unacceptable in 2017... I built kernel without 32 bit support and im not going to waste my disk space by installing multilib(32 bit versions of drivers and other libs)...
          Multilib is required anyway for native runtime support of 32-bit games.

          Comment


          • #6
            The problem with Valve is that they are not releasing 64 bit verison of Steam which is unacceptable in 2017... I built kernel without 32 bit support and im not going to waste my disk space by installing multilib(32 bit versions of drivers and other libs)...
            Your problem. Based on pragmatic reasoning multilib environments will still be the way to got for some time going on.

            Comment


            • #7
              Originally posted by ArchFanatic View Post
              The problem with Valve is that they are not releasing 64 bit verison of Steam which is unacceptable in 2017... I built kernel without 32 bit support and im not going to waste my disk space by installing multilib(32 bit versions of drivers and other libs)...
              Yeah, that's like 2-4 GiB, totally going to make a huge difference in any kind of half-modern mass storage device.

              Comment


              • #8
                Why do this and not integrate wine into steam? You come to the same ethical choice.

                Comment


                • #9
                  Originally posted by Hibbelharry View Post

                  Your problem. Based on pragmatic reasoning multilib environments will still be the way to got for some time going on.
                  That's a circular reasoning. 32 bits should be dropped ASAP (and I say this while regularly playing Steam games on my laptop, which has a 32 bits only Atom).
                  Of course, having a way to play old 32 bits game would be nice, but that's something I'm prepared to do without.
                  The major blocker will probably be middleware, however.

                  On the topic of glthread, I am all for its inclusion (if the code quality is good enough). And if the current code causes a lot of regressions, a whilelist sounds sensible. Maybe the proper solution is to create a new OpenGL extension to enable or disable it?
                  I do not see this as extremely game-specific. That's not hand-optimizing shaders for some games. But it would be nice if it could be made so that it works reliably with every game.

                  Comment


                  • #10
                    Dropping 32bit support is not happening for years to come.

                    Comment

                    Working...
                    X