On 29.04.2016 07:41, Dave Airlie wrote:> On 13 April 2016 at 14:17, Alex Goins <agoins at 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.
