[PATCH v5 00/13] PRIME Synchronization

[Alex Goins]

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.

Thanks,
Alex

On Sat, 30 Apr 2016, Alex Goins wrote:

> D'oh, I was still running mutter with vblank_mode=0 from when I had no native
> heads present. Now it's using the Present extension to wait for vblank, but not
> to flip. Still not seeing the issues described.
> 
> Thanks,
> Alex
> 
> On Sat, 30 Apr 2016, Alex Goins wrote:
> 
> > So far I've been unable to reproduce this, but I don't see the Present extension
> > being used.
> > 
> > What exactly is your setup to get mutter running against X using DRI3? I've
> > ensured that DRI3 page flipping is enabled (it's required for PRIME
> > synchronization too anyway), and glamor_egl->dri3_capable == TRUE. Maybe I'm
> > missing something. Is there something out of tree that I need? I don't see
> > anywhere where the present extension is actually used, only initialized.
> > 
> > I also tried a mixed-head configuration and it seems to work fine, although you
> > mentioned it worked OK with DRI2 so that probably doesn't mean much until I can
> > resolve the above.
> > 
> > Thanks,
> > Alex
> > 
> > On Fri, 29 Apr 2016, Alex Goins wrote:
> > 
> > > > Okay I've finally gotten around to playing with these today.
> > > 
> > > Thanks!!
> > > 
> > > > I'm using a i915 + nouveau system with nouveau running as the master. Both
> > > > using modesetting DDX.
> > > > 
> > > > The basics seem to work okay, but I am seeing some issues I'm not 100% sure
> > > > are the fault of these patches.
> > > > 
> > > > Scenario 1:
> > > > start X, start mutter against X (using DRI3), start gnome-terminal,
> > > > drag g-t around
> > > > seems smooth.
> > > > set provider output, xrandr in a new display, drag g-t around, I get
> > > > choppy rendering
> > > > on the main display, the offloaded display is smooth!
> > > > 
> > > > I don't think this happens with DRI2 mutter, so I'm not 100% sure what
> > > > is going on there,
> > > > I assume it's something to do with page flipping not being allowed for
> > > > present anymore.
> > > 
> > > My test machine at the time I sent these out was an Optimus laptop, so I don't
> > > think I have tried mixed native and offloaded displays with modesetting source
> > > except once briefly the other day. I have a desktop machine with offloading
> > > capabilities now, so I'll try that more in depth.
> > > 
> > > > Scenario 2:
> > > > start X, set provider output, xrandr in a new display, start mutter in
> > > > DRI3 mode, things
> > > > go horribly wrong. Again it seems fine in DRI2 mode. so I expect this
> > > > is some interaction
> > > > with the present extension fighting this.
> > > > 
> > > > I'm going to try and look at the interfaces a bit more now that I have
> > > > it running on a machine.
> > > > 
> > > > Dave.
> > > 
> > > That does sound like there is some interaction between DRI3 and these patches.
> > > I'll see if I can reproduce it.
> > > 
> > > Thanks,
> > > Alex
> > > 
> > 
>