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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
