Announcement

Collapse
No announcement yet.

Gallium3D's HUD Gets A Frametime Graph Capability

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

  • Gallium3D's HUD Gets A Frametime Graph Capability

    Phoronix: Gallium3D's HUD Gets A Frametime Graph Capability

    In addition to being able to plot the frames per second, CPU usage, and many other possible sensor outputs, the Gallium3D Heads-Up Display (HUD) is now capable of showing the frametime while gaming...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Could you please show an image that shows the actual feature? I was a bit baffled for not being able to find in the picture you have chosen.

    Comment


    • #3
      Is this just going to show the time in milliseconds for each frame rather then the FPS?

      Comment


      • #4
        So, basically 1/FPS, or am I missing something?

        Comment


        • #5
          Originally posted by M@yeulC View Post
          So, basically 1/FPS, or am I missing something?
          1 / FPS = Frame-time (s)

          (1 / FPS) * 1000 = Frame-time (ms)

          ...and back to fps...

          1 / (Frame-time (ms) / 1000) = FPS

          ...so it's basically the same thing... except with one caveat: When people are talking frame-time, they usually mean the time it takes to render a single frame. When talking FPS, they usually mean an average calculated across several frames rendered. They could also mean instantaneous FPS for just a single frame, which is exactly the same thing as frame-time with a different unit attached to it, but this is not usually what people mean when using the term FPS. Actually, most people probably have no idea what they're actually talking about, but if there's a norm for how they are used, this is it.

          In the case of Gallium3D's HUD, I do not know if the FPS is an average or if it's instantaneous.

          Comment


          • #6
            Having a frame time instead of an FPS value helps evaluating the smoothness of the output. FPS is an averaged value over an amount of time and therefore does naturally filter out deviations.

            The example given in the mailing list was that the statement "we have rendered 60 FPS in the last second" does not allow conclusions about how smooth and consistent the output was, because 59 frames could have been rendered instantly and one single frame could have taken very long.

            As Marek wrote in the mailing-list, the FPS value in the gallium hud is an average of the GALLIUM_HUD_PERIOD. Setting that period to zero will have the same effect of having an exact value per frame (the inverse of the frame time) but at the same time affect all the other graphs (CPU load, clocks, memory usage, ...) as well and it might not be desired having those updated each frame.
            Last edited by juno; 16 May 2018, 10:17 AM.

            Comment


            • #7
              Typo:

              Originally posted by phoronix View Post
              render each frame in miliseconds.

              Comment


              • #8
                Yes, it adds a value every frame to the graph, ignoring the hud period. I was not aware that this actually works, but it does. As a result it depends on how many frames are rendered per second to how fast the graph is "flowing" from right to left.

                This becomes a problem with very high framerates. If you run for example
                Code:
                GALLIUM_HUD=.dframetime vblank_mode=0 glxgears
                the graph becomes nearly useless because at ~12000 fps any spike you may possibly see in the graph is immediately gone.

                Another problem is that the frame time is taken at the time when query_data() is called. It's a bit unclear when exactly that is. Beginning of the rendering of the frame? somewhere asynchronously in between? When the frame has finished rendering?
                If it's not the first, then you could get some "false positive" spikes:
                You have an application running at a perfect 60 fps = each frame takes 16.666... ms.
                The first frame takes 10 ms to render, then the frame time is taken.
                The second frame takes 10 ms to render, then the frame time is taken. Perfect 16.666ms between the frames, no problem.
                The third frame takes only 1 ms to render, then frame time is taken. Now there is 16.666ms - 9ms = 7.666ms frame time.
                The fourth frame takes 14 ms to render, then the frame time is taken. Now we have 16.666ms + 9ms + 4ms = 29ms frame time, so there's a significant spike, even though with good frame pacing it runs at a perfect 60 fps.

                I don't know to what extend this actually happens in mesa but it may be a good idea to display a moving average in a 2-3 frame window to smooth out such spikes that cancel each other out. Unless of course I'm misunderstanding frame pacing a bit.


                I've tried two other approaches a while ago:
                https://gist.github.com/ChristophHaa...9b865896f8c342

                The first "low-fps" patch follows the thought that if you have a stutter you basically want to see the worst single "fps" value between two frames, so it shows fps based on the largest time between two frames which probably shows this problem with the point in time when query_data() is called better...


                The second one is to measure another dimension of "badness" of a stutter, and that is how much have all frames together exceeded a target framerate. So if you display a framerate_60 graph, if it shows *any* data at all you know at least one frame took longer than 16.666... ms. Maybe that's not too useful in this form but it adding excess frame time over the entire hud period, maybe it does show something useful in some situations.


                But again, these patches too suffer from the problem of not having the real time when the frame is actually finished rendering. I did look a little bit into the mesa code and the ideal place to take it would be the present code in the glx loader, but the loader is not actually linked to the drivers so you can't just take the value from there so someone should go through the rendering code and determine the last point before the drivers hand off the rendered frame to the loader to add a hook or something to get the time at this point...
                Last edited by haagch; 16 May 2018, 11:46 AM.

                Comment


                • #9
                  I wonder if the HUD logging functionality has low enough overhead when logging frametime with a single frame interval that it could be used fairly for frame time analyses. I've used it for that in a pinch but not really sure.

                  Comment


                  • #10
                    I don't see why it should have more overhead than fps calculation, it's just a different visualization of the same data (frame timestamps).

                    Comment

                    Working...
                    X