Announcement

Collapse
No announcement yet.

AMD's Marek Has A Patch Helping To Reduce Gallium3D Input Lag

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

  • #11
    Originally posted by debianxfce View Post

    There is nothing wrong in the open source Mesa driver. Test with the War Thunder game
    You don't understand what I mean. Here, I'll quote my explanation:

    Originally posted by tildearrow View Post
    ​​​​​​The draw procedure of an application goes like this:

    1. clear
    2. draw
    3. present (AKA swap buffers)

    If VSync is on, in a proper driver, present must wait until the vertical blank has been reached, and then swap buffers.

    Code:
    A display frame (in this example, rate 50Hz (period 20ms)):
    Every line indicates a millisecond
    L GPU CPU
    @ *Pre-VBlank* Update Logic (CPU) (e.g. 4ms)
    | .
    | .
    | *Visible Raster* .
    | Clear (e.g. 1ms)
    | . Draw (e.g. 6ms)
    | . .
    | . .
    | . .
    | . .
    | . .
    | SwapBuffers is requested here
    | |
    | |
    | | The driver
    | | waits for
    | | VBlank
    | *Post-VBlank* <- SwapBuffers happens here
    | (rest of actions)
    | .
    However, if we spend too much time in a frame, it will halve our FPS:

    Code:
    L GPU CPU
    @ *Pre-VBlank* Update Logic (CPU) (e.g. 4ms)
    | .
    | .
    | *Visible Raster* .
    | Clear (e.g. 1ms)
    | . Draw (e.g. 23ms)
    | . .
    | . .
    | . .
    | . .
    | . .
    | . .
    | . .
    | . .
    | . .
    | . .
    | . .
    | *Post-VBlank* .
    | . .
    | . .
    @ *Pre-VBlank* .
    | . .
    | . .
    | *Visible Raster* .
    | . .
    | . .
    | . .
    | . .
    | | SwapBuffers is requested here
    | | Driver waits
    | | for VBlank
    | |
    | |
    | |
    | |
    | |
    | |
    | *Post-VBlank* <- SwapBuffers happens here
    | (rest of actions)
    | .
    In order to fix this "problem", NVIDIA invented Adaptive-VSync, and then this method was ported to Mesa.

    This way we no longer wait for VSync when swapping buffers, but rather put the frame in a "queue" that will be popped on the next VBlank.
    The wait only happens if you send another command (e.g. clear).

    Code:
    L GPU CPU
    @ *Pre-VBlank* Update Logic (CPU) (e.g. 4ms)
    | .
    | .
    | *Visible Raster* .
    | Clear (e.g. 1ms)
    | . Draw (e.g. 6ms)
    | . .
    | . .
    | . .
    | . .
    | . .
    | SwapBuffers happens right here
    | Frame remains Update Logic (CPU)
    | in a queue .
    | and returns .
    | immediately .
    | Clear
    | *Post-VBlank* Draw
    | Popped from .
    | queue .
    However, this is undesirable for applications like compositors and UI toolkits with animation, as it will prevent us from knowing when do we exactly hit VBlank.

    (If you're wondering why do we want to know when does VBlank happen, it's for lag reduction techniques)

    Furthermore in Mesa's implementation the catch-up issue appears.

    Code:
    Display | Machine
    frame 0 | frame 0
    frame 1 | frame 1
    frame 2 | frame 2
    frame 3 | say we lag here for ~250ms
    frame 4 | frame 2
    frame 5 | .
    frame 6 | .
    frame 7 | .
    frame 8 | .
    frame 9 | .
    frame 10 | .
    frame 11 | .
    frame 12 | .
    frame 13 | .
    frame 14 | .
    frame 15 | .
    frame 16 | .
    frame 17 | .
    frame 18 | frame 2 frame 3 frame 4 frame \
    frame 19 | 5 frame 6 frame 7 frame 8 fra |
    frame 20 | me 9 frame 10 frame 11 frame |
    frame 21 | 12 frame 13 frame 14 frame 15 | Catch-up
    frame 22 | frame 16 frame 17 frame 18 fr |
    frame 23 | ame 19 frame 20 frame 21 fram |
    frame 24 | e 22 frame 23 frame 24 /
    frame 25 | frame 25
    frame 26 | frame 26
    frame 27 | frame 27
    frame 28 | frame 28
    frame 29 | frame 29
    In other words, say I make an application that intentionally waits 500ms after rendering 30 frames of a spinning triangle.

    Under a proper driver, this would happen:

    (60Hz display)

    1. Triangle rotates for 0.5s
    2. Triangle stops rotating and application waits 0.5s
    3. Triangle continues rotating for 0.5s
    4. Triangle stops rotating and application waits 0.5s
    5. Loop from 1

    However, under Mesa, this happens:

    1. Triangle rotates for 0.5s
    2. Triangle stops rotating and application waits 0.5s
    3. Triangle suddenly skips to a different rotation
    4. Application waits 0.5s
    5. Triangle suddenly skips to a different rotation
    6. Application waits 0.5s
    7. Loop from 3

    How can I stop this behavior and go back to the good old true waiting VSync?
    Besides, aren't you the guy who decided to tease me in the other thread?

    Comment


    • #12
      Originally posted by debianxfce View Post

      Play the War Thunder game with Vsync enabled and you see no stuttering. https://store.steampowered.com/app/236390/War_Thunder/
      I'm not talking about stuttering right now. I'm talking about Mesa's "catch-up" behavior!!!!!!!!!

      Comment


      • #13
        Originally posted by debianxfce View Post

        Mesa is stuttering in your stupid animation.
        I see both stuttering. I think tildearrow is claiming that the observed behaviour is caused by Mesa using a worse algorithm, which causes larger spans of frames to be dropped after the first one's present deadline is missed.

        Comment


        • #14
          Originally posted by ssokolow View Post
          I see both stuttering. I think tildearrow is claiming that the observed behaviour is caused by Mesa using a worse algorithm, which causes larger spans of frames to be dropped after the first one's present deadline is missed.
          I'm not sure if this applies, though. Vsync with fps below refreshrate looked pretty much as expected here with radv & Hitman 2. I'd say the same applied to Skyrim with wined3d9.

          Comment


          • #15
            Originally posted by debianxfce View Post

            Mesa is stuttering in your stupid animation.
            You are stuttering in your stupid brain.

            Comment


            • #16
              Originally posted by ssokolow View Post

              I see both stuttering. I think tildearrow is claiming that the observed behaviour is caused by Mesa using a worse algorithm, which causes larger spans of frames to be dropped after the first one's present deadline is missed.
              The "stutters" (0.5s pauses) shown in the animation are induced on purpose to show a flaw when this occurs. Once again, let me explain:

              This is what should occur:
              1. Triangle spins normally for 0.5s
              2. Triangle should stop for 0.5s (on purpose)
              3. Triangle continues spinning for 0.5s
              4. Triangle stops for 0.5s
              5. Repeat from 3

              However, in Mesa this occurs:
              1. Triangle spins normally for 0.5s
              2. Triangle stops for 0.5s (on purpose)
              3. Triangle skips to another position immediately, caused by the fact Mesa is trying to catch up
              4. Triangle stops for 0.5s
              5. Repeat from 3, sometimes from 1

              Comment


              • #17
                Originally posted by debianxfce View Post

                tildearrow is using old and buggy drivers, that is why he is seeing stuttering and feeling bad.

                " OpenGL: renderer: Radeon Vega Frontier Edition (VEGA10, DRM 3.26.0, 4.18.3-zen1-1-zen, LLVM 6.0.1) version: 4.5 Mesa 18.1. "
                LOL, you will never understand what I mean then.

                Comment


                • #18
                  I'd say so too that vsync with Mesa works as well as on Windows. Tested this with Hitman 2 DXVK and Dying Light OGL.

                  Comment


                  • #19
                    Originally posted by debianxfce View Post

                    You will never understand what you write. You wrote that "Triangle stops for 0.5s" with Vega 10. That is impossible with Mesa and Vega10, play the War Thunder game vsync enabled.
                    You will definitely never understand anything at all.

                    Let me try to dumb it down as much as possible.
                    The program I created stops the triangle on purpose, to demonstrate behavior differences between Mesa and proprietary drivers.
                    When you open the program, it pops up a window with a white triangle on a black background.
                    The triangle rotates for a half-second, and then stops ON PURPOSE by using usleep. Let me repeat again, on freaking purpose. I made it stop intentionally, because this is what allows me from seeing the behavior differences between Mesa and proprietary.
                    After a half-second of it being stopped, it must continue rotating like normal for another half-second, and then stop for another half-second, and continue rotating for a half-second, and so on.
                    But as you can clearly see in the GIF, under Mesa this doesn't happen. This is what happens under Mesa:
                    The triangle rotates for half-second and then stops for half-second (I repeat, the application does this ON PURPOSE). However, after that the triangle doesn't resume and rotates like normal. Instead, Mesa thinks the program had a lag spike, and as such thinks it's a good idea to catch up with the rendering. This causes the triangle to spontaneously skip to another position, then immediately stopping for a half-second, and so on.

                    Do you finally understand now?

                    Edit: Here is the program source so you can check it yourself: https://gist.github.com/tildearrow/d...ae15397a594e6c
                    Last edited by tildearrow; 10 May 2019, 05:39 PM.

                    Comment


                    • #20
                      Originally posted by debianxfce View Post

                      Yes, you have problems with kde and using the Xfce desktop with open source drivers helps.
                      I AM *NOT* talking about KDE or any desktop!!!!! This is about a Mesa problem, NOT about desktops. Therefore this will reproduce on XFCE too.

                      Comment

                      Working...
                      X