Am 23.06.2014 21:46, schrieb Dieter N?tzel:
> 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
Addendum:
I can reliable generate such lines in Xorg.0.log with KWin cube desktop
effect.
Rotate screens with mouse wheel or screen switcher => new entry in
Xorg.0.log. If it happens I notice ('see') flip delay.
[ 9893.183] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip
completion event has impossible msc 594382 < target_msc 594383
[ 10859.753] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip
completion event has impossible msc 652497 < target_msc 652498
[ 10915.719] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip
completion event has impossible msc 655863 < target_msc 655864
[ 10916.817] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip
completion event has impossible msc 655929 < target_msc 655930
[ 10925.843] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip
completion event has impossible msc 656472 < target_msc 656473
[ 10926.774] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip
completion event has impossible msc 656528 < target_msc 656529
[ 10965.519] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip
completion event has impossible msc 658859 < target_msc 658860
[ 11081.878] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip
completion event has impossible msc 665846 < target_msc 665847
>>> 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...
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
