Announcement

Collapse
No announcement yet.

OpenGL Frame Latency / Jitter Testing On Linux

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

  • #11
    Are the values reliable? Latest catalyst has huge frame latency problems, at most on setups that have fast CPU and a slower GPU - it often reaches hundreds of milliseconds and more (I've read someone mention even second delay) - see here. I'm interested if this test can provide some insight.

    Comment


    • #13
      i like this hmm

      Comment


      • #14
        Re inaccuracy:

        Measuring frame time at the application side like this is an exact indicator for app latency. If some frame takes long, the app cannot begin processing input for the next frame, causing a visible input lag to the user.

        This happens regardless of what buffering or queue the driver is using. It has a direct, provable correlation to input latency.

        Quoting from anandtech:
        Simply put, FRAPS cannot tell you the frame interval at the end of the pipeline, it can only infer it from what it’s seeing.
        This is a different measurement. AMD is correct in that it does not measure how often frames come out of the GPU; but AMD is incorrect in saying the latter number matters more. By buffering frames appropriately, the driver can ensure the frames come out evenly spaced in time. This does not help input latency, what the app sees. It actually adds to it.

        So while out-the-gpu latency means smoother movement, it does not mean smoother response to input events, but the opposite.


        @Michael

        It's completely possible to measure this for all OpenGL apps just like the id engines do for their own frames. I've been sitting on a 84-line library that does just that, maybe I should publish that on github or something. Linux-only though.

        The other thing, please do the other common representation of the latency graphs - a sorted graph, with marker lines for 50%, 90%, and 95% thresholds.

        Comment


        • #15
          this will work well on Wayland no? seeing how all of them have a time stamp?

          Comment


          • #16
            Originally posted by DDF420 View Post
            although windows related this video was interesting ...
            I'm subscribed to the PC Perspective podcast and follow Ryan Shrout's work on "Frame Rating". This describe the video as "windows related" is a bit disingenuous!! The problem of more accurately measuring the "full latency" to render each frame is just as pertinent to Linux/OpenGL Desktops as it is to Windows/DirectX Desktops. I would love to see some "frame-rating" done on games run on top of Wine for example.

            The difficulty in physically doing "frame-rating" analysis is not the dumb drawing of colour coded bars on the frame edges (for sorting frames being rendered into order) - the application Nvidia wrote has been opensourced - this code was subsequently picked up and added in as a feature into one of the many Windows only 3rd-party GPU utilities (sorry forgotten which one!!)...

            The real difficulty is acquiring the $1000's worth of HDMI capture card to get the video frames back for subsequent analysis!! No doubt with Windows-only drivers

            The post-processing calculations required are again relatively simple: detect coloured bars and write to a spreadsheet, etc. Then you can perform statistical analysis on the results...

            In general gamers are going to find frame stuttering far more annoying than a smoother lower FPS (say 30 vs. 60). Games played through Wine suffer from frame stuttering problems (unless your system is say 1-2 orders of magnitude greater than the equivalent Windows system required to play the game smoothly). Current Linux benchmark results do not accurately reflect this reality (not just picking on Phoronix here )...

            IMHO I can't really trust or rely on content that doesn't use this methodology... I've always felt Fraps-type measurements were a bit bogus...

            Ho hum... Just my $0.02

            Comment


            • #17
              Originally posted by bobwya View Post
              The real difficulty is acquiring the $1000's worth of HDMI capture card to get the video frames back for subsequent analysis!! No doubt with Windows-only drivers

              The post-processing calculations required are again relatively simple: detect coloured bars and write to a spreadsheet, etc. Then you can perform statistical analysis on the results..
              Why can't you use a normal video camera that can record at least 60 fps and just film a screen? Sure, you need a bit more computer vision methods for analyzing it, but it should be about as good. Sure, it may not sync exactly to screen refreshs, but it would always be the same delay, so it wouldn't matter, would it? (I don't really know how exactly screens update)

              Comment


              • #18
                Originally posted by ChrisXY View Post
                Why can't you use a normal video camera that can record at least 60 fps and just film a screen? Sure, you need a bit more computer vision methods for analyzing it, but it should be about as good. Sure, it may not sync exactly to screen refreshs, but it would always be the same delay, so it wouldn't matter, would it? (I don't really know how exactly screens update)
                1) Captured won't be in sync. 60Hz (but not the same 60Hz!!)

                2) Really capture a 1920x1080p images accurately at 60Hz?

                3) Post-processing of images subject to shift (in horizontal and vertical planes) and colour/luminescence changes, etc. is HARD!!

                4) Pixel-level accuracy is required for detecting "runt frames"

                etc. etc.!!

                Basically the capture won't be nearly accurate enough. Watch some of the PC Per videos on it - Ryan Shrout is no "rocket scientist" and makes the topic very accessible to the layman...

                Comment


                • #19
                  I think oculus latency tester is pretty close to basic but okay solution for the input->output latency (limited to whole frame latency though).

                  Comment

                  Working...
                  X