Announcement

Collapse
No announcement yet.

OpenGL Frame Latency / Jitter Testing On Linux

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

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