Announcement

Collapse
No announcement yet.

Frame latency analysis on Doom 3

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

  • #16
    Basically it is nothing "new", lots of benchmark tests (on win) show the fps drawn on a time graph. Also you should not compare your system against his, because the gfx card is definitely different. When the card is fast (and only limited by driver) then other aspects like asset load time you have to take into account. Didn't you remember his remarks that load time could be tuned by a special kernel config - all that is more or less complete bullshit. Usually a 2nd run does not show these peaks when everything is pre-cached. It's also the same person who would buy a 2.x ghz quad core for dual socket 2011 instead of a 3.5 ghz quad with turbo for gaming - just to fix jitter - do you call that normal?

    Comment


    • #17
      I do not see why this discussion should be about Paradox Uncreated. This thread is about measuring hiccups/judder/jitter (or how you'd call it) in doom3. My point is that this could be useful. I posted the comparison of my system with Paradox's to demonstrate the possibilities of this method, no more, no less.

      I would rather have a system which can always churn out 30 fps minimum, instead of a system which does 60 fps average, but with hiccups of 500 ms or larger.

      Comment


      • #18
        Guano hopes to be prime bitch the next ten years too. Out of respect for threadstarter I am just going to ignore the subcattle, and their worthless bloodstream.

        I do think he makes a very good point of who he is though. Apparently even not the extreme jitter in the demo, is visible to him. He must obviously be blind. And seeing his argumentation in low-jitter kernel thread, not only mind, but lack a mind and senses aswell.

        I have already posted the numbers I get also, and they show low-jitter.

        Ofcourse it fits logically. The only enemy of sense, must be senselessness itself.

        And he probably is frustrated from not recieving his daily cottaging. And rages in threads on phoronix, and probably osnews.

        THE TROLL. Olaf in his barn. He doesn`t understand computers, and he doesn`t understand Islam. Just don`t let him fool you, because then you will live at the lowest level, as him.

        http://paradoxuncreated.com/Blog/wordpress/?p=4486

        Peace Be With You.

        Comment


        • #19
          It depends how you measure your 60 fps. If you measure it with vsync enabled in the gfx driver then it is unlikely that you will notice many drops while you play the game (ok, when it loads new game data, faster from ssd btw). If you get 60 fps average while the gfx driver (and the game setting) does not restrict the rendering then it more likely that there are many parts below 60 fps (that's the case with my gt630 @ 1920x1200). The switches in framerate you can see thats clear - but then you just need a faster gfx card usually to get rid of em. D3 is from 2004, so all cpus should be fast enough. As the code is opensource you can limit the HZ to 30 or 120 or whatever you like in neo/framework/UsercmdGen.h.

          Comment


          • #20
            This is exactly what was said in the other tread too. There is no "loads new game data" framelosses here, and that is even without SSD. And as I said in the other thread, not even QUAD SLI will improve jitter. Actually it will worsen it.

            Peace Be With You.

            Comment


            • #21
              We can ofcourse discuss the settings, and try to achieve the lowest jitter.

              First of all, a kernel with "low latency desktop" enabled. You can edit Kconfig.hz and change 100 to 90. (search/replace).
              You can add idle=poll and tick_skew=1 to boot options. And compile a shaved local kernel by doing "make localmodconfig" from a full distro kernel. (Also remember to turn of high_res_timers if enabled, because then hz will be 4016 or atleast high.)

              CFS granularity should be set to 1158500nS. (Current setting is a bit high, and may give jitter)
              Renice X to -20, to prevent X being a bottleneck.
              Remove 60hz limit in doom 3, to avoid timing jitter. http://paradoxuncreated.com/tmp/AutoExec.cfg

              Some nvidia-specific stuff on my blog aswell : http://paradoxuncreated.com/Blog/wordpress/?p=2268

              A lot of people think SLAB has lower jitter than SLUB etc, aswell, and some tuning with regards to what kernel options execute the least code, least background activity can be done.

              Rather than listen to someone moan and not want to realize reality, I`d much more like to see people understanding this, and contributing to an improvement. And I very much appreciate the initiative of the thread. However to really see doom 3 jitter, it must be run at normal speed. So just play through a level. and record those values instead, would be more informative.

              Peace Be With You.
              Last edited by Paradox Uncreated; 11-06-2012, 10:01 AM.

              Comment


              • #22
                Originally posted by Paradox Uncreated View Post
                First of all, a kernel with "low latency desktop" enabled. You can edit Kconfig.hz and change 100 to 90. (search/replace).
                Do you have an explanation for why a lower Hz setting improves jitter? I thought the general wisdom was that a higher setting would improve timing precision.

                Comment


                • #23
                  Less interrupt triggered = less interruptions = less jitter. Depending on how things is done, if less interrupts means larger data bursts, there may be a sweet spot. I have found 90 hz, to give the least jitter, with 5hz accuracy.

                  Comment


                  • #24
                    Well maybe you should reboot your system and try 2 passes or 3 of the demo and compare. Be prepared that your thesis is wrong.

                    Comment


                    • #25
                      Originally posted by Paradox Uncreated View Post
                      Less interrupt triggered = less interruptions = less jitter. Depending on how things is done, if less interrupts means larger data bursts, there may be a sweet spot. I have found 90 hz, to give the least jitter, with 5hz accuracy.
                      It would be interesting to test rational multiples (e.g. 2, 3, 5, 3/2, 4/3) of the monitor refresh rate for Hz (e.g. 60, 120, 180, 300, 90, 80).

                      Also, if Phoronix Test Suite adds frame time graphs, it would be helpful to show the X axis as time for demos that run at a constant speed (i.e. not like Quake 3 timedemos). That way it's easier to tell if a long frame always happens in the same place in a demo.

                      Comment


                      • #26
                        Originally posted by Kano View Post
                        Well maybe you should reboot your system and try 2 passes or 3 of the demo and compare. Be prepared that your thesis is wrong.
                        Reboot? LOL. My "thesis"? Both the use of that word, and ignoring the fact that clear difference can be observed, simply by doing what I said above.

                        Like Guano could refute anything of a thesis. LOL

                        Guano continues his completely mindless behaviour. How much nonsense of his, must be refuted before he realizes he is wrong? Ofcourse it could be that he is doing this, because he thinks he is "cool".

                        I run doom 3 completely without jitter. When running playdemo with the demo, it jitters in similar places, and the framerate is reduced.

                        A warning to all is the only thing Guano is.

                        Now instead of arguing the obvious with Guano, I am going to reply to people who actually want to discuss the problem, provide fixes, inspiration to solutions etc.

                        Leave cottaging guano-lover to himself, where he can run his performance with suboptimal settings, and get the performance of the ultimate low-end.

                        Comment


                        • #27
                          Originally posted by unix_epoch View Post
                          It would be interesting to test rational multiples (e.g. 2, 3, 5, 3/2, 4/3) of the monitor refresh rate for Hz (e.g. 60, 120, 180, 300, 90, 80).

                          Also, if Phoronix Test Suite adds frame time graphs, it would be helpful to show the X axis as time for demos that run at a constant speed (i.e. not like Quake 3 timedemos). That way it's easier to tell if a long frame always happens in the same place in a demo.
                          No. 90. Rational multiples does not mean "minmal jitter".

                          Comment


                          • #28
                            Ofcourse it could be possible to do vsynced HZ, and cleverly arranging things, so that each vsync, buffer is delivered, and next frame calculated. One for the kernel-engineers. (Who have time.)

                            Comment


                            • #29
                              Please keep it on-topic. The subject is about the TechReport article and how this could be applied to Linux systems testing.

                              Comment


                              • #30
                                Originally posted by unix_epoch View Post
                                Also, if Phoronix Test Suite adds frame time graphs, it would be helpful to show the X axis as time for demos that run at a constant speed (i.e. not like Quake 3 timedemos). That way it's easier to tell if a long frame always happens in the same place in a demo.
                                What would then be measured in the y-range?

                                I believe that Doom 3 timedemos are frame-for-frame identical across machines, because delays happen always in the same frame. Moreover, timedemos always have the same frame lenght.

                                Comment

                                Working...
                                X