No announcement yet.

Linux 3.7 + Mesa 9.1-devel Running On Ubuntu 12.10

  • Filter
  • Time
  • Show
Clear All
new posts

  • Linux 3.7 + Mesa 9.1-devel Running On Ubuntu 12.10

    Phoronix: Linux 3.7 + Mesa 9.1-devel Running On Ubuntu 12.10

    For those Intel Sandy Bridge owners wondering if there's any worthwhile performance improvements when upgrading from Ubuntu 12.10 with Mesa 9.0 and the Linux 3.5 kernel up to the early Mesa 9.1-devel state with the Linux 3.7 Git kernel, here are some benchmarks...

  • #2
    Doom3 36 fps

    Doom3 36 fps even at low setting, means that the opensource drivers are out of the question for most people who want to play the game.
    It runs really really well on my low-jitter kernel, with the closed source drivers though.

    Peace Be With You.


    • #3
      You can play Doom 3 with those frames actually, but you also fail to consider the fact that those are from an Intel IGP. Please read the article rather than using it merely as an excuse to pimp an idea.


      • #4
        You can play doom3 at 36 fps? Not really. You can get an idea of it, but the exhilaration of low-jitter 72fps it will not have.

        But it was intel. I assumed it was opensource nvidia since the fps was so low.

        So intel gfx performs that poorly. Well I appreciate the benchmark anyway.


        • #5
          PS: Even my mac mini from 2010 plays HL2 ep2 well, and that is much newer. Thats an nvidia 320m processor. (2.4ghz core2duo). Carmack says doom 3 still stresses a lot of hardware, because of the 3 passes he uses to render stuff. Which is also why I linked to my low-jitter kernel, because it runs doom 3 well. (Better than windows).


          • #6
            Doom 3 was set for 30 fps on console, so yes it is playable.


            • #7
              Stunt Car Racer on amiga500 was also playable. It was 5 fps.


              • #8
                Originally posted by Paradox Uncreated View Post
                Stunt Car Racer on amiga500 was also playable. It was 5 fps.
       framerates aren't necessarily important?


                • #9
                  You can see for yourself.


                  • #10
                    I guess the Doom3 benchmarks which are not using ultra settings have got rendering issues. I tested mesa 8.0.4 and 9.0 and got em. The problem you see easyly in the timedemo when the flashlight is used:


                    I tested sandy and ivy bridge, doom3 native and dhewm3.


                    • #11
                      I notice it says 61 FPS though - what do you usually get?


                      • #12
                        I forgot the exact numbers, but they are in the lower 20s @ 1920x1200 with ivy bridge, dhewm3 64 bit is a bit slower than doom3 32 bit. sandy bridge hd 2000 (i7-2600) has 29.x fps using ultra settings @ 1280x1024 (which are default for dhewm3). Now i play the game a bit with nvidia gt630 (kepler) @ 1920x1200 there i get easyly 60 fps. You can test it like that without pts:
                        doom3 +set r_mode -1 +set r_customwidth 1920 +set r_customheight 1200 +set com_showfps 1 +timedemoquit demo1


                        • #13
                          Originally posted by Paradox Uncreated View Post
                          You can play doom3 at 36 fps? Not really.
                          Have you ever even played Doom3? It runs just fine at 30fps - as long as that's the minimum, and it's not consistently dipping down into the teens.

                          Doom3 isn't a twitch shooter that requires 60fps.


                          • #14

                            Admittedly I didn`t read that article the first time, but who even makes any h/w that runs a game from 2004, at 30fps. I am looking back at the article to see if there was anything I missed.

                            Doom 3, at LOW setting 1280x1024 - 36/38 fps.

                            What is this chipset? Something made for windows GUI? Sandy Bridge = worse performance than my mac mini?


                            In January 2011, the Sandy Bridge processors were released introducing the "second generation" HD Graphics:

                            i5 = the 6 "execution units" version?

                            36 fps. lol. I don`t even think 72fps w/ jitter is good. I have reduced it on my local kernel though, so that most of it is gone. And then it plays great, and it is one of my favorite games, along with HL2.

                            Doom 3 is also very jitter sensitive, so it is great to have it playing well on my computer. Carmack says it uses 3 passes for rendering, and some say it even can look better than Rage, where he only uses one. So it is a bit interesting to tweak my computer for it, and reducing jitter there, seems to improve overall computing also.

                            Then with a GTX280 and a core2duo 2.5ghz, it plays extremely close to perfect, 72fps at max setting + 2xMS. On my current setup, I noticed just one "jitter" with some hd-activity, which maybe even that can be removed.

                            If you have played it low-jitter and 72fps you think everything else is a bit lame.

                            HL2 in wine, also plays much better on a low-jitter kernel, nearly as good as my optimized windows install (~100 threads). Also ofcourse HL2 on that windows, plays very smooth. Doom 3 on windows though, even highly tweaked is much to jitter-sensitive to play as good as the linux-version.

                            I have also enabled the "jittered subsampling" (r_jitter = 1), which actually adds jitter, to it, but this kind of jitter increases percieved resolution. Which will not work well with low fps. Interesting option, which one can build some ideas on.

                            Peace Be With You.


                            • #15
                              Not to bash your work on configuring CFS, but I think the behavior you're looking for in CFS has already been attained in BFS. For instance, when BFS was still in development, I worked with Con to make sched_yield always take precedence over other loads. This makes iD Tech engines (Quake 3, Doom 3), and games like Savage 2, all run "smooth". This is very important since almost all applications using sched_yield to process frames are all 3D games that rely on low latency frame rendering. A good game to observe this behavior is Warsow - try playing this game on BFS and CFS with your adjustments with a high definition youtube video playing on a second monitor. This game is especially sensitive to anomalies in poor behavior to sched_yield calls.

                              Smooth is defined as no jitter, kind of like what Google was trying to attain with Project Butter, where the application rendering animated graphics does not suddenly lose frames due to another process preempting the process rendering the screen.

                              You can check some work done to achieve this a bit further on ( is currently down) under the zen-tune branch. In this branch, we create profiles where we reduce the context switching time from 6ms+ on CFS to 3ms, and also set BFS' 6ms round robin interval down to 3ms. There's no fancy code changing here, only new defaults.

                              Direct commit link for Linux 3.5:

                              A notice to beware for users with old CPUs though, rapid context switching can increase L2 cache misses on older generation processors. This is especially evident on android phones, where setting the rr_interval below 8ms on the Snapdragon CPU available on the Nexus One causes poor raw throughput that's required to run things like Gameboid to emulate GBA games. This throughput loss is immeasurable on new CPUs like the Core 2 Duo, however. I did a few benchmarks on my laptop and couldn't find a difference outside a measurement of error (below 1-0.5%).

                              An FYI for any Debian users here, all these changes are already available under the Liquorix kernel, which uses the newest Zen Kernel sources.