Announcement

Collapse
No announcement yet.

A Look At Linux Gaming Performance Scaling On The Threadripper 2950X

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

  • #11
    NUMA is clearly making a difference here, keeping fragmentation of memory and threads to a minimum. How much of a difference might be interesting to see, if not this test, when perhaps a future 2990WX test.

    Comment


    • #12
      Originally posted by torsionbar28 View Post
      We have intel to thank for this quad-core performance stagnation.
      can you substantiate that claim?

      Comment


      • #13
        Originally posted by Dr. Righteous View Post
        Wow.
        I like computer gaming as much as the next guy but since most game development is targeted at consoles, scaling across multiple cores isn't given much priority. So for the subject of gaming. Meh. But what is exciting is the boon this is to content creators, videographers, and the like that need as much crunching power as they can get.
        If you are working under looming dead lines to render out computer graphics or 4k (or 8k) video the more core/threads the better. The codecs workload scales smoothly across multiple cores. The boon for game development is Vulkan but unfortunately most developers are ignoring it since they don't want to abandon old coding paradigms.
        The consoles with 8 weak cores? Why wouldn't that be a priority to get the most benefit from those? I don't get your point.

        Comment


        • #14
          Originally posted by clintar View Post
          The consoles with 8 weak cores? Why wouldn't that be a priority to get the most benefit from those? I don't get your point.
          I was about to ask the same question but you beat me to it.

          That said, I probably would have replaced "weak" with something like "low power" since they are mostly our cores

          Comment


          • #15
            Unigine Superposition v1.0 and X-Plane 11 is nice to see, finally.
            GREAT work AMD Mesa team.
            RADV is on track, too.

            Comment


            • #16
              Originally posted by nuetzel View Post
              Unigine Superposition v1.0 and X-Plane 11 is nice to see, finally.
              GREAT work AMD Mesa team.
              RADV is on track, too.
              ??? Been benchmarking Superposition since launch day and X-Plane 11 has been part of PTS for months (and before that XPlane 9).
              Michael Larabel
              http://www.michaellarabel.com/

              Comment


              • #17
                Originally posted by Michael View Post

                ??? Been benchmarking Superposition since launch day and X-Plane 11 has been part of PTS for months (and before that XPlane 9).
                I know, but look at the numbers: AMD Vega 64 (OSS) vs Nvidia 1080 Ti (closed)

                Comment


                • #18
                  Originally posted by schmidtbag View Post
                  I'm surprised it scaled up so nicely - I thought the 16 and 32 core configurations were going to really suffer in performance, but apparently not. It's pretty obvious that 32 cores would run slower than 16 (due to the dies without direct memory access, in the event they ever get utilized in the game) but the performance losses as a result really weren't that bad.
                  I thought the same thing. Looks like having 8 cores is actually beneficial for linux gaming at the moment, and more didn't hurt anything. That's not so bad, all things considered.

                  Comment


                  • #19
                    This notion that "games don't scale past 4/8 threads" is an aging meme. It's been ages since threading was explicitly managed by the programmer(s). Consoles have had 6+ hardware threads since Xbox 360 / PS3, *and* been capable of GPU compute -- everything migrated to job-pools then; sophisticated ones too, since the mix of compute resources was so different across PC/PS3/360. Today, a typical game might have a few explicit threads (rendering, simulation, I/O, networking), but they kick most of the heavy lifting out to the job-pool.

                    The job pool itself is infinitely scalable. What you're actually seeing when your 12-plus-core, hyperthreaded CPU doesn't make your games any faster is *not* that games code is architected to only utilize the 4-8 threads that have been mainstream for so long (in other words, that thread availability/concurrency itself is the limiting factor), but that the total experience of the game itself has been scaled with what those 4-8 core mainstream systems have been capable of running (in other words, the game design--rather than the code--is only asking for 4-8 threads worth of work.)

                    And if you see that your game only spikes those 4-8 threads in task manager, that's either the job pool and/or your OS's thread scheduler being clever enough to realize that those 4-8 newer, faster cores in your beefy CPU are more than capable of keeping up, and it's better to keep the extras in a low-power/low-thermal state.

                    All that needs to happen is that publishers and developers simply need to become comfortable asking for more than what 4-8 bygone-era threads could provide. The plumbing is already in place. It's all about install-base of higher-core-count CPUs now.

                    Comment


                    • #20
                      Originally posted by ravyne View Post
                      This notion that "games don't scale past 4/8 threads" is an aging meme. It's been ages since threading was explicitly managed by the programmer(s). Consoles have had 6+ hardware threads since Xbox 360 / PS3, *and* been capable of GPU compute -- everything migrated to job-pools then; sophisticated ones too, since the mix of compute resources was so different across PC/PS3/360. Today, a typical game might have a few explicit threads (rendering, simulation, I/O, networking), but they kick most of the heavy lifting out to the job-pool.

                      The job pool itself is infinitely scalable. What you're actually seeing when your 12-plus-core, hyperthreaded CPU doesn't make your games any faster is *not* that games code is architected to only utilize the 4-8 threads that have been mainstream for so long (in other words, that thread availability/concurrency itself is the limiting factor), but that the total experience of the game itself has been scaled with what those 4-8 core mainstream systems have been capable of running (in other words, the game design--rather than the code--is only asking for 4-8 threads worth of work.)

                      And if you see that your game only spikes those 4-8 threads in task manager, that's either the job pool and/or your OS's thread scheduler being clever enough to realize that those 4-8 newer, faster cores in your beefy CPU are more than capable of keeping up, and it's better to keep the extras in a low-power/low-thermal state.

                      All that needs to happen is that publishers and developers simply need to become comfortable asking for more than what 4-8 bygone-era threads could provide. The plumbing is already in place. It's all about install-base of higher-core-count CPUs now.
                      Partially correct. The *real* reason games aren't scaling beyond a few threads is because only a handful of threads do any real amount of work.

                      I've actually dug into performance metrics, and it's pretty much always the same: The main executable thread is always one of the major threads, the rest are all render threads. Whether you get one or two "heavy" threads or seven-eight "lighter" threads is largely dependent on your choice of graphical API.

                      Basically: You have more CPU cores then threads doing measurable amount of work. Sure, games *use* 70-80 threads nowadays, but only 2-10 or so do any measurable amount of processing.

                      Comment

                      Working...
                      X