On 08/12/15 17:00, Chris Wilson wrote:
On Tue, Dec 08, 2015 at 04:51:16PM +0000, Dave Gordon wrote:
In various places, a GEM object is filled with data by means of CPU
writes. In such cases, the object should be marked dirty, to ensure that
the data is not discarded if the object is evicted under memory
pressure.
This incorporates and supercedes Alex Dai's earlier patch
[PATCH v1] drm/i915/guc: Fix a fw content lost issue after it is evicted
Signed-off-by: Dave Gordon <david.s.gordon@xxxxxxxxx>
Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
Cc: Alex Dai <yu.dai@xxxxxxxxx>
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 1 +
drivers/gpu/drm/i915/i915_gem.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 814d894..292bd5d 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -945,6 +945,7 @@ static u32 *copy_batch(struct drm_i915_gem_object *dest_obj,
drm_clflush_virt_range(src, batch_len);
memcpy(dst, src, batch_len);
+ dest_obj->dirty = 1;
There is no bug here.
-Chris
Because the shadow batch has been page-pinned by the caller? Two
questions, then:
1. Do we reuse the same shadow batch if the same source batch is
resubmitted? If so, can we be sure that it has stayed pinned
(one way or another) for the entire intervening period?
2. If the shadow batch can never be unpinned, why do we allocate
it as a GEM object with backing store which can apparently
never be used. We could get rid of the shmfs setup overhead by
choosing an object type without backing store.
.Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
