All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Gordon <david.s.gordon@intel.com>
To: intel-gfx@lists.freedesktop.org
Subject: [PATCH 2/3] drm/i915: mark GEM objects as dirty when updated by the CPU
Date: Tue,  8 Dec 2015 16:51:17 +0000	[thread overview]
Message-ID: <1449593478-33649-3-git-send-email-david.s.gordon@intel.com> (raw)
In-Reply-To: <1449593478-33649-1-git-send-email-david.s.gordon@intel.com>

In various places, one or more pages of a GEM object are mapped into CPU
address space and updated. In each such case, either the page or the the
object should be marked dirty, to ensure that the modifications are not
discarded if the object is evicted under memory pressure.

Ideally, we would like to mark only the updated pages dirty; but it
isn't clear at this point whether this will work for all types of GEM
objects (regular/gtt, phys, stolen, userptr, dmabuf, ...). So for now,
let's ensure correctness by marking the whole object dirty.

Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c   | 2 ++
 drivers/gpu/drm/i915/i915_gem_render_state.c | 1 +
 drivers/gpu/drm/i915/i915_guc_submission.c   | 1 +
 drivers/gpu/drm/i915/intel_lrc.c             | 6 +++++-
 4 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index a4c243c..bc28a10 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -281,6 +281,7 @@ relocate_entry_cpu(struct drm_i915_gem_object *obj,
 	}
 
 	kunmap_atomic(vaddr);
+	obj->dirty = 1;
 
 	return 0;
 }
@@ -372,6 +373,7 @@ relocate_entry_clflush(struct drm_i915_gem_object *obj,
 	}
 
 	kunmap_atomic(vaddr);
+	obj->dirty = 1;
 
 	return 0;
 }
diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c b/drivers/gpu/drm/i915/i915_gem_render_state.c
index 5026a62..dd1976c 100644
--- a/drivers/gpu/drm/i915/i915_gem_render_state.c
+++ b/drivers/gpu/drm/i915/i915_gem_render_state.c
@@ -144,6 +144,7 @@ static int render_state_setup(struct render_state *so)
 	so->aux_batch_size = ALIGN(so->aux_batch_size, 8);
 
 	kunmap(page);
+	so->obj->dirty = 1;
 
 	ret = i915_gem_object_set_to_gtt_domain(so->obj, false);
 	if (ret)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c
index 0d23785b..c0e58f8 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -574,6 +574,7 @@ static void lr_context_update(struct drm_i915_gem_request *rq)
 	reg_state[CTX_RING_BUFFER_START+1] = i915_gem_obj_ggtt_offset(rb_obj);
 
 	kunmap_atomic(reg_state);
+	ctx_obj->dirty = 1;
 }
 
 /**
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 4ebafab..bc77794 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -391,6 +391,7 @@ static int execlists_update_context(struct drm_i915_gem_request *rq)
 	}
 
 	kunmap_atomic(reg_state);
+	ctx_obj->dirty = 1;
 
 	return 0;
 }
@@ -1030,7 +1031,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)
@@ -1461,6 +1462,8 @@ static int intel_init_workaround_bb(struct intel_engine_cs *ring)
 
 out:
 	kunmap_atomic(batch);
+	wa_ctx->obj->dirty = 1;
+
 	if (ret)
 		lrc_destroy_wa_ctx_obj(ring);
 
@@ -2536,6 +2539,7 @@ void intel_lr_context_reset(struct drm_device *dev,
 		reg_state[CTX_RING_TAIL+1] = 0;
 
 		kunmap_atomic(reg_state);
+		ctx_obj->dirty = 1;
 
 		ringbuf->head = 0;
 		ringbuf->tail = 0;
-- 
1.9.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2015-12-08 16:51 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-08 16:51 [PATCH 0/3] drm/i915: mark GEM objects as dirtied by CPU Dave Gordon
2015-12-08 16:51 ` [PATCH 1/3] drm/i915: mark GEM objects as dirty when filled by the CPU Dave Gordon
2015-12-08 17:00   ` Chris Wilson
2015-12-08 18:06     ` Dave Gordon
2015-12-10 10:49       ` Daniel Vetter
2015-12-08 16:51 ` Dave Gordon [this message]
2015-12-08 17:00   ` [PATCH 2/3] drm/i915: mark GEM objects as dirty when updated " Chris Wilson
2015-12-08 18:43     ` Dave Gordon
2015-12-08 16:51 ` [PATCH 3/3] drm/i915: mark GEM objects as dirty when written " Dave Gordon
2015-12-08 17:03   ` Chris Wilson
2015-12-08 18:24     ` Dave Gordon
2015-12-10 13:10       ` Daniel Vetter
2015-12-09 15:52 ` [PATCH 0/2 v2] drm/i915: mark GEM objects as dirtied by CPU Dave Gordon
2015-12-09 15:52   ` [PATCH 1/2 v2] drm/i915: mark GEM object pages dirty when mapped & written by the CPU Dave Gordon
2015-12-10 13:29     ` Chris Wilson
2015-12-10 17:24       ` Dave Gordon
2015-12-10 21:04         ` Chris Wilson
2015-12-11 17:08           ` Daniel Vetter
2015-12-11 17:27             ` Chris Wilson
2015-12-09 15:52   ` [PATCH 2/2 v2] drm/i915: mark GEM objects dirty after overwriting their contents Dave Gordon
2015-12-10 13:22     ` Chris Wilson
2015-12-10 14:06     ` Daniel Vetter
2015-12-10 14:52       ` Chris Wilson
2015-12-11 17:09         ` Daniel Vetter
2015-12-10 16:19       ` Dave Gordon
2015-12-10 18:51   ` [PATCH 0/4 v3] drm/i915: mark GEM objects as dirtied by CPU Dave Gordon
2015-12-10 18:51     ` [PATCH 1/4 v3] drm/i915: mark GEM object pages dirty when mapped & written by the CPU Dave Gordon
2015-12-10 21:07       ` Chris Wilson
2015-12-10 18:51     ` [PATCH 2/4 v3] drm/i915: mark a newly-created GEM object dirty when filled with data Dave Gordon
2015-12-10 21:06       ` Chris Wilson
2015-12-11 17:21         ` Daniel Vetter
2015-12-10 18:51     ` [PATCH 3/4 v3] drm/i915: always mark the target of pwrite() as dirty Dave Gordon
2015-12-10 21:09       ` Chris Wilson
2015-12-10 18:51     ` [PATCH 4/4 v3] drm/i915: miscellaneous tiny tweaks to GEM object->dirty Dave Gordon
2015-12-10 21:16       ` Chris Wilson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1449593478-33649-3-git-send-email-david.s.gordon@intel.com \
    --to=david.s.gordon@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.