<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Following up on my message from Jan 19, now with a lot more hard
    data and a less intrusive modification. Still a prototype though.
    CC-ing DRI-devel and Mario Kleiner for a larger audience.<br>
    <br>
    To recap, I was seeing consistent flickering with Mesa/KMS on
    Android on my Iconia Tab W500 tablet with an AMD C-50 APU. I was
    also noticing occasional flickering under Ubuntu on the same system
    when maximizing/restoring windows and releasing windows after moving
    them.<br>
    <br>
    I believe that flickering is related to page flipping and the
    associated notifications to user space. A small modification to the
    page flipping code in the Radeon driver made the problem disappear
    on both Ubuntu and Android. As I understand it, the page flip
    notification logic works as follows:<br>
    <ol>
      <li>Hardware issues vsync IRQ</li>
      <li>IRQ handler calls radeon_crtc_handle_flip</li>
      <li>radeon_crtc_handle_flip calls radeon_page_flip, which programs
        MMIO to flip pages and returns status whether the flip has been
        completed</li>
      <li>if flip has not been completed, radeon_crtc_handle_flip uses
        current scanout position to predict whether flip will complete
        in the current frame or not</li>
      <li>if flip is predicted to complete, signal user space, otherwise
        defer until next vsync IRQ<br>
      </li>
    </ol>
    The condition in step 4 needed a slight modification on my hardware.
    If the current scanout position is negative (inside vblank
    interval), the page flip will not complete until the next vsync on
    my hardware.<br>
    <br>
    I'm attaching two patches. radeon_flip_diag.diff adds some debug
    output to the kernel log that helped me understand the timing of
    VSync IRQs used for handling page-flips relative to the screen
    refresh in progress. It also measures the time it takes to program
    the page flip in MMIO in pixels scanned out (typically about 300
    pixels, so relatively insignificant compared to the vertical
    refresh).<br>
    <br>
    On my system it turned out that the scanout position at the time
    radeon_crtc_handle_flip was called was somewhere between 798-800 and
    -2-0 (the LVDS screen having 800 visible rows). I used an awk script
    (also attached) to compute some statistics. With the original
    condition almost no page flips were detected as deferred to the next
    vsync IRQ. With the modified condition about 50% page flips were
    completed immediately according to radeon_page_flip and of the
    remaining ones about 50% were correctly predicted to complete based
    on the scanout position. In total about 25% were deferred until the
    next vsync. These 25% must have been causing flickering with the
    original condition.<br>
    <br>
    radeon_flip_fix.diff shows the minor modification to the condition
    used to decide whether a page-flip has been completed or will
    complete in the current screen refresh.<br>
    <br>
    My conclusion is that on this particular hardware the condition
    that&nbsp; predicts page flip completion must be modified in order to
    avoid notifying user space of completed page flips prematurely.<br>
    <br>
    Regards,<br>
    &nbsp; Felix<br>
    <pre class="moz-signature" cols="72">-- 
 _____    Felix Kuehling
 \ _  |   MTS Software Development Eng.
 /|_| |   SW-Linux Base Gfx | AMD
|__/ \|   T 905.882.2600 x8928</pre>
  </body>
</html>