Am 23.06.2014 11:34, schrieb Michel D?nzer: > On 18.06.2014 18:14, Christian K?nig wrote: >> Am 18.06.2014 07:53, schrieb Michel D?nzer: >>> >>> Looking into these issues has got me thinking about the use of the >>> page >>> flip interrupt: If the page flip interrupt arrives before the >>> corresponding >>> vertical blank interrupt, the DRM vblank counter will be lower than >>> expected by 1 in drm_send_vblank_event(). I suspect this is the cause >>> of >>> >>> (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion >>> event has impossible msc [x-1] < target_msc [x] >>> >>> messages in the X log file which have been popping up in bug reports >>> lately. >>> This also results in 0s being returned to the client for the MSC and >>> timestamp of the swap completion, which could cause all kinds of bad >>> behaviour. >> First of all thanks for looking into it. Are you getting this on 3.16 >> or >> 3.15? > > I haven't actually run into this myself yet. I thought I'd seen it in > several bug reports, but right now I can only find > https://bugs.freedesktop.org/show_bug.cgi?id=80029#c17 , which seems to > include the page flipping changes from 3.16.
With 3.16-rc2 I get it now on my RV730 AGP as in the above bug report. But only the lines in Xorg.0.log. NO signs of any damage/error in use. Since 3.15 and 3.16 (rc2 only) my system is rock solid. I've tried 3.15-rc7 + Christian's pflip rework (did some little handwork), too. It was solid but I saw the reported flip/black distortion in the below part during Kwin 4.13 cube screen effect (rotation). Your fix for 3.16-rc1 fixed that. Before 3.15/3.16-rcX I got some hangs from time to time during system boot. Nothing in the logs but SSD RAID1 rebuild. Maybe it was MD related an NOT r600/DRM. 3.16-rcX (3.15-rc7+pflip patches) seems to be more responsive that 3.15, for me. First and latest attchments from bug #80141 https://bugs.freedesktop.org/attachment.cgi?id=101605 show same. Where should I add/send my Xorg.0.log? Cheers, Dieter >> I don't think that the pflip irq is thrown earlier than the vblank, >> but >> on 3.16 it might actually be that we program the flip so fast into the >> hardware that we do it one frame earlier than planned. > > So userspace is notified of the previous vertical blank period and > calls > the page flip ioctl in response, which then manages to program the > scanout address update into the hardware before the scanout address > update is latched during the previous vertical blank period? > > To avoid that scenario, one possibility might be to check if we're in > vertical blank before calling radeon_page_flip(), and if so sleep for > 1ms or so before trying again? That might unnecessarily delay flips on > other CRTCs though...
