Announcement

Collapse
No announcement yet.

AMDGPU DC Code Improvements Bring Better Page-Flipping

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

  • #21
    Originally posted by MrCooper View Post
    That doesn't sound like any functionality Mesa has. Not sure what exactly you mean by "disables VSync if the game is running too slow by not waiting for VBlank when swapping but rather doing so on the next command" though, maybe try elaborating on the symptoms.
    Mesa does have that functionality since 2013 (https://phoronix.com/scan.php?page=news_item&px=MTU0NDE), and at some point in time it became a permanent default.

    Sure. I'll explain.

    ​​​​​​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

    (sorry for the crude explanation... I'll post a GIF soon)

    How can I stop this behavior and go back to the good old true waiting VSync?
    Last edited by tildearrow; 01-23-2019, 02:05 PM.

    Comment


    • #22
      Originally posted by DarkFoss View Post

      Have you tried adding Option "VariableRefresh" "off" to your 10-amdgpu.conf ? Located in usr/share/xorg.conf.d
      My monitor is too old and doesn't support freesync bad things happen with openmw if it's set to auto or on
      Note that I do not mean Adaptive-Sync (AKA FreeSync), but rather Adaptive-VSync.

      Comment


      • #23
        Originally posted by tildearrow View Post

        Note that I do not mean Adaptive-Sync (AKA FreeSync), but rather Adaptive-VSync.
        Sorry need some coffee I think this reddit page has some links and info for what your looking for. https://www.reddit.com/r/linuxquesti..._mode_setting/

        Comment


        • #24
          Originally posted by Azpegath View Post
          It's a shame it doesn't get into 5.0, it would be nice to have some clean-ups of the DC as soon as possible. I agree with oleid, there has been many stability issues with DC. I'm running it on a R290, so I guess I'm an outlier (they aren't officially supported, right?) and have to accept some issues, but the kernel didn't even boot for 2 whole main release versions. Now they've fixed the first specific issue I had, but I still haven't tried updating to anything newer than 4.18.20, since there where so many other issues (the filesystem corruption, etc). I think I'm mainly waiting for 5.0.(>5), to not risk hitting any issues.
          Since 4.19, everything is running perfectly for me with the RX 560.
          Whether it is switching output screen, turning AV receiver off/on (used for playing sound and passing through image via HDMI to output screen) , switching monitor on/off, or the more touchy suspending/resuming. All the bits that were initially leading to freezes have been ironed out starting with 4.19.

          I am currently at 90 days of uptime with 100+ suspending/resuming and AV Receiver turning off/on, gaming, Spotifying, netflixing and many other stuff included. amdgpu is now completely stable for me.
          Last edited by Mez'; 01-23-2019, 03:21 PM.

          Comment


          • #25
            Originally posted by oleid View Post
            Anyone with DC problems, too? Since DC is merged, I only get black screen (on my 4k screen) during boot. I can disable DC, and then command line works. But well...
            I have a similar issue with an ultrawidescreen monitor giving me a blank screen (though the non-DC code paths also had issues of not correctly displaying antice resolution).

            I have it reported here: https://bugs.freedesktop.org/show_bug.cgi?id=107668 - I tried 5.0 RC1 but that hadnt got the fix in yet.

            Comment


            • #26
              Originally posted by DarkFoss View Post

              Sorry need some coffee I think this reddit page has some links and info for what your looking for. https://www.reddit.com/r/linuxquesti..._mode_setting/
              Neither option fixed the issue.

              By the way, here is an animation of the issue:

              Comment


              • #27
                Originally posted by salsadoom View Post
                What is this? *Finally* freesync over hdmi?? Awesome!
                Shit, I just realized I misread the blurb. Well, shit. Looks like HDMI users get left out in the cold again. Why is this such a damn problem, it works just fine in Windows for F sakes.

                Comment


                • #28
                  Originally posted by Mez' View Post
                  Since 4.19, everything is running perfectly for me with the RX 560.
                  Whether it is switching output screen, turning AV receiver off/on (used for playing sound and passing through image via HDMI to output screen) , switching monitor on/off, or the more touchy suspending/resuming. All the bits that were initially leading to freezes have been ironed out starting with 4.19.

                  I am currently at 90 days of uptime with 100+ suspending/resuming and AV Receiver turning off/on, gaming, Spotifying, netflixing and many other stuff included. amdgpu is now completely stable for me.
                  Interesting, 4.19 doesn't boot at all with Hawaii cards, until (I think) 4.19.15 or so, because of incorrect recognition of the cards caused by a bug. Michael wrote an article about it after I sent him a link to the bug report. This also resulted in the bug-fix being merged almost immediately after the article came out. But like I said, I haven't had the guts to try the kernels after the fix.

                  Comment


                  • #29
                    L_A_G - Yeah, that's a crappy situation.

                    My R9 390 has Direct 3D 12, Vulkan 1.1 and Open GL 4.x, Open CL 2.x, Freesync over HDMI, H.264 and H.265 decoding and encoding, Wattman supported in Windows.

                    In Linux by comparison, the officially supported Radeon kernel driver excludes Vulkan, Freesync support. Only with the "experimental" support in AMDGPU kernel driver do we get Vulkan and Freesync support. The AMDGPU driver is more stable and performant for my R9 390, than the radeon kernel driver - it's the reason I switched in the first place. At most OpenCL 1.1 is supported, and I think it's half baked support not full support. H.264 decoding and encoding seems to be supported. The driver quality sucks, there's always some new bug in each new kernel version (and in point releases as well). Either the GPU hangs randomly, or the screen stops working after suspend and resume.

                    As far as I can see, AMD's Linux support is mediocre - way better than NVIDIA's closed source crap and their Wayland situation, but AMD's support is pretty bad in comparison to Intel's Linux drivers.

                    Comment


                    • #30
                      Originally posted by sandy8925 View Post
                      L_A_G - Yeah, that's a crappy situation.

                      My R9 390 has Direct 3D 12, Vulkan 1.1 and Open GL 4.x, Open CL 2.x, Freesync over HDMI, H.264 and H.265 decoding and encoding, Wattman supported in Windows.

                      In Linux by comparison, the officially supported Radeon kernel driver excludes Vulkan, Freesync support. Only with the "experimental" support in AMDGPU kernel driver do we get Vulkan and Freesync support. The AMDGPU driver is more stable and performant for my R9 390, than the radeon kernel driver - it's the reason I switched in the first place. At most OpenCL 1.1 is supported, and I think it's half baked support not full support. H.264 decoding and encoding seems to be supported. The driver quality sucks, there's always some new bug in each new kernel version (and in point releases as well). Either the GPU hangs randomly, or the screen stops working after suspend and resume.

                      As far as I can see, AMD's Linux support is mediocre - way better than NVIDIA's closed source crap and their Wayland situation, but AMD's support is pretty bad in comparison to Intel's Linux drivers.
                      I'm a bit surprised at that as well... I would think that AMD would have a huge test farm, with at least one of every card, running nightly builds of every kernel branch, running at least the mesa regression test suite, including power cycle tests. It's not like the cards are expensive for them.

                      Comment

                      Working...
                      X