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:
1. Hardware issues vsync IRQ
2. IRQ handler calls radeon_crtc_handle_flip
3. radeon_crtc_handle_flip calls radeon_page_flip, which programs MMIO
to flip pages and returns status whether the flip has been completed
4. 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
5. 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.
Regards,
Felix
--
_____ Felix Kuehling
\ _ | MTS Software Development Eng.
/|_| | SW-Linux Base Gfx | AMD
|__/ \| T 905.882.2600 x8928
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120201/89c7e3ef/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: parse_flip.awk
Type: application/x-awk
Size: 486 bytes
Desc: parse_flip.awk
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120201/89c7e3ef/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: radeon_flip_diag.diff
Type: text/x-patch
Size: 2866 bytes
Desc: radeon_flip_diag.diff
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120201/89c7e3ef/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: radeon_flip_fix.diff
Type: text/x-patch
Size: 621 bytes
Desc: radeon_flip_fix.diff
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120201/89c7e3ef/attachment-0002.bin>
