From patchwork Thu Dec 10 18:51:26 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dave Gordon X-Patchwork-Id: 7821491 Return-Path: X-Original-To: patchwork-intel-gfx@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 8322D9F387 for ; Thu, 10 Dec 2015 18:51:44 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id A3D8C205D3 for ; Thu, 10 Dec 2015 18:51:43 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id B99D3205CD for ; Thu, 10 Dec 2015 18:51:42 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 42C617A1DB; Thu, 10 Dec 2015 10:51:42 -0800 (PST) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by gabe.freedesktop.org (Postfix) with ESMTP id EFBFE7A1DB for ; Thu, 10 Dec 2015 10:51:40 -0800 (PST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101.jf.intel.com with ESMTP; 10 Dec 2015 10:51:40 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,409,1444719600"; d="scan'208";a="858285433" Received: from dsgordon-linux2.isw.intel.com ([10.102.226.88]) by fmsmga001.fm.intel.com with ESMTP; 10 Dec 2015 10:51:39 -0800 From: Dave Gordon To: intel-gfx@lists.freedesktop.org Date: Thu, 10 Dec 2015 18:51:26 +0000 Message-Id: <1449773486-30822-5-git-send-email-david.s.gordon@intel.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1449773486-30822-1-git-send-email-david.s.gordon@intel.com> References: <1449773486-30822-1-git-send-email-david.s.gordon@intel.com> Organization: Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ Subject: [Intel-gfx] [PATCH 4/4 v3] drm/i915: miscellaneous tiny tweaks to GEM object->dirty X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP This patch covers a couple more places where a GEM object is (or may be) modified by means of CPU writes, and should therefore be marked dirty to ensure that the changes are not lost in the event that the object is evicted under memory pressure. One is in i915_gem_begin_cpu_access(); after this call, the GEM object may be written to by the caller (which may not be part of the i915 driver e.g. udl). We must therefore assume that the object is dirty hereafter if the caller has asked for write access. Another is in copy_batch(); the destination object is obviously dirty after being written, but failing to mark it doesn't cause a bug at present, because the object is page-pinned at this point, and should remain either page- pinned or GTT-pinned until it's retired, at which point its content can be discarded. However, if the lifecycle of shadow batches is ever changed (e.g. by the introduction of a GPU scheduler) this might no longer be true, so it's safer to mark it correctly (this introduces no overhead if the buffer is never swappable). It also makes the content cycle clearer: ---allocate--> [empty buffer acquired from pool] ---fill--> [valid buffer full of unsaved data] ---use--> [buffer full of unsaved but unwanted data] --retire--> [purgeable buffer returned to pool] ... repeat ... The last change here is just for consistency; since 'dirty' has been declared as an (unsigned int) bitfield, let's not treat it as a bool. Maybe it should be a byte instead? Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_cmd_parser.c | 3 +++ drivers/gpu/drm/i915/i915_gem_dmabuf.c | 3 +++ drivers/gpu/drm/i915/intel_lrc.c | 2 +- 3 files changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c b/drivers/gpu/drm/i915/i915_cmd_parser.c index 814d894..81a4fa2 100644 --- a/drivers/gpu/drm/i915/i915_cmd_parser.c +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c @@ -946,6 +946,9 @@ static u32 *copy_batch(struct drm_i915_gem_object *dest_obj, memcpy(dst, src, batch_len); + /* After writing on the dest_obj, its backing store is out-of-date */ + dest_obj->dirty = 1; + unmap_src: vunmap(src_base); unpin_src: diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/i915_gem_dmabuf.c index e9c2bfd..5eb7887 100644 --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c @@ -208,6 +208,9 @@ static int i915_gem_begin_cpu_access(struct dma_buf *dma_buf, size_t start, size return ret; ret = i915_gem_object_set_to_cpu_domain(obj, write); + if (write) + obj->dirty = 1; + mutex_unlock(&dev->struct_mutex); return ret; } diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index ceccecc..c7520b7 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1030,7 +1030,7 @@ static int intel_lr_context_do_pin(struct intel_engine_cs *ring, if (ret) goto unpin_ctx_obj; - ctx_obj->dirty = true; + ctx_obj->dirty = 1; /* Invalidate GuC TLB. */ if (i915.enable_guc_submission)