[PATCH v5 00/13] PRIME Synchronization

Alex Goins agoins at nvidia.com
Thu May 19 22:36:21 UTC 2016

Hi Dave,

Any update on this? Anything I can do to help?


On Tue, 3 May 2016, Dave Airlie wrote:

> On 3 May 2016 at 12:19, Alex Goins <agoins at nvidia.com> wrote:
> > Sorry for all of the self-replies.
> >
> > I spent more time looking into what might be causing this (despite not being
> > able to reproduce it), and found that in the Present extension's
> > present_check_flip(), it doesn't use flipping if there are slave outputs. So,
> > that's why it's not allowing page flipping, but that isn't due to these patches.
> >
> > Since it can't flip, it falls back to just waiting for vblank and you can get
> > some ugly tearing on the native display. I still can't reproduce the choppy
> > rendering, but if there is a problem it's likely something to do with
> > drmWaitVBlank().
> >
> > Have you tried to see if it fails like that even without my patches? If the
> > problem is with drmWaitVBlank(), it might just be that something is going wrong
> > there, and adding output slaves just exposes the issue.
> >
> > It looks like since drmWaitVBlank() doesn't take in the crtc_id directly like
> > drmModePageFlip(), and since there is no standard interface to do something like
> > drm_intel_get_pipe_from_crtc_id(), we just make a best guess in
> > drmmode_crtc_vblank_pipe(). Could be error-prone.
> Okay thanks for looking into it. Yes the present behaviour is known as
> we can't flip
> on multiple crtcs with the current present driver API, I should post
> patches to at
> least clean that up.
> Otherwise you are probably right wrt what is causing the choppiness, I'll try
> and get some times (it might be next week) to track it down, but I don't think
> it should block these patches at this point.
> I'll try and finish review by the end of the week,
> Dave.

More information about the xorg-devel mailing list