No announcement yet.

Linux 3.7 + Mesa 9.1-devel Running On Ubuntu 12.10

  • Filter
  • Time
  • Show
Clear All
new posts

  • #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.


            • #16
              Damentz, I have already tried BFS, and I appreciate that you understand jitter, and make some observations on it.
              However BFS performs worse than CFS here. It was actually only with CFS and 90hz timer, and quite a high CFS granularity that I got the jitterbehaviour I wanted. (smooth low constant jitter tuned to a psychovisual profile of "natural" due to the fact that some low-jitter is interpreted as natural by the senses.) And this is also a tuning, that favours throughput.

              At the moment, the opening of doom3 runs completely smooth, where before and with BFS there was some jitter. From playing the game, I have only seen one occasion where there was a loss of frame, "one jitter". Also, daemons etc seems to make a slight difference, and I have taken what I have learned, to thoughts on improvements of CFS.

              For instance, several runqueues, where daemons can be put on queue 2, so you have |1.mainapp||2.daemon1|1.mainapp|2.daemon2|1.mainpp |2.daemon3| - queued.That should reduce jitter. It may be easy to modify exisiting code, for batch or idle, to do this, so all daemons can be put on batch or idle, for low jitter. (And one wouldn`t need "minimal linux" distros).

              Peace Be With You.