Page 2 of 2 FirstFirst 12
Results 11 to 19 of 19

Thread: OpenGL Frame Latency / Jitter Testing On Linux

  1. #11
    Join Date
    Jun 2013
    Posts
    38

    Default

    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.

  2. #12
    Join Date
    Oct 2007
    Posts
    125

    Default Price / performance please

    http://www.cpubenchmark.net/cpu.php?...+A10-6800K+APU
    http://www.cpubenchmark.net/cpu.php?....50GHz&id=1919

    150 USD vs 337 USD

    5328 vs 10153 CPU Passmark points - unfortunately Phoronix do not want to make a normalized score

    GPU Radeon HD 8610G vs Intel HD 4600

    http://www.videocardbenchmark.net/gp...+8610G&id=2568
    http://www.videocardbenchmark.net/gp...D+4600&id=2451

    669 vs 592

  3. #13
    Join Date
    Jul 2013
    Location
    USA
    Posts
    715

    Default

    i like this hmm

  4. #14
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,337

    Default

    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.

  5. #15
    Join Date
    Jul 2013
    Location
    USA
    Posts
    715

    Default

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

  6. #16
    Join Date
    Nov 2010
    Posts
    93

    Default

    Quote 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

  7. #17
    Join Date
    Jun 2010
    Location
    ฿ 16LDJ6Hrd1oN3nCoFL7BypHSEYL84ca1JR
    Posts
    1,052

    Default

    Quote 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)

  8. #18
    Join Date
    Nov 2010
    Posts
    93

    Default

    Quote 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...

  9. #19
    Join Date
    Jun 2013
    Posts
    38

    Default

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •