[Intel-gfx] [PATCH 0/4] xf86-video-intel DRI3 and Present patch series

[Chris Wilson]

On Wed, Nov 20, 2013 at 12:53:33PM -0800, Keith Packard wrote:
> Here's a series of patches which provide DRI3 and Present support in
> the Intel 2D driver. The first two patches pave the way by
> synthesizing 64-bit vblank counters and extending the DRM event
> handling to allow for both DRI2 and DRI3 events. Then there's a patch
> to add DRI2 and miSyncShm support followed by a patch to add Present
> support.
> 
>  [PATCH 1/4] Support 64-bit MSC values. Handle kernel vageries about

Some spurious assignments that appear to intentially drop the error code
could be clarified, and intel_crtc_msc_to_sequence() is always called
with a derived current_msc already to hand. The latter present path
obfuscates its derived current_msc.

>  [PATCH 2/4] Restructure DRM event handling.

This won't compile against older Xorg due to xorg_list in the common
code.

>  [PATCH 3/4] Add DRI3 and miSyncShm support

O_CLOEXEC needs protecting, also would appear to be candidate for a
render-node. The imported and exported DRI3 pixmaps need to be pinned
to prevent the driver using BO exchanges on that pixmap.  DRI3 doesn't
respect the xorg.conf Option for disabling.  A fence is only tied to a
screen and no XID or Client in particular? So it is a global operation
akin to intel_flush_callback() which would be called before the Sync
reply was sent.

>  [PATCH 4/4] Add Present extension support

Yikes. The patch is itself fairly innoculous, but only because the Present
extension in the server appears to be repeating the worst of DRI2,
including its original bugs. The fallback/non-fullscreen case is not
synchronised to screen refresh (if the Client so desired), and should
be passed through to the driver.  The whole driver interface seems to be
too low a level, baking in many assumptions, rather the usual approach of
providing a set of mi routines that the driver can plug into or not as the
case may be. That the WindowPixmap no longer points to the actual bo leads
to a few problems, such as the CRTC misconfiguration and GetImage being
broken after a PresentFlip. After a vblank_event, Present must check that
the flip is still valid before execution. In the backend it is not clear
whether the RRCrtc should be the primary CRTC or the only CRTC to flip.
Damage is processed after the fallback but not the Flip path, the lack
of Damage notification would upset Prime amongst others.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre