[Nouveau] [PATCH v5 00/13] PRIME Synchronization

[poma]

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.