On Tue, Oct 28, 2014 at 06:39:27PM +0530, akash.goel@xxxxxxxxx wrote: > From: Akash Goel <akash.goel@xxxxxxxxx> > > 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) > > Signed-off-by: Akash Goel <akash.goel@xxxxxxxxx> > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> I'm still not super convinced by the full copy and paste of the function where all I can see changing is the pointer storing the virtual address and the flags. Something I'm missing? What do others think (I'm not the maintainer of anything in libdrm). -- Damien _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
