Flickering with page-flipping on Acer Iconia W500 (AMD C-50 APU)

Paul Menzel paulepanter at users.sourceforge.net
Tue Feb 21 15:34:18 PST 2012


Hi Felix!


Am Dienstag, den 21.02.2012, 15:07 -0500 schrieb Alex Deucher:
> On Wed, Feb 1, 2012 at 5:43 PM, Felix Kuehling <felix.kuehling at amd.com> wrote:
> > 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.
> >
> > 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.
> >
> > 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:
> >
> > Hardware issues vsync IRQ
> > IRQ handler calls radeon_crtc_handle_flip
> > radeon_crtc_handle_flip calls radeon_page_flip, which programs MMIO to flip
> > pages and returns status whether the flip has been completed
> > 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
> > if flip is predicted to complete, signal user space, otherwise defer until
> > next vsync IRQ
> >
> > 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.
> >
> > 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).
> >
> > 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.
> >
> > 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.
> >
> > My conclusion is that on this particular hardware the condition that
> > predicts page flip completion must be modified in order to avoid notifying
> > user space of completed page flips prematurely.
> 
> The fix looks ok to me.  Mario any thoughts?
> 
> Reviewed-by: Alex Deucher <alexdeucher at gmail.com>

A Signed-off-by line is required, is not it? Should it also got to
stable?

Additionally should the diagnose also be committed?

Felix:

        git config user.name "Felix Kühling"
        git config user.email "felix.kuehling at amd.com"
        git clone git://people.freedesktop.org/~airlied/linux
        git checkout -b flicker-fix drm-next # I hope that is the correct one.
        # apply your fix
        git commit -a -s
        # add your commit message with Alex’s Reviewed-by line
        git format-patch -1
        # use git send-email or paste it to your message editor to send the patch to the list


Thanks,

Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120222/6c04d849/attachment.pgp>


More information about the dri-devel mailing list