[Intel-gfx] [PATCH v5] intel: New libdrm interface to create unbound wc user mappings for objects

[Daniel Vetter]

On Mon, Mar 14, 2016 at 06:51:54PM +0200, Martin Peres wrote:
> On 10/03/16 10:39, Martin Peres wrote:
> >On 09/03/16 11:09, akash.goel at intel.com wrote:
> >>From: Akash Goel <akash.goel at intel.com>
> >>
> >>A new libdrm interface 'drm_intel_gem_bo_map_wc' is provided by this
> >>patch. Through this interface Gfx clients can create write combining
> >>virtual mappings of the Gem object. It will provide the same funtionality
> >>of 'mmap_gtt' interface without the constraints of limited aperture
> >>space,
> >>but provided clients handles the linear to tile conversion on their own.
> >>This patch is intended for improving the CPU write operation performance,
> >>as with such mapping, writes are almost 50% faster than with mmap_gtt.
> >>Also it avoids the Cache flush after update from CPU side, when object is
> >>passed on to GPU, which will be the case if regular mmap interface is
> >>used.
> >>This type of mapping is specially useful in case of sub-region
> >>update, i.e. when only a portion of the object is to be updated.
> >>Also there is a support for the unsynchronized version of this interface
> >>named 'drm_intel_gem_bo_map_wc_unsynchronized', through which wc virtual
> >>mappings, but unsynchronized one, can be created of the Gem object.
> >>To ensure the cache coherency, before using this mapping, the GTT
> >>domain has
> >>been reused here. This provides the required Cache flush if the object
> >>is in
> >>CPU domain or synchronization against the concurrent rendering
> >>
> >>The drm_i915_gem_mmap structure (for the DRM_I915_GEM_MMAP_IOCTL) has
> >>been
> >>extended with a new flags field (defaulting to 0 for existent users). In
> >>order for userspace to detect the extended ioctl, a new parameter
> >>I915_PARAM_HAS_EXT_MMAP has been added for versioning the ioctl
> >>interface.
> >>
> >>v2: Aligned with the v2 of the corresponding kernel patch (Chris)
> >>v3: Added the unmap calls for the wc mapping (Damien)
> >>     Added the param feature check before creating the wc mapping &
> >>reduced
> >>     the vma limit (Chris)
> >>v4: Removed the extraneous unlock call from map_wc function (Damien)
> >>v5: Rebased.
> >>
> >>Signed-off-by: Akash Goel <akash.goel at intel.com>
> >>Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> >>Reviewed-by: Damien Lespiau <damien.lespiau at intel.com>
> >
> >Chris, Damien,
> >
> >Do you still stand by your S-o-b and R-b? If so, I can push the patch in
> >the coming days.
> 
> Another ping, with both Chris and Damien CCed this time.

Not entirely sure, but we tended to not push libdrm patches if the open
source userspace wasn't there yet. That's why this one was hanging in the
air forever iirc.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch