On 29.04.2016 07:41, Dave Airlie wrote: > On 13 April 2016 at 14:17, Alex Goins <ago...@nvidia.com> wrote: >> Hello all, >> >> These patches change the xserver to support setting up PRIME with double >> buffering, and implement double buffered PRIME sink and source support in >> the modesetting driver. In addition to these changes, I've upstreamed a >> couple of patches to the i915 DRM driver that mesh with these, and have >> implemented double buffered PRIME source support in the NVIDIA proprietary >> driver (pending release.) >> >> Previous cover letters: >> v4: https://lists.x.org/archives/xorg-devel/2016-March/048944.html >> v3: http://lists.x.org/archives/xorg-devel/2016-February/048677.html >> v2: http://lists.x.org/archives/xorg-devel/2016-January/048434.html >> v1: http://lists.x.org/archives/xorg-devel/2015-November/048039.html >> >> I wasn't able to get any of my questions answered in the last thread, so I >> addressed the issues how I saw fit. Aside from some small tweaks, the biggest >> changes in this patch set involve resolving the ambiguity with >> rrSetScanoutPixmap(). Instead of using multiple calls to >> rrSetScanoutPixmap() to >> setup scanout pixmaps for flipping, the scanout pixmap setting is done >> implicitly in rrEnableSharedPixmapFlipping(). >> >> There are two new patches that fix outstanding bugs with >> drmmode_set_scanout_pixmap(), with details in their respective commit >> messages: >> modesetting: Internal storage of scanout pixmaps >> modesetting: Always tear down scanout pixmap >> >> Getting RRReplaceScanoutPixmap() working with synchronization would require >> an >> ABI change to pass in two pixmaps instead of one, so I just made it fail >> gracefully in the synchronized case. None of the drivers that I implemented >> PRIME synchronization for seem to use RRReplaceScanoutPixmap(). In fact, I >> believe it is currently broken with the modesetting driver without the above >> 2 >> patches. > > Okay I've finally gotten around to playing with these today. 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. > > 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. >
Generally speaking nouveau/DRI3 -is- half-broken, talk to Skeggs and try to solve it once and for all. _______________________________________________ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau